summaryrefslogtreecommitdiff
path: root/common
AgeCommit message (Collapse)Author
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>
2011-08-29New function VbExDecompress(), changed VbExDisplayImage().Bill Richardson
The vboot_api.h interface has changed, so we need to adapt. VbExDecompress() now allows the vboot library access to native decompression routines. The signature of VbExDisplayImage() has changed, so we now only need to support uncompressed native-format bitmaps. BUG=chromium-os:19134 TEST=manual I tested by modifying the U-Boot build so I could get into the U-Boot prompt and run "vbexport_test display". The GBB screens rendered correctly. Change-Id: Iec605dee0af46e7d9eecc89b826e260f8a5930a4 Reviewed-on: http://gerrit.chromium.org/gerrit/6131 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
2011-08-29save boot timing in the device tree.Da Zheng
BUG=chromium-os:18126 TEST=run "cat /sys/kernel/debug/bootstage/report" in chromeos to see the boot timing of u-boot. Change-Id: Ie7b2677f2df58ae80305989ebe79cbe9f5c142fe Reviewed-on: http://gerrit.chromium.org/gerrit/5504 Tested-by: Da Zheng <zhengda@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29Enable OF_CONTROL for Alex.Vadim Bendebury
This change makes the Alex u-boot use configuration settings coming from the device tree supplied by coreboot through the coreboot table. The device tree now includes the necessary console configuration information. Code is added to retrieve the device tree pointer from the coreboot table, the appropriate coreboot structures and tag values are being duplicated in arch/i386/include/asm/ic/coreboot/tables.h. The pointer to the FDT is added to the global data structure, it is initialized as soon as it is retrieved from the coreboot table. For some reason placing the global data structure anywhere but in the .data segment causes the system to crash. This phenomenon will be investigated shortly, this commit is an intermediate step to get the device tree handover used by other coreboot/u-boot contributors. Core retrieving the device tree from CBFS is not needed anymore and gets removed. BUG=chrome-os-partner:5248 TEST=manual . build the new image and program it on Alex . restart the target, observe the console output The target boots all the way to u-boot prompt. Change-Id: I087cf70362ede0873be37fa5a98aa66a0b979d8f Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/6132 Reviewed-by: Stefan Reinauer <reinauer@google.com>
2011-08-29bootstage: Fix incorrect arguments to qsort()Simon Glass
This was a nasty bug introduced during the previous code review. BUG=chromium-os:17805 TEST=build, boot on Aebl Change-Id: I9d600b7ac89c53598ac76f9031a988a4d27a66fa Reviewed-on: http://gerrit.chromium.org/gerrit/6091 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-29Add check that console is ready before outputSimon Glass
If puts() or printf() is called before the console is ready, U-Boot will either hang or die. This adds a check for this so that debug() can be used in early code without concern that it will hang. BUG=chromium-os:17062 TEST=build and boot U-Boot, then #define DEBUG in fdt_decode and see that U-Boot boots properly Change-Id: I299cbbb074e31a1df2d742dec2e9aab5ac7ca0a5 Reviewed-on: http://gerrit.chromium.org/gerrit/6066 Reviewed-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Anton Staaf <robotboy@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-29fdt: Add debugging feature to fdt_decodeSimon Glass
It is sometimes difficult to work out where an fdt decode is failing unless you have a debugger running. This adds a simple debug/trace features to the fdt_decode library. To use it #define DEBUG in fdt_decode.c BUG=chromium-os:17062 TEST=build U-Boot with this debugging enabled, see that output appears Change-Id: I21a3f8668be33a0f09354be9f286abef73812684 Reviewed-on: http://gerrit.chromium.org/gerrit/5051 Reviewed-by: Anton Staaf <robotboy@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-29Small refactor to remove duplicate serial codeSimon Glass
This tidies up duplicate code, and checks that default_serial_console() does in fact produce a device. BUG=chromium-os:17062 TEST=build and boot U-Boot on Seaboard Change-Id: Icc20e304049fc3568717457ad8366903a7a05bf8 Reviewed-on: http://gerrit.chromium.org/gerrit/6064 Reviewed-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Anton Staaf <robotboy@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-29Sort the bootstage time summarySimon Glass
Since we can't easily control the order in which records are added to the bootstage list, this sorts the list before display. BUG=chromium-os:17805 TEST=build and boot on Aebl, see that list is sorted Timer summary in microseconds: Mark Elapsed Stage 0 0 reset 316,789 316,789 arch_cpu_init AVP 321,096 4,307 arch_cpu_init A9 321,147 51 arch_cpu_init done 321,149 2 board_init_f start 393,588 72,439 board_init_r start 642,657 249,069 main_loop 647,449 4,792 do_vboot_twostop 649,768 2,319 twostop_init 661,083 11,315 twostop_select_and_set_main_firmware 886,859 225,776 twostop_main_firmware 1,324,964 438,105 select_and_load_kernel_exit 1,328,934 3,970 bootm_start 1,490,433 161,499 start_kernel Change-Id: Ieea6c5f107243d81882207e85775e78924956e34 Reviewed-on: http://gerrit.chromium.org/gerrit/5777 Reviewed-by: Anton Staaf <robotboy@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-29Add new bootstage stepsSimon Glass
This adds steps for arch_cpu_init() and board_init_f/r() BUG=chromium-os:17805 TEST=build and boot on Aebl Change-Id: If29288b896585f7e1eb8c8bf67e48b76dd06fb48 Reviewed-on: http://gerrit.chromium.org/gerrit/5776 Reviewed-by: Anton Staaf <robotboy@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: remove earlier prototype codesChe-Liang Chiou
The removed codes are belong to an earlier prototype of integrating vboot wrapper API, which is not compiled/used anymore. Besieds, the prototype has a known vulnerability of buffer overflow when reading key blocks. So there is no many referential value for keeping the prototype codes in the codebase. And keeping the prototype also adds costs to new patches, which have to changes two implementations. All in all, I think it is time we retire this prototype. This patch also fixes coreboot build failure due to the removal. BUG=chromium-os:16542 TEST=emerge-{x86-alex,tegra2_aebl} chromeos-u-boot Change-Id: Ib6be9457f2dbc2daa3213c3d9c80bcdc56c520c4 Reviewed-on: http://gerrit.chromium.org/gerrit/5874 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-11-15 20:07:35 +0000