summaryrefslogtreecommitdiff
path: root/host/arch
Commit message (Collapse)AuthorAgeFilesLines
* Modify crossystem to recognize Panther Point GPIO controllerrelease-R19-2046.BVadim Bendebury2012-03-231-1/+2
| | | | | | | | | | | | | | | | | | | There is a filter in crossystem which makes sure that it accepts GPIO information only from a subset of GPIO controllers. Panther Point needs to be included in the list. BUG=chrome-os-partner:8615 TEST=manual . run the new crossystem on a Link . modify write protect and and recovery (as it comes from servo-2) pins' status . observe the appropriate crossystem values change Change-Id: I3ac269a9ea520f2c44ee090fe71ec8ad808692ba Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/18936 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* 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>
* 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>
* 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>
* 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-151-2/+0
| | | | | | | | | | | | | | | 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>
* 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>
* 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-271-6/+6
| | | | | | | | | | | | | | | 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-271-5/+25
| | | | | | | | | | | | | | | | 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-052-64/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 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 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-072-0/+697
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
View Lorry Controller Status