3f4d8d05ba4e32990c8584bd47cdf082d4604232 |
|
02-Dec-2014 |
Dan Ehrenberg <dehrenberg@chromium.org> |
vboot: Plumb the two disk sizes and external GPT param through This patch reinstates the external GPT support which was previously committed and reverted. Improvements since last time include: - Cleaned-up internal interface based on code review - Function correctly on legacy bootloaders (e.g., depthcharge before NAND-related patches are added) - Better comments - Treat new field values = 0 -> not use new feature - Tests are added to ensure external GPT flag is passed down properly The original commit had change-id I5a77e417aea8ee9442d18c200d1b073aa5375ecf Its commit message is reproduced below, and then an additional test. ---- To support an external GPT, disks have two new attributes: - A binary flag indicating whether the GPT is in the same address space as the payloads or a separate one. - The number of sectors of the streaming portion of storage, as opposed to the portion containing the GPT. These have been added elsewhere to GptData (in cgptlib) and BlockDev (in depthcharge). This patch adds the plumbing between those, including in the DiskInfo interface between the firmware and vboot. BUG=chromium:425677 BRANCH=none TEST=Interactively wrote the GPT with cgpt and observed the following boot with depthcharge to read the GPT from SPI and then read from the proper locations in NAND flash. TEST=make runalltests passes. TEST=boots from USB with depthcharge from HEAD. Change-Id: Ia7956517a7b9da0301f01fac5a10204f6d78cf4f Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/234640 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel_tests.c
|
79a9e0e63fd1001a3f9615f96c09acba5f20250d |
|
15-Nov-2014 |
Julius Werner <jwerner@chromium.org> |
Revert "vboot: Plumb the two disk sizes and 'gpt on device' param through" This reverts commit 5040a945dfd0dd305d3ca8e923b8bf0bd5c6528e. This patch breaks booting any image (both fixed and removable) on Veyron_Pinky (and presumably every other non-NAND board?). By the power vested in me through the office of ChromeOS tree sheriff (well, five hours early but whatever) it is hereby reverted! BUG=chromium:425677 BRANCH=none TEST=Can successfully boot on Veyron_Pinky again. Change-Id: I9323a3d5e34491337fc7eb09dd00d845ac42997d Reviewed-on: https://chromium-review.googlesource.com/229963 Reviewed-by: Julius Werner <jwerner@chromium.org> Commit-Queue: Julius Werner <jwerner@chromium.org> Tested-by: Julius Werner <jwerner@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel_tests.c
|
5040a945dfd0dd305d3ca8e923b8bf0bd5c6528e |
|
05-Nov-2014 |
Dan Ehrenberg <dehrenberg@chromium.org> |
vboot: Plumb the two disk sizes and 'gpt on device' param through To support an external GPT, disks have two new attributes: - A binary flag indicating whether the GPT is in the same address space as the payloads or a separate one. - The number of sectors of the streaming portion of storage, as opposed to the portion containing the GPT. These have been added elsewhere to GptData (in cgptlib) and BlockDev (in depthcharge). This patch adds the plumbing between those, including in the DiskInfo interface between the firmware and vboot. BUG=chromium:425677 BRANCH=none TEST=Interactively wrote the GPT with cgpt and observed the following boot with depthcharge to read the GPT from SPI and then read from the proper locations in NAND flash. make runalltests passes. Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org> Change-Id: I5a77e417aea8ee9442d18c200d1b073aa5375ecf Reviewed-on: https://chromium-review.googlesource.com/228943 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel_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_kernel_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_kernel_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_kernel_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_kernel_tests.c
|
3401fdcd4125beea1a8cb1cc59ee27df89d4d88a |
|
16-Aug-2013 |
Simon Glass <sjg@chromium.org> |
Correct some minor compiler warnings A few places in the code through up warnings when building with strict compiler flags. Correct these. BUG=chrome-os-partner:21115 BRANCH=pit TEST=manual Build with: FEATURES=test emerge-peach_pit vboot_reference and see that iot now succeeds. Warnings include: host/arch/arm/lib/crossystem_arch.c: In function 'ReadFdtValue': host/arch/arm/lib/crossystem_arch.c:93:8: error: ignoring return value of 'fread', declared with attribute warn_unused_result [-Werror=unused-result] Change-Id: I765723636e5f8979b794925c7b610081b2849026 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66174
/external/vboot_reference/tests/vboot_api_kernel_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_kernel_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_kernel_tests.c
|
0714d9de56da3a5c686b26755d15aa6788c727d4 |
|
05-Feb-2013 |
Randall Spangler <rspangler@chromium.org> |
Fix and enable vboot_api_kernel_tests Previously, these were not being run, and failed due to a test config problem when they were run (vboot_api_kernel.c worked correctly, but the test checked the wrong recovery reason). BUG=chromium-os:38139 BRANCH=none TEST=make runtests && FEATURES=test emerge-daisy vboot_reference Change-Id: Ibefe5fe32f99a2c40f619a85df1bbfc81eb0c26c Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/42668
/external/vboot_reference/tests/vboot_api_kernel_tests.c
|
7c55708979036bff83370036034d8d2cea3053ed |
|
05-Feb-2013 |
Randall Spangler <rspangler@chromium.org> |
Reformat to kernel style No code changes, just reformatting. BUG=none BRANCH=none TEST=make runtests Change-Id: Ibffadf6c8a5911b79a29f8f554ca00c595f6b27b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/42624
/external/vboot_reference/tests/vboot_api_kernel_tests.c
|
172360ec5dc9b5a620d677a985ece05f4e0301bd |
|
09-Sep-2012 |
Gabe Black <gabeblack@chromium.org> |
Replace %L with %ll in format strings. %L is, in some standard libraries like U-Boot's, a synonym for %ll which is for long long integers, required by the C99 standard to be at least 64 bits. For practical purposes that basically means %ll should be used with 64 bit values. Since %L seems to be non-standard and, at least in U-Boot's case, %ll is recognized in the same way, %ll seems preferable. BUG=chrome-os-partner:8339 TEST=Booted ChromeOS using depthcharge and U-Boot. Booted with depthcharge/libpayload which does not support %L and saw a number where %L had been printed. BRANCH=None Change-Id: Id51fb5c9295e0dd65b42a5c0738eb34c8210a2b2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/32660 Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel_tests.c
|
ee2e590ff0db1f0a0c5f6a8122d7c090ea833924 |
|
27-Jan-2012 |
Bill Richardson <wfrichar@chromium.org> |
Bah. Fix the test, too. BUG=chrome-os-partner:7775 TEST=none Change-Id: Id1409808b69f5c8f5b5e2244bb8bf6c7591cba0c Reviewed-on: https://gerrit.chromium.org/gerrit/14968 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel_tests.c
|
bf020a0d4db68897058503767067567565450dde |
|
25-Jan-2012 |
Bill Richardson <wfrichar@chromium.org> |
Make VbTryLoadKernel() go to recovery when no valid disks are found Previously, it was going to recovery only when no disks existed. That didn't catch the case where disks exist but none of them are usable. BUG=chrome-os-partner:7715 TEST=manual I've added a test specifically for this, so just make make runtests should verify it. To test on actual hardware, find a disk or USB drive that has something other than 512 bytes per LBA, and try it. It won't be bootable, but using it shouldn't hang the system or cause weird behavior. Once in recovery, press TAB, and you should see the reason code VBNV_RECOVERY_RW_NO_DISK Change-Id: I475ddd01e13fa806025a2107c260c030d098a17e Reviewed-on: https://gerrit.chromium.org/gerrit/14816 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Commit-Ready: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/tests/vboot_api_kernel_tests.c
|