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
%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>
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>
