summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* mx53loco: Call PMIC related functions from board_late_init()Fabio Estevam2012-12-27-2/+9
| | | | | | | | | | | | | | | | | | | | | | | Since commit c733681 (pmic: Extend PMIC framework to support multiple instances of PMIC devices) mx53loco fails to allocate the memory for PMIC: U-Boot 2013.01-rc2-dirty (Dec 20 2012 - 15:55:01) Board: MX53 LOCO I2C: ready DRAM: 1 GiB pmic_alloc: No available memory for allocation! pmic_init: POWER allocation error! CPU: Freescale i.MX53 family rev2.0 at 800 MHz Reset cause: POR MMC: FSL_SDHC: 0, FSL_SDHC: 1 Calling the PMIC related functions at a later stage, ie, from board_late_init() fixes the issue. Reported-by: Robert Nelson <robertcnelson@gmail.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Tested-by: Stefano Babic <sbabic@denx.de>
* mx6qsabre_common: Change default loadaddr to 0x12000000Otavio Salvador2012-12-26-1/+1
| | | | | | | This allow use of mainline and Freescale BSP Linux kernel with same environment. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
* mx6qsabrelite: Change default loadaddr to 0x12000000Otavio Salvador2012-12-26-1/+1
| | | | | | | This allow use of mainline and Freescale BSP Linux kernel with same environment. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
* mx53loco: Change default loadaddr to 0x72000000Otavio Salvador2012-12-26-1/+1
| | | | | | | This allow use of mainline and Freescale BSP Linux kernel with same environment. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
* mx53loco: We shouldn't hardcode a rootfs filesystem typeOtavio Salvador2012-12-26-5/+2
| | | | | | | For a generic environment, we shouldn't have a fixed rootfs filesystem so we drop it from env. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
* mx35pdk: Allow booting of a device tree kernelFabio Estevam2012-12-26-0/+1
| | | | | | Select CONFIG_OF_LIBFDT, so that a dt kernel can be launched. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx25pdk: Allow booting a device tree kernelFabio Estevam2012-12-13-0/+1
| | | | | | Select CONFIG_OF_LIBFDT so that a device tree kernel can be launched. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* mx53loco: Fix PMIC nameFabio Estevam2012-12-13-1/+1
| | | | | | | | | commit c73368150 (pmic: Extend PMIC framework to support multiple instances of PMIC devices) has incorrectly passed the PMIC name under the FSL PMIC case. Fix that by passing "FSL_PMIC" as the parameter of pmic_get. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
* woodburn: Set gpio value in gpio_direction_output()Fabio Estevam2012-12-11-2/+1
| | | | | | | | Set the gpio value in gpio_direction_output() instead of an extra gpio_set_value call. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Stefano Babic <sbabic@denx.de>
* mx25pdk: Adapt it for the new PMIC frameworkFabio Estevam2012-12-11-6/+13
| | | | | | | | Make the necessary adaptions for the new PMIC framework, so that mx25pdk can be built again. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Stefano Babic <sbabic@denx.de>
* Merge branch 'master' of git://git.denx.de/u-boot into masterStefano Babic2012-12-08-2509/+23900
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/power/power_fsl.c include/configs/mx35pdk.h include/configs/mx53loco.h include/configs/woodburn_common.h board/woodburn/woodburn.c These boards still use the old old PMIC framework, so they do not merge properly after the power framework was merged into mainline. Fix all conflicts and update woodburn to use Power Framework. Signed-off-by: Stefano Babic <sbabic@denx.de>
| * Merge branch 'master' of git://git.denx.de/u-boot-x86Tom Rini2012-12-07-128/+2347
| |\
| | * x86: Fix coreboot config to boot on ChromebookSimon Glass2012-12-06-14/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The config is current broken. It compiles but does not boot because IDE is enabled. Remove all IDE options, and enable SCSI instead. Also add a working boot command and Linux bootargs, and enable command line editing to make it easier to work with. Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Turn on support for EFI's GPT in the coreboot configGabe Black2012-12-06-0/+3
| | | | | | | | | | | | | | | | | | | | | This allows u-boot to figure out the partitions of a chrome-os install. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: coreboot: Enable video displaySimon Glass2012-12-06-2/+8
| | | | | | | | | | | | | | | | | | Enable the display on coreboot, using CFB. Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Build vga video code only if CONFIG_VIDEO_VGA is definedSimon Glass2012-12-06-2/+9
| | | | | | | | | | | | | | | | | | | | | When running from coreboot we don't want this code, so make it optional. Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Remove video_init() prototype from u-boot-x86.hSimon Glass2012-12-06-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This function is not intended to be exported from the video drivers, so remove the prototype. This fixes an error: cfb_console.c:1793:12: error: static declaration of 'video_init' follows non-static declaration Signed-off-by: Simon Glass <sjg@chromium.org>
| | * video: Check for valid FB pointer before clearingDuncan Laurie2012-12-06-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This command will start erasing at memory address zero if there is not a valid framebuffer address that was found during video_init(). This is a common case with Chrome OS devices in normal mode when we do not execute the video option rom in coreboot. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: drop unused code in coreboot.cStefan Reinauer2012-12-06-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function setup_pcat_compatibility() is weak and implemented as empty function in board.c hence we don't have to override that with another empty function. monitor_flash_len is unused, drop it. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Remove coreboot_ from file nameStefan Reinauer2012-12-06-2/+1
| | | | | | | | | | | | | | | | | | | | | ... because that information is already "encoded" in the directory name. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Provide a way to throttle port80 accessesVadim Bendebury2012-12-06-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some systems (like Google Link device) provide the ability to keep a history of the target CPU port80 accesses, which is extremely handy for debugging. The problem is that the EC handling port 80 access is orders of magnitude slower than the AP. This causes random loss of trace data. This change allows to throttle port 80 accesses such that in case the AP is trying to post faster than the EC can handle, a delay is introduced to make sure that the post rate is throttled. Experiments have shown that on Link the delay should be at least 350,000 of tsc clocks. Throttling is not being enabled by default: to enable it one would have to set MIN_PORT80_KCLOCKS_DELAY to something like 400 and rebuild the u-boot image. With upcoming EC code optimizations this number could be decreased (new new value should be established experimentally). Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Provide tick counter and frequency reference for Intel core architectureVadim Bendebury2012-12-06-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some u-boot modules rely on availability of get_ticks() and get_tbclk() functions, reporting a free running clock and its frequency respectively. Traditionally these functions return number and frequency of timer interrupts. Intel's core architecture processors however are known to run the rdtsc instruction at a constant rate of the so called 'Max Non Turbo ratio' times the external clock frequency which is 100MHz. This is just as good for the timer tick functions in question. Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Issue SMI to finalize Coreboot in final stageDuncan Laurie2012-12-06-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This will write magic value to APMC command port which will trigger an SMI and cause coreboot to lock down the ME, chipset, and CPU. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Fix MTRR clear to detect which MTRR to useDuncan Laurie2012-12-06-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Coreboot was always using MTRR 7 for the write-protect cache entry that covers the ROM and U-boot was removing it. However with 4GB configs we need more MTRRs for the BIOS and so the WP MTRR needs to move. Instead coreboot will always use the last available MTRR that is normally set aside for OS use and U-boot can clear it before the OS. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Emit port 80 post codes in show_boot_progress()Stefan Reinauer2012-12-06-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | This helps us monitor boot progress and determine where U-Boot dies if there are any problems. Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: fdt: Create basic .dtsi file for corebootSimon Glass2012-12-06-12/+59
| | | | | | | | | | | | | | | | | | | | | | | | This contains just the minimum information for a coreboot-based board. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: coreboot: Set CONFIG_ARCH_DEVICE_TREE correctlyGabe Black2012-12-06-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | We will use coreboot.dtsi as our fdt include file. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Add support for CONFIG_OF_CONTROLGabe Black2012-12-06-0/+36
| | | | | | | | | | | | | | | | | | | | | Allow a device tree to be provided through the standard mechanisms. Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Add CONFIG_DELAY_ENVIRONMENT to delay environment loadingStefan Reinauer2012-12-06-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This option delays loading of the environment until later, so that only the default environment will be available to U-Boot. This can address the security risk of untrusted data being used during boot. When CONFIG_DELAY_ENVIRONMENT is defined, it is convenient to have a run-time way of enabling loadinlg of the environment. Add this to the fdt as /config/delay-environment. Note: This patch depends on http://patchwork.ozlabs.org/patch/194342/ Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
| | * x86: Add back cold- and warm-boot flagsGabe Black2012-12-06-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These were removed, but actually are useful. Cold means that we started from a reset/power on. Warm means that we started from another U-Boot. We determine whether u-boot on x86 was warm or cold booted (really if it started at the beginning of the text segment or at the ELF entry point). We plumb the result through to the global data structure. Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Override calculate_relocation_address to use the e820 mapGabe Black2012-12-06-7/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because calculate_relocation_address now uses the e820 map, it will be able to avoid addresses over 32 bits and regions that are at high addresses but not big enough for U-Boot. It also means we can remove the hack which limitted U-Boot's idea of the size of memory to less than 4GB. Also take into account the space needed for the heap and stack, so we avoid picking a very small region those areas might overlap with something it shouldn't. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Make calculate_relocation_address an overridable functionGabe Black2012-12-06-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Different systems may have different mechanisms for picking a suitable place to relocate U-Boot to. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Make the upper bound on relocated symbols closed instead of openGabe Black2012-12-06-1/+1
| | | | | | | | | | | | | | | | | | This seems to be a bug. Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Reorder x86's post relocation memory layoutGabe Black2012-12-06-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the layout in decreasing addresses from: 1. Stack 2. Sections in the image 3. Heap to 1. Sections in the image 2. Heap 3. Stack This allows the stack to grow significantly more since it isn't constrained by the other u-boot areas. More importantly, the generic memory wipe code assumes that the stack is the lowest addressed area used by the main part of u-boot. In the original layout, that means that u-boot tramples all over itself. In the new layout, it works. Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Initialise SPI if enabledGabe Black2012-12-06-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | If we have SPI support, make sure that we init it. Signed-off-by: Gabe Black <gabeblack@google.com> Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Vic Yang <victoryang@chromium.org>
| | * x86: Implement arch_phys_memset so that it can wipe memory above 4GBGabe Black2012-12-06-0/+229
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement arch_phys_memset so that it can set memory at physical addresses above 4GB using PAE paging. Because there are only 5 page tables in PAE mode, 1 PDPT and 4 PDTs, those tables are statically allocated in the BSS. The tables must be 4K page aligned and are declared that way, and because U-Boot starts as 4K aligned and the relocation code relocates it to a 4K aligned address, the tables work as intended. While paging is turned on, all 4GB are identity mapped except for one 2MB page which is used as the window into high memory. This way, U-Boot will continue to work as expected when running code that expects to access memory freely, but the code can still get at high memory through its window. The window is put at 2MB so that it's 2MB page aligned, low in memory to be out of the way of things U-Boot is likely to care about, and above the lowest 1MB where lots of random things live. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * Introduce arch_phys_memset which works like memset but on physical memoryGabe Black2012-12-06-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default implementation of this function is just memset, but other implementations will be needed when physical memory isn't accessible by U-Boot using normal addressing mechanisms. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Che-Liang Chiou <clchiou@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Increase the size of the phys_size_t and phys_addr_t typesGabe Black2012-12-06-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | These types should be 64 bits long to reflect the fact that physical addresses and the size of physical areas of memory are more than 32 bits long. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Fix off-by-one error in do_elf_reloc_fixups()Duncan Laurie2012-12-06-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The use of post-increment with a do-while loop results in the loop going one step too far when handling relocation fixups. In about 1/100 cases this would cause it to hang. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Ignore memory >4GB when parsing Coreboot tablesDuncan Laurie2012-12-06-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | U-boot is unable to actually use that memory and it can cause problems with relocation if it tries to. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Enable CONFIG_CMD_ZBOOT for corebootSimon Glass2012-12-06-0/+3
| | | | | | | | | | | | | | | | | | Enable this option to support booting a zImage. Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Fix indirect jmp warning in zimage.cSimon Glass2012-12-06-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the following warning: zimage.c:312: Warning: indirect jmp without `*' Also fixed these warnings to keep checkpatch quiet: warning: arch/x86/lib/zimage.c,311: unnecessary whitespace before a quoted newline warning: arch/x86/lib/zimage.c,312: unnecessary whitespace before a quoted newline warning: arch/x86/lib/zimage.c,313: unnecessary whitespace before a quoted newline Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Clean up MTRR 7 right before jumping to the kernelStefan Reinauer2012-12-06-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | This cleans up the rom caching optimization implemented in coreboot (and needed throughout U-Boot runtime). Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Import MSR/MTRR code from LinuxGraeme Russ2012-12-06-0/+913
| | | | | | | | | | | | | | | | | | Imported from Linux 3.1 with a few modifications to suit U-Boot Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Provide a function to clean up just before booting a zimageStefan Reinauer2012-12-06-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | This function can be used by boards which want to do some clean-up before booting a zImage. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Add basic cache operationsStefan Reinauer2012-12-06-72/+155
| | | | | | | | | | | | | | | | | | | | | Add functions to enable/disable the data cache. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Fill in the dram info using the e820 map on coreboot/x86Gabe Black2012-12-06-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This way when that dram "banks" are displayed, there's some useful information there. The number of "banks" we claim to have needs to be adjusted so that it covers the number of RAM e820 regions we expect to have/care about. This needs to be done after "RAM" initialization even though we always run from RAM. The bd pointer in the global data structure doesn't automatically point to anything, and it isn't set up until "RAM" is available since, I assume, it would take too much space in the very constrained pre-RAM environment. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Add a CBMEM timestamp generated right before the kernel startup.Vadim Bendebury2012-12-06-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To maintain the initialization state of the timestamp facility, thesq pointer to the CBMEM section containing the timestamp table should be kept in the .data section (so that it is maintained across u-boot relocation). Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Enable coreboot timestamp facility support in u-boot.Vadim Bendebury2012-12-06-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change turns on the code which allows u-boot to add timestamps to the timestamp table created by coreboot. Since u-boot does not use the tsc_t like structure to represent HW counter readings, this structure is being replaced by 64 bit integer. The timestamp_init() function is now initializing the base timer value used by u-boot to calculate the HW counter increments. Timestamp facility is initialized as soon as the timestamp table pointer is found in the coreboot table. The u-boot generated timer events' ID will start at 1000 to clearly separate u-boot events from coreboot events in the timer trace. Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
| | * x86: Add function to read time stamp counterVadim Bendebury2012-12-06-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Put this function in the u-boot-x86.h header file. We could instead create timer.h perhaps. We support setting a base time, and reading the time relative to this base. Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-10-15 03:29:55 +0000