summaryrefslogtreecommitdiff
path: root/lib
AgeCommit message (Collapse)Author
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-11-02Move Memset from vboot_reference to vbexport/u-bootStefan Reinauer
All memory operations (except the "safe ones") live in the firmware so the fast operations can be used. Except Memset. This CL changes that problem. There is another CL for this issue (removing the function from vboot_reference) BUG=chrome-os-partner:6313 TEST=run coreboot/u-boot on Stumpy Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Ic2ee5970d2ee9df64a9eda261a4348341cb4b31a Reviewed-on: https://gerrit.chromium.org/gerrit/10992 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
2011-10-18Don't use ARM's hard coded RO value for EC status on x86.Stefan Reinauer
But let coreboot pre-fill that field instead. BUG=chrome-os-partner:6212 TEST=boot coreboot+u-boot on Lumpy, see EC firmware reported as RW in crossystem. Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Icc4ac474e19dc72b61040faafbe1a184738564d0 Reviewed-on: http://gerrit.chromium.org/gerrit/10266 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2011-10-17CHROMIUM: Clean up cros gpio codeSean Paul
This CL simplifies how cros gpios are handled by moving the required logic out of cros_gpio.c and into the application logic. This means that cros_gpio.c assumes that none of the gpios are required, and just returns an error when fetch is called. It's up to the caller of fetch to determine whether or not they should ignore the error or act upon it. BUG=chromium-os:21700 TEST=Tested on asymptote, ensured gpio access worked as expected. Change-Id: Ief3f1915026bfe981d345b9cc4709fef19edc7bf Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/10174 Reviewed-by: Simon Glass <sjg@chromium.org>
2011-10-12[PATCH1/2] mrc cache: Add MRC cache FMAP entry support.Vadim Bendebury
Add code to retrieve the location of the MRC cache from the FMAP device tree definition. fdt_decode.c should be refactored (fmap_offset could be determined just once and used throughout without passing it as a parameter), will leave this for another day. BUG=chrome-os-partner:5808 TEST=manual . see test description in the second patch commit message. Change-Id: Ic4003d685609beb61d1dea324bd804a2838e471c Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/9961 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
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-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-04CHROMIUM: Guard lib/chromeos/fdt_decode correctlySimon Glass
This file needs to depend on both CONFIG_CHROMEOS and CONFIG_OF_CONTROL. BUG=chromium-os:19353 TEST=build with CONFIG_OF_CONTROL, but without CONFIG_CHROMEOS; see that it now succeeds Change-Id: I94b2616b6bcb10619b00c5fe93adf2e36d459fb0 Reviewed-on: http://gerrit.chromium.org/gerrit/8682 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-09-23Use the vdat firmware index when setting up the ACPI crossystem data tableGabe Black
Instead of using a hardcoded value, set this field of the table used by the crossystem ACPI driver to whatever is stored in VDAT. BUG=chrome-os-partner:5944 BUG=chrome-os-partner:5961 BUG=chrome-os-partner:5962 TEST=Booted on Alex. Verified that corrupting firmware A made crossystem change mainfw_act to B instead of A. Signed-off-by: Gabe Black <gabeblack@google.com> Change-Id: I01b26508fede3d15e78b584b638e1393c5b03501 Reviewed-on: http://gerrit.chromium.org/gerrit/8189 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Ready: Gabe Black <gabeblack@chromium.org>
2011-09-23Update VbExBeep() signature to match changed API.Bill Richardson
Signed-off-by: Bill Richardson <wfrichar@google.com> BUG=none TEST=none Change-Id: I636eee76069d9f6ae0679135b87f0006d59c2723 Reviewed-on: http://gerrit.chromium.org/gerrit/8242 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com>
2011-09-20Set up basic vboot data for use by crossystemGabe Black
This change sets up basic vboot data for use by crossystem. The pieces of information and what they're set to are below. I assumed that the constants defined in the coreboot version of this code describe all of the available settings for each option. Boot reason: BOOT_REASON_OTHER The choices here are BOOT_REASON_OTHER and BOOT_REASON_S3DIAG. I don't know what BOOT_REASON_S3DIAG is for or how to detect which to use. I believe S3 resume happens without going through u-boot, so hardcoding this to BOOT_REASON_OTHER seems reasonable for now at least. Active main firmware: ACTIVE_MAINFW_RW_A The choices are ACTIVE_MAINFW_RECOVERY, ACTIVE_MAINFW_RW_A and ACTIVE_MAINFW_RW_B. This information isn't stored in the crossystem_data_t structure. For now it's hard coded to ACTIVE_MAINFW_RW_A which is going to frequently be wrong. I suspect we also need to add a value which indicates that the read only firmware was used by itself. Active EC firmware: cdata->active_ec_firmware A direct match with data already gathered by u-boot/vboot. CHSW: Translation from booleans to bitfields. The cdata boot_write_protect_switch, boot_recovery_switch, and boot_developer_switch boolean fields are translated into the CHSW_FIRMWARE_WP_DIS, CHSW_RECOVERY_X86 and CHSW_DEVELOPER_SWITCH bitfields. The CHSW_RECOVER_EC bitfield is ignored since there's no obviously corresponding field in crossystem_data_t. HWID: cdata->hardware_id A direct match with data already gathered by u-boot/vboot. FWID: cdata->firmware_id A direct match with data already gathered by u-boot/vboot. FRID: cdata->readonly_firmware_id A direct match with data already gathered by u-boot/vboot. Active main firmware type: cdata->firmware_type A direct match with data already gathered by u-boot/vboot. Recovery reason: RECOVERY_REASON_NONE The choices are RECOVERY_REASON_NONE and RECOVERY_REASON_ME. Since u-boot has no information about the ME, this is hardcoded to RECOVERY_REASON_NONE. FMAP base address: cdata->fmap_offset An assumed direct match with data already gathered by u-boot/vboot. There is a little ambiguity as far as what this is the offset of and from. BUG=chrome-os-partner:5944 BUG=chrome-os-partner:5961 BUG=chrome-os-partner:5962 TEST=Booted successfully on both stumpy and alex. Used crossystem to verify that information like the firmware ID was extracted successfully. The GPIOs, which are not sent with this mechanism, seem to work sometimes but not always. Signed-off-by: Gabe Black <gabeblack@google.com> Change-Id: If7ea2a6470d8edf7122f87f289c19d4464775e8c Reviewed-on: http://gerrit.chromium.org/gerrit/7977 Commit-Ready: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com>
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-15CHROMIUMOS: small code clean ups in boot_kernel/fdt_decodeSimon Glass
This just changes to standard 'blob' naming, and fixes a code style error. BUG=chromium-os:19353 TEST=build and boot on Seaboard Change-Id: Ib79d526ef612a181091ef15a5dd427ea73c53330 Reviewed-on: http://gerrit.chromium.org/gerrit/7681 Reviewed-by: Vadim Bendebury <vbendeb@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-06Add SATA interface for vbexport.Vadim Bendebury
Copy device_ide.c into device_scsi.c, editing as appropriate along the way. Ensure that the new file is included if CONFIG_AHCI_SCSI is defined fro the platform. BUG=chromium-os:19837 TEST=manual . program updated image (including AHCI fixes and configuration changes) on an Alex. . restart the machine and enter `vboot_twostop' at u-boot prompt. Observe it boot up all the way to ChromeOs login screen. Change-Id: I146591c53f61722cc33f7261a1921aa07e861ee3 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/7234 Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-31Fix refactoring problems introduced earlier.Vadim Bendebury
It was noticed that the system fails to come up while running the latest u-boot from the 2011.06 branch. Further investigation has discovered that the problem is due to the fact that the initialization of the verified boot wrapper was not handled properly and that the IDE index reported by the IDE discovery routine was wrong. BUG=chromium-os:19599 TEST=manual . build and install the new firmware image on an Alex with a valid ChromeOS image . restart the machine . enter vboot_two at u-boot prompt observe the machine to bring up the ChromeOs login screen. Change-Id: Icc78d682d5c81d6f08d31896c32c8cd48d0a4f2d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/7030 Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
2011-08-30CHROMIUMOS: Refactor boot_device to support multiple devices nicelySimon Glass
Now that we have MMC, USB and IDE, with some enabled for only some platforms, the code has become ugly. This refactors the code to separate out each device into its own file, with a generic start/scan interface. This also fixes the problem with indexing of devices, where it could not cope with MMC and IDE active at the same time. BUG=chromium-os:19518 TEST=build on Seaboard; vbexport_test diskinfo See that all boot devices are found with SD and USB inserted Change-Id: I4844f7b33885ec01e922686a17c90afdf0a55a9d Reviewed-on: http://gerrit.chromium.org/gerrit/6254 Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Anton Staaf <robotboy@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/6918 Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: guard boot_kernel fdt codes with #ifdefChe-Liang Chiou
boot_kernel sets up pointer to crossystem data for embedding into kernel device tree unconditionally regarding CONFIG_OF_UPDATE_FDT_BEFORE_BOOT. This patch guards boot_kernel codes that are specific to kernel device tree with the config flag. Note: x86 boards might use a mechanism other than device tree to deliver crossystem data to kernel. BUG=none TEST=emerge-{tegra2_aebl,x86-alex} chromeos-u-boot Change-Id: Ifd04af1681d72c918c838ba3713ddecaca0ff18a Reviewed-on: http://gerrit.chromium.org/gerrit/6466 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUMOS: Add vbexport_init() to set up librarySimon Glass
We need to register available boot devices. It seems reasonable that this library should be initialized before use. BUG=chromium-os:19518 TEST=build on Seaboard; vbexport_test diskinfo See that all boot devices are found with SD and USB inserted Change-Id: I17a535dc85b5aaee669ea67b439632bafb19c806 Reviewed-on: http://gerrit.chromium.org/gerrit/6501 Reviewed-by: Anton Staaf <robotboy@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-29Choose the right boot function for x86Stefan Reinauer
BUG=chrome-os-partner:4552 TEST=vboot_twostop does not fail with an error after loading the kernel. Change-Id: I16016239716c8030ea63c7da6bd99a2f03b0e40d Reviewed-on: http://gerrit.chromium.org/gerrit/5549 Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2011-08-29Only include mmc.h when mmc is enabled.Stefan Reinauer
From http://gerrit.chromium.org/gerrit/#change,6253 BUG=none TEST=none Change-Id: I3145aa84a8426506d8dc44d094da4884f079b3b4 Reviewed-on: http://gerrit.chromium.org/gerrit/6355 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29Look for an IDE boot device on non-MMC systems.Stefan Reinauer
This is a rewrite of http://gerrit.chromium.org/gerrit/#change,5547 which tries to integrate more transparently into vbexport's code and at the same time removes some (false) assumptions about always booting from MMC. BUG=none TEST=none Change-Id: I18f3b91f307b16622de9ced97ab00454c29941fe Reviewed-on: http://gerrit.chromium.org/gerrit/6232 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Reinauer <reinauer@google.com>
2011-08-29CHROMIUMOS: tidy msleep castSimon Glass
BUG=chromium-os:19353 TEST=build for Seaboard Change-Id: Iba1da73cdd5a8e3972240e939a40ee4a32e83786 Reviewed-on: http://gerrit.chromium.org/gerrit/6252 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.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-29Add board_panic_no_console to deal with early critical errorsSimon Glass
Change-Id: I1e1cc76214cdb45399cec090677d3164ca2d33eb Reviewed-on: http://gerrit.chromium.org/gerrit/6065 Reviewed-by: Mike Frysinger <vapier@chromium.org> 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>
2011-08-29Makes the VbExGetTimer vboot callback function board specificGabe Black
The timer_get_us function which is called by the existing implementation of VbExGetTimer isn't trivial to implement on x86. The vboot source says that the TSC is an appropriate time source to return from this function. This change makes the VbExGetTimer function per board so that it can use rdtsc instead of timer_get_us. BUG=chrome-os-partner:4552 TEST=Built and booted on x86-alex, and built on tegra2_kaen. Signed-off-by: Gabe Black <gabeblack@google.com> Change-Id: I335d5ae98949cd05c42dc3f30c52931bdf63a623 Reviewed-on: http://gerrit.chromium.org/gerrit/5544 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29Introduce generic TPM support in u-boot.Vadim Bendebury
This code is used on x86 platforms to control a standard LPC based TPM device. The actual driver implementation is based on the article "Writing a TPM Device Driver" published on http://ptgmedia.pearsoncmg.com and the submission by Stefan Berger on Qemu-devel mailing list. One substantial difference is that in the simplest configuration (the case of the Alex device under coreboot/u-boot control) the other than 0 TPM localities do not get mapped by some devices (for instance, by Infineon slb9635), so this driver provides access to locality 0 only. BUG=chrome-os-partner:4547 TEST=manual Booted an Alex with this code, tried accessing TPM. Access routines do not fail, even though it is not yet possible to write data into a TPM location and read it back. This could be related to the fact that the CLI command does not intialize the TPM properly. boot > tpm generic_lpc_tpm.c:155 found TPM SLB9635 TT 1.2 by Infineon boot > tpm r 0x1008 10 boot > tpm w 0x1008 1 2 3 4 boot > tpm r 0x1008 4 Change-Id: Id8d23e9bb24ba2bcd999135c99e7612f9010f384 Reviewed-on: http://gerrit.chromium.org/gerrit/5492 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Vadim Bendebury <vbendeb@chromium.org>
2011-08-29Implement missing functions for vboot:Stefan Reinauer
* video_clear() Clear the video framebuffer. * cold_reboot() Do a hard reset through the chipset's reset control register. This register is available on all x86 systems (at least those built in the last 10ys) * power_off() Power down the machine by using the power management sleep control of the chipset. This will currently only work on Intel chipsets. However, adapting it to new chipsets is fairly simple. You will have to find the IO address of the power management register block in your southbridge, and look up the appropriate SLP_TYP_S5 value from your southbridge's data sheet. BUG=chrome-os-partner:3912 TEST=Run vboot_twostage and see vboot first clear the screen and later cold boot. Run poweroff and coldboot command in uboot console. Change-Id: I59f49a41e8807b2ec3ebb3d083d2a06ced9553a0 Reviewed-on: http://gerrit.chromium.org/gerrit/5361 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
2011-08-29Decouple x86 u-boot from fdt related functions.Vadim Bendebury
The x86 u-boot does not enable the CONFIG_OF_CONTROL flag yet, and as such should not compile in the FDT related functions. This change takes care of this arrangement and also removes the remaining common code using fdt unconditionally. BUG=chrome-os-partner:4993 TEST=manual . build u-boot for Kaen, verify that the system still comes up as expected. . build coreboot image for Alex, verify that the system still can be started manually. Change-Id: I5416f9fd0a6cc9f86aef9051b1f7b6d9b252964e Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/5362
2011-08-29Make the FMAP configuration decoding function board specific.Gabe Black
This change makes the FMAP configuration decoding function board specific so that it can, for instance, use CBFS to store the FMAP on x86. The ARM implementation uses fdt_decode_twostop_fmap in its implementation and should behave the same. The new more generic interace is called decode_twostop_fmap. BUG=chrome-os-partner:5248 TEST=Built, installed and booted on Kaen, built and installed on Alex, ran vboot_twostop and saw new "unimplemented" message. Signed-off-by: Gabe Black <gabeblack@google.com> Change-Id: I07f6f8f7c8a62c5998ec4919d4609a7ac84783da Reviewed-on: http://gerrit.chromium.org/gerrit/5233 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29Remove the device tree from one of the vboot support APIs.Gabe Black
This change removes the device tree from one of the vboot support APIs so that they fit better with coreboot u-boot. Specifically this is cros_gpio_fetch which is for getting GPIO values. Coreboot will read these and provide the values through its coreboot tables. The device tree pointer is global data so it doesn't need to be passed around as a parameter to be accessible. This change also removes the device tree from other interfaces in cmd_vboot_twostop.c so the structure of the code is more consistent. This way people can expect the device tree to always be the one pointed at by the global data and not sometimes one and sometimes the other, even though as written those will be equivalent. This change also takes the opportunity to mark the local functions in that file static, which is most of them. BUG=chrome-os-partner:4552 TEST=Built for x86-alex and tegra2_kaen. Installed and booted to chromeos login on Kaen. Change-Id: I084e774d97025d9ec71abe09c92fab8a7827892f Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/5232 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29Make the chromeos FMAP data structures more generic and in their own files.Gabe Black
This change separates out the FMAP data structures from the FDT decode functions and renames them to more neutral names. These structures don't intrinsically have to be loaded from the FDT, and their new names and location remove the implied dependency. BUG=chrome-os-partner:5248 TEST=Built for x86-alex and tegra2_kaen. Installed on Kaen and booted to chromeos login. Change-Id: I5680a3f3aaa52efe44c2060d0b6db9ad47a547ec Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/5231 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29CHROMIUM: move VbExHashFirmwareBody() to lib/vbexport/Che-Liang Chiou
This patch only moves code around. BUG=chromium-os:16542 TEST=build okay Change-Id: Idc908fd2e652c114ae8029c120386fb44e63b4f9 Reviewed-on: http://gerrit.chromium.org/gerrit/5204 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Gabe Black <gabeblack@chromium.org>
2011-08-29CHROMIUM: avoid using printf %s on long stringsChe-Liang Chiou
The U-Boot printf() implementation has an output buffer limitation on output, and so cannot be used for very long output. Instead, puts() has no such limitation. BUG=chromium-os:18351 TEST=run on Aebl Change-Id: I3f3e3b81968f5169a2fe1f581924fa19c3dc1a43 Reviewed-on: http://gerrit.chromium.org/gerrit/4990 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29Prevent the LP0 vector from being wiped out.Vadim Bendebury
It was observed that the sleep recovery fails when Kaen is in dev mode. Further investigation has shown that the LP0 vector space is set to all zeros when the system is in dev mode, which clearly prevents it from resuming operations properly. Then it turned out that the recently introduced memory u-boot wipeout fails to exclude the LP0 vector space, so it gets erased. For some reason u-boot does this in two different places in the code, so the fix adds exclusion of the LP0 vector space in those spaces. BUG=chrome-os-partner:5152 TEST=manual Build a new u-boot image, install it on a kaen. Then bring up the kaen in normal and developer mode, login, close the lid and open it back a few times. Before the fix the machine would hang every single attempt at closing the lid when in dev mode, after the fix it enters and exits sleep state seamlessly in both dev and normal modes. Change-Id: I9ec31495bca41abed68de8559560f0b1fcdd4969 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/5193 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29CHROMIUM: make sure update_cmdline does not buffer overflowChe-Liang Chiou
Although we should not pass any command-line that causes update_cmdline to buffer overflow, it is good to check and avoid this. BUG=chromium-os:18139 TEST=unit tests on user space Change-Id: Ifc481068c30aa5c141d6e3d36f3affd5e3d95ffb Reviewed-on: http://gerrit.chromium.org/gerrit/4914 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
2011-08-29CHROMIUM: eliminate confusing comma separatorChe-Liang Chiou
BUG=none TEST=none Change-Id: I3b83f2df71df0227aa71dba8300e641944eb4c8b Reviewed-on: http://gerrit.chromium.org/gerrit/4909 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Micah Catlin <micahc@chromium.org>
2011-08-29Implement shared display support.Vadim Bendebury
This change fills up the stubs in lib/vbexport/display.c to provide support on both ARM (where LCD driver is used) and X86 (where the CFB driver is used) platforms. BUG=chrome-os-partner:4552 TEST=manual On X86 (alex with a Dediprog programmer connected to it), run the following commands: . emerge-x86-alex vboot_reference-firmware chromeos-u-boot chromeos-coreboot dd if=/build/x86-alex/coreboot/coreboot.rom of=/tmp/coreboot seek=3584 bs=1K sudo flashrom -p dediprog -w /tmp/coreboot . Reboot the machine, observe it come up to boot> prompt, start ChromeOS (using the `boot' cli command). On ARM (tegra2_kaen) . emerge-tegra2_kaen vboot_reference-firmware chromeos-u-boot chromeos-bootimage . program the resulting image into Kaen, restart it, observe the machine come up. . install the new OS image on the machine, restart it, observe the machine come up. . request recovery reboot using crossystem, restart the machine, observe it come up in recovery request mode. This test case actually failed: the system did show the recovery request screen, but then proceeded to boot from the plugged in USB stick (it was supposed to wait for the stick to be removed/reinserted) Change-Id: I75310de3f93464645cc9e61237f65d7d19b71873 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/4886 Reviewed-by: Stefan Reinauer <reinauer@google.com>
2011-08-29CHROMIUM: remove using sprintf to convert a known constant to stringChe-Liang Chiou
BUG=none TEST=emerge-{ARM board, x86 board} chromeos-u-boot Change-Id: Ib6c267d6624cebf2b83cb1996ae8135b9cb0e436 Reviewed-on: http://gerrit.chromium.org/gerrit/4911 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29Get rid of the CONFIG_CHROMEOS_KERNEL_* config optionsGabe Black
These were incompletely renamed to CHROMEOS_KERNEL_* this change cleans up the remaining use of the old name and gets rid of the old option from the coreboot configuration. BUG=chrome-os-partner:4552 TEST=Built for coreboot, aebl, and kaen. Change-Id: I267932ab1d2f4a148357e7c95f15a104422ba687 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/4889 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29Add a missing include into main_entry.cGabe Black
main_entry.c uses the TPM_SUCCESS constant but wasn't including the file that defines it. This was breaking the build for u-boot/coreboot. BUG=chrome-os-partner:4552 TEST=Built for coreboot. Change-Id: I684c4272fcc67403eaf70e2b063dbe3db2b6eb88 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://gerrit.chromium.org/gerrit/4848 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29Conditionally implement vboot function wipe_unused_memoryGabe Black
The wipe_unused_memory function in bootstub_entry.c in the vboot library which depends on being able to call fdt_decode_memory which only compiled in with CONFIG_OF_CONTROL. That setting breaks booting u-boot with coreboot right now. This change conditionally compiles in the existing implementation if the right support is available and compiles in a warning message if it isn't. BUG=chrome-os-partner:4552 TEST=Built on x86. Change-Id: I6404eb12b25c19eb21eb65ad16a5031a5e3d0ad7 Reviewed-on: http://gerrit.chromium.org/gerrit/4843 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29Conditionally implement vbexport functionsGabe Black
There are a few functions in display.c in the vbexport library which depend on being able to call functions provided by the LCD driver. If that support isn't turned on then compilation will fail. It can't always be turned on because it's not always the right driver to use. This change conditionally compiles in the existing implementation if the right support is available and compiles in a warning message and a failing return code if it isn't. BUG=chrome-os-partner:4552 TEST=Built on x86. Signed-off-by: Gabe Black <gabeblack@google.com> Change-Id: I70695f06bb1b55063d035307e0420f8fc58b1efa Reviewed-on: http://gerrit.chromium.org/gerrit/4768 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
2011-08-29CHROMIUM: cherry-pick gbb partial loading optimizationChe-Liang Chiou
This patch is cherry-picked from commit 1d01c6b. You may gain 142ms in boot time. BUG=chromium-os:16542 TEST=boot normal/developer/recovery on Aebl Change-Id: I983e2dec32205dd586a2d7f267409eaafefb267f Reviewed-on: http://gerrit.chromium.org/gerrit/4806 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29CHROMIUM: reorganize config headersChe-Liang Chiou
The headers are merged and split into the board-independent header chromeos.h and a board-dependent header, e.g., chromeos_tegra2_twostop.h. The board-independent header defines/enables all features that a verified boot firmware must have, and is included by a board-dependent header. Moreover, the CONFIG_CHROMEOS_* flags are reduced into a single flag CONFIG_CHROMEOS. BUG=none TEST=make chromeos_tegra2_twostop_config && make Change-Id: I2ec9092ed898c640175095e86cfcb100efbefb3a Reviewed-on: http://gerrit.chromium.org/gerrit/4731 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29CHROMIUM: add cros_vboot/cros_legacy to kernel command lineChe-Liang Chiou
Some scripts, like those in factory process, detect whether Chrome OS is booted from a verified boot or a legacy boot by overloading crossystem. If crossystem returns a valid hardware id, the scripts believe that Chrome OS is booted from a verified boot. Although this trick works, it does not sound right. This patch adds "cros_vboot" and "cros_legacy" to kernel command line of verified boot firmware and legacy firmware so that the scripts can grep the value, or the crossystem may do the grep. This patch also fixes unsafe use of strncpy. BUG=chromium-os:15700,chromium-os:18139 TEST=verified boot and grep cros_vboot /proc/cmdline TEST=boot from legacy and grep cros_legacy /proc/cmdline Change-Id: Id5182c2f4e05fc566a17b1e50f9157f96c50f866 Reviewed-on: http://gerrit.chromium.org/gerrit/4645 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29CHROMIUM: factor out gbb loader functionsChe-Liang Chiou
This patch also eliminates duplications of decoding fmap from the device tree. BUG=chromium-os:16542 TEST=make chromeos_seaboard_vboot_config && make Change-Id: I0af75335be10823b8644c94f6fc9aac0304a2633 Reviewed-on: http://gerrit.chromium.org/gerrit/4745 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-07-04 18:50:11 +0000