summaryrefslogtreecommitdiff
path: root/firmware/lib/vboot_display.c
Commit message (Collapse)AuthorAgeFilesLines
* Rename Strncat to StrnAppend, use it instead of strncat.firmware-spring-3824.Bfirmware-spring-3824.84.Bfirmware-spring-3824.55.Bfirmware-spring-3824.4.Bfirmware-skate-3824.129.BBill Richardson2013-03-061-26/+25
| | | | | | | | | | | | | | | | | | Strncat() looks almost like strncat(), but it's completely different. Change the name to reduce confusion. Also fix a place where strncat() was misused anyway. BUG=none BRANCH=all TEST=manual sudo FEATURES=test emerge vboot_reference FEATURES=test emerge-$BOARD vboot_reference Change-Id: I39c30d391aa6566ec67461462e800720ade66a91 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/44572
* vboot_display: fix -Wwrite-strings compiler errorsAaron Durbin2013-02-261-3/+3
| | | | | | | | | | | | | | | | | | | | VbHWID() returns a fixed string which can also be a returning a string that lives in the read only text segment or read only flash. Because of this the compiler will rightfully error when built with -Werror and -Wwrite-strings because the const qualifier is being ignored. Correct this and the ripple effect in VbRenderTextAtPos(). VbRenderTextAtPos() should be using constant strings anyhow. BUG=chrome-os-partner:17695 BRANCH=None TEST=built fwlib with -Werror -Wwrite-strings. Compiles correctly. make runtests still passes as well. Change-Id: Id03a783d2d9b5de4cc3b3ce0fa6d74934751cca4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/44043 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add more display testsRandall Spangler2013-02-111-9/+6
| | | | | | | | | | | BUG=chromium-os:38139 BRANCH=none TEST=make runtests && FEATURES=test emerge-daisy vboot_reference Change-Id: I28cd31f995f078d1715acaeaccce6e864930a986 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/42846 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* EC software sync uses precomputed hash if availableRandall Spangler2013-02-061-0/+6
| | | | | | | | | | | | | This removes the need to load the EC code at all when the precomputed hash matches. BUG=chrome-os-partner:17606 BRANCH=spring TEST=wouldn't that be nice Change-Id: If4438b9db8b1449b8fd4d90ef3acb3bbec5e09a0 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/42567
* Reformat files to kernel styleRandall Spangler2013-01-291-604/+657
| | | | | | | | | | | | | No code changes, just reformatting. BUG=none BRANCH=none TEST=make runtests Change-Id: I93507c45c0790da6162758e0fb02031441169f65 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/42171 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add display testsRandall Spangler2013-01-291-8/+2
| | | | | | | | | | | BUG=chromium-os:38139 BRANCH=none TEST=make runtests Change-Id: Ibfd3f5f2b7ac8871a99e5d8603baae17926ab972 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/42170 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Start adding display testsRandall Spangler2013-01-251-2/+1
| | | | | | | | | | | BUG=chromium-os:38139 BRANCH=none TEST=make runtests Change-Id: Idd1c275077a9a00cd2f7eab684238eb5b2d235dd Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/42015 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add more recovery_reason codesBill Richardson2012-11-261-4/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several places where the same recovery_reason was used to report slightly different points of failure. Let's create some new codes instead. Remember that recovery mode is handled by RO firmware, so if an updated RW firmware uses one of the new error codes, pressing TAB at the recovery screen will say "We have no idea what this means". That's not a bug. This CL deprecates the original codes, so the fact that the RO firmware doesn't recognize it just means it's a new code reported by a new RW BIOS. BUG=chromium-os:36562 TEST=manual BRANCH=parrot Run make && make runtests It should pass. You can test some of the error cases on actual hardware by using crossystem recovery_reason=86 reboot and pressing TAB at the recovery screen. For that example you should see the message recovery_reason: 0x56 TPM lock error in rewritable firmare Change-Id: I123c781e6c6f6fe0284c4fd49f5f5a855eece7df Reviewed-on: https://gerrit.chromium.org/gerrit/38652 Commit-Ready: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add recovery reason for failure to correct TPM errorLuigi Semenzato2012-10-291-0/+2
| | | | | | | | | | | | | | | | | The TPM on snow devices may boot in an unusable state. The workaround is to detect this early and reboot. The workaround code prevents an infinite reboot loop by counting the number of reboots and entering recovery mode with this reason after a small threshold has been reached. BUG=chromium:156655 TEST=no test! Not even compiled! BRANCH=none Change-Id: Ica2f14f8f7df8c46b7cbe5dbd578ba93c8f3a78c Reviewed-on: https://gerrit.chromium.org/gerrit/36790 Tested-by: Luigi Semenzato <semenzato@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Luigi Semenzato <semenzato@chromium.org>
* Rename RANDOM_POWER_OFF to a more descriptive SAVE_LOCALE_IMMEDIATELYRandall Spangler2012-09-241-1/+1
| | | | | | | | | | | | | --snark; no functional change. BUG=none TEST=build code BRANCH=none Change-Id: Id3a8c5aaf0e5a9d0e1949af602840efcc1895f50 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/33898 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add CTRL-L in dev screen to support a "legacy boot option"Stefan Reinauer2012-09-201-0/+5
| | | | | | | | | | | | | | | | | | | | | This option is disabled per default and can be enabled with crossystem dev_boot_legacy=1 or by setting the GBB flag GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080 BUG=chrome-os-partner:6108 TEST=crossystem dev_boot_legacy=1 boot to dev mode screen, press CTRL-L, see SeaBIOS start (other CLs needed) BRANCH=link Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Change-Id: I593d2be7cff5ca07b8d08012c4514a172bd75a38 Reviewed-on: https://gerrit.chromium.org/gerrit/31265 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
* Don't copy BMP data on ARMSimon Glass2012-09-101-0/+4
| | | | | | | | | | | | | | | | | | | | | This just chews up memory and wastes time on ARM, since the data is already in memory. BUG=chrome-os-partner:13492 BRANCH=snow TEST=manual Build and boot on snow with manually modified code, to see that the bmpfv pointer is in the same region as the bmp region. Build and boot on link and see that displaying screens is still fast. Change-Id: I98349b73671e38fa6cace966b6953a2abf129fab Reviewed-on: https://gerrit.chromium.org/gerrit/32629 Reviewed-by: Mike Truty <truty@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Commit-Ready: Simon Glass <sjg@chromium.org>
* Define all screens in enum ScreenIndex and use themSimon Glass2012-09-101-8/+8
| | | | | | | | | | | | | | | | | | This enum seems partially complete, and not used in vboot_reference. Complete it and use it. BUG=chrome-os-partner:13492 BRANCH=snow TEST=manual Build and boot through to recovery on snow. Run through the various screens and check that they still appear correctly. Change-Id: Ifca54d072457d9a0396a38026f44f8334efb9cf5 Reviewed-on: https://gerrit.chromium.org/gerrit/32628 Reviewed-by: Mike Truty <truty@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Commit-Ready: Simon Glass <sjg@chromium.org>
* Remove power button work-around for ARMSimon Glass2012-09-071-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | On x86 U-Boot cannot see the power button, which means that the EC must deal with it, and may power off the unit at any time. To get around this, we write the vbcontext every time we change it. Since this isn't a problem on ARM, and we want to avoid spurious writes (due to delay and disk wear), make this code execute only on x86 machines. BUG=chrome-os-partner:13717 BUG=chrome-os-partner:7689 BRANCH=snow,link TEST=manual On snow, see that the EC no longer gets MKBP messages to write the nv context. On link, manually add a print to U-Boot's nvstorage_write_disk() function and see that changing language in recovery still causes a write. Change-Id: I62508739c9fc3aca46fba58b196a8af45269af2a Reviewed-on: https://gerrit.chromium.org/gerrit/32464 Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org> Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
* Cache GBB images to speed up displaySimon Glass2012-09-071-5/+5
| | | | | | | | | | | | | | | | | | | | | Rather than read the images from slow flash every time we need them, cache them the first time and use that cache thereafter. BUG=none BRANCH=snow,link TEST=manual Go into recovery mode on link See that we can display a new screen in roughly 20ms instead of the 250ms it previously took on link. Also tested on snow and shown to have no ill effects. Change-Id: Ieb39c44bddeb6315da8983669f19f550888659bd Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32462 Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org> Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
* firmware: Add TONORM_CONFIRM screen.Hung-Te Lin2012-08-131-0/+3
| | | | | | | | | | | | | | We need to alert user his change has been accepted for 5 seconds. BUG=chrome-os-partner:11078 TEST=emerge-daisy vboot_reference-firmware vboot_reference chromeos-u-boot chromeos-boogimage Change-Id: I6a3b13e7543479fbd6543d759093ecf501fb1d04 Reviewed-on: https://gerrit.chromium.org/gerrit/29982 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org>
* Add WAIT screen to default bitmapBill Richardson2012-08-051-0/+3
| | | | | | | | | | | | | | | | | | | | | Some systems take a long time to program the EC firmware (because it's behind a really slow I2C bus or something). This could happen at any boot as part of software sync. If it's necessary to reprogram the EC on a slow system, we need to display a BIOS screen to the user so he/she doesn't think it's bricked. This CL is just to add a new default bitmap so we'll have something to display when we need it. Nothing actually uses it yet. BUG=chrome-os-partner:12254 TEST=none There should be no user-visible changes. We don't invoke this screen yet. Change-Id: Icb922f933e2e921472dbdff7a26a3ca4d58fbba3 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/29241 Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* TONORM screen should display at Dev screen, not Recovery screen.Bill Richardson2012-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're still working out the correct behavior for the keyboard-based dev-mode. Before this, we rebooted into recovery mode before asking if you wanted to return to normal mode, so if you said "no, stay in dev-mode" you'd still be at the recovery screen. But now the confirmation for returning to normal mode happens at the dev-mode screen, so you never get to the recovery screen (unless normal mode won't boot, in which case you get there automatically). BUG=chrome-os-partner:11707 TEST=manual First, clear the GBB flags so that you can actually test the virtual dev switch: /usr/share/vboot/bin/set_gbb_flags.sh 0 reboot It should come up in normal mode. Activate keyboard-based dev-mode as before: - three-finger salute - Ctrl-D at the recovery screen - Press ENTER when asked Now, at the DEV screen, try to leave: - Press SPACE. It should ask if you want to go to normal mode. - Press ESC (no). You should be back at the DEV screen again. - Press ENTER. It should ask if you want to go to normal mode. - Press ESC (no). You should be back at the DEV screen again. - Press SPACE. It should ask if you want to go to normal mode. - Press ENTER (yes). It should reboot into normal mode. Change-Id: I99af6e7b97fb61f943bd14c8c7166571b5ccf106 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/28872
* Add more specific recovery reasons for EC software sync.Randall Spangler2012-07-261-2/+12
| | | | | | | | | | | | Software sync will, of course, work perfectly, so these will never be needed. BUG=none TEST=none (hey, it all works perfectly) Change-Id: I0014dfb99507c5eb00de73b77edb7538b598658f Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/28495 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Partial EC software sync implementationRandall Spangler2012-07-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Doesn't check the EC hash, but does jump to the correct image, for now assuming the hash is good. BUG=chrome-os-partner:11087 TEST=manual - Power+refresh. System boots. EC is in RO (verify via 'ectool version') - Create a BIOS signed *without* RO-normal. - Power+refresh. System boots. EC ends up in A. - ectool eventgetb. Event 0x2000 IS present, indicating EC has rebooted - ectool eventclearb -1 - Power button to shut down, then power button to power back on. - ectool eventgetb. Event 0x2000 is NOT present. - crossystem recovery_request=123 && reboot. System reboots to recovery mode and EC is in read-only (verify via EC console 'sysinfo') - Power off and on. System boots. EC ends up in A again. Change-Id: I39682d1bf7215c62a4b20613d029e78194b98826 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27574 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Support virtual dev-switch (keyboard-based dev-mode)Bill Richardson2012-06-081-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:9706 TEST=manual Currently, Link is the only platform that enables this feature. To enter dev-mode: Boot into recovery mode using the magic key chord. At the Insert screen, press Ctrl-D. You'll be asked if you want to enter developer mode. If you then press ENTER, it will reboot with dev-mode enabled. If you press SPACE or ESC, it will return to the Insert screen. If you enter recovery mode through any other means, or if dev-mode is already enabled, pressing Ctrl-D at the Insert screen will have no effect. To return to normal mode: Reboot. At the Dev screen, press ENTER or SPACE. It will reboot to recovery mode and ask you if you want to return to normal mode. If you press ESC or power off, you'll still be in dev-mode. Press ENTER or SPACE, and it will reboot into normal mode (of course, if you've messed up your images while in dev-mode, you'll just come right back to recovery mode again). You can also request a direct return to normal mode by running crossystem disable_dev_request=1 and rebooting. Change-Id: I435905855a6c39932ee466cc046bdc4c4c860f98 Reviewed-on: https://gerrit.chromium.org/gerrit/24160 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Bill Richardson <wfrichar@chromium.org>
* Add new line after printing non-zero GBB flags.Stefan Reinauer2012-02-281-0/+1
| | | | | | | | | | | | | | | | Callers of vboot might print some additional information in VbExDisplayDebugInfo(). Add a new line to the end of the buffer so that output is aligned with the normal <tab> information. BUG=none TEST=set gbb flags to 1, see cursor go to next line at dev screen. Change-Id: I8dd77404338a05bddc5f3ec54d7b65c890a60c50 Reviewed-on: https://gerrit.chromium.org/gerrit/17001 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Be aggressive in saving locale to nvram.Bill Richardson2012-01-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On x86 platforms, the power button and lid switch events have to be handled by coreboot SMM code, because it needs to interact with the southbridge and/or EC, and U-Boot doesn't have a way to do that. Once the kernel takes over, it sends an SMI to that code which tells it to start delivering ACPI events instead of whatever pre-ACPI handling it has been doing. U-Boot doesn't have any code to handle either case, and adding it would either be a major undertaking (adding ACPI support to U-Boot!), or would require creating yet another special-purpose interface just for our U-Boot (yuck). It's much simpler to just make vboot_reference be more aggressive about writing to the nvram for this one case where it matters. OTOH, ARM will need U-Boot to handle the lid switch and power button via GPIOs since it uses only U-Boot and has no SMI handler. This change isn't necessary for ARM, but shouldn't hurt either. BUG=chrome-os-partner:7689 TEST=manual 1. Boot to dev-mode screen or recovery screen. 2. Press arrow keys to change locale. 3. Power off (press power button or yank A/C & battery) 4. Power on again. The BIOS screen locale should still be set to your last choice before powering off. Change-Id: I9008811c3be71de47ff1c6899e81955cf0560a52 Reviewed-on: https://gerrit.chromium.org/gerrit/14721 Tested-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Dev-mode allows booting self-signed kernels by default.Bill Richardson2011-11-181-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | When you enter dev-mode, Pressing Ctrl-U to boot from USB is DISABLED. Booting any self-signed kernel from the SSD is ENABLED. This replaces the "crossystem dev_boot_custom" argument with "crossystem dev_boot_signed_only", which has the opposite polarity. So if you want to dev-mode to only boot official kernels, you have to explictly set it that way. If you leave dev-mode and then come back, it will go back to the conditions shown above. BUG=chrome-os-partner:5954 TEST=manual Just run the factory flow. It was broken; this should fix it (except for any workarounds that were added while it was broken; those may need to be reverted). Change-Id: I13e0edbc0e77c5d6ea609dabf771085006cd1805 Reviewed-on: https://gerrit.chromium.org/gerrit/11853 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* Fix typo, add one VBDEBUG.Bill Richardson2011-11-141-1/+1
| | | | | | | | | | BUG=none TEST=none Change-Id: Ie82c5eb3052c84272da4bf21d80cc2bf204fd08d Reviewed-on: https://gerrit.chromium.org/gerrit/11670 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Dev-mode only boots official kernels by defaultBill Richardson2011-11-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although we're now using a single unified BIOS, it is pretty nice to be able to get a shell in developer mode while still using verified boot for the kernel and filesystem. Alex & ZGB implemented this by requiring the dev-mode user to install a special dev-mode BIOS. We don't do that, but we DO require setting a special flag with "crossystem" to accomplish the same thing. In order to allow booting a self-signed kernel, you must boot in developer mode, open a shell, and run this: crossystem dev_boot_custom=1 Special note to internal developers: If you're in the habit (as I am) of booting directly from a USB stick in dev-mode, you'll have to run this: crossystem dev_boot_custom=1 dev_boot_usb=1 Just using dev_boot_usb=1 is no longer enough, because the USB kernel is signed using the recovery key and by pressing Ctrl-U, we validate it with the kernel data key. That worked before this change because any self-signed kernel was fine, and that's how the USB key was treated. Now it actually requires a verified signature until you enable dev_boot_custom=1 also. BUG=chrome-os-partner:5954 TEST=manual Boot once in normal mode, which clears the special flags. Then switch to developer mode. You should be able to boot and get a root shell. Run crossystem dev_boot_usb=1 Obtain a USB recovery image that's keyed differently. For example, if you're testing with dev-keys, use a PVT-signed image or vice-versa. Reboot into dev-mode with the USB recovery stick inserted. At the dev-mode screen, press Ctrl-U. You should hear a single beep, but it should not boot. Press Ctrl-D to boot from the hard drive, log in to a shell and run crossystem dev_boot_custom=1 Repeat the previous test. This time when you press Ctrl-U, it should boot the recovery image. Turn the system off before it does anything. That's it. Change-Id: I1811ee9a188974b3f94c83c52b00b60028b86c69 Reviewed-on: https://gerrit.chromium.org/gerrit/11442 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* new signature for optional easter egg.Bill Richardson2011-10-111-1/+1
| | | | | | | | | | BUG=none TEST=none Change-Id: I86743dbba3210858d817c8e6982f17df96920420 Reviewed-on: http://gerrit.chromium.org/gerrit/9889 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Some easter eggs may need a refresh.Bill Richardson2011-10-111-1/+2
| | | | | | | | | | BUG=none TEST=none Change-Id: I4b8cffa63dd10261e45a5ca6233b4d5cd2471f62 Reviewed-on: http://gerrit.chromium.org/gerrit/9861 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Add more debugging info to BIOS screens.Bill Richardson2011-09-281-1/+95
| | | | | | | | | | | | | | | | | | | | This displays the gbb.flags value when being warned about it being nonzero. It also decodes the recovery_reason value into English. BUG=chromium-os:20972 TEST=manual 1. Use gbb_utility to create a BIOS with valid bitmaps, but with gbb.flags set to a non-zero value. Boot into recovery mode. You should see the warning that gbb.flags is non-zero, and the value itself. 2. Press TAB. The recovery_reason field should display not only a value, but also an English string explaining the value. Change-Id: I99b7aa35bc67453bdf3385b9573491090c3dec1d Reviewed-on: http://gerrit.chromium.org/gerrit/8459 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* VbExBeep() now returns VbError_t instead of voidBill Richardson2011-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This enables us to support playing sounds in the background if the BIOS allows it, so we don't have to block while beeping is happening. The new declaration is: VbError_t VbExBeep(uint32_t msec, uint32_t frequency); If the audio codec can run in the background, then: zero frequency means OFF, non-zero frequency means ON zero msec means return immediately, non-zero msec means delay (and then OFF if needed) else: non-zero msec and non-zero frequency means ON, delay, OFF, return zero msec or zero frequency means do nothing and return immediately The return value is used by the caller to determine the capabilities. The implementation should always do the best it can if it cannot fully support all features - for example, beeping at a fixed frequency if frequency support is not available. At a minimum, it must delay for the specified non-zero duration. Currently, VbExBeep() is called only when displaying the dev-mode screen. BUG=none TEST=manual I've tested on x86 and ARM, all timeouts and noises work as before. Note that ARM and coreboot will require a corresponding change to their VbExBeep() implementations, which will have to be handled with separate, simultaneous CLs. Change-Id: I3417ae4b99d9d0aee63f2ccaeed39b61d4333e5d Reviewed-on: http://gerrit.chromium.org/gerrit/8234 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com>
* Make BIOS screens warn when GBB.flags is nonzero.Bill Richardson2011-09-141-0/+11
| | | | | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:5919 TEST=manual Until the factory flow has completed, BIOS screens should display a warning message about GBB.flags. This message should disappear once the flags field is zero. You can see the state of the GBB flags in a particular BIOS image using gbb_utility -g --flags BIOS.bin And set it with gbb_utility -s --flags=VALUE BIOS.bin NEWBIOS.bin Change-Id: I15d336bda571978ece0a9744f19d80f0ae385fb1 Reviewed-on: http://gerrit.chromium.org/gerrit/7719 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Stub out easter egg, in case BIOS wants to implement one.Bill Richardson2011-09-141-0/+15
| | | | | | | | | | | | BUG=none TEST=manual Type 'xyzzy' at dev-mode BIOS screen. What happens next depends on the BIOS. Change-Id: Ifdb49eb6cb53ecee91f576be91679bd5a232f008 Reviewed-on: http://gerrit.chromium.org/gerrit/7656 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Up/Down keys should change locale in BIOS screens.Bill Richardson2011-09-131-2/+3
| | | | | | | | | | | | | BUG=chrome-os-partner:5927 TEST=manual Install BIOS with valid bitmaps, boot to dev-mode or recovery, press arrow keys. Change-Id: I3946bac94cc075f9d11b4dd3fcb118807c3318c4 Reviewed-on: http://gerrit.chromium.org/gerrit/7636 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Display sha1sums in BIOS debug infotest-982.Bfactory-980.BBill Richardson2011-09-011-2/+37
| | | | | | | | | | | | BUG=none TEST=manual Press 'TAB' at any BIOS screen. You should see some sha1sums. Change-Id: Id2f034ad198e4c9c53ab2f2a8fa6195f3479f6aa Reviewed-on: http://gerrit.chromium.org/gerrit/7101 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* bmpblock v1.2 - render HWID inside vboot_referenceBill Richardson2011-08-241-42/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vboot_api.h doesn't require the BIOS display the ASCII HWID in a graphical form (ARM U-Boot doesn't know how), so we have to do it ourselves. This change makes that possible. Summary of changes: * bmpblk_font.h defines a structure to map ASCII chars to BMPs * bmpblk_font utility generates that font structure * bmpblock format is bumped to version 1.2 - YAML file specifies font to use for $HWID - make_default_yaml updated to emit the new format - README updated to describe the difference BUG=chromium-os:18631 TEST=manual I've tested this on ARM, like so: Inside the chroot, build a U-Boot that uses it: emerge-tegra2_kaen vboot_reference vboot_reference-firmware emerge-tegra2_kaen tegra-bct tegra2-public-firmware-fdts \ chromeos-u-boot chromeos-bootimage Outside chroot, but in src/platform/vboot_reference: make <copy ./build/utility/bmpblk_font and ./build/utility/bmpblk_utility to somewhere in your $PATH> make clean cd scripts/newbitmaps/fonts bmpblk_font --outfile ../images/hwid_fonts.bin outdir/* cd scripts/newbitmaps/images make arm cd out_arm <edit DEFAULT.yaml> bmpblk_utility -z 2 -c DEFAULT.yaml arm_bmpblock.bin <use gbb_utility to replace the bitmaps in the U-Boot image, boot it> The HWID string is displayed. Change-Id: I782004a0f30c57fa1f3bb246e8c59a02c5e9f561 Reviewed-on: http://gerrit.chromium.org/gerrit/6544 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Put VbDisplay* functions into their own file.Bill Richardson2011-08-221-0/+325
This refactoring will enable us to test and mock them separately from the rest of the vboot_api functions. BUG=chromium-os:17564 TEST=manual Built for ARM, ran "vbexport_test display" at U-Boot prompt. Still works. Change-Id: I2ddb01d3e981603f371aaa7317184457bdff48ac Reviewed-on: http://gerrit.chromium.org/gerrit/6422 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
View Lorry Controller Status