summaryrefslogtreecommitdiff
path: root/common
AgeCommit message (Collapse)Author
2011-11-30fdt: Add function to read a clock rate from fdtSimon Glass
This reads the frequency of a named clock from the fdt. BUG=chromium-os:23496 TEST=build and boot on Seaboard, T33, Kaen Change-Id: Ib35bf7ef749f51862644218b1015057ca4e25203 Reviewed-on: https://gerrit.chromium.org/gerrit/12243 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Commit-Ready: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-11-29fdt: uart: fix uart clock freq override; broke x86 uartTom Warren
CONFIG_SYS_PLLP_BASE_IS_408MHZ is meant only for T30 builds. Don't override to 216MHZ if not Tegra3 && not 408MHZ BUG=chromium-os:23521 TEST=built Seaboard, Waluigi and tested Waluigi. x86 build in queue. Signed-off-by: Tom Warren <twarren@nvidia.com> Change-Id: If9517c473e76b8a1a49c6ff81891946cdb263a44 Reviewed-on: https://gerrit.chromium.org/gerrit/12219 Commit-Ready: Doug Anderson <dianders@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2011-11-18Fix bug introduced by hardware-mapped SPISimon Glass
This was missed at the time. BUG=chrome-os-partner:6585, chromium-os:22528 TEST=build and boot on Kaen, see that it doesn't cold reboot now Change-Id: Ied4f08a5078312dbee4ae4b0715e5c02d55f159a Reviewed-on: https://gerrit.chromium.org/gerrit/11879 Commit-Ready: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2011-11-18Tidy up fdt_decode_alloc_region() to make alloc separateSimon Glass
Move the malloc() out of fdt_decode_alloc_region() and rename it accordingly. This makes the code somewhat cleaner and allows us to print a sensible error message. BUG=chromium-os:17062 TEST=build and boot on Kaen Change-Id: I8edc8809baa42578e74c5e42cf47494b31b774e7 Reviewed-on: https://gerrit.chromium.org/gerrit/11878 Commit-Ready: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-11-18arm: Tegra3: complete 408MHz PLLP initTom Warren
Signed-off-by: Tom Warren <twarren@nvidia.com> BUG=chromium-os:21033 TEST=Built and booted OK on my Waluigi. UART is OK, mmc, spi, i2c OK. Note that this is only valid with CONFIG_SYS_PLLP_BASE_IS_408MHZ. No affect on Tegra2. Seaboard builds fine, BTW. Change-Id: I05a367afd1e78a2170d7308a658ce64017850ca0 Reviewed-on: https://gerrit.chromium.org/gerrit/11811 Tested-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
2011-11-17UPSTREAM: net: tftpput: add tftpput commandSimon Glass
This adds the tftpput command to U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> (cherry picked from commit 2d46cf291eae29a42bb5ca3d280d2b136339686b) Change-Id: I7d0dc1fd78d9269ed932899cb1c301771ee24fbf Reviewed-on: https://gerrit.chromium.org/gerrit/11802 Commit-Ready: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-11-17UPSTREAM: tftpput: add save_addr and save_size global variablesSimon Glass
We need something akin to load_addr to handle saving data. Signed-off-by: Simon Glass <sjg@chromium.org> (cherry picked from commit 1aec244acf9daf0d4dad80fe86b2c2b7404251d6) Change-Id: I56c586abb3e075f0ab422c833637a3160d7e2a5f Reviewed-on: https://gerrit.chromium.org/gerrit/11800 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-11-17BACKPORT: net: tftpput: Rename TFTP to TFTPGETSimon Glass
This is a better name for this protocol. Also remove the typedef to keep checkpatch happy, and move zeroing of NetBootFileXferSize a little earlier since TFTPPUT will need to change this. (cherry-picked from e4bf0c5) Change-Id: I90d03045de0231553a693f7119bdcc67a908e3c9 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/11796
2011-11-16BACKPORT: Add setenv_ulong() and setenv_addr()Simon Glass
It seems we put numbers and addresses into environment variables a lot. We should have some functions to do this. (cherry picked from commit d67f10c) Change-Id: I922e72a7db872f26774459a6dc074a80016ef904 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/11792 Reviewed-by: Doug Anderson <dianders@chromium.org>
2011-11-16UPSTREAM: Move simple_itoa to vsprintfSimon Glass
This function is generally useful and shouldn't hide away in hush. It has been moved as is. Signed-off-by: Simon Glass <sjg@chromium.org> (cherry picked from commit 3cce8a5496452285e1828984ad3945417205cfc3) Change-Id: I014f58e901e6b035b5eeb694c62e6e881a7b75c2 Reviewed-on: https://gerrit.chromium.org/gerrit/11791 Reviewed-by: Doug Anderson <dianders@chromium.org> Commit-Ready: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-11-04Introduce ability to use hardware SPI mapping for read accesses.Vadim Bendebury
On X86 systems the hardware maps the bootprom SPI flash chip into the top of memory address range. This could be used for accessing all information in the SPI flash. The vboot-reference code requires access to FMAP sections containing cryptographic information, and as of today, u-boot reads the whole sections, which are 64 KB in size, even though the actual areas accessed by vboot-reference are much smaller. A much faster way of accessing this information would be just passing around pointers to the appropriate memory areas. This would eliminate one copy, and also would make sure that only the areas actually accessed get fetched from SPI flash. This patch provides this ability trying to keep code changes to a minimum. New feature is enabled by defining CONFIG_HARDWARE_MAPPED_SPI. The firmware storage API for file reads changes when the new configuration option is set: a pointer to pointer to buffer is passed to the read_spi() function instead of a pointer to buffer. When the new feature is enabled the read_spi() function sets the pointer value to point to the requested data instead of copying the data into the buffer. A new data type is introduced (read_buf_type), which is set to be a (void *) if the new feature is not enabled, or (void **) otherwise. This type is used as the buffer pointer in the spi_read() function. Code allocating/freeing buffers used to keep data read from SPI flash is now conditionally compiled. Call sites for the spi_read() function are modified to adjust the buffer pointer parameter (pass the address of the parameter instead of the parameter, when the new feature is enabled). gbb field access functions can be aliased to gbb_init(), as they all in fact do the same - read a certain section of the gbb area. This change does not benefit the ARM implementations, and makes the code more complicated that it should be. Some u-boot rearchitecture along with vboot_reference API enhancements could address this. A tracking issue (http://code.google.com/p/chromium-os/issues/detail?id=22528) has been opened for that. BUG=chrome-os-partner:6585, chromium-os:22528 TEST=manual . build a new stumpy firmware image . boot the stumpy, observe it start up chromeos. . assess the boot timing using the cbmem.py utility (this modification shaves in excess of 100ms off the boot time). . disable the new feature, build a stumpy image, observe that is still boots chromeOs. . run emerge-terga2_kaen chromeos-u-boot to confirem that ARM version builds cleanly. Change-Id: I4e6ab530d24f5771b5a86a48d3f3135101b469a6 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/11152
2011-10-28mmc: tegra: Rename tegra2_mmc to tegra_mmc in prep for tegra3Doug Anderson
BUG=chromium-os:21540 TEST=Built u-boot and booted u-boot on tegra2_kaen Change-Id: Id6f11512ea1a95bd57b600601b488ae20b34db2d Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/10808 Reviewed-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-10-19CHROMIUM: tegra3: i2c: Move DVC semantics choice to device treeDoug Anderson
On the tegra30, it appears that the "DVC" i2c controller has been normalized and no longer requires special semantics for accessing it (it has also just been renamed to "i2c5"). This change makes it so that we don't pick DVC semantics based on the periperal ID, but instead allow the device tree to specify. BUG=chromium-os:21540 TEST=Compiled / booted on Kaen Change-Id: Idfd96d1193b5ac267c61416544c63cc03dab396d Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/10279 Reviewed-by: Simon Glass <sjg@chromium.org>
2011-10-19CHROMIUM: fdt: Use __func__ in print messages.Doug Anderson
This moves debug messages from manually including their own function name to using __func__ to get it. This is less error prone. As a result of this, some error messages are now fixed to list the proper function name. BUG=None TEST=Added '#define DEBUG 1' to this file and saw that several of the debugs messages seemed fine; no compiler warnings found. Change-Id: I548c3e2e8850ee558149b9879d2801c19fe21d63 Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/10339 Reviewed-by: Simon Glass <sjg@chromium.org>
2011-10-19Remove the workaround for F0000-100000 in x86's setup_arch_unused_memoryGabe Black
This region is now marked properly in the e820 table, so it doesn't need to be explicitly preserved by u-boot any more. BUG=None TEST=Built and booted on Stumpy. Verified that the i915 DRM driver was able to find the vbios tables, or at least didn't complain that it couldn't. Change-Id: I2d5953e00d302e68f076f9bdd77a5efbbb93a64a Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/10334 Reviewed-by: Simon Glass <sjg@chromium.org>
2011-10-17Vboot: Exclude kcrashmem from vboot's memory wipeKatie Roberts-Hoffman
Exclude kcrashmem from vboot unused memory wipe to allow for recovery of kernel crash dumps. If the kcrashmem size changes, then the corresponding fdt must be updated. BUG=chrome-os-partner:5168 TEST=Manually observed kcrash preserved Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org> Change-Id: Iecb2bd7f7df958125ed3cb3bf0b789602e314e7c Reviewed-on: http://gerrit.chromium.org/gerrit/8942 Reviewed-by: Simon Glass <sjg@chromium.org> Commit-Ready: Katie Roberts-Hoffman <katierh@chromium.org> Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
2011-10-14Extend the vboot_test memwipe to test the new memory wipe APIGabe Black
BUG=None TEST=Ran vboot_test memwipe on Stumpy and saw it pass. Change-Id: Ibac1d9ae10804b87b31127af2f60cb6d3dd565c7 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/10068 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com>
2011-10-14Implement wipe_unused_memory for x86Gabe Black
The implementation adds the e820 regions marked as RAM, removes the ones that aren't, manually removes an area that is incorrectly left out of the e820 map, and then uses the the protect_u_boot_memory function to protect the generic u-boot memory regions. BUG=chrome-os-partner:6194 BUG=chrome-os-partner:6195 TEST=Boot on Stumpy. Manually check the wipe areas reported during boot. Change-Id: Icaf7b9167282f9ab418d98491aa0493f020e287d Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/10007 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
2011-10-14Split wipe_unused_memory into arch specific and generic functionsGabe Black
This new organization will allow x86 to do things differently, and also avoid duplicating code. BUG=chrome-os-partner:6194 BUG=chrome-os-partner:6195 TEST=Built and booted on Stumpy and Kaen. Change-Id: Ifb47d08c2df9116a10f6090b15614828e3cba9e1 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/10005 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-10-13Make u-boot load the recovery key in developer modeGabe Black
The recovery key is needed to display recovery reason information when the tab key is pressed. If it's not loaded, the data in the in-memory copy of the GBB can be anything, and vboot may take a very long time to process a malformed key. This workaround, provided by clchiou, ensures that the recovery key is loaded when in developer mode so that when the tab key is pressed vboot doesn't get stuck. BUG=chrome-os-partner:6266 TEST=Booted into dev mode and pressed tab. Saw the recovery info and that the system didn't hang and could continue to boot once Ctrl+D was pressed. Change-Id: I2b85933d38d879a33d3ae369a8249a86af3e9caf Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/10008 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com>
2011-10-11Refactor the memory wipe infrastructure to better support x86Gabe Black
The memory wipe infrastructure in u-boot makes some assumptions about how memory is arranged that make it not quite fit with x86. Specifically, it assumes that there is a single region of memory, and with certain exceptions that's what should be wiped. In x86, specifically in the e820 map, there are multiple regions of RAM, possibly multiple regions to exclued from that that may completely, partially, or not overlap with the others, and then u-boot related regions. This is addressed by making the memory wipe infrastructure a little more generic. Now, areas can be added and subtracted arbitrarily, and will accumulate in the order they're encountered. In the x86 use case, we can add the e820 regions marked as RAM, subtract the areas marked as anything else, and subtract the u-boot related regions. Rather than tracking the actual regions of the address space, this implementation tracks the boundaries between the regions using a linked list. The code itself is short and relatively simple, and I tried to ensure that it was as clear as possible to make any memory (or other) bugs easier to see and fix. BUG=chrome-os-partner:6195 BUG=chrome-os-partner:6194 TEST=Built and booted on kaen using the A-A cable. Ran vboot_test memwipe, and a modified version that took advantage of the new API. Change-Id: I122fbf499ef473350afa27b612cb0e565366b1ad Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/9715 Reviewed-by: Simon Glass <sjg@chromium.org>
2011-10-10CHROMIUM: add scsi_write to SCSI driver.Hung-Te Lin
Verified boot requires writing to GPT attributes (success / tries), so we need to implement *_write. "scsi write" command is also added to console for testing. BUG=chrome-os-partner:6258 TEST=(1) Modified GPT to trigger VBOOT updating GPT, and verified GPT changed successfully (by firmware) after reboot (2) ext2load usb 1:1 10000000 /part2.bin # load kernel partition dump scsi write 10000000 5000 5000 # write into kernel partition in #2 Change-Id: I8027b6075cdabf8df81ea1ba620ca0dcd3d33232 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/8841 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com>
2011-10-07CHROMIUM: bootm: Avoid 256-byte overflow in fixup_silent_linux()Doug Anderson
This makes fixup_silent_linux() use malloc() to allocate its working space, meaning that our maximum kernel command line should only be limited by malloc(). Previously it was silently overflowing the stack. BUG=chromium-os:21313 TEST=Manual: 1. Built with: USE="-cros-debug" emerge-${BOARD} \ chromeos-u-boot \ chromeos-bootimage 2. Flashed with: cros_write_firmware --board=${BOARD} /build/${BOARD}/firmware/image.bin 3. Saw that I could boot. TEST=Manually copied unittest code (included in next checkin) to a C file and then ran it. All tests pass. Note that there is no automated way to run unittests like this in u-boot yet. Change-Id: I0b5fd0d4a3cd09b7545d676a201a11b4a9b7dada Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/8815 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
2011-10-06Revert "Add support for a bios-base device tree/flashmap setting"Gabe Black
This reverts commit 8e93aec313c2807704b14fbd21123a9ffc86a087. The bios-base setting has been deprecated. BUG=None TEST=Built and booted on Stumpy. Change-Id: I792761ac44763b06bf1d3abb4db8e9e1a3f113c5 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/8823 Reviewed-by: Stefan Reinauer <reinauer@google.com>
2011-10-05CHROMIUM: cosmetic: Fixup fixup_silent_linux() for checkpatch.Doug Anderson
BUG=None TEST=Compile u-boot. Change-Id: I696e6795d80fc93a37093fdf5274addeacbe2b6f Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/8814 Reviewed-by: Anton Staaf <robotboy@chromium.org>
2011-10-04console: Implement pre-console bufferGraeme Russ
Allow redirection of console output prior to console initialisation to a temporary buffer. To enable this functionality, the board (or arch) must define: - CONFIG_PRE_CONSOLE_BUFFER - Enable pre-console buffer - CONFIG_PRE_CON_BUF_ADDR - Base address of pre-console buffer - CONFIG_PRE_CON_BUF_SZ - Size of pre-console buffer (in bytes) The pre-console buffer will buffer the last CONFIG_PRE_CON_BUF_SZ bytes Any earlier characters are silently dropped. Signed-off-by: Graeme Russ <graeme.russ@gmail.com> Change-Id: I3c4caad276b9e981ebea0a0fb79d85ee3a3bcb7d Reviewed-on: http://gerrit.chromium.org/gerrit/8686 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-10-04console: Squelch pre-console output in console functionsGraeme Russ
There are some locations in the code which anticipate printf() being called before the console is ready by squelching printf() on gd->have_console. Move this squelching into printf(), vprintf(), puts() and putc(). Also make tstc() and getc() return 0 if console is not yet initialised Signed-off-by: Graeme Russ <graeme.russ@gmail.com> Change-Id: If62863017eaa48915b721675a5d520f9caa7e5e0 Reviewed-on: http://gerrit.chromium.org/gerrit/8685 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-10-04Add CBMEM console driver.Vadim Bendebury
This patch builds upon the recently introduced CBMEM console feature of coreboot. CBMEM console uses a memry area allocated by coreboot to store the console output. The memory area has a certain structure, which allows to determine where the buffer is, the buffer size and the location of the pointer in the buffer. This allows different phases of the firmware (rom based coreboot, ram based coreboot, u-boot after relocation with this change) to keep adding text to the same buffer. Note that this patch introduces a new console driver and adds the driver to the list of drivers to be used for console output, i.e. it engages only after u-boot relocates. Usiong CBMEM console for capturing the pre-relocation console output will be done under a separate change. BUG=chrome-os-partner:4200 TEST=manual . build the new firmware and program it on a stumpy . restart the machine . after it comes up to ChromeOS, run the cbmem.py utility (which is a part of the coreboot package). Observe u-boot console output in the log, starting with vvvvvvvvvvvvvvvvv SCSI: AHCI 0001.0300 32 slots 6 ports ? Gbps 0xf impl SATA mode flags: 64bit ilck stag led pmp pio ^^^^^^^^^^^^^^^^ and ending with vvvvvvvvvvvvvvvvv Magic signature found Kernel command line: "cros_secure quiet loglevel=1 console=tty2... ^^^^^^^^^^^^^^^^^ Note that the entire u-boot output fits into the buffer only if the coreboot log level is reduced from the most verbose. Ether the buffer size will have to be increased, or the coreboot verbosity permanently reduced. Change-Id: I399a90f3aeef9fae074db3e0842d876101c1a85e Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/8720 Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
2011-09-27CHROMIUM: ARM: tegra: asymptote: Fix Asymptote backlight vdd enable lineSean Paul
This line is a NC on Asymptote, but right now we're using the pwm line (incorrectly). This CL removes the backlight-vdd line from Asymptote dts and ensures that it's safely ignored if it's missing. BUG=None TEST=Built u-boot for Asymptote and flashed it on the device. Ensured that the backlight still works in u-boot. Change-Id: Id751b6756bac120e2211b7b32c58f356ff30b767 Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/8063 Reviewed-by: Jon Kliegman <kliegs@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-09-21Add some missing endian conversions in fdt_support.cGabe Black
Some functions in fdt_support.c use fdt_getprop to read 32 bit values out of the device tree, but then use them directly without doing any endian conversion. Because they check for a value that doesn't actually appear in practice, the functions continued to work even though they're incorrect. This change adds the missing conversions. BUG=None TEST=Built and booted on Alex and Stumpy Change-Id: I467f68ad1eda7ef25c23341952c87b1a0a135285 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/8077 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Simon Glass <sjg@chromium.org> Commit-Ready: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-09-19fdt_support: Use uintptr_t for 32/64-bit compatibilitySimon Glass
This fixes problems in these files when building on 64-bit machines. BUG=chromium-os:19353 TEST=build for Seaboard Change-Id: Ib013db127505b326436ab4f650ce72e40963e208 Reviewed-on: http://gerrit.chromium.org/gerrit/7644 Reviewed-by: Anton Staaf <robotboy@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-09-19fdt: Move Chrome OS memory areas to fdtSimon Glass
This moves the last remaining hard-coded CONFIG to the fdt. BUG=chromium-os:17062 TEST=build for Seaboard Change-Id: Ic152ce12a0f87211e4cc98eef15601f0703137b1 Reviewed-on: http://gerrit.chromium.org/gerrit/7642 Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Anton Staaf <robotboy@chromium.org>
2011-09-15tegra: Rename TEGRA2 to TEGRASimon Glass
Some constants are actually better of with generic Tegra family names. This also cleans up a few addresses which were in drivers rather than in the tegra.h header file. BUG=chromium-os:19004 TEST=build and boot on Seaboard Change-Id: I1cabb5191a2b36648a37268069beb3b43c12d0e1 Reviewed-on: http://gerrit.chromium.org/gerrit/7128 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-09-14Add support for a bios-base device tree/flashmap settingGabe Black
This setting specifies where the bios image described by the "flash" section starts in the ROM. When the device tree is consumed by u-boot, this value is added to the given offset of accesses to the flash so that it ends up in the right place in the ROM. The binary fmap will reflect that address directly so that tools like flashrom can use it without modification. By not modifying the locations of the sections in the "flash" node of the device tree directly, we can continue to share definitions between boards that have the same layout for the BIOS image itself but who may be offset differently in the ROM. If not present, a default value of 0 is used. Unmodified device trees will continue to behave like they always have. The name bios-base isn't perfect since on ARM there is no bios. Another alternative firmware-base is also flawed because there are multiple firmwares in the ROM on x86. Yet another option, flashmap-base, doesn't quite work either because flashmap already has a very similarly named field which describes where the image described by the flashmap appears in the physical address space. Because bios-base fits the best on x86 and x86 is currently the only place it's used, that's the name I went with. BUG=chrome-os-partner:5844 TEST=Used this and other changes to compensate for the image offset and vboot on stumpy. Vbooted on x86-alex. Built with vboot_test and vbexport_test built in to verify that they still compile. Change-Id: Ie727fc2db27f7d0db8ebf7ed2b98bc97052b4923 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/7239 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-09-13fdt: Add function to locate or allocate regionSimon Glass
This function looks up a property in a node which contains a memory region address and size. It returns a pointer to this address, but if the address is zero, it is allocated with malloc() instead. It is used to allocate Chrome OS GBB memory regions and the like. BUG=chromium-os:19353 TEST=build for Seaboard Change-Id: I91fe8656f3ea50839998ab0e16b023635adbc119 Reviewed-on: http://gerrit.chromium.org/gerrit/7640 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Simon Glass <sjg@chromium.org>
2011-09-13fdt: Correct debug message compiler errorSimon Glass
This corrects a compile erron when DEBUG is defined in fdt_decode. Also change property to prop_name throughout, for consistency. BUG=chromium-os:19353 TEST=build for Seaboard Change-Id: I7503343cea20b556afeb0e507ce9d2cf2165c837 Reviewed-on: http://gerrit.chromium.org/gerrit/7639 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Simon Glass <sjg@chromium.org>
2011-09-13fdt: Only support serial if selected by CONFIGSimon Glass
This fixes what would become a build break if a board did not have NS16550 serial support included. T30 needs this change. Change-Id: I6e06dd7f7fce7e475c0cbe48edae8d068ca5b7e8 Reviewed-on: http://gerrit.chromium.org/gerrit/7637 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-09-09fdt: Add NAND decode functionsSimon Glass
BUG=chromium-os:17062 TEST=build and boot on Seaboard Change-Id: I7aa667fc608d3c42b4e16b0b9af3ef34df425cd0 Reviewed-on: http://gerrit.chromium.org/gerrit/6070 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/7453
2011-09-07Initialized skipped and todo to 0.Ahmad Sharif
BUG=chromium-os:20072 TEST=emerged chromeos-u-boot Signed-off-by: Reviewers Change-Id: I7afcb0b6b6ae614e7a32089abac2f44eb3251330 Reviewed-on: http://gerrit.chromium.org/gerrit/7354 Tested-by: asharif <asharif@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2011-09-06Provide support for a list of AHCI controllers.Vadim Bendebury
Many AHCI controllers are identical, the main (and often the only) difference being the PCI Vendor ID/Device ID combination reported by the device. This change allows the config file to define a list of PCI vendor ID/device ID pairs. The driver would scan the list and initialize the first device it finds. No actual multiple device list is introduced yet, this change just add the framework. BUG=chromium-os:19837 TEST=manual . program updated image on an Alex. . restart the machine and enter `vboot_twostop' at u-boot prompt. Observe ChromeOS booting all the way to login screen. Change-Id: I5253a3da798d7602dd09694fa3c029e92e1e0c65 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/7297 Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com> Reviewed-by: Stefan Reinauer <reinauer@google.com>
2011-09-06Fix AHCI driver to operate on Intel controllers.Vadim Bendebury
First - make sure the ahci driver compiles and links properly when building for x86 platforms. Then it turned out that when trying to use AHCI driver on an x86 platform with an Intel AHCI controller, the driver does not operate properly if the requested amount of blocks to read was exceeding 255. It is probably possible to specify 0 as the block count and the driver will read 256 blocks, but it was decided to limit the number of blocks read at once to 128 (it should be a power of 2 for the optimal performance of solid state drives). BUG=chromium-os:19837 TEST=manual . program updated image (including vbexport SATA support extension) on an Alex. . restart the machine and enter `vboot_twostop' at u-boot prompt. Observe ChromeOS booting all the way to login screen. Change-Id: I7224ca14ae60f414db6dbe9e2f0a649312a9459c Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/7232 Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2011-09-03Fix constness of the fdt void pointer in fdt_getprop_u32_defaultGabe Black
The function fdt_getprop_u32_default doesn't modify the fdt, so it can use a const void * for its fdt argument. BUG=None TEST=Built with no errors. Change-Id: I1987a7aa9e9fa9f5042e7fa2bf650e4cbc0bad0e Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/7238 Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-30Pass correct VDAT address to the vboot wrapper.Vadim Bendebury
On X86 systems where VDAT address is passed to the kernel through ACPI the u-boot must retrieve the address from the coreboot table and make it available to the vboot wrapper. This change accomplishes just that utilizing the coreboot changes which include the vdat area address and size into the coreboot table. Another modification is removing conditional compilation for including fields in the sysinfo table. The thing is that the code is not conditionally compiled anyways, so keeping an extra pointer in a table even if not needed is not a problem. BUG=chrome-os-partner:5707 TEST=manual . program the new firmware on an Alex . bring up ChromeOS . try running crossystem It was reporting errors before (when displaying data retrieved from VDAT). It displays sensible values now. Change-Id: Ib4090049092f7963a1b1705409d2beea8a9abfac Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/6868 Tested-by: Vadim Bendebury <vbendeb@google.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/6919 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-29Fix use of conditional LMBSimon Glass
This code was not guarded with CONFIG_LMB so failed to build on x86. BUG=chromium-os:19599 TEST=manual: make ARCH=x86 CROSS_COMPILE=i686-pc-linux-gnu- VBOOT=/build/x86-mario/usr VBOOT_DEBUG=1 Change-Id: I67ec1e5349646f6432426c8fda4f83f85b38b368
2011-08-29Fix IO UART selection from device treeStefan Reinauer
and also change address from 3f8 to i3f8 to clarify that it's an IO address. BUG=none TEST=boot coreboot on stumpy, see serial console output contain u-boot messages. Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Ib876e2812f05ded28de458ab2c38451ce85aed19 Reviewed-on: http://gerrit.chromium.org/gerrit/6606 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
2011-08-29Correct cast in LCD cache flushSimon Glass
This case was incorrect and gives warnings on 64-bit machines. BUG=chromium-os:19353 TEST=build and boot on Seaboard Change-Id: Id467aa27100701e971ddcddfec57347f79675d99 Reviewed-on: http://gerrit.chromium.org/gerrit/6522 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-29Allow NS16550 driver to support IO and memory mapped registersStefan Reinauer
This is needed to use the same config files for all x86 platforms, while the right incarnation of register accesses is determined by the device tree. BUG=chrome-os-partner:4520 TEST=boot u-boot on Alex and Stumpy, get serial output on both. Change-Id: Ibb8192657861713d656358c5f085f6dde2cb1365 Reviewed-on: http://gerrit.chromium.org/gerrit/6248 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Gabe Black <gabeblack@chromium.org>
2011-08-29Remove explicit support for the OXPCIE952Gabe Black
Early in development, we needed a driver for the OXPCIE952 UART which would be left configured by coreboot and just needed to send and receive characters. It was only partially developed and was somewhat redundant with the NS16550 UART support already in u-boot. Now that we're using the device tree to configure the serial console and it requires us to use the NS16550 driver, the OXPCIE952 driver is no longer necessary. Since it isn't likely to be useful in other contexts, this change removes support for it entirely. BUG=chrome-os-partner:4520 TEST=Built on x86-alex and tegra2_kaen. Installed and booted on x86-alex and verified that the serial console still worked. Change-Id: I124c4596b224f1b2a8d27b2b38e08ee2ce739c79 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/5871 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29Revert "Make the FMAP configuration decoding function board specific."Gabe Black
This reverts commit 23cefdce356de66442d858abf12c72afc8d33cac. Since we changed our minds about loading FMAP information from CBFS, we can go back to using the same mechanism on ARM and x86. BUG=chrome-os-partner:5432 TEST=Built and booted on x86-alex and verified that the FMAP information showed up in debugging output from vboot_twostop. Change-Id: Id41c82ca24dbfa301559e24104b5e226ec9b7e03 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/5864 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29cmd_sf: add "update" subcommand to do smart SPI flash updateSimon Glass
This adds a new SPI flash command which only rewrites blocks if the contents need to change. This can speed up SPI flash programming when much of the data is unchanged from what is already there. Series-to: u-boot Series-cc: mikef Series-version: 5 Series-changes: 2 - Moved loop into a function - Moved malloc outside loop - Other minor changes from review comments Series-changes: 3 - Change error message - Style and function name change Series-changes: 4 - tweak summary - fix printf warnings with %d vs %zu - fix help string and missing/extra newlines Series-changes: 5 - Stop on first error, rather than continuing Change-Id: I4e524783fe1fc10aa655a0fe2bb8b27fa44a4429 Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mike Frysinger <vapier@gentoo.org>