summaryrefslogtreecommitdiff
path: root/host
Commit message (Collapse)AuthorAgeFilesLines
* Add a failure check to ReadFdtBlock in ReadFdtPlatformFamilyBernie Thompson2012-01-191-1/+2
| | | | | | | | | | | | | | | | This adds in logic to check that ReadFdtBlock within ReadFdtPlatformFamily succeeded, returning NULL on failure. BUG=None TEST=Manual, run crossystem on an ARM system without a valid compatible FDT entry and ensure (error) is returned for platform_family. Change-Id: I6351292ff73e4bc08b028f85e72ccfe62159194a Reviewed-on: https://gerrit.chromium.org/gerrit/14321 Reviewed-by: Olof Johansson <olofj@chromium.org> Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
* Allow crossystem ReadFdtBlock() to use a direct path starting with '/'Bernie Thompson2012-01-181-4/+8
| | | | | | | | | | | | | | | | | This extends the ReadFdtBlock function for ARM to allow for a direct path to a FDT entry by starting the property with a '/'. This allows the ReadFdtPlatformFamily function to use a direct path instead of stepping back through folders, and will enable future crossystem entries to do the same. BUG=chromium-os:24669 TEST=Manual Change-Id: Ibddb881815947259c2532d7f5474eda5fdc9f803 Reviewed-on: https://gerrit.chromium.org/gerrit/14305 Reviewed-by: Olof Johansson <olofj@chromium.org> Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
* Add in a platform_family value to crossystemBernie Thompson2012-01-092-0/+106
| | | | | | | | | | | | | | | | | | | | | | This implements a platform_family value within the crossystem utility, as the platform (particularly for ARM) is not easily accessable elsewhere at runtime. For the ARM side this contains a table which is used to determine the platform family based on the /proc/device-tree/compatible entry. Similarly on x86 the table is used to check against PCI entries. Additional entries can be made as new platform families emerge. BUG=chromium-os:24669 TEST=Manual, verified that crossystem runs properly and returns a valid platform_family value on various platforms (mario, alex, z600, x220, etc). Change-Id: Id0e973902d27ead471c1243bcc6c3292acc8479d Reviewed-on: https://gerrit.chromium.org/gerrit/13520 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Olof Johansson <olofj@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org> Tested-by: Olof Johansson <olofj@chromium.org>
* Fix crossystem on amd64 boardsSonny Rao2011-11-231-57/+1
| | | | | | | | | | | | | | | | | Since x86 and amd64 boards use the same firmware and are otherwise identical use the same implementation for crossystem on both BUG=chromium-os:21386 TEST=emerge-x86-generic ; test crossystem works on Samsung Series 5 TEST=emerge-amd64-generic ; test crossystem works on Samsung Series 5 TEST=run unit tests on build machine with: RUNTESTS=1 make Change-Id: Ica516cca7ead6cb9cdfae0894bd532669ba3ba88 Reviewed-on: https://gerrit.chromium.org/gerrit/12059 Tested-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
* Dev-mode allows booting self-signed kernels by default.Bill Richardson2011-11-181-4/+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>
* vboot_reference: fix CMOS writing for x86 platformsHung-Te Lin2011-11-161-10/+9
| | | | | | | | | | | | | | | | VbCmosWrite should seek to correct offset before starting to write; also fixed file handle leakage. BUG=chromium-os:23000 TEST=crossystem recovery_request=1; echo $? # show: 0 crossystem recovery_request # show: 1 reboot # see recovery screen Change-Id: I33bca8af2b351ba9b364309838df699a31bb543a Reviewed-on: https://gerrit.chromium.org/gerrit/11756 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Ready: Hung-Te Lin <hungte@chromium.org>
* Wrap CMOS read/write functions so they automatically pacify the nvram driver.Gabe Black2011-11-111-44/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A legacy checksum in CMOS is not maintained by coreboot and may be invalid. If the Linux kernel driver sees that the checksum is wrong, it will return EIO when read from or written to. That makes crossystem return an error since it can't read the CMOS, and it also prevents it from changing some settings. One way to fix the problem would be to remove the checksum check in the kernel driver. This would change the semantics of the driver so that either x86 was inconsistent with the other architectures, or change the semantics of those other architectures as well. Another option would be to fix the checksum during manufacturing since nothing should be changing those particular bytes of CMOS. The problem with this approach is that something might corrupt the CMOS after manufacturing, and we'd have the same problem again. Yet another solution would be to make the firmware, most likely coreboot, actually keep the checksum up to date. This seems like an awful waste of boot time, the bytes protected by the checksum aren't actually used by anything, and the bytes of the CMOS that are used are protected by vboot using its own checksum. The solution implemented here is to make crossystem recognize when the driver has determined that the checksum is invalid and make it call an ioctl that gets the driver to fix the checksum. Wrapper functions for fread, fwrite, fgetc, and fputc are implemented which first attempt to read or write, on failure check for the EIO error code, and if they find it to call the appropriate ioctl and attempt the access again. This way, we won't take any extra time to talk to the CMOS when everything is working properly, and when there's a problem it gets fixed up transparently. One problem with this approach is that using the /dev/nvram device file will still fail until crossystem is run at least once and given a chance to fix the checksum. BUG=chrome-os-partner:6718 TEST=For version 1, verified that crossystem reported an error on Sameer's Lumpy. Used strace to verify that crossystem received an EIO error when trying to read or write /dev/nvram. Built a new image with this change and booted it using a USB stick. Ran crossystem and verified that crossystem no longer reported an error. Rebooted into the original image and verified that crossystem worked there as well, indicating that the persistent problem in the CMOS had been corrected. For version 2, the same as version 1 except that I used a custom version of u-boot to purposefully corrupt the CMOS rather than using Sameer's Lumpy. Change-Id: I929535bd2a7d666e41a707b6b24c3f0b0df1147f Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/11373 Tested-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Dev-mode only boots official kernels by defaultBill Richardson2011-11-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Determine GPIO base from /sys/class/gpio/gpiochip<N>Bill Richardson2011-08-311-13/+39
| | | | | | | | | | | | | | | ... instead of using hard-coded 192 constant. BUG=chromium-os:19876 TEST=manual If crossystem still reports correct values for devsw_cur recoverysw_cur (and maybe wpsw_cur, although that's a separate bug), then it works. Change-Id: Id8d4fb389bfd78f40da9ef08aa372071d77cbec1 Reviewed-on: http://gerrit.chromium.org/gerrit/7014 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Allow CougarPoint as a valid GPIO controller.Bill Richardson2011-07-281-6/+8
| | | | | | | | | | | | BUG=chrome-os-partner:4879 TEST=manual (just try it) NOTE: You must use a BIOS that exports the correct ACPI tables. Change-Id: I027680a203f3a566edf9ed82fb1fe1a9fa4c4f0f Reviewed-on: http://gerrit.chromium.org/gerrit/4957 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Make crossystem kern_nv field read-only.Randall Spangler2011-07-261-4/+6
| | | | | | | | | | | | | | | | | | | | | BUG=chromium-os:14029 TEST=make && make runtests, and manually check: crossystem fwupdate_tries=3 crossystem fwupdate_tries kern_nv (should print 3 0x00000003) crossystem kern_nv=0 (should fail) crossystem fwupdate_tries kern_nv (should print 3 0x00000003) crossystem fwupdate_tries=0 crossystem fwupdate_tries kern_nv (should print 0 0x00000000) Change-Id: I906ad41a36378b93e0c3330d8f94b7d69aafa536 Reviewed-on: http://gerrit.chromium.org/gerrit/4751 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Add check to validate VbSharedData magicNick Sanders2011-07-201-0/+7
| | | | | | | | | | TEST=run crossystem BUG=chrome-os-partner:4691 Change-Id: If590d185446dfa7cb628b5014f3a9a9c7b7a901d Reviewed-on: http://gerrit.chromium.org/gerrit/3355 Reviewed-by: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org>
* CHROMIUM: fix incorrect crossystem recovery_reasonChe-Liang Chiou2011-07-201-7/+1
| | | | | | | | | | | | | | | | | | U-Boot should not parse the raw contents of VbNvStorage, and so cannot read the recovery reason from the VbNvStorage. On the other hand, it is easy for crossystem to read the recovery reason from the VbNvStorage itself. After this change is merged, U-Boot will stop providing the (incorrect) recovery reason in the device tree. BUG=chromium-os:17876,chromium-os:17852 TEST=press recovery button and see crossystem reports recovery_reason=2 Change-Id: I236667f0b4f2e25da193cf6b6f7db3871d1e093f Reviewed-on: http://gerrit.chromium.org/gerrit/4396 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Report mainfw_act based on VbSharedData780.BRandall Spangler2011-07-152-3/+20
| | | | | | | | | | | | | | | Don't use FDT to report it on ARM. This fixes ARM reporting the wrong thing for RO-normal. BUG=none TEST=none Change-Id: Id3a1bd2a1d2502e1d9493ab362be5a58fa88d70e Reviewed-on: http://gerrit.chromium.org/gerrit/4213 Reviewed-by: Olof Johansson <olofj@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* crossystem: arm: use proper gpio referencesOlof Johansson2011-07-141-11/+24
| | | | | | | | | | BUG=none TEST=make sure developer switch and recovery switch runtime reading works as expected (manually) Change-Id: I3b17ac66f88b2b789bebe4e7d271666f8c63a8b0 Reviewed-on: http://gerrit.chromium.org/gerrit/4127 Reviewed-by: Olof Johansson <olofj@chromium.org> Tested-by: Olof Johansson <olofj@chromium.org>
* arm: convert to new device tree usageOlof Johansson2011-07-141-102/+114
| | | | | | | | | | | | | This also includes reading the nonvolatile storage from disk instead of through the device-tree, since it's not updated there. BUG=none TEST=read and write a few crossystem variables Change-Id: I6836a6eb0c92a0560dd393e694690a694bdb77a6 Reviewed-on: http://gerrit.chromium.org/gerrit/4078 Tested-by: Olof Johansson <olofj@chromium.org> Reviewed-by: Rong Chang <rongchang@chromium.org>
* Add support for flags in the firmware preamble.Randall Spangler2011-07-133-3/+7
| | | | | | | | | | | | | | | | | | The old (v2.0) parser is compatible with new (v2.1) structs. That is, this won't break existing firmware or vbutil_firmware. A new (v2.1) parser parsing an old (v2.0) struct will return 0 for the flags. This will be used to support the RO-normal code path in a subsequent CL. BUG=chromium-os:17304 TEST=added unit tests; make && make runtests Change-Id: I73bcd8acd3330b0d7d143061b5ef838e6d79cf1a Reviewed-on: http://gerrit.chromium.org/gerrit/4030 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Introduce arm fdt support in crossystem utilityRong Chang2011-07-111-172/+218
| | | | | | | | | | | | | | | | | | | | This CL builds upon recent changes in u-boot and kernel. (see issue ids: 15744, 16665) - Remove /sys/kernel/debug/chromeos_arm share memory mechanism - Load properties from /proc/device-tree/crossystem/* - Write NVCXT to /dev/mmcblk0:lba[0] BUG=chromium-os:17300 TEST=manual Run crossystem on device console. Check current values of gpio switches. All other values are exported from FDT directly. Change-Id: Ib8db4a4aeb6dc36308ad8882403cb2f5978a5c70 Signed-off-by: Rong Chang <rongchang@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/3676 Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
* Add support for dev_boot_usb flagRandall Spangler2011-07-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG=chromium-os:17433 TEST=make && make runtests. Additional manual tests: 0. Insert a valid dev-signed USB key. 1. Boot with dev switch off. `crossystem dev_boot_usb` should print 0. 2. Flip dev switch on. `crossystem dev_boot_usb` should print 0. Ctrl+U at dev screen should beep, but not boot USB. 3. Type `crossystem dev_boot_usb=1`. Should succeed. `crossystem dev_boot_usb` should print 1. 4. Reboot system. At the dev mode warning, press Ctrl+U System should boot from USB key `crossystem dev_boot_usb` should print 0. 5. Flip dev switch off. `crossystem dev_boot_usb` should print 0. 6. Flip dev switch on. `crossystem dev_boot_usb` should print 0. Note that this does not apply to Cr-48, Alex, or ZGB. Change-Id: Idf85fdd642f38f531c89e5fa5b1679e84936d4da Reviewed-on: http://gerrit.chromium.org/gerrit/3875 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Randall Spangler <rspangler@chromium.org>
* Vboot wrapper - add recovery reason, refactor timingRandall Spangler2011-07-081-6/+6
| | | | | | | | | | | | | | | | | | | | | Pressing Tab at a firmware screen now displays real data, including the recovery reason, HWID, and contents of VbNvStorage. Entry point start/end time tracking in VbSharedData now refers to the new wrapper APIs. Added capability for calling firmware to request recovery mode (for example, if it's unable to initialize RAM, can't find the SSD, etc.). Previously, calling firmware had no (good) way to do this other than faking the recovery button being pressed. BUG=chromium-os:17018 TEST=emerge on x86 and tegra2_seaboard Change-Id: I7d377f279842b30a10d945d13571c41c464633f1 Reviewed-on: http://gerrit.chromium.org/gerrit/3814 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Vboot wrapper initial implementationRandall Spangler2011-07-081-2/+0
| | | | | | | | | | | | | | | | | | 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>
* crossystem: fix VbSharedDataHeader sizeHung-Te Lin2011-06-301-3/+1
| | | | | | | | | | | | | The content in VbSharedMem should be VbSharedData instead of FMAP. BUG=chromium-os:17168 TEST=crossystem # seeing correct value (the test need a u-boot with fix included) Change-Id: I3d7d1eb2b35c9475c2047e9479cee69464da20b1 Reviewed-on: http://gerrit.chromium.org/gerrit/3436 Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org>
* Fix ARM build for vboot_reference crossystem libRandall Spangler2011-06-271-1/+1
| | | | | | | | | | BUG=none TEST=none Change-Id: I655cd69a0e1d2a3ad6ce9f326cbd989fc8ecb43d Reviewed-on: http://gerrit.chromium.org/gerrit/3270 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Verified boot wrapper - add stub implementations for hostRandall Spangler2011-06-2710-97/+93
| | | | | | | | | | | | | | | 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>
* Vboot wrapper API - crossystem and header filesRandall Spangler2011-06-274-8/+41
| | | | | | | | | | | | | | | | Header file changes for wrapper API implementation Crossystem support for reading recovery reason from VbSharedData, and explicit support for version 1 VbSharedData structs. BUG=chromium-os:16970 TEST=make && make runtests; run crossystem on Alex and make sure it still reports recovery_reason in recovery mode. Change-Id: I15195b899583e425d3c9e8df09842d764528e2cb Reviewed-on: http://gerrit.chromium.org/gerrit/3203 Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org> Reviewed-by: Che-Liang Chiou <clchiou@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Fixed compiler warning in v-boot reference.Doug Anderson2011-05-251-2/+2
| | | | | | | | | | | | | | The error was: arch/arm/lib/crossystem_arch.c: In function ‘VbReadSharedMemory’: arch/arm/lib/crossystem_arch.c:134: error: format ‘%d’ expects type ‘int’, but argument 5 has type ‘long unsigned int’ BUG=none TEST=(outside choot): cd src/platform/vboot_reference; make Change-Id: I5e1f69abd125fe06cf6ae04a7946568bdbcef83e Reviewed-on: http://gerrit.chromium.org/gerrit/1547 Tested-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* crossystem: arm: fix incorrect mainfw_act outputChe-Liang Chiou2011-05-221-1/+1
| | | | | | | | | | | | | | | | BUG=chromium-os:15626 TEST=manual when not recovery boot $ [ $(crossystem mainfw_act) = "A" ] || [ $(crossystem mainfw_act) = "B" ] when recovery boot $ [ $(crossystem mainfw_act) = "recovery" ] Change-Id: I3917106b61e2979d8cb07f01fd0cec044ae725cb Reviewed-on: http://gerrit.chromium.org/gerrit/1345 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* Ensure ARM crossystem gpio readings match u-boot.Vadim Bendebury2011-05-191-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | U-boot and crossystem interpret the same switch state differently for 'recovery mode' and 'write protect', This change adds the ability to invert certan GPIO readings such that crossystem and u-boot return the same values. BUG=chromium-os:15393 TEST=manual Running crossystem on the target with developer u-boot image: - observe that recoverysw_cur reading matches recoverysw_boot and wpsw_cur reading matches_wpsw_boot. - try rebooting with recovery or developer mode buttons pressed, observe the change in reported values of devsw_boot and recoverysw_boot. - observe reported values of devsw_cur and recoverysw_cur following pressing of the buttons. Change-Id: I628f59b60008719bbff1722d23154ce934af6c36 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/1193 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Introduce arm support in crossystem.Vadim Bendebury2011-05-053-64/+242
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL builds upon earlier firmware and kernel changes (see CLs related to the same bug, chromium-os:12522). ARM firmware now simulates both Nvram storage and VDAT buffer, the structures the x86 version uses extensively to communicate back and forth between firmware/kernel/userland. So, to make crossystem work on arm, all what's needed is to provide architecture specific interface to Nvram and VDAT simulation, and architecture specific processing for variables which are accessed on ARM platforms in a different way. The few discrepancies and platform specifics which had to be addressed for ARM specifically are as follows: - the Nvram contents are cached in the shared memory and available for reading as part of /sys/kernel/debug/chromeos_arm. When writing Nvram, the same file needs to be written, but only the 16 bytes (representing the Nvram contents) are aacepted. - the VDAT buffer also comes from the shared memory (as part of the same sysfs file) - when crossystem starts, it needs to read in this shared memory contents, a` weak' function VbArchInit() is being added such that it is provided on ARM platforms only, on x86 an empty stub is called. - current developer/recovery request/ro firmware switch states are retrieved through GPIO drivers. The GPIO numbers are defined in the file, the GPIO driver is supposed to be configured before crsossystem can operate. - the BINF values are supplied through an array within shared memory, it would be easy to refactor both x86 and ARM use the same code to process BINF values, but with this submission the code is duplicated to minimize x86 impact. - the following crossystem variables do not have ARM equivalents, thier values are reported as '(error)': recoverysw_ec_boot savedmem_base savedmem_size BUG=chromium-os:12522 TEST=manual: . bring up a kaen system . execute the following script to enable the appropriate GPIOSs: for gpio in 56 59 168; do echo $gpio > /sys/class/gpio/export; done . run `crossystem' and observe reasonable output values . to verify that it reads GPIOs properly, try echo $(./crossystem recoverysw_cur) with the miniservo 'GOOG_REC' button pressed and released, observe different readings (note that the state of the button is reversed, the released button is reported as '1') . to verify the write capabilities, note that the nvram contents can be accessed using the following shell commands echo 3 > /proc/sys/vm/drop_caches 2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && \ od -t x1 /tmp/blk | head -1 (the first command cause the device cache dropped, and the second command accesses the device contents. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv localhost var # echo $(./crossystem fwb_tries) 10 localhost var # echo 3 > /proc/sys/vm/drop_caches localhost var # 2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && od -t x1 /tmp/blk | head -1 0000000 60 0a 00 be 00 00 00 00 00 00 00 02 00 00 00 a2 localhost var # ./crossystem fwb_tries=9 localhost var # echo $(./crossystem fwb_tries) 9 localhost var # echo 3 > /proc/sys/vm/drop_caches localhost var # 2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && od -t x1 /tmp/blk | head -1 0000000 60 09 00 be 00 00 00 00 00 00 00 02 00 00 00 8a localhost var # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Change-Id: Ie4c6ff44441d98a42b1057953208fdb90c08f46d Reviewed-on: http://gerrit.chromium.org/gerrit/113 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org>
* Process case of corrupted firmware explicitly.Vadim Bendebury2011-04-191-0/+1
| | | | | | | | | | | | | | | | | | | | | Add the missing return statement to allow to tell between different recovery reasons on legacy firmware. Change-Id: I287e9d91dde040dd0edbe23422dc8914f81cc9f2 BUG=chromium-os:14295 TEST=manual On a system with a chromeOS Flash USB drive plugged in: - preserve currently running firmware - corrupt both RW firmware sections - restart the system (it comes up in recovery mode) - login - run `crossystem recovery_reason' and observe the result: it used to print '66' before the fix, prints '3' after the fix. - restore the firmware Review URL: http://codereview.chromium.org/6879051
* Add crossystem loc_idxRandall Spangler2011-04-121-0/+4
| | | | | | | | | | | | | | | Change-Id: I9fdedabd02b11e5623b9417f24dc388ce092548c R=wfrichar@chromium.org BUG=chromium-os:14069 TEST=manual crossystem loc_idx=3 crossystem loc_idx # prints 3 crossystem loc_idx=0 crossystem loc_idx # prints 0 Review URL: http://codereview.chromium.org/6826057
* Add Mario support for fwupdate_triesRandall Spangler2011-04-111-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I1c4240ebe5783ca923c310061e2a76947aa6601b R=reinauer@chromium.org BUG=chromium-os:14030 TEST=manual On a Mario: crossystem fwupdate_tries=3 crossystem fwupdate_tries # should be 3 cat /mnt/stateful_partition/.need_firmware_update # should be 3 crossystem fwupdate_tries=0 crossystem fwupdate_tries # should be 0 cat /mnt/stateful_partition/.need_firmware_update # should complain file doesn't exist On a newer platform: crossystem fwupdate_tries=3 crossystem fwupdate_tries # should be 3 cat /mnt/stateful_partition/.need_firmware_update # should complain file doesn't exist crossystem fwupdate_tries=0 crossystem fwupdate_tries # should be 0 cat /mnt/stateful_partition/.need_firmware_update # should complain file doesn't exist Review URL: http://codereview.chromium.org/6825047
* Add crossystem fwupdate_tries and fix nv storage writesRandall Spangler2011-04-081-1/+17
| | | | | | | | | | | | | | | | | Change-Id: I1835f4867de80aa3764e4a4c6d90b3fde2dc4308 R=reinauer@chromium.org BUG=chromium_os:13672 TEST=manual crossystem kern_nv=3 crossystem fwupdate_tries # should print 3 crossystem fwupdate_tries=15 crossystem kern_nv # should print 0x0000000F crossystem kern_nv=0 crossystem fwupdate_tries # should print 0 Review URL: http://codereview.chromium.org/6813056
* Add crossystem arch (reports x86 or arm, depending on platform)Randall Spangler2011-04-082-2/+6
| | | | | | | | | | | | Change-Id: I857ead5b108d42195145cdbc5cdafa817f3416b4 R=reinauer@chromium.org BUG=chrome-os-partner:3023 TEST=crossystem arch (reports 'x86' on x86 platform, 'arm' on ARM platform) Review URL: http://codereview.chromium.org/6813054
* Add dummy crossystem_arch implementation for amd64 (host)Randall Spangler2011-04-071-0/+57
| | | | | | | | | Change-Id: Ia87cdd9551af1d592ece641c2abcc02db73869e1 R=piman@chromium.org,jrbarnette@chromium.org BUG=none TEST=sudo emerge vboot_reference TBR=jrbarnette@chromium.org
* Refactor crossystem to move x86-specific implementation to its own file.Randall Spangler2011-04-077-604/+893
| | | | | | | | | | | | | | | | | | | | This should be ready for the ARM team to pick up and work on. I added a placeholder ARM implementation file, though it's not hooked up in the Makefile yet. As soon as you implement the VbNvStorage APIs, all the related crossystem commands will start working. Ditto for VbSharedData. The params which x86 gets from ACPI you'll need to get from u-boot somehow, probably via your own kernel driver. R=robotboy@chromium.org BUG=chromium-os:12522 TEST=emerge-x86-alex vboot_reference, make sure it still works on x86 Review URL: http://codereview.chromium.org/6780008 Change-Id: I628ee56508421b937ed50db7cb9b8385408d2f5e
* Use uint64_t and avoid down casting as much as possible.Gaurav Shah2011-03-251-2/+2
| | | | | | | | | Change-Id: I231d1b3a059907c3806feced7e1b8f1c06575ba5 BUG=chromeos-partner:2912 TEST=make clean all && make runtests Review URL: http://codereview.chromium.org/6733018
* Print LoadKernel() debug data from VbSharedDataRandall Spangler2011-03-211-10/+124
| | | | | | | | | | Change-Id: I60cf9c4dd07e83b1ed1a5bac8a3ce8c2a54df45b R=reinauer@chromium.org BUG=chrome-os-partner:2748 TEST=manually check output of 'crossystem vdat_lkdebug' Review URL: http://codereview.chromium.org/6685097
* Use VbSharedData instead of VbNvStorage for fwb_tries and kernkey_vfyRandall Spangler2011-03-181-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I5ed3509a9d4e578cd2e98f493dab59bc2fbd5827 R=dlaurie@chromium.org BUG=chrome-os-partner:2748 TEST=manual crossystem fwb_tries=3 (reboot) crossystem tried_fwb (should print 1) crossystem fwb_tries=0 (reboot) crossystem tried_fwb (should print 0) In dev mode... Boot a kernel signed with the same key as in the firmware crossystem kernkey_vfy (should print sig) Boot a kernel signed with a different key than the firmware crossystem kernkey_vfy (should print hash) Review URL: http://codereview.chromium.org/6711045
* Add TPM version checkingRandall Spangler2011-03-171-2/+13
| | | | | | | | | | | | | Change-Id: Ic32b7bcf0bc5501e21dc84e79419a256d9b0d095 R=semenzato@chromium.org,reinauer@chromium.org BUG=chrome-os-partner:2832 TEST=manual crossystem tpm_fwver tpm_kernver On a debug system, this will return 0x00010001 0x00010001 Review URL: http://codereview.chromium.org/6685075
* Add VbSharedData field parsingRandall Spangler2011-03-171-40/+92
| | | | | | | | | | | | | | | | | | | | | 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
* Add VB test error func/numRandall Spangler2011-03-151-0/+8
| | | | | | | | | Change-Id: Ibe253963f0424935554fe91f166ef5040a723c6f BUG=13107 TEST=make && make runtests Review URL: http://codereview.chromium.org/6698032
* Add function for VDAT processing.Vadim Bendebury2011-03-151-0/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL is a user space counterpart of http://codereview.chromium.org/6690023, which provided the ability to retrieve buffers through chromeos_acpi driver. The buffer contents is communicated as a multi line string with each buffer byte represented as a two symbol hex number. `crosstool', on the other has to map the buffer contents into a certain binary structure. This CL add conversion of the multiline string into a binary buffer and also adds a temp. routine to dump the buffer contents on the screen when `crosstool' is invoked. Change-Id: I8dd3eb935332f9bc8769c71de0db302365f12d70 BUG=chromium-os:13069, chromium-os:13091 TEST=manual - Install the new image on a target with firmware providing the VDAT ACPI method. - Run crosstool and watch for the last line: vdat = 11 22 33 44 ff 1f 1c 40 ff 57 74 41 ff ff ff ff # Raw VDAT contents. localhost tmp # Review URL: http://codereview.chromium.org/6695012
* Add check-value support and check /proc/cmdline for cros_nodebugRandall Spangler2011-03-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: I35158810184be03f18d98893e4dd640088384579 BUG=12904 TEST=manual crossystem fwb_tries=1 crossystem fwb_tries?1 && echo YES || echo NO --> YES crossystem fwb_tries?0x01 && echo YES || echo NO --> YES crossystem fwb_tries?0 && echo YES || echo NO --> NO crossystem fwb_tries=0 crossystem fwb_tries?0 && echo YES || echo NO --> YES crossystem fwb_tries?1 && echo YES || echo NO --> NO crossystem fwb_tries?0x01 && echo YES || echo NO --> NO crossystem ecfw_act --> RW (if it's not, change RW to RO in the tests below) crossystem ecfw_act?RW && echo YES || echo NO --> YES crossystem ecfw_act?BOB && echo YES || echo NO --> NO For the following tests, boot Alex with dev switch on and fwb_tries=1 Expected output of `crossystem mainfw_type mainfw_act cros_debug` under each of the following scenarios: * Neither "cros_debug" nor" cros_nodebug" in kernel command line: normal B 1 * Kernel command line changed to include "cros_nodebug": normal B 0 * Kernel command line changed to include "cros_nodebugg": normal B 1 * Kernel command line changed to include "ccros_nodebug": normal B 1 Review URL: http://codereview.chromium.org/6665005
* Add cros_debug option to crossystemRandall Spangler2011-03-101-4/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: Ie62364a87f7f144ee647054d2a9ef83522cdbe7d BUG=12904 TEST=manual Expected output of `crossystem mainfw_type cros_debug` under each of the following scenarios: * Boot Alex with dev switch off: normal 0 * Boot Alex with dev switch on (and dev firmware): developer 1 * Boot Alex with dev switch on (and normal firmware): normal 1 * Boot Alex with recovery firmware: recovery 0 * Boot Alex with dev switch off, then turn the dev switch on after booting: normal 0 * Boot Cr-48 with dev switch off: normal 0 * Boot Cr-48 with dev switch on: developer 1 * Boot Cr-48 with recovery firmware: recovery 0 * Boot Alex with dev switch off and kernel command line changed to include "cros_debug": normal 1 * Boot Alex with dev switch off and kernel command line changed to include "cros_debugg": normal 0 * Boot Alex with dev switch off and kernel command line changed to include "ccros_debug": normal 0 * Boot H2O BIOS with kernel command line changed to include "cros_debug": nonchrome 1 * Boot H2O BIOS with kernel command line changed to include "cros_debugg": nonchrome 0 * Boot H2O BIOS with kernel command line changed to include "ccros_debug": nonchrome 0 Review URL: http://codereview.chromium.org/6659021
* Add crossystem support for nvram_cleared and kern_nvRandall Spangler2011-03-011-9/+6
| | | | | | | | | | | | | | | Fix try_b processing And move key block flags check up in LoadFirmware(), which speeds up boot when the dev switch is off because it doesn't do a signature check and then throw it out. BUG=12282 TEST=build firmware, try by hand Review URL: http://codereview.chromium.org/6596081 Change-Id: I10474e9e0ae324906dfe02a351347d04ce847f67
* Add kern_nv field to crossystemRandall Spangler2011-03-011-1/+7
| | | | | | | | | | | | Change-Id: Ifa5cc3bd8367a258fb720162572f450a1be99c03 BUG=none TEST=manual crossystem kern_nv=0x12345678 crossystem kern_nv Review URL: http://codereview.chromium.org/6602040
* rename tried_fwb constantsRandall Spangler2011-02-251-1/+1
| | | | | | | | | Change-Id: Ib8018bfe29eed50766c699d832efe4f1afcabb1a BUG=none TEST=make && make runtests Review URL: http://codereview.chromium.org/6597015
* Add NV storage fields for firmware flagsRandall Spangler2011-02-251-0/+13
| | | | | | | | | | | | | | | 1) Did firmware attempt RW slot B before slot A? 2) Did firmware check the kernel keyblock signature, or just its hash? Added crossystem support as well. BUG=chrome-os-partner:1657 TEST=make && make runtests Review URL: http://codereview.chromium.org/6597011 Change-Id: I0d743ae87cedd938ba988170793717d3fdbd8ce9
* crossystem uses VbNvStorageRandall Spangler2011-02-251-6/+119
| | | | | | | | | | | | | | | | | | | | | | | Change-Id: I3f158115c8514bda0b271674870d68717c4816e6 BUG=12282 TEST=manual crossystem fwb_tries=0 && crossystem fwb_tries This should print 0 on both BIOSes. crossystem fwb_tries=6 && crossystem fwb_tries This should print 1 on an older BIOS and 6 on a new BIOS (0050+) Then reboot and run crossystem mainfw_act This should print 'B', since fwb_tries was non-zero. Review URL: http://codereview.chromium.org/6576059
View Lorry Controller Status