summaryrefslogtreecommitdiff
path: root/lib
AgeCommit message (Collapse)Author
2011-08-29CHROMIUM: Implement utility APIs provided by u-boot and exported to ↵Tom Wai-Hong Tam
vboot_reference. We put the new vboot wrapper export API to /lib/vbexport directory to separate the original APIs which in /lib/chromeos directory. A u-boot prompt testing tool, vbexport_test, is added for the API unit tests. This CL is dependent on http://gerrit.chromium.org/gerrit/#change,2195 BUG=chromium-os:16543 TEST=build chromeos_seaboard_vboot_config, flash it to seaboard, and run: Tegra2 # vbexport_test debug Preforming the debug output tests... Expect: K 75 Hello! It's "Chrome OS". Actual: K 75 Hello! It's "Chrome OS". Expect: -22222 0xa932 Actual: -22222 0xa932 Expect: 44444 0xad9c Actual: 44444 0xad9c Expect: -1111111111 0xbdc5ca39 Actual: -1111111111 0xbdc5ca39 Expect: 2222222222 0x84746b8e Actual: 2222222222 0x84746b8e Expect: -8888888888888888888 0x84a452a6a1dc71c8 Actual: -8888888888888888888 0x84a452a6a1dc71c8 Expect: 11111111111111111111 0x9a3298afb5ac71c7 Actual: 11111111111111111111 0x9a3298afb5ac71c7 Tegra2 # vbexport_test malloc Preforming the malloc/free tests... Trying to malloc a memory block for 1 bytes... - SUCCESS Trying to malloc a memory block for 2 bytes... - SUCCESS Trying to malloc a memory block for 4 bytes... - SUCCESS Trying to malloc a memory block for 8 bytes... - SUCCESS Trying to malloc a memory block for 32 bytes... - SUCCESS Trying to malloc a memory block for 1024 bytes... - SUCCESS Trying to malloc a memory block for 4096 bytes... - SUCCESS Trying to malloc a memory block for 32768 bytes... - SUCCESS Trying to malloc a memory block for 1048576 bytes... - SUCCESS Trying to malloc a memory block for 12345 bytes... - SUCCESS Trying to malloc a memory block for 13579 bytes... - SUCCESS Tegra2 # vbexport_test sleep Preforming the sleep tests... System is going to sleep for 10 ms... From tick 20158963 to 20168065 (delta: 9102) - SUCCESS System is going to sleep for 50 ms... From tick 20345437 to 20395038 (delta: 49601) - SUCCESS System is going to sleep for 100 ms... From tick 20572586 to 20672087 (delta: 99501) - SUCCESS System is going to sleep for 500 ms... From tick 20849623 to 21349024 (delta: 499401) - SUCCESS System is going to sleep for 1000 ms... From tick 21526751 to 22526052 (delta: 999301) - SUCCESS Tegra2 # vbexport_test longsleep Preforming the long sleep tests... System is going to sleep for 5000 ms... From tick 71318054 to 76318055 (delta: 5000001) - SUCCESS System is going to sleep for 10000 ms... From tick 76495950 to 86495051 (delta: 9999101) - SUCCESS System is going to sleep for 50000 ms... From tick 86672951 to 136672052 (delta: 49999101) - SUCCESS Tegra2 # vbexport_test beep Preforming the beep tests... System is going to sleep for 500 ms... Beep! From tick 11288504 to 11788451 (delta: 499947) - SUCCESS Change-Id: Ia192c1f152fa75f7d587d8a87eb22a1cf0a505c3 Reviewed-on: http://gerrit.chromium.org/gerrit/2656 Tested-by: Tom Wai-Hong Tam <waihong@chromium.org> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
2011-08-29CHROMIUM: update and tidy up gbb_bmpblkChe-Liang Chiou
Changes include: * CONFIG_CMD_BMP is not defined and so every reference to it is removed * remove #ifdef guards; if any symbol is missing, build should fail Note: debug output messes up bitmaps display, but this is intended. Most test users do not have the privilege to access serial output, and so LCD is their only source of debug message. We will turn off debug output on LCD after we feel that firmware is stable enough that debug messages are not useful to test users. BUG=chromium-os:16508 TEST=bitmaps are displayed in developer and recovery mode on seaboard Change-Id: I80be6544298bd6cf3db24f650583dbad247f431c Reviewed-on: http://gerrit.chromium.org/gerrit/3067 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: implement SD card probing functionChe-Liang Chiou
BUG=chromium-os:16508 TEST=manual 1. unplug SD card and any other external storage media 2. boot to recovery mode 3. check that u-boot does not probe any external storage media 4. plug in SD card 5. check that u-boot probes the SD card Change-Id: I00413485306ddecb3baf593a70230d2cd2f52bac Reviewed-on: http://gerrit.chromium.org/gerrit/3079 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: fix warning when turn off debug outputChe-Liang Chiou
BUG=chromium-os:16508 TEST=build w/ and w/o -DVBOOT_DEBUG and no warnings Change-Id: I8e17cf405a5543d6c40b3d40bcb57479140ada75 Reviewed-on: http://gerrit.chromium.org/gerrit/3035 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29CHROMIUM: vboot_reference/Malloc use memalignChe-Liang Chiou
mmc driver prefers a buffer aligned to cache line size. The vboot_reference should try allocate buffers this way. BUG=chromium-os:16508 TEST=manual boot w/o memalign: 5 buffer unaligned warnings ------------------------------------------------------------ SF: Detected W25Q16 with page size 256, total 2 MiB Requested clock rate 52000000 not honored (got 48000000) mmc_prepare_data: Unaligned data, using slower bounce buffer mmc_prepare_data: Unaligned data, using slower bounce buffer mmc_prepare_data: Unaligned data, using slower bounce buffer mmc_prepare_data: Unaligned data, using slower bounce buffer mmc_prepare_data: Unaligned data, using slower bounce buffer ------------------------------------------------------------ boot w/ memalign: only 1 buffer unaligned warning ------------------------------------------------------------ SF: Detected W25Q16 with page size 256, total 2 MiB Requested clock rate 52000000 not honored (got 48000000) mmc_prepare_data: Unaligned data, using slower bounce buffer ------------------------------------------------------------ Change-Id: If9e9ce93faec1bbaa8cda25b6966a92bba4c182d Reviewed-on: http://gerrit.chromium.org/gerrit/3034 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29Add assert() for debug assertionsSimon Glass
assert() is like BUG_ON() but compiles to nothing unless DEBUG is defined. This is useful when a condition is an error but a board reset is unlikely to fix it, so it is better to soldier on in hope. Assertion failures should be caught during development/test. It turns out that assert() is defined separately in a few places in U-Boot with various meanings. Build errors exposed by this change (and defining DEBUG) are also fixed in this commit. BUG=chromium-os:11623 TEST=build U-Boot for seaboard Change-Id: I27500491d2328405694bfd65ab991d42d9641927 Reviewed-on: http://gerrit.chromium.org/gerrit/2777 Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anton Staaf <robotboy@chromium.org>
2011-08-29CHROMIUM: add prototype onestop firmwareChe-Liang Chiou
The onestop firmware boot flow is (pseudo code): -------------------------------- init internal state if fail fatal and reboot if user presses recovery button or recovery is requested do recovery boot flow init VbSharedData if fail fatal and reboot do rewritable boot flow -------------------------------- The rewritable boot flow is normal plus developer boot flow; it is like the Cr-48 style of rewritable firmware that does both. The VbSharedData initialization partially simulates LoadFirmware function by pretending that rewritable firmware A is loaded. As a result, the initialization codes break the encapsulation of vboot_reference library and access to private functions of the library. To fix this break of encapsulation, the library should implement and expose a new top-level entry point for initializing VbSharedData without calling LoadFirmware. Known issue: It cannot always properly initialize external mmc device; it stops at initializing SD card. When trying to initialize external mmc device, u-boot shows -------------------------------- mmc_prepare_data: Unaligned data, using slower bounce buffer -------------------------------- and then stops. BUG=chromium-os:16508 TEST=manual Launch onestop firmware and see it boots from internal mmc device (in normal or developer mode) or from external USB device (in developer or recovery mode) Change-Id: If8a2c98b0df7371bcd880a4aa470974e2cc6e544 Reviewed-on: http://gerrit.chromium.org/gerrit/2579 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: strictly check return value of block_{read,write}Che-Liang Chiou
The block device read/write functions return how many blocks are read or written. Instead of checking whether the return value is negative, we should check whether the requested number of blocks are actually read or written. BUG=chromium-os:16508 TEST=manual make ARCH=arm \ CROSS_COMPILE=armv7a-cros-linux-gnueabi- \ USE_PRIVATE_LIBGCC=yes \ VBOOT=/build/tegra2_seaboard/usr \ chromeos_seaboard_onestop_config make ARCH=arm \ CROSS_COMPILE=armv7a-cros-linux-gnueabi- \ USE_PRIVATE_LIBGCC=yes \ VBOOT=/build/tegra2_seaboard/usr \ all Change-Id: Ie6faada844a7b92e8f2a477b5e64b99d5cbf40fa Reviewed-on: http://gerrit.chromium.org/gerrit/2783 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29CHROMIUM: [6/6] refactor for onestop; kernel shared data initializerChe-Liang Chiou
* move kernel shared data initializer into a separated function * update document BUG=chromium-os:16508 TEST=manual; see first commit Change-Id: Ida90aefce5bcaf801868304a2d2d3db1b708fabe Reviewed-on: http://gerrit.chromium.org/gerrit/2746 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29CHROMIUM: [5/6] refactor for onestop; simplify load kernel processChe-Liang Chiou
* simplify load kernel process * update document BUG=chromium-os:16508 TEST=manual; see first commit Change-Id: Id17bfc537991b11547d98a9f92a9eff31cfdba7c Reviewed-on: http://gerrit.chromium.org/gerrit/2739 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: [4/6] refactor for onestop; simplify VbNvContext accessChe-Liang Chiou
* remove unneeded functions * udpate document BUG=chromium-os:16508 TEST=manual; see first commit Change-Id: I4cf5f8636f21aa97ce5aa5a52eac0a8e2890df0b Reviewed-on: http://gerrit.chromium.org/gerrit/2730 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: [3/6] refactor for onestop; simplify firmware storage accessChe-Liang Chiou
* remove support of RAM and NAND storage device * udpate document BUG=chromium-os:16508 TEST=manual; see first commit Change-Id: Ida09fa47956ff28146c230c7ae99b0ca4cf9d328 Reviewed-on: http://gerrit.chromium.org/gerrit/2724 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29CHROMIUM: [2/6] refactor for onestop; remove unused macroChe-Liang Chiou
* Remove unused macro MMC_DEV_NUM_SD BUG=chromium-os:16508 TEST=manual; see first commit Change-Id: I4e2097f03e51c1e955539c2e52136926be796908 Reviewed-on: http://gerrit.chromium.org/gerrit/2723 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29CHROMIUM: [1/6] refactor for onestop; remove obsolete filesChe-Liang Chiou
Compared to the old four firmware variants design, the onestop design is simpler, and as a result, many parts of the old codebase are overly complex or obsolete. This series of commits refactor the codebase and will give us a simpler and cleaner codebase, as our foundation of onestop firmware. Changes in this commits: * remove fmap.{h,c} - it was only for debugging purpose and very rarely useful; we should no longer maintain this feature * remove get_firmware_body.{h,c} - since in onestop design we never have to load a second-stage firmware * remove load_firmware_helper.{h,c} - same reason above BUG=chromium-os:16508 TEST=manual As all commits in series do not break build, you can run: make ARCH=arm \ CROSS_COMPILE=armv7a-cros-linux-gnueabi- \ USE_PRIVATE_LIBGCC=yes \ VBOOT=/build/tegra2_seaboard/usr \ chromeos_seaboard_onestop_config make ARCH=arm \ CROSS_COMPILE=armv7a-cros-linux-gnueabi- \ USE_PRIVATE_LIBGCC=yes \ VBOOT=/build/tegra2_seaboard/usr \ all Change-Id: I1fcec8a2056ac8fcc63e95e35e20e20071b3d93c Reviewed-on: http://gerrit.chromium.org/gerrit/2720 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: [7/7] fix to merely compilable; fix type conversion compiler warningsChe-Liang Chiou
This is the seventh of the seven commits in the series. For more information, please refer to the first commit. Changes in this commit: * fix compiler warnings due to type conversions * fix compiler warnings due to missing return value BUG=chromium-os:16508 TEST=manual; see the first commit Change-Id: I2732cd864d1ed6cb5a5cd81b34958f75594f717a Reviewed-on: http://gerrit.chromium.org/gerrit/2681 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: [5/7] fix to merely compilable; remove ref to ↵Che-Liang Chiou
CONFIG_VB_SHARED_DATA_BLOB This is the fifth of the seven commits in the series. For more information, please refer to the first commit. Changes in this commit: * remove reference to static buffer reserved for VbSharedData; the buffer for holding VbSharedData will be passed from the caller * set reference to new kernel buffer macros BUG=chromium-os:16508 TEST=manual; see the first commit Change-Id: I5ebe63319470f69ced61660b130e2fa992db2984 Reviewed-on: http://gerrit.chromium.org/gerrit/2679 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: [4/7] fix to merely compilable; rewrite VbNvContext accessor for ↵Che-Liang Chiou
new mmc driver This is the fourth of the seven commits in the series. For more information, please refer to the first commit. Changes in this commit: * rewrite VbNvContext accessor for new mmc driver BUG=chromium-os:16508 TEST=manual; see the first commit Change-Id: I4702cb12bddd985dec661ed13647d9a221526cbd Reviewed-on: http://gerrit.chromium.org/gerrit/2678 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: [3/7] fix to merely compilable; add mmc initializer and remove ↵Che-Liang Chiou
obsolete mmc and usb codes This is the third of the seven commits in the series. For more information, please refer to the first commit. Changes in this commit: * implement mmc device initializer for new mmc driver * remove obsolete mmc and usb probing codes BUG=chromium-os:16508 TEST=manual; see the first commit Change-Id: I40430a7bdc676fdddb473a09f2de3681fd250cb3 Reviewed-on: http://gerrit.chromium.org/gerrit/2701 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29CHROMIUM: [1/7] fix to merely compilable; delete obsolete filesChe-Liang Chiou
The compiler warnings and errors due to cherry-picking verified boot integration library into new u-boot codebase are fixed here. This and the following six commits only give you a compilable repository, and do not give you a working verified boot; neither onestop nor the old four-variants style of verified boot are supposed to be functioning. Changes in this commit: * delete obsolete files: - cpu_state.c - eeprom_driver.c * delete unused firmware storage device: - firmware_storage_{nand,ram}.c BUG=chromium-os:16508 TEST=manual After all seven commits are checked in, you should be able to run: make ARCH=arm \ CROSS_COMPILE=armv7a-cros-linux-gnueabi- \ USE_PRIVATE_LIBGCC=yes \ VBOOT=/build/tegra2_seaboard/usr \ chromeos_seaboard_onestop_config make ARCH=arm \ CROSS_COMPILE=armv7a-cros-linux-gnueabi- \ USE_PRIVATE_LIBGCC=yes \ VBOOT=/build/tegra2_seaboard/usr \ all Change-Id: I8a73e5536277a7c22dad3f95c1a33da90689a6f3 Reviewed-on: http://gerrit.chromium.org/gerrit/2676 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-29Read the RO/RW FWID from firmware storage instead of U-Boot version.Tom Wai-Hong Tam
As the conclusion in the bug http://crosbug.com/15633, we use the ChromeOS version string as RO/RW FWID. They are placed into the firmware during packing the whole firmware. The U-Boot should use the offsets to find the correct RO/RW FWID from firmware storage. BUG=chromium-os:15633 TEST=emerge-tegra2_kaen u-boot-config chromeos-u-boot-next chromeos-bios And run in ChromeOS Ctrl+Alt+T shell: $ crossystem | grep fwid fwid = 0.13.582.2011_06_01_1754 # Active firmware ID ro_fwid = 0.13.582.2011_06_01_1754 # Read-only firmware ID It also works on seaboard. Change-Id: Ie2b42a0a60e0479b933af959ae9914cde6963b0b Reviewed-on: http://gerrit.chromium.org/gerrit/1885 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29Add a bound of strcat to prevent buffer overflows.Tom Wai-Hong Tam
TEST=emerge chromeos-u-boot-next successfully BUG=none Change-Id: Idc7385776fabdcaa0942143264106be3f34bbb6c Reviewed-on: http://gerrit.chromium.org/gerrit/1809 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29can separately enable vboot-related debug outputChe-Liang Chiou
U-Boot debug output is very verbose, and sometimes does not help debugging verified boot related changes. This commit let us enable vboot-related debug output separately. BUG=chromium-os:15747 TEST=boot and see vboot-related debug output Cherry-pick: 84c65f7 Change-Id: I934d46654777347f09d9d3d71c55b3e478fd02c6 Reviewed-on: http://gerrit.chromium.org/gerrit/1532 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29support deprecated kernel cmdline substitution schemeChe-Liang Chiou
As the kernel-side CL related to kernel command-line processing are jammed up upstream, u-boot still has to support the deprecated kernel command-line variable substitution so that Chrome OS boots. This CL should be reverted after kernel-side CL is merged. BUG=none TEST=boot smoothly Change-Id: I3a0be2ad396668b3cc03b80183ef7ad3aed453b8 Reviewed-on: http://gerrit.chromium.org/gerrit/1531 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29go to recovery when kernel is brokenChe-Liang Chiou
BUG=chromium-os:15685 TEST=boot with a signed but unbootable kernel (e.g. a broken one) Change-Id: Ib1c023022a98b6e5dd0b2d699ed585e3b3b83ee7 Reviewed-on: http://gerrit.chromium.org/gerrit/1526 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29Variable substitution in kernel command-lineChe-Liang Chiou
Replace the following variables in kernel command-line: %D -> device number %P -> partition number %U -> GUID BUG=chromium-os:14022 TEST=boot kernel from usb, emmc, and sd card and verify cmdline is correct Change-Id: I4ed1be93ac46072c134effdb67817d1b0bc38716 Reviewed-on: http://gerrit.chromium.org/gerrit/1103 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
2011-08-29Refactor codesChe-Liang Chiou
This commits refactors the following aspects of codes: * Factor out common pattern of load and boot kernel from: + developer firmware + normal firmware + recovery firmware * Mark functions that are not used outside load_kernel_helper.c as static due to the above factorization: + boot_kernel() + load_kernel_config() + prepare_bootargs() * Remove unused first argument of reboot_to_recovery_mode() * Fix a compiler warning BUG=none TEST=CROSS_COMPILE=armv7a-cros-linux-gnueabi- ./MAKEALL chromeos Change-Id: I570b6ba1208772afbb4f26c0a74b83fa5375e29b Reviewed-on: http://gerrit.chromium.org/gerrit/920 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29Fill in frid and fwid as u-boot version.Tom Wai-Hong Tam
We need these informations in firmware update process. BUG=chromium-os:15249 TEST=build u-boot and update firmware. After boot, run in Chrome OS shell: $ crossystem | grep f.id fwid = U-Boot 2010.09 (May 17 2011 - 16:59:54) # Active firmware ID ro_fwid = U-Boot 2010.09 (May 17 2011 - 17:00:56) # Read-only firmware I Change-Id: I724c9ec7744e4e7417d19c82ec3316c7ea6852c2 Reviewed-on: http://gerrit.chromium.org/gerrit/1010 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29Boot from multiple USB portsChe-Liang Chiou
Recovery and developer firmware should boot from multiple USB ports. For mmc ports, we currently do not have an easy way to distinguish internal/external mmc ports; thus, we still hard-code mmc ports. BUG=chromium-os:15238 TEST=manual The recovery and developer firmware should boot from multiple USB ports. You should test the following combinations: * normal from internal eMMC * recovery from USB 0 * recovery from USB 1 * recovery from SD card * developer from internal eMMC * developer from USB 0 * developer from USB 1 * developer from SD card Change-Id: I6d203c3ddbb21327649b8738f6d77a367ae87880 Reviewed-on: http://gerrit.chromium.org/gerrit/1099 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29Get hwid from GBB and correct write-protect GPIO polarityChe-Liang Chiou
BUG=none TEST=[ $(crossystem wpsw_boot) = 1 ] && [ crossystem hwid = "$HWID_YOU_ASSIGNED" ] Cherry-pick: 5f30788 Change-Id: Id29b56748fafc6ad64cd336207ac7ef43befbbf5 Reviewed-on: http://gerrit.chromium.org/gerrit/1004 Reviewed-by: Rong Chang <rongchang@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29Implement developer firmwareChe-Liang Chiou
BUG=chromium-os:12191 TEST=manual 1. CROSS_COMPILE=armv7a-cros-linux-gnueabi- ./MAKEALL chromeos 2. Run developer firmware and verify that: 2.1 It responses to key strokes: ctrl-u, ctrl-d, space, enter, escape 2.2 Timer expires after 30 seconds Change-Id: Ifa4420dc478d60783c76e76424dd60cbced305ee Reviewed-on: http://gerrit.chromium.org/gerrit/666 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29Implement cold rebootChe-Liang Chiou
The verified boot spec requires that firmware cold (not warm) reboots so that TPM gets reseted. BUG=chrome-os-partner:3574 TEST=manual 1. Run load_fw twice, and verify that SetupTPM failed in the second run ------------------------------------------------------------ CrOS> cros load_fw 0x0 0x01000000 0x00400000 0x10000000 ... DEBUG: TPM: SetupTPM(r0, d0) ... DEBUG: TPM: SetupTPM() succeeded ... CrOS> cros load_fw 0x0 0x01000000 0x00400000 0x10000000 ... DEBUG: TPM: SetupTPM(r0, d0) ... DEBUG: Unable to setup TPM and read stored versions. ------------------------------------------------------------ 2. Run load_fw twice and a reset in between, and results the same ------------------------------------------------------------ CrOS> cros load_fw 0x0 0x01000000 0x00400000 0x10000000 ... CrOS> reset ... CrOS> cros load_fw 0x0 0x01000000 0x00400000 0x10000000 ------------------------------------------------------------ 3. Run load_fw twice and a "cros cold_reboot" in between, and verify that SetupTPM succeeds in both runs ------------------------------------------------------------ CrOS> cros load_fw 0x0 0x01000000 0x00400000 0x10000000 ... CrOS> cros cold_reboot ... CrOS> cros load_fw 0x0 0x01000000 0x00400000 0x10000000 ------------------------------------------------------------ Cherry-pick: bbb6ba7 Change-Id: Ie74bb214c80714d1814b4ae295c4780aa2bc7ddc Reviewed-on: http://gerrit.chromium.org/gerrit/756 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Rong Chang <rongchang@chromium.org>
2011-08-29Developer firmware template and refactor common codesChe-Liang Chiou
This commit defines a template of developer firmware, and factors out common codes that will be used between normal and developer firmware. BUG=chromium-os:12191 TEST=manual 1. CROSS_COMPILE=armv7a-cros-linux-gnueabi- ./MAKEALL chromeos 2. Run normal and recovery boot flow on kaen Change-Id: Ib3db0aaa09a5ca964d521af6323ab4366fb7c9bd Reviewed-on: http://gerrit.chromium.org/gerrit/586 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29Use the kernel config in the kernel image instead of the kernel script.Tom Wai-Hong Tam
There are two kernel config in our kernel image. One is the kernel script wh embedded in the bootloader address, only applied on ARM case. And the other is embedded in the kernel config area. All the vboot related tools use the latter. This change is to load the latter instead of former. Previous review feedback is in http://codereview.chromium.org/6905055/. BUG=chromium-os:14572 TEST=build u-boot-next and boot to a verified-boot image. Change-Id: I1712e3b43bd8dc2304804f8cafa1d1b670b64a86 Reviewed-on: http://gerrit.chromium.org/gerrit/523 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-29Recovery firmware should clear recovery requestChe-Liang Chiou
BUG=chromium-os:14996 TEST=manual 1. Press recovery button when booting 2. After the machine boots into recovery firmware, reset 3. Verify that the machine boots into normal firmware Change-Id: Ifdcc4ee4b35b7b0d0efe25afc8c1d04ee58c2395 Reviewed-on: http://gerrit.chromium.org/gerrit/513 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Che-Liang Chiou <clchiou@chromium.org>
2011-08-29Remove TPM functions and x86-specific CPU stateChe-Liang Chiou
The removed TPM functions are implemented in verified boot reference library (vboot_reference), and so this commit removes the implementation of these functions in u-boot. This commit also removes codes that are related to x86-specific CPU state (S3 resume). BUG=none TEST=CROSS_COMPILE=armv7a-cros-linux-gnueabi- ./MAKEALL chromeos Cherry-pick: 75707bc Change-Id: Id4a967b9dd16549bb26adbe27ce96caa713bfe30 Reviewed-on: http://gerrit.chromium.org/gerrit/515 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2011-08-24Make sure shared memory is intialized properly on test startups.Vadim Bendebury
Modify the 'cros load_k' command such that it would populate the nvram cache in the shared memory blob with the data read from its proper location in the MBR, and also have the wrapper function intialize the absolute address of the data buffer accessed by crossystem. BUG=chromium-os:12522 TEST=manual: . build all dev and flasher u-boot images . program the new dev u-boot image into a kaen . restart the target and drop through to u-boot shell . run 'cros nvram read' to see NVRAM contents . run 'cros nvram write <data>' to alter NVRAM contents . start up chromeos . install chromeos_arm driver . examine the shared memory contents, the nvram cache location in the buffer (16 bytes starting at offset of 28 bytes into the buffer) should match the one given to 'cros write' at u-boot prompt vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv CrOS> cros nvram read EMMC 0 Probed Successfully nvram content: 7000aabb0000000000000000000000ad content after VbNvSetup: 7000aabb0000000000000000000000ad CrOS> cros nvram write 70000102030405060708090a0b0c0d0e content after VbNvTeardown: 70000102030405060708090a0b0c0df0 CrOS> run vb # <== This starts up chromeos . . . localhost var # insmod chromeos_arm.ko localhost var # od -t x1 /sys/kernel/debug/chromeos_arm | head -4 0000000 3c 07 00 00 43 48 52 4f 4d 45 4f 53 00 00 01 00 0000020 00 00 00 00 00 00 00 00 00 00 10 00 70 00 01 02 0000040 03 04 05 06 07 08 09 0a 0b 0c 0d f0 00 00 00 00 0000060 01 00 01 01 20 02 00 00 41 52 4d 20 4b 41 45 4e localhost var # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Change-Id: I3144ae40a346341e48d127e8db80bd1d07e57783
2011-08-24Drop unused file parameter when accessing nvram contents.Vadim Bendebury
It seems that the nvram accessor functions have evolved and use a parameter which is not needed anymore. This CL adds the nvram caching in the shared memory blob and removes the unnecessary parameter from all instances where nvram accessor functions are used. BUG=chromium-os:12522 TEST=manual: . build all u-boot images, observe clean compilation It turns out that drivers/tpm/slb9635_i2c/tpm.c:transmit_cmd() is an unused static function, and is reported as such during building the u-boot image. This will have to be addressed separately. Change-Id: Ic2a39ad151bc7801bad5b68bd44edd71d5660dcb
2011-08-24Change the shared memory structure.Vadim Bendebury
This change modifies the shared memory structure such that the fields of interest for the kernel (vbnv and nvcxt_cache) bubble up to the base of the structure. The kernel side change requiring this modification is being submitted under http://codereview.chromium.org/6902164/ Also, this eliminates the gpio array in the shared memory and introduces fields to convey actual states of the bits of interest (wrote_protect, recovery and developer mode). The crossystem changes using this CL are being prepared under http://codereview.chromium.org/6902172. The kernel changes using this CL are being reviewed under http://codereview.chromium.org/6902164/ BUG=chromium-os:12522 TEST=manual See http://codereview.chromium.org/6902164 for test description. Change-Id: Ifdba918ff0287e3f11851b95a0919a61370fb564
2011-08-24Allow to create shared memory space without loading kernel.Vadim Bendebury
This change provides the ability to create the shared memory blob without invoking the verified boot Loadkernel() function. Setting environment variable `bypass_load_kernel' to any value will prevent invoking Loadkernel() by the 'cros load_k' cli command. This makes debugging the shared memory issues much easier as the user can load the kernel by other means (like netbooting) but still have the shared memory structure in place. This CL also rearranges the shared memory structure (such that fields the kernel driver cares about are moved to the base of the structure) and introduces a field to convey the size of the shared memory structure. This allows the kernel driver to be oblivious to the actual data layout of the remainder of the structure and to make potential future layout changes transparent for the driver. Change-Id: I03d879c180ad5869bab6c2e21d92c5a8d90c0c43 BUG=None TEST=manual, see below: The test requires availability of the kernel on a tftp host, proper kernel command line in the environment and root file system present on a drive. . program the updated u-boot image on kaen . restart it and catch in u-boot shell . enter the following command sequence: setenv bypass_load_kernel 1 usb start dhcp tftpboot ${loadaddr} server:path cros load_k 1 2 # using dummy parameters 1 and 2 bootm . wait for the target to start up . install the chromeos_arm module and observe it report finding the signature. Review URL: http://codereview.chromium.org/6902086
2011-08-24Store VbNvContext in MBRChe-Liang Chiou
The VbNvContext cookie has to be stored in a place that firmware and kernel can access even before the partition table is created. So the EFI partition is not a good candidate of storage. On ARM platforms the MBR is not used by any part of the system, and so it is quite safe to use MBR for VbNvContext storage. This commit also reverts commit 8e23ac. Note: The VbNvContext was stored in SPI flash, but it turned out that kernel could not access SPI flash due to driver issues. So the storage was temporarily moved to eMMC device. R=rongchang@chromium.org BUG=none TEST=none Review URL: http://codereview.chromium.org/6878095 Change-Id: Ie460318a653c54060dfc238a8d3bd77ade16c59b
2011-08-24HACK: Pass data from firmware to kernelChe-Liang Chiou
Changes here is an urgent workaround for factory bring up, and should be reverted or significantly rewritten after the protocol specification between Chrome OS firmware and kernel is finalized. R=rongchang@chromium.org BUG=chromium-os:13609 TEST=none Review URL: http://codereview.chromium.org/6804009 Change-Id: I36d2e1f190b2edc1bc771a768c6ed01eae25b453
2011-08-24Store VbNvContext in a file on EFI partitionChe-Liang Chiou
Doing so makes kernel and user space programs easier to access VbNvContext. R=rongchang@chromium.org BUG=none TEST=run "cros nvram" Review URL: http://codereview.chromium.org/6882037 Change-Id: Ibcbd6da6330bedd876889c3ae3eac35a468d82e7
2011-08-24Find proper device index when access VbNvContext on eMMCChe-Liang Chiou
R=rongchang@chromium.org BUG=none TEST=none Review URL: http://codereview.chromium.org/6879004 Change-Id: I43dbd540e4df90dcd70efa1d987021b748d754ce
2011-08-24HACK: Temporarily change VbNvContext from SPI to eMMCChe-Liang Chiou
So far kernel does not have a SPI flash driver. That means kernel cannot access VbNvContext in SPI flash for now. Here is a temporary workaround for factory bring up that changes the VbNvContext storage device from SPI flash to eMMC, where we are certain that kernel is able to access. R=rongchang@chromium.org BUG=none TEST=none Review URL: http://codereview.chromium.org/6825069 Change-Id: I60059ef23e57facc278340db6613caa83c76529a
2011-08-24Remove primary_firmware index variableChe-Liang Chiou
The verified boot spec has been changed, and so this index variable is not longer needed. R=rongchang@chromium.org BUG=none TEST=MAKEALL successfully Review URL: http://codereview.chromium.org/6851011 Change-Id: I595c4b9babe69f6ebea9d5d10304844a622422d9
2011-08-24Remove executing scripts in EFI partitionChe-Liang Chiou
Executing scripts in EFI partition is insecure because stuff in EFI partition is unsigned. R=waihong@chromium.org BUG=chromium-os:13064 TEST=boot to Chrome OS and verify that kernel command-line is correct Review URL: http://codereview.chromium.org/6824072 Change-Id: I0e01d43d27425e8fb7392ad29d1c059493ec5325
2011-08-24Fill in a successful response when no hardware TPM.Tom Wai-Hong Tam
Caller functions also check the response value. Since the original value is declared in the stack and uninitialized. If we don't change it, the result is unpredictable. BUG=none TEST=build and run bootstub firmware: U-Boot 2010.09-00080-g4eccccb-dirty (Apr 01 2011 - 15:47:42) Board: Tegra2 chromeos/tegra2/seaboard/stub DRAM: 1 GiB Using default environment In: tegra-kbc Out: lcd Err: lcd Hit any key to stop autoboot: 0 SF: Detected W25Q16B with page size 256, total 2 MiB DEBUG: LoadFirmware started... DEBUG: VbSharedDataInit, 16384 bytes, header 1072 bytes DEBUG: TPM: Startup DEBUG: TPM: command: 0c1 000c 00099 DEBUG: TPM: response: 00 000a 0000 DEBUG: TPM: command 0x99 returned 0x0 DEBUG: TPM: Continue self test DEBUG: TPM: command: 0c1 000a 00053 DEBUG: TPM: response: 00 000a 0000 DEBUG: TPM: command 0x53 returned 0x0 DEBUG: Checking key block signature... DEBUG: Firmware 0 is valid. DEBUG: VbSharedDataReserve 1032 bytes at 1072 DEBUG: Checking key block signature... DEBUG: TPM: command: 0c1 00022 00014 DEBUG: TPM: response: 00 000a 0000 DEBUG: TPM: command 0x14 returned 0x0 DEBUG: TPM: SetTPMBootModeState boot mode PCR out_digest 281f6b4 281f6b5 281f6b6 281f6b7 DEBUG: Will boot firmware index 0 load_firmware_wrapper: will jump to rewritable firmware 0 ... Change-Id: Ibb785d720c45b37f62395fef446339f7e77ee1d5 R=rongchang@chromium.org BUG= Review URL: http://codereview.chromium.org/6771044
2011-08-24This is the preliminary v05 TPM driver from Infineon. With a wrapper layer ↵Rong Chang
added to auto detect v03 and v05 chips. This is a version that just work. Cleanup will start after the initial push. BUG=chromium-os:10497 TEST=Manual Build 1. build a compatible lib first emerge-tegra2_seaboard vboot_reference-firmware 2. use MAKEALL script to check all cfg CROSS_COMPILE=armv7a-cros-linux-gnueabi- VBOOT=/build/tegra2_seaboard/usr ./MAKEALL chromeos 3. check result. 25 passed, no warning, no error u-boot command 1. build a compatible version USE-debug VBOOT_DEBUG=1 emerge-tegra2_seaboard -av vboot_reference-firmware chromeos-u-boot-next 2. flash it using proper tools [board specific] 3. reset system and boot into command prompt 4. test with cros_tpm_test command sets: cros_tpm_test enable cros_tpm_test fast_enable cros_tpm_test startup cros_tpm_test timing Review URL: http://codereview.chromium.org/6683023 Change-Id: I37b73dc90399533594c841b016a194ff21ab889a
2011-08-24Get/set VbNvContext cookies from SPI flashChe-Liang Chiou
BUG=chromium-os:10503 TEST=MAKEALL successfully Review URL: http://codereview.chromium.org/6723013 Change-Id: Iabccfe8bdf473545cdff834c5628f969b3990291
2011-08-24Add implementation of SPI firmware storage interfaceChe-Liang Chiou
R=robotboy@chromium.org,waihong@chromium.org BUG=chromium-os:13063 TEST=see cl/6676109 Review URL: http://codereview.chromium.org/6696066 Change-Id: Ief655c3055cf8e0857a67085f4c76d8862a7228b
generated by cgit v1.2.3 (git 2.0.4) at 2024-07-08 00:42:37 +0000