aboutsummaryrefslogtreecommitdiff
path: root/src/mainboard/google/storm/chromeos.c
AgeCommit message (Collapse)Author
2017-03-28vboot: Assume EC_SOFTWARE_SYNC and VIRTUAL_DEV_SWITCH by defaultJulius Werner
The virtualized developer switch was invented five years ago and has been used on every vboot system ever since. We shouldn't need to specify it again and again for every new board. This patch flips the Kconfig logic around and replaces CONFIG_VIRTUAL_DEV_SWITCH with CONFIG_PHYSICAL_DEV_SWITCH, so that only a few ancient boards need to set it and it fits better with CONFIG_PHYSICAL_REC_SWITCH. (Also set the latter for Lumpy which seems to have been omitted incorrectly, and hide it from menuconfig since it's a hardware parameter that shouldn't be configurable.) Since almost all our developer switches are virtual, it doesn't make sense for every board to pass a non-existent or non-functional developer mode switch in the coreboot tables, so let's get rid of that. It's also dangerously confusing for many boards to define a get_developer_mode() function that reads an actual pin (often from a debug header) which will not be honored by coreboot because CONFIG_PHYSICAL_DEV_SWITCH isn't set. Therefore, this patch removes all those non-functional instances of that function. In the future, either the board has a physical dev switch and must define it, or it doesn't and must not. In a similar sense (and since I'm touching so many board configs anyway), it's annoying that we have to keep selecting EC_SOFTWARE_SYNC. Instead, it should just be assumed by default whenever a Chrome EC is present in the system. This way, it can also still be overridden by menuconfig. CQ-DEPEND=CL:459701 Change-Id: If9cbaa7df530580a97f00ef238e3d9a8a86a4a7f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18980 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-04-05chromeos: Simplify fill_lb_gpios even furtherJulius Werner
A long time ago many Chrome OS boards had pages full of duplicated boilerplate code for the fill_lb_gpios() function, and we spent a lot of time bikeshedding a proper solution that passes a table of lb_gpio structs which can be concisely written with a static struct initializer in http://crosreview.com/234648. Unfortunately we never really finished that patch and in the mean time a different solution using the fill_lb_gpio() helper got standardized onto most boards. Still, that solution is not quite as clean and concise as the one we had already designed, and it also wasn't applied consistently to all recent boards (causing more boards with bad code to get added afterwards). This patch switches all boards newer than Link to the better solution and also adds some nicer debug output for the GPIOs while I'm there. If more boards need to be converted from fill_lb_gpio() to this model later (e.g. from a branch), it's quite easy to do with: s/fill_lb_gpio(gpio++,\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\));/\t{\1, \2, \4, \3},/ Based on a patch by Furquan Shaikh <furquan@google.com>. BUG=None BRANCH=None TEST=Booted on Oak. Ran abuild -x. Change-Id: I449974d1c75c8ed187f5e10935495b2f03725811 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14226 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-04-22google/storm: indicate start of normal boot on LED ringVadim Bendebury
Instead of switching off the LED ring for the normal boot path, turn it on with the dedicated pattern, indicating that the device firmware has started executing. BRANCH=storm BUG=chrome-os-partner:39044 TEST=program the new firmware on an SP5 device and verify that the new 'normal boot' pattern is displayed in all following scenarios: - power up the device (the pattern shows within the first second) - boot the device to bash prompt and restart. - press the recovery button and reboot the device. Once the LED ring shows the 'recovery button pressed' pattern, release the recovery button. Change-Id: Iedd66d2575ad587af77e35d23efb22a83a92858b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 092358bd17a323d0bd2fec555f43cb587486bbec Original-Change-Id: I24de45326eab83b57bcf16b5598388f81c7d0f00 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/265536 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9923 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-22google/storm: enable virtual development mode switchVadim Bendebury
The whirlwind device is using a button instead of the switch to enable dev mode. BRANCH=storm BUG=chrome-os-partner:36059 TEST=with the rest of the patches applied it is possible to enable and disable dev mode on Whirlwind and the mode persists over reboots. Change-Id: I6d31c8429ea0515bea2b7d707325d9092487048a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 495bd07e3a1d6c587a5f01efa2801d2c4e7edbe8 Original-Change-Id: I8879833ca13074e8275393c3b98df06d56a5361d Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/261416 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9875 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22i2c/ww_ring: decouple LED display from vbootVadim Bendebury
The patterns displayed on the LED ring while under the coreboot control are not driven by the vboot, but by the board code instead, The four distinct states of the LED display are: - all off - recovery button push detected, waiting for it to be released - wipeout request pending - recovery button was pushed long enough to trigger this request - recovery request pending - recovery button was pushed long enough to trigger this request. BRANCH=storm BUG=chrome-os-partner:36059 TEST=no functional changes Change-Id: I38d9a3028013b902a7a67ccd4eb1c5d533bf071c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: bdfff0e646283da6a2faaacf33e0179d2fea221c Original-Change-Id: Ie279151b6060a2888268a2e9a0d4dc22ecaba460 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/260649 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9868 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22google/storm: support factory reset (wipeout) requestVadim Bendebury
The recovery switch on storm is overloaded: it needs to be pressed for a certain duration at startup to signal different requests: - keeping it pressed for 8 to 16 seconds after startup signals the need for factory reset (wipeout); - keeping it pressed for longer than 16 seconds signals the need for Chrome OS recovery. This patch adds a function to report the wipeout request status and enables the new feature on Storm. BRANCH=storm BUG=chrome-os-partner:37219 TEST=verified that keeping the recovery button pressed between 8 and 16 seconds at startup results in the wipeout request generated (crossystem 'wipeout_request' returns 1). Keeping the button pressed for more than 16 seconds triggers recovery mode. Change-Id: I17131593e12833866a22837271feb0e6989e6750 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3c503ec13c2b096d4a21fb299c0dd0396f1d01e9 Original-Change-Id: Ic3678217906e56307d47378fa8a6defeb314084e Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/259844 Reviewed-on: http://review.coreboot.org/9863 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-22google/storm: use whirlwind LED ring on SP5 boardsVadim Bendebury
The latest whirlwind requirements call for the need to indicate different device states while it is still in coreboot (it could be waiting for recovery or for factory reset trigger). Initialize the LED ring when running on the SP5 hardware (which is the first proper Whirlwind device). BRANCH=storm BUG=chrome-os-partner:36059 TEST=when the device starts the LED ring gets shut down Change-Id: I9dd0bca4849a2a8500322c84c7351aeef00d862e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 24e4da56d4c43d03f235d0cfd5995ef235e6a2c5 Original-Change-Id: Ica37301aa27f35897d2bf467ae319fb5e68adc1d Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/258271 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9859 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17storm: handle dual purpose recovery buttonVadim Bendebury
Storm devices' recovery button is overloaded. Pressing it when the system is running is supposed to reset the device. To trigger recovery mode the button must be held pressed for at least 5 seconds after reset. Currently interpreting the recovery button state is the responsibility of the board (vboot gets a consolidated state, which is a combination of several conditions), so the simplest way to implement this feature is to make the board follow the recovery button state. In case the button is not pressed when it is first sampled, its state is saved immediately and no recovery request is reported. In case the button is pressed when it is first sampled, the board code keeps polling it up to 5 seconds and acts accordingly. BRANCH=storm BUG=chrome-os-partner:36059 TEST=tried starting a whirlwind with recovery button pressed for various durations, it entered recovery mode when the button was pressed longer than 5 seconds. Change-Id: Icb3250be7c2a76089c070acd68cb521d1399e245 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 45e7265bc760944f93dd98903d39d2b30aa96365 Original-Change-Id: Iab3609ebce3a74e3d0270775b83f3cf03a8837ca Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/251711 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/9761 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-15storm: add code for detecting rec/dev/write protect switches' statusDaisuke Nojiri
The gpio access code has been moved to a separate file to match other platforms. Accessor functions are added to read different switches state. They will be read by verstage, when it is enabled, and by ramstage, for passing the values to depthcharge. It is unfortunate that the gpio values are not being cached and can change by the time CBMEM table is filled, but we have to live with that for now. BUG=chrome-os-partner:33756,chrome-os-partner:34161 BRANCH=storm TEST=none yet. Change-Id: I229fed0e35d643912f929671d5fc25aee5d1d167 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7e15aa281a1dbf2c463650b6c04991436022d8d4 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I940b54cd3cf046b94d57d59d370e634a70a8bbeb Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229426 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9681 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>