summaryrefslogtreecommitdiff
path: root/utility/load_kernel_test.c
Commit message (Collapse)AuthorAgeFilesLines
* Revert "vboot: Plumb the two disk sizes and 'gpt on device' param through"stabilize-6480.Bfactory-ryu-6486.Bfactory-ryu-6486.1.BJulius Werner2014-11-151-1/+0
| | | | | | | | | | | | | | | | | | | | 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>
* vboot: Plumb the two disk sizes and 'gpt on device' param throughDan Ehrenberg2014-11-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Implementation of Region APIstabilize-4636.BSimon Glass2013-08-301-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Implementation of Region API"Yoshiki Iguchi2013-08-291-4/+1
| | | | | | | | | | | | | 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>
* Implementation of Region APISimon Glass2013-08-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Get rid of some crufty macros.Gabe Black2013-03-191-3/+4
| | | | | | | | | | | | | | | | | | | | | | | These were macros that were never used, or that were only set to one thing and could be substituted up front. I left in code guarded by the HAVE_ENDIAN_H and HAVE_LITTLE_ENDIAN macros even though those are never defined because they guard a reportedly significantly faster implementation of some functionality, at least according to a comment in the source. It would be a good idea to enable that code path and see if it really does make a big difference before removing it entirely. BUG=None TEST=Built for Link, Daisy, and the host with FEATURES=test. Built depthcharge for Link and booted in normal mode. BRANCH=None Change-Id: I934a4dd0da169ac018ba07350d56924ab88b1acc Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/45687 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
* Omit body load address checkChe-Liang Chiou2012-04-241-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | Omit this check because this check is not really necessary and it is dealing more harms than goods to ARM boards. While body load address is configurable, it is not quite possible to fix all the build scripts and runtime scripts to carry this address; so in reality all scripts use the default body load address. The problem is, this default address is not friendly to ARM boards, and it virtually makes this check fails on ARM boards. BUG=chromium-os:28077 TEST=emerge-{daisy,x86-alex} vboot_reference TEST=load_kernel_test -b 1 chromiumos_image.bin TEST=run verified boot on Daisy Change-Id: I1a1cc0aedf254e2a2b680046812ab7154f26dea7 Reviewed-on: https://gerrit.chromium.org/gerrit/20947 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
* Move VbNvContext setup/teardown to vboot wrapper funcsRandall Spangler2011-07-261-0/+1
| | | | | | | | | | BUG=chromium-os:18226 TEST=make && make runtests Change-Id: Ie22e99a9796866e646ed92158410bc7a2fdf90f6 Reviewed-on: http://gerrit.chromium.org/gerrit/4754 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Randall Spangler <rspangler@chromium.org>
* Refactor LoadFirmware() and LoadKernel() to return VbError_tRandall Spangler2011-07-261-3/+4
| | | | | | | | | | BUG=chromium-os:18161 TEST=make && make runtests Change-Id: I1f60654fef84e26ee15fa8bdaacdb87fb1ddf69e Reviewed-on: http://gerrit.chromium.org/gerrit/4676 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Add support for merged normal+dev firmwareRandall Spangler2011-07-111-9/+0
| | | | | | | | | | | | | | | BUG=chromium-os:17457 TEST=make && make runtests When this is merged into an actual firmware build, can test it: * dev switch off -> no dev screen, won't boot self-signed kernel * dev switch on --> dev warning screen, will boot self-signed kernel (e.g., it acts like the Cr-48) Change-Id: I985428256e48b7e05dd4d8fe582a0c0103bf5fb2 Reviewed-on: http://gerrit.chromium.org/gerrit/3901 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Randall Spangler <rspangler@chromium.org>
* Vboot wrapper initial implementationRandall Spangler2011-07-081-7/+8
| | | | | | | | | | | | | | | | | | Patch 1: Initial change Patch 2: Fix comment in vboot_struct.h Patch 3: Revert files unintentionally reverted Patch 4: (rebase) Patch 5: (rebase) Patch 6: Revert files unintentionally reverted (again) Patch 7: Fix mocked tlcl for ARM build BUG=chromium-os:17010 TEST=make && make runtests; works on H2C; emerge-tegra2_seaboard chromeos-bootimage compiles Change-Id: I6e5ce72d41b9297c07a3f330a881eba68cfabee2 Reviewed-on: http://gerrit.chromium.org/gerrit/3593 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Verified boot wrapper - add stub implementations for hostRandall Spangler2011-06-271-10/+8
| | | | | | | | | | | | | | | This is part 2 of the wrapper API refactor. It adds stub implementations for the host, and changes the host-side utilities to use them. Firmware implementation is unchanged in this CL (other than a few updates to macros). BUG=chromium_os:16997 TEST=make && make runtests Change-Id: I63989bd11de1f2239ddae256beaccd31bfb5acef Reviewed-on: http://gerrit.chromium.org/gerrit/3256 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Add VbSharedData field parsingRandall Spangler2011-03-171-2/+2
| | | | | | | | | | | | | | | | | | | | | R=reinauer@chromium.org BUG=chrome-os-partner:2578 TEST=manual crossystem vdat_timers should show 'LFS=0,0 LF=number1,number2 LK=number3,number4' where number1 < number2 < number3 < number4 crossystem vdat_lfdebug run from a dev mode console, should show 'check=12,0 index=0x00 tpmver=(hex number) lowestver=(hex number)' crossystem vdat_flags run from a dev mode console, flags should be 0x04. Review URL: http://codereview.chromium.org/6685068 Change-Id: Id7b958ae300d10cdcdc1b17a1bb17b7e5069166f
* This is necessary to pass additional information about whether firmware A or ↵Randall Spangler2011-03-091-4/+50
| | | | | | | | | | | | | | | | | | | | | | | B is being run. This change also passes the GBB directly into LoadFirmware() and LoadKernel(). Change-Id: I976c11c82c3d665a4feb88226e919f16c2440f60 BUG=chrome-os-partner:1657 TEST=manual - see below make && make runtests Then test verifying a test image in both dev mode (-b1, no key specified) and recovery mode (key specified) build/utility/load_kernel_test -b1 ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin build/utility/load_kernel_test ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin tests/devkeys/recovery_key.vbpubk And make sure the firmware with this change actually boots to USB and SSD. NOTE: u-boot-next needs to change to work with this change. will attempt a follow-up CL with that change Review URL: http://codereview.chromium.org/6626045
* Reapply patch from http://codereview.chromium.org/6594092/Randall Spangler2011-03-031-0/+3
| | | | | | | | | | | (somehow that never got committed) Change-Id: I304e594066c5dd72fc7cf37d31e27b1096ae1a38 BUG=12282 TEST=make && make runtests Review URL: http://codereview.chromium.org/6610019
* Support dev vs consumer firmware in vboot_referenceRandall Spangler2011-02-141-0/+9
| | | | | | | | | Change-Id: I5a42ba017974b3d591abc574ef7b9b7c9ac579e8 BUG=chrome-os-partner:1824 TEST=make && make runtests Review URL: http://codereview.chromium.org/6462010
* Changes to allow user-signed kernels to be generated.Bill Richardson2010-08-091-18/+57
| | | | | | | | | | | | | Make vbutil_keyblock handle unsigned blocks. Also enable --unpack option and add tests for it. Modify vbutil_kernel to allow unsigned keyblocks, correct usage message, and fix the --debug option which was somehow disabled. Update load_kernel_test to accept /dev/null for the public key, to test non-signed kernel keyblocks. Review URL: http://codereview.chromium.org/3124004
* Make LoadKernel() pass back the kernel partition's UniqueGuid.Bill Richardson2010-07-231-0/+19
| | | | | | | | | | | | | LoadKernel already returns the partition number for the selected kernel. This change makes it also return the GPT Entry's UniqueGuid, which will eventually be passed to the kernel itself, so the kernel can determine which of several possible devices it has booted from. It doesn't know for certain because the BIOS and the kernel may enumerate the devices in a different order. BUG=chromium-os:4984 Review URL: http://codereview.chromium.org/3056014
* Fix load_kernel_test, add check to LoadKernel to detect bad args.Bill Richardson2010-07-221-0/+1
| | | | | | | | | load_kernel_test was failing because it wasn't setting params->kernel_buffer_size before calling LoadKernel(). This fixes that, plus adds some checks to LoadKernel so that it will notice bad params if it happens again. Review URL: http://codereview.chromium.org/3060004
* Add lots of debugging to TPM library.Randall Spangler2010-07-191-1/+1
| | | | | | Temporarily disable TPM in developer mode. Review URL: http://codereview.chromium.org/3041005
* Make optional flag optionalMandeep Singh Baines2010-07-091-1/+1
| | | | | | Change-Id: I022a0bdf58b4884b0bc8c640b6b543e419743fd1 Review URL: http://codereview.chromium.org/2959005
* Add an optional flag argument to load_kernel_test.Gaurav Shah2010-07-091-5/+8
| | | | Review URL: http://codereview.chromium.org/2905006
* load_kernel_test tests the recovery image now (submit for Bill)Louis Yung-Chieh Lo2010-07-051-2/+2
| | | | | | See original CL here: http://codereview.chromium.org/2803033/show Review URL: http://codereview.chromium.org/2830038
* Make vboot_reference build in MSVC command line environment.vbendeb2010-06-241-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is a mostly NOOP change which modifies the source code to compile cleanly in the MSVC command line build environment. A new makefile is introduced (msc/nmakefile) along with a README.txt in the same directory explaining how to build the code in the DOS window. As of this submission the build is running in a 32 bit environment, the intention is to use the same makefile for 64 bit builds in the future. Enabling high compilation warnings level allowed to identify a couple of bugs in the code which are being fixed. Not all sources are being compiled in the MSVC environment, only those in firmware/ and most of those in test/ subdirectories. The benchmark calculations require porting of the timer facilities and are being postponed. TEST Built in DOS and linux environments. Ran unit tests in linux environment. Review URL: http://codereview.chromium.org/2809037
* Move old vkernel code out of vboot_firmware.Randall Spangler2010-06-161-2/+5
| | | | | | It will go away entirely once the build has moved to vboot_kernel. Review URL: http://codereview.chromium.org/2866006
* fix typos in load_kernel_testRandall Spangler2010-06-141-1/+2
| | | | Review URL: http://codereview.chromium.org/2820004
* Utility to pack public key, version, algorithm into a single file in ↵Randall Spangler2010-06-101-17/+5
| | | | | | VbPublicKey format Review URL: http://codereview.chromium.org/2762009
* Major refactoring of structures, with unit tests. This matches the doc I ↵Randall Spangler2010-06-101-1/+1
| | | | | | | | | | sent out earlier. Firmware-side code for LoadKernel() is in place now. LoadFirmware() replacement coming soon. The new functions are implemented in parallel to the existing ones (i.e., everything that used to work still does). Review URL: http://codereview.chromium.org/2745007
* fixed VerifyKernelHeaderRandall Spangler2010-06-031-12/+40
| | | | | | | removed extra debugging fixed printf() format specifiers Review URL: http://codereview.chromium.org/2561001
* fix int reference to unint64 from http://codereview.chromium.org/2438005Colin Chow2010-06-021-5/+5
| | | | Review URL: http://codereview.chromium.org/2550001
* Much rearranging of cgptlib. Passes all its (new) unit tests.Randall Spangler2010-06-021-0/+125
Also includes part of LoadKernel(), which I'll split into a separate CL. With some hacks, gets into VerifyKernel() before dying because I'm not passing in the right key blob. cgptlib is now pretty stable, and worth looking at. LoadKernel() less so. Thanks, Randall Review URL: http://codereview.chromium.org/2438005
View Lorry Controller Status