summaryrefslogtreecommitdiff
path: root/host/arch/x86/lib/crossystem_arch.c
Commit message (Collapse)AuthorAgeFilesLines
* crossystem: Add Skylake PCH GPIO controller IDfirmware-ultima-7287.131.Bfirmware-terra-7287.154.Bfirmware-setzer-7287.360.Bfirmware-reks-7287.133.Bfirmware-edgar-7287.167.Bfirmware-cyan-7287.57.Bfirmware-celes-7287.92.BDuncan Laurie2015-07-211-0/+1
| | | | | | | | | | | | | | | Add the GPIO controller ID that is used in the Skylake PCH so it can properly export and use GPIOs that are exported in VBNV for write protect. BUG=chrome-os-partner:42560 BRANCH=none TEST=verify crossystem output with and without WP enabled Change-Id: Ic85c202bd0ca15c154c10481926ef18bafe3fac5 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/286827 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* crossystem: Add skylake platform IDsDuncan Laurie2015-07-211-0/+2
| | | | | | | | | | | | | | Add the skylake-u and skylake-y vendor/device IDs so it can be reported by crossystem. BUG=chrome-os-partner:42560 BRANCH=none TEST=run "crossystem platform_family" on glados Change-Id: I5f9b92d404166e56d77cf8b0cd627a3a0b63bedf Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/286921 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* crossytem:Fix the write protect line gpio valuefactory-smaug-7265.BJohn Zhao2015-07-141-24/+72
| | | | | | | | | | | | | | | | | | | | For crossystem to work correctly on Strago/Cyan, add Braswell string and correct GPIO offset calculations. In Braswell, write protect line is MF_ISH_GPIO_4 as encoded as 0x10016 where the GPEAST offset (COMMUNITY_OFFSET_GPEAT) is 0x10000 BUG=chrome-os-partner:40835 BRANCH=None TEST=test_that -b <strago/cyan> <IP> platform_Crossystem Change-Id: I365f3d6ca9f3ac7ef50abb9b2ba13f184d39c100 Signed-off-by: John Zhao <john.zhao@intel.com> Signed-off-by: Arindam Roy <arindam.roy@intel.com> Reviewed-on: https://chromium-review.googlesource.com/274841 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
* vboot_reference: fix several syntax warnings found by clang.stabilize-6996.BYunlian Jiang2015-04-151-3/+1
| | | | | | | | | | | | BUG=chromium:475949 TEST=CC=x86_64-cros-linux-gnu-clang CXX=x86_64-cros-linux-gnu-clang++ emerge-falco vboot_reference BRANCH=none Change-Id: I3341e840c3f26f8579d35e0bb411566b0ad86164 Reviewed-on: https://chromium-review.googlesource.com/265834 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yunlian Jiang <yunlian@chromium.org> Tested-by: Yunlian Jiang <yunlian@chromium.org>
* crossystem: Add support for multiple gpiochip entriesDuncan Laurie2014-10-201-4/+46
| | | | | | | | | | | | | | | | | | | | | | The current logic for finding a GPIO expects only one gpiochip entry to exist in /sys/class/gpio. With Samus there is a second entry because the codec also exports a set of GPIOs. To solve this we can use the gpiochip#/label file and compare against the GPIO controller name described in ACPI. This adds support for that detection method, as well as a new GPIO controller entry for INT3437:00 which is used in Broadwell systems. BUG=chrome-os-partner:33098 BRANCH=samus TEST=crossytem wpsw_cur works on samus (TOT with enabled codec) Change-Id: Ib06f25c7c7e1451a3ab3bb00fd063e23b4d75878 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224156 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* crossystem: Change ReadFileInt to take an unsigned int pointerDuncan Laurie2014-10-181-73/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently ReadFileInt assumes that an integer value read from a file is never going to be "-1" and uses that value to indicate failure. In particular for GPIO values that may be returned by the kernel it is possible for them to be not simply 0 or 1 but instead a bit within the GPIO status register that indicates the value. The function semantics are changed to have the caller pass in the variable to store the integer in, and use the return code explicitly as a pass or fail condition. This requires all the callers of ReadFileInt to be changed to use the new scheme, and the x86 ReadGpio function is changed to normalize the GPIO value that is read from the kernel instead of assuming it is always 1 for active high values. BUG=chrome-os-partner:32645 BRANCH=samus,auron TEST=build for samus, check crossystem output and ensure that all values are properly reported and that wpsw_cur is correct now. Also tested to ensure no changes in output on: x86-alex, daisy, peach_pit, lumpy, stumpy, nyan_big, nyan_blaze, rush_ryu, panther, wolf, zako, auron, rambi, squawks, parrot_ivb, veyron_pinky Change-Id: I824152eed5f96cf1faaa18ba31a01f4d346ad172 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223009 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add broadwell PCI ID for platform family lookup tableDuncan Laurie2014-08-291-0/+1
| | | | | | | | | | | | | | | Currently broadwell systems are returning (error) for this lookup. BUG=chrome-os-partner:28234 BRANCH=none TEST=test crossystem output: > crossystem platform_family Broadwell Change-Id: I204dd47e62683d5e81e16ddb9c3ea96034fb22a5 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/214862 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* crossystem: Add PCH-LP GPIO typeDuncan Laurie2014-07-301-0/+1
| | | | | | | | | | | | | | Rather than continuing to report different variants of PCH GPIO the same way use the common name of PCH-LP. BUG=chrome-os-partner:28234 BRANCH=None TEST=boot on samus and ensure there are no (error) reported Change-Id: I9321e7bd85b2b3b3ebadc22ac32be6759e85f822 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/210393 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* crossystem: handle BayTrail gpiosAaron Durbin2013-12-111-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | BayTrail systems have 3 banks of gpios. Therefore, the Linux kernel exposes these 3 banks as 3 gpiochip entries. The kernel driver expects the 3 banks to be exposed with specific UIDs associated with a specific banks. ChromeOS firmware maps gpios within a given bank using the bank's MMIO offset. In summary: Bank Type | UID | Offset ----------+-----+------- SCORE | 1 | 0x0000 NCORE | 2 | 0x1000 SUS | 3 | 0x2000 BUG=chrome-os-partner:24408 BUG=chrome-os-partner:24324 BRANCH=None TEST=Built. 'crossystem wpsw_cur' works correctly. Change-Id: I251f86285ce9733f7ca90ed1ebef536f4fe5c07c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179513 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* crossystem: add GpioChipset sturcture for x86Aaron Durbin2013-12-111-6/+29
| | | | | | | | | | | | | | | | | | | | | Up until recently the x86 systems had a single contiguous set of gpio numbers exported through /sys/class/gpio as /sys/class/gpiochip<X> values. BayTrail systems have 3 sets of gpio numbers. Therefore, there needs to be a translation/look-up function based on chipset. The existing chipsets have a 1:1 mapping, but this patch lays the ground- work for chipset-specific translation. BUG=chrome-os-partner:24324 BUG=chrome-os-partner:24440 BUG=chrome-os-partner:24408 BRANCH=None TEST=Built. Ran on Rambi. Change-Id: I32bcd975aea421f86a0220ee30332f48fe727656 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179512 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* crossystem: make BayTrail a valid platform_familyAaron Durbin2013-12-111-0/+1
| | | | | | | | | | | | | | | BayTrail is a valid chromeos platform. Therefore, allow it to be returned for 'platform_family'. BUG=chrome-os-partner:24324 BUG=chrome-os-partner:24440 BRANCH=None TEST=Built. 'crossystem platform_family' reports 'BayTrail'. Change-Id: I8d0b835f5f40e7f34adb4f91bd974c428bbaf6da Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179511 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Make crossystem.h more polite and more useful.test-4980.Btest-4824.Bstabilize-R33-4982.Bstabilize-5062.Bstabilize-4920.6.Brelease-R32-4920.Bfirmware-bolt_kirby-4979.Bfactory-panther-4920.23.BJ. Richard Barnette2013-10-311-1/+3
| | | | | | | | | | | | | | | | | | | This adds a VB_MAX_STRING_PROPERTY for callers that don't want to guess at how big to make their buffers. Additionally, it changes the size parameter to VbGetPropertyString() from int to size_t. BUG=None TEST=compile the code BRANCH=none Change-Id: I22809d48e13b535593cb22a56444e2dcb27791a5 Reviewed-on: https://chromium-review.googlesource.com/175039 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Richard Barnette <jrbarnette@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
* crossystem: Add device IDs for haswellDuncan Laurie2013-05-231-0/+2
| | | | | | | | | | | | | | | | | 0x8086,0x0a04 is Haswell ULT 0x8086,0x0c04 is Haswell Mobile BUG=chrome-os-partner:19263 BRANCH=none TEST=manual test on slippy hardware: $ crossystem platform_family Haswell Change-Id: Ia885d0c8f0be2fb626257ca513f581df50259173 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56075 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* crossystem: Add LynxPoint to list of valid x86 chipset typesDuncan Laurie2013-05-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Haswell CPUs are paired with the LynxPoint chipset and this needs to be a valid controller name for crossystem. BUG=chrome-os-partner:19263 BRANCH=none TEST=manual This was tested on a wtm2 system to ensure that a GPIO defined in chromeos ACPI that is exported by the kernel at /sys/devices/platform/chromeos_acpi/GPIO.# is used by crossystem and the GPIO is exported in /sys/class/gpio and read. $ cat /sys/devices/platform/chromeos_acpi/GPIO.1/GPIO.2 34 $ cat /sys/class/gpio/gpio196/value 1 $ crossystem wpsw_cur 1 Change-Id: I04064109e99270d7d26b27182b17fffbf47b025b Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50224 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* Massive refactoring of external header files.Bill Richardson2013-04-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This reduces the number of exported header files to the minimum needed by the existing userspace utilities and firmware implementations. BUG=chromium:221544 BRANCH=none TEST=manual, trybots CQ-DEPEND=CL:47019,CL:47022,CL:47023 sudo FEATURES=test emerge vboot_reference FEATURES=test emerge-$BOARD \ vboot_reference \ chromeos-cryptohome \ chromeos-installer \ chromeos-u-boot \ peach-u-boot \ depthcharge Change-Id: I2946cc2dbaf5459a6c5eca92ca57d546498e6d85 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/47021 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* crossystem devsw_cur returns devsw_boot if virtual dev switchRandall Spangler2012-10-041-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | devsw_cur is really a meaningless concept on systems with virtual dev switches; it exists primarily to support factory test of physical developer switches. However, some plugins use this instead of the preferred devsw_boot, and it's easier to modify crossystem than the plugins at this point in time. BUG=chrome-os-partner:12928 BRANCH=none (affects all current products, but is an OS-level change, not FW) TEST=manual - On link, 'crossystem devsw_cur devsw_boot' with dev switch on -> '1 1' - On link, 'crossystem devsw_cur devsw_boot' with dev switch off -> '0 0' - On lumpy or earlier, 'crossystem devsw_cur' should return current dev switch position; check this by toggling the physical switch without rebooting and see that the reported value follows the switch value. Change-Id: Ie7416e5cb03c133572c32af677b55ed18884dfb8 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/34531 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* Crossystem should return at-boot switch positions from VbSharedDataRandall Spangler2012-08-061-29/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is more reliable than reading them through FDT/ACPI, since it reflects the positions as shown to verified boot code. Notes: 1. This affects ALL platforms with virtual dev switches (x86 AND arm) 2. The fix should have no effect on older platforms, but I haven't tested those. BUG=chrome-os-partner:11805 TEST=manual 1. boot in normal mode. devsw_boot = 0 # Developer switch position at boot recovery_reason = 0 # Recovery mode reason for current boot recoverysw_boot = 0 # Recovery switch position at boot wpsw_boot = 1 # Firmware write protect hardware switch position at boot 2. boot in developer mode. localhost ~ # crossystem devsw_boot = 1 # Developer switch position at boot recovery_reason = 0 # Recovery mode reason for current boot recoverysw_boot = 0 # Recovery switch position at boot wpsw_boot = 1 # Firmware write protect hardware switch position at boot 3. boot in developer-recovery mode using keyboard combo. devsw_boot = 1 # Developer switch position at boot recovery_reason = 2 # Recovery mode reason for current boot recoverysw_boot = 1 # Recovery switch position at boot wpsw_boot = 1 # Firmware write protect hardware switch position at boot 4. disable WP and reboot. wpsw_boot should be 0. Change-Id: If4156b5e14c6923c5b331c7e5feaabbffe1dad37 Reviewed-on: https://gerrit.chromium.org/gerrit/29199 Commit-Ready: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Require -Wall -Werror for everything.Bill Richardson2012-05-031-1/+1
| | | | | | | | | | | BUG=none TEST=none Change-Id: Ib9781238274285f73d00d8fca4ecda28fc2c6678 Reviewed-on: https://gerrit.chromium.org/gerrit/21748 Commit-Ready: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* crossystem: introduce a new main firmware type, 'netboot'Vadim Bendebury2012-04-201-0/+2
| | | | | | | | | | | | | | | | | | | | We need to be able to tell when a ChromeOS machine was brought up using netboot. This condition will be communicated from firmware using the BINF.3 ACPI object (upcoming u-boot change). BUG=chrome-os-partner:7952 TEST=manual . boot a ChromeOS machine using the updated firmware and examine the main firmware type reported by crossystem: localhost ~ # echo $(/var/crossystem mainfw_type) netboot Change-Id: I35b10f41eb1f928a122c384d0179c9027f263acd Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/20707 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* 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 in a platform_family value to crossystemBernie Thompson2012-01-091-0/+56
| | | | | | | | | | | | | | | | | | | | | | 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>
* 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>
* 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>
* Introduce arm support in crossystem.Vadim Bendebury2011-05-051-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-081-1/+3
| | | | | | | | | | | | 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
* Refactor crossystem to move x86-specific implementation to its own file.Randall Spangler2011-04-071-0/+591
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