487a54bcbe7b6dac1a856b0991e6d13c34a1c423 |
|
27-Jul-2014 |
Sheng-Liang Song <ssl@chromium.org> |
vboot: Notify EC of current boot mode Notify EC of boot mode, i.e. normal, developer or recovery. This is necessary for battery firmware updates. BUG=chrome-os-partner:24741 CQ-DEPEND=CL:205323 CQ-DEPEND=CL:210033 CQ-DEPEND=CL:215720 BRANCH=ToT TEST=Verified on samus & glimmer. Passed runalltests. ~/trunk/src/platform/vboot_reference $ make runalltests -j Change-Id: I1613ede34b4a929d1e8114fb519861f349377e94 Signed-off-by: Sheng-Liang Song <ssl@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/210032 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
e778adae83d2ac4ab94aa10acceab328bbd3ea7b |
|
16-Jul-2014 |
Randall Spangler <rspangler@chromium.org> |
Change VbExEc functions to take a devidx parameter This will be used in subsequent CLs to support PD software sync. For now, only devidx=0 is used. This changes the external vboot API, so must be checked in at the same time as changes to the u-boot and depthcharge implementations. For now, those implementations should simply check if devidx=0 and fail if it's not. BUG=chrome-os-partner:30079 BRANCH=none TEST=make runtests CQ-DEPEND=CL:208195,CL:208196 Change-Id: Iad3be9d676ac224c4582669bcd67176b39f75c73 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/208210 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
a53a0b040f45a1086515e7a5c8a8326c0b1d1f74 |
|
11-Jan-2014 |
Luigi Semenzato <semenzato@chromium.org> |
vboot: use recovery button as dev mode switch confirmation We don't allow ENTER from a USB keyboard as the confirmation in the switch from normal to developer mode. For devices that have a physical recovery button, we require a recovery button press instead. For other devices, we require that ENTER be pressed on the internal keyboard. This prevents an "evil keyboard" attack in which a USB keyboard (or other USB device pretending to be a keyboard) sends a control-D/ENTER sequence shortly after every boot (followed by more evil keys). In that situation, when users power-on in recovery mode, they will be forced to dev mode even if it was not their intention. Further attacks are easy at that point. TESTING. On a panther device: 1. powered on with recovery button pressed -> booted in recovery mode 2. pressed control-D on external USB keyboard -> got to ToDev? screen 3. pressed ENTER -> system beeped 4. pressed recovery button -> system rebooted in DEV mode ... all as expected Also: 1. powered on with recovery button pressed and HELD recovery button 2. pressed control-D -> system beeped BUG=chrome-os-partner:21729 TEST=manual (see commit message) BRANCH=none CQ-DEPEND=CL:182420,CL:182946,CL:182357 Change-Id: Ib986d00d4567c2d447f8bbff0e5ccfec94596aa7 Reviewed-on: https://chromium-review.googlesource.com/182241 Reviewed-by: Luigi Semenzato <semenzato@chromium.org> Tested-by: Luigi Semenzato <semenzato@chromium.org> Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
04171532583052935121a3e33550cc39ef2625ec |
|
13-Dec-2013 |
Shawn Nematbakhsh <shawnn@chromium.org> |
VbBootRecovery: Make second check for 'remove' devices if none found There is some inherent latency between the time the USB root hub is initialized and the time USB devices are detected. This can lead to a situation where USB media is attached, yet not found when we do our initial device poll. The device may be detected in subsequent polls, so the media can be booted and no 'remove' screen will be displayed. With this change, if no media to remove is initially found, a second poll will be made after a 500ms delay. This will be enough time for USB devices to be correctly detected in our test cases. Also, it is necessary to change the unit test due to the fact that we now call VbExDiskGetInfo twice before actually displaying any screen. TEST=Manual on Monroe. Insert USB media and trigger recovery boot. Verify 'remove' screen is seen, 'insert' screen is seen after removing media, and system boots after re-inserting media. Also passes vboot_reference unit tests. BUG=chrome-os-partner:23840 BRANCH=Panther, Monroe Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Ia902c3a126588cd7ea618f2dbbca6b38d35d6ea0 Reviewed-on: https://chromium-review.googlesource.com/179757 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
2500185a83b453580f187087fffc6376f19f8ff0 |
|
16-Aug-2013 |
Simon Glass <sjg@chromium.org> |
Add memory leak checking Add checks that the vboot library does not leak memory. This works by tracking VbExMalloc() calls and making sure that they have an associated VbExFree(). Adjust host_signature to use VbExFree() instead of free(), so that this scheme works correctly for existing code. BUG=chrome-os-partner:21115 BRANCH=pit TEST=FEATURES=test emerge-peach_pit vboot_reference Change-Id: I6ccccfbcc162fc43fb75862cd0eddad78ce8b18a Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/66175
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
527ba810eff4006cf69579f6b96cb4350cb1e189 |
|
25-Jul-2013 |
Simon Glass <sjg@chromium.org> |
Implementation of Region API At present reading data from storage in Vboot is a little fragmented. For the firmware image, we expect the boot loader to handle this. For the disk we have a block-level API. For the GBB (which also sits in the firmware image) we expect the entire thing to be read before Vboot is called. Add the concept of a region, and an API to read from a region. At present, and most pressing, is reading from a GBB region. In the future this could be extended to other parts of the firmware or even the disk. Move all access to the GBB into this API so that the boot loader can provide either a GBB region in one large contiguous chunk, or a function to deal with read requests from vboot. The call to VbExRegionRead() is behind a flag since not all boot loaders support it yet. The main change for boot loaders which don't support this new API is that vboot will do more behind the scenes. For example, it will allocate memory for chunks of data that it reads from the GBB, rather than just accessing it directly. This approach is considerably simpler than trying to pass char ** everywhere and have vboot decide whether something needs to be allocated or not. The tests are updated, mainly to include setting up a GBB structure accessible from VbCommonParams, which is now required by the firmware and kernel functions. In normal operation this is set up at the start of VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call children of these functions directly, the GBB structure must be set up manually by the test. BUG=chrome-os-partner:21115 BRANCH=none TEST=manual FEATURES=test sudo -E emerge vboot_reference Change-Id: If2b8bbe467fdbd643239d8d9b5d7aa98df4d286f Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/63336 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167361
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
8fa13ad6f727d44fdc0ae1d2bde5f54b32dab9b9 |
|
29-Aug-2013 |
Yoshiki Iguchi <yoshiki@chromium.org> |
Revert "Implementation of Region API" This reverts commit 1d3c804b6b9d2ffb6953a7ee98fabfd548915ad7. This patch breaks cbuildbot on internal paladins bots. Change-Id: Icf7f9d9bbb56b092035888eaa3e249ffd23fac16 (cherry picked from commit 3a60335ebb1530e5fd9d5da3bc6214949bc59caf) Reviewed-on: https://chromium-review.googlesource.com/167451 Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org> Commit-Queue: Yoshiki Iguchi <yoshiki@chromium.org> Tested-by: Yoshiki Iguchi <yoshiki@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
1d3c804b6b9d2ffb6953a7ee98fabfd548915ad7 |
|
25-Jul-2013 |
Simon Glass <sjg@chromium.org> |
Implementation of Region API At present reading data from storage in Vboot is a little fragmented. For the firmware image, we expect the boot loader to handle this. For the disk we have a block-level API. For the GBB (which also sits in the firmware image) we expect the entire thing to be read before Vboot is called. Add the concept of a region, and an API to read from a region. At present, and most pressing, is reading from a GBB region. In the future this could be extended to other parts of the firmware or even the disk. Move all access to the GBB into this API so that the boot loader can provide either a GBB region in one large contiguous chunk, or a function to deal with read requests from vboot. The call to VbExRegionRead() is behind a flag since not all boot loaders support it yet. The main change for boot loaders which don't support this new API is that vboot will do more behind the scenes. For example, it will allocate memory for chunks of data that it reads from the GBB, rather than just accessing it directly. This approach is considerably simpler than trying to pass char ** everywhere and have vboot decide whether something needs to be allocated or not. The tests are updated, mainly to include setting up a GBB structure accessible from VbCommonParams, which is now required by the firmware and kernel functions. In normal operation this is set up at the start of VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call children of these functions directly, the GBB structure must be set up manually by the test. BUG=chrome-os-partner:21115 BRANCH=none TEST=manual FEATURES=test sudo -E emerge vboot_reference Change-Id: I2c19e9dc2ed602d0642bbf4f7d27f79fe9fad873 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/63336 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
f2a1dc0a54ec542dd4be7b634483de317c89a2a2 |
|
12-Jun-2013 |
Randall Spangler <rspangler@chromium.org> |
Add GBB flags for disabling software sync and defaulting to legacy boot 1) GBB flag to skip EC software sync, so EC will be untouched. Needed for EC development. 2) GBB flag to default to booting legacy at end of dev screen timeout. Very handy for booting Ubuntu (or other OS). Also added unit tests for the new flags. BUG=chrome-os-partner:20111 BRANCH=none TEST=make runtests Change-Id: I9da87d87014881a1b1393b0b4a5acb921d080066 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58270 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
0c3ba249abb1dc60f5ebabccf84ff13206440b83 |
|
29-Mar-2013 |
Bill Richardson <wfrichar@chromium.org> |
Massive refactoring of external header files. This reduces the number of exported header files to the minimum needed by the existing userspace utilities and firmware implementations. BUG=chromium:221544 BRANCH=none TEST=manual, trybots CQ-DEPEND=CL:47019,CL:47022,CL:47023 sudo FEATURES=test emerge vboot_reference FEATURES=test emerge-$BOARD \ vboot_reference \ chromeos-cryptohome \ chromeos-installer \ chromeos-u-boot \ peach-u-boot \ depthcharge Change-Id: I2946cc2dbaf5459a6c5eca92ca57d546498e6d85 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/47021 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|
7f43669630cb42e40ca6ddc1128eefea8fd339d9 |
|
05-Feb-2013 |
Randall Spangler <rspangler@chromium.org> |
Add more vboot_api_kernel tests BUG=chromium-os:38139 BRANCH=none TEST=make runtests && FEATURES=test emerge-daisy vboot_reference Change-Id: Ib280b80ba707f8a2141d728f78ae296774b1301a Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/42669
/external/vboot_reference/tests/vboot_api_kernel2_tests.c
|