Needed for the main() prototype
Change-Id: I921a77d8b131b751291d3a279b23ee18b13eca8d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10862
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch aligns the output of coreinfo with the output
of libpayload, and switches from using $(Q) to .SILENT
Change-Id: I6c3cdda7febc02bab9195fc98f46490c0d478a9a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10744
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
LDO2 regulator is used as an always-on reference for the droop alert
circuit. Set output voltage to match kernel settings.
CQ-DEPEND=CL:284649
BUG=chrome-os-partner:42305
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt
Change-Id: I5ef4e266d8ec278dadffa846af8dc49b6d18c37e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 611465f6248cba0ddce0083b431cb7ee17bc4b4c
Original-Change-Id: I58cc473452b871392d813387707a0b8288e46561
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/284879
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10900
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Define custom stage_entry to apply workaround for A57 hardware issue
for power on reset. It is observed that BTB contains stale data after
power on reset. This could lead to unexpected branching and crashes at
random intervals during the boot flow. Thus, invalidate the BTB
immediately after power on reset.
BUG=chrome-os-partner:41877
BRANCH=None
TEST=Compiles successfully and reboot test does not crash in firmware
for 10K iterations.
Change-Id: Ifbc9667bc5556112374f35733192b67b64a345d2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bc7c2fec3c6b29e291235669ba9f22ff611064a7
Original-Change-Id: I1f5714074afdfee64b88cea8a394936ca848634b
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/284869
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10899
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This allows SoCs/CPUs to have custom stage_entry in order to apply any
fixups that need to run before standard cpu reset procedure.
BUG=chrome-os-partner:41877
BRANCH=None
TEST=Compiles successfully
Change-Id: Iaae7636349140664b19e81b0082017b63b13f45b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 498d04b0e9a3394943f03cad603c30ae8b3805d4
Original-Change-Id: I9a005502d4cfcb76017dcae3a655efc0c8814a93
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/284867
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10897
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Well, this is just embarrassing...
BRANCH=None
BUG=None
TEST=None
Change-Id: I7c443d2100b6861d736320ac14c1bd9965937a66
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 455e3784882ea1b76bcf8e17724869e37d9c629d
Original-Change-Id: Ia33e98aeaa8e78e3e3d2c7547e673a623ea86ce2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/284596
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/10879
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Martin Roth <gaumless@gmail.com>
- extra rule for config.h creation
- include kconfig.h from libpayload
- libpayload symbols are conflicting with gcc builtins (e.g. log2)
- ALIGN() is already defined in libpayload these days
- move libpayload build directory under build/
Change-Id: I2aefdde26853253d58f6cf6e186e784871c1cb5b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10717
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Print the old timB value to observes changes made.
Change-Id: Iecec4918f1d95560b6e7933a169ccce83fcf073d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10891
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Issue observed:
Any memory DIMM placed in channel0 slots stops at "c320c discovery failed".
The same memory DIMM works when placed in channel1 slots.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
* DIMMs:
* elixir 1GB 1Rx8 PC3-10600U M2Y1G64CB88A5N
* crucial 2GB 256Mx64 CT2566aBA160BJ
* corsair 8GB CMZ16GX3M2A1866C9
Problem description:
In case of good timmings (all bits are set) an offset of 3*64 was applied.
The following test (c320c discovery) failed only on those byte-lanes.
Problem solution:
Don't modify timB in case of good timings measured.
Final testing result:
The system boots with every DIMM placed in channel 0 slots.
Change-Id: Iea426ea4470640ce254f16e958a395644ff1a55c
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10889
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
For hex and int type kconfig symbols, IS_ENABLED() doesn't work. Instead
check to make sure they're defined and not zero. In some cases, zero
might be a valid value, but it didn't look like zero was valid in these
cases.
Change-Id: Ib51fb31b3babffbf25ed3ae4ed11a2dc9a4be709
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10886
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Platforms selecting the HUDSON_DISABLE_IMC symbol were showing the
warning:
warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
CPU_AMD_AGESA_BINARY_PI) selects HUDSON_DISABLE_IMC which has unmet
direct dependencies (SOUTHBRIDGE_AMD_PI_AVALON ||
SOUTHBRIDGE_AMD_PI_BOLTON || SOUTHBRIDGE_AMD_PI_KERN)
By moving the definition of the symbol outside of the if block
and removing the default n, we can get rid of the warning without
changing the value for any platform.
Change-Id: I5c1bdfbcf3c5c44ee05b8c5e679f6854d784d8dc
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10680
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
This protection didn't make sense to me - it seems like things would
probably break if printf wasn't defined anyway.
Change-Id: Ifb6bad46e193b35c13b7ad4946511fec74beff92
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10887
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The script `util/crossgcc/buildgcc` was rewritten in commit 85b07d68
(buildgcc: move to a package centric user interface) and the switches
changed. This patch does the following:
- IASL was split out of the gcc builds, so needs a target of its own.
- Add clang build target
- Update the build-ARCH targets as buildgcc -G no longer builds gcc.
- Rework all the targets to use common targets to call buildgcc
- Split the tempfile clean from the regular clean
- Change the 'all' target to leave the tempfiles until all architectures
are built so that if one fails and needs a rebuild, it doesn't have to
start from scratch.
- Add an all_without_gdb target
- Add clang build to all
Change-Id: I4ff720eab6d9b72d00757fd2b632e6d9a6c25aa3
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10679
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Kconfigs symbols of type bool are always defined, and can be tested with
the IS_ENABLED() macro.
symbol type except string.
Change-Id: Ic4ba79f519ee2a53d39c10859bbfa9c32015b19d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Display a warning if CONFIG_HUDSON_FWM_POSITION is not inside CBFS.
This can be extended to other Kconfig values for CBFS.
Change-Id: I2423f7b361dda8aac5dab409fa7b656de486f635
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10683
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch calculates the address where the chipset firmware descriptor
should be located and compares it against the actual value from Kconfig.
If the two don't match, it puts up a warning.
This could probably replace the config variable completely, but I wanted
to see how other people felt before doing that. I seem to recall that
the value used to be calculated, so I figure that there must be a reason
it's done this way at this point.
If we do want to keep the Kconfig setting, this patch could also be
modified to just verify that the HUDSON_FWM_POSITION is inside the ROM
space.
Change-Id: I94addf463e2c694a94eef218ec855103a3bb5da5
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10682
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The CBFS_BASE_ADDRESS can be compared against values used with cbfstool
to generate warnings. This can help cut down on mistakes and debug
time.
Change-Id: I149007dd637661f799a0f2cdb079d11df726ca86
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10681
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add macros to standardize math done in the Makefiles in a posix
compliant manner.
int-multiply takes an arbitrary list of values to multiply, the same as
the int-addition macro.
The other macros only work on two values at a time.
Change-Id: I3b754b9bcde26f33edc4f945d5af3d5444f383c7
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10874
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
rmodule.c: In function ‘rmodule_create’:
rmodule.c:287:29: error: ‘phdr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
(phdr->p_vaddr + phdr->p_memsz))) {
^
rmodule.c:204:14: note: ‘phdr’ was declared here
Elf64_Phdr *phdr;
^
Change-Id: I94a235253610348484eef218ec855103a3bb5da5
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Reviewed-on: http://review.coreboot.org/10881
Tested-by: build bot (Jenkins)
Reviewed-by: Francis Rowe <info@gluglug.org.uk>
While running ramstage with the EARLY_CBMEM_INIT config the timestamp
cache was re-initialized and subsequently used. The result was that
the ramstage timestamps would be dropped from cbmem. The reason
is that the ramstage timestamps perpetually lived in ramstage BSS
never getting sync'd back into cbmem. The fix is to honor the
cache state in ramstage in the timestamp_init() path.
Also, make cache_state a fixed bit width to allow for different
architectures across the pre-ramstage stages.
TEST=Used qemu-armv7 as a test harness with debugging info.
Change-Id: Ibb276e513278e81cb741b1e1f6dbd1e8051cc907
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10880
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Fix up commit f44ac13d (Add TCPA table.) by adding an entry for
`CBMEM_ID_TCPA_LOG` to the macro `CBMEM_ID_TO_NAME_TABLE`.
Currently, printing the CBMEM table of contents the name is missing.
$ sudo cbmem -l
CBMEM table of contents:
ID START LENGTH
[…]
6. 54435041 c7fa8ff8 00010000
[…]
Adding an entry and rebuilding the utility cbmem, the name `TCPA_LOG` is
shown.
$ sudo cbmem -l
CBMEM table of contents:
ID START LENGTH
[…]
6. TCPA LOG c7fa8ff8 00010000
[…]
Change-Id: I089ea714349e07b322330bc11f723cc031c61c56
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10856
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix up commit f44ac13d (Add TCPA table.) by moving the entry to the
correct position so that all entries are sorted.
Change-Id: Ib68deb525a942051e1063ea2ec0a3e3b4a937024
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10855
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Include the microcode files from the microcode subdirectory.
BRANCH=none
BUG=None
TEST=Build and run on cyan.
Change-Id: I4c8bf64d221d9ead18f1b7d6e1f01f61d88c9b25
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10873
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Update Makefile.inc to use the simplified CBFS image type.
BRANCH=none
BUG=None
TEST=Build and run on cyan
Change-Id: Ibb8413ab90b147e9d26d32639a8822c57ca54a46
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10871
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Useful information, record it in the destination directory,
together with .config.
Change-Id: Icf3282f61f502b37f9f06d7d5a0a630f49c96ed2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10864
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of having a second copy that already within 2-3 days
becamer quite outdated, use the same xcompile copy for coreboot
and libpayload, as we do with Kconfig already.
This requires a simple change to the top level xcompile to understand
both CONFIG_COMPILER_GCC and CONFIG_LP_COMPILER_GCC (only one of
them will occur at the same time)
libpayload's .xcompile target was moved later so that it can make use
of $(top)
Change-Id: I44001067f551cd0776dd303cbaeaa40eb3d5c1db
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10863
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The include breaks compilation on ARM with clang.
Change-Id: I1ce0d58dbcbb8785c23739670c8c9574c329a81c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10858
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This fixes issues with our clang reference toolchain on ARM.
Change-Id: Ib754941059285f15332bc694814aff6285969545
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10857
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
clang probing will pick up the first one that clang does not complain about
and right now that is armv7a-eabi, even though our toolchain builds for
armv7-a-eabi (and consecutively the build fails because there is no
armv7a-eabi-as)
Change-Id: I2594151150107f8e9c1aad33647dcb2f9878f953
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10830
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
One kilobyte of SRAM needs to be allocated and the feature enabled.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=timer error messages do not show up in the coreboot log any more
Change-Id: I1d5e5521bf9ae495d4f4f50ff017c846a8420719
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffb9bfb0cdfab1391f8ae07669a2ab6b24d88dd7
Original-Change-Id: I60066672334db36f5e7adbef6794d7afd177d292
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235893
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10847
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds support for the LZ4 decompression algorithm to
libpayload. It's what all the cool kids are using for decompression
these days and has many interesting advantages over LZMA (and everything
else I know of): blazing fast decompression (20(!) times faster than
LZMA, twice as fast as LZO on my Cortex-A72), no memory requirements on
decompression, and possibly in-place decompression support. It pays for
that with a lower compression ratio (about 50% larger compressed size
than LZMA, 10% larger than LZO for an ARM64 Linux kernel binary), but
the boot time math still works in its favor for our IO speeds.
This patch only adds the raw decompression functions for use by external
payloads, we can later try integrating them in CBFS. It copies the
decompression code itself unmodified from the upstream LZ4 library at
github.com/Cyan4973/lz4 which will hopefully make it easy to update. The
frame format parsing is reimplemented since the upstream version looks
unnecessarily complex and unreadable for our needs.
BRANCH=smaug
BUG=chrome-os-partner:32184
TEST=With other patches, booted ARM64 kernel that got compressed from
15M to 5.1M and decompresses in 44ms.
Change-Id: I65bdc4b2b19bd51c7b7e17a4e4b79da301a2a014
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f8a1fc996d5b0234d07f567fa8163d0f802d5144
Original-Change-Id: I15c0620da05561ade2552b15ffdf6bb3afd7eb26
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/282743
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10845
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=chrome-os-partner:42220
BRANCH=veyron
TEST=Used physical recovery button to enter dev mode on mickey
Change-Id: I78332f516b042be9c0cef6d8a59af44b670fc260
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4fcd79a133dc750dffd5d23e0b84a109e7b7cb8d
Original-Change-Id: I8d8dc0c0b98bbd194095d47047c8c5199ce17769
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/283546
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10844
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
HW team has suggested to set CAR2PMC_CPU_ACK_WIDTH to 0.
BUG=None
BRANCH=None
TEST=Tested on Smaug; still boot to kernel
Change-Id: I4d13a4048b73455b16da7a40c408c912fa97e4e7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8891a79e72af26d986af9e415149d4ca0aa6fedd
Original-Change-Id: I850a6756d7743993802fb85aad403e4cbef7a661
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/282416
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10841
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I2C6 controller needs SOR_SAFE and DPAUX1 clocks to work. These 2 clocks
are mistakenly enabled by MBIST. MBIST fix will be submitted next, which
will disable these 2 clocks as initial states. Enable these 2 clocks now
so I2C6 will continue to work after MBIST fix.
BUG=None
BRANCH=None
TEST=Tested on Smaug, make sure that panel shows display
(I2C6 is used to turn on backlight)
Change-Id: Id47453e784d53fd6831e8d19a8d57c04c4e1f82f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 83e935f100be85e1e831a3f9f16962304f7cd7d6
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Change-Id: If312881c94570066bdc54f0f5c48226e862bddc6
Original-Reviewed-on: https://chromium-review.googlesource.com/282415
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10840
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Danger has a physical developer mode switch, it was just never
set up. This patch defines it, sets it up in fill_lb_gpios(),
and disables VIRTUAL_DEV_SWITCH.
Note: For now at least, dev mode is a bit wonky on Danger. It's
connected to both a DIP switch and a button. The button is normally
open, pulling dev mode high (defaulting to ON). The switch's "ON"
position will pull the value low, so we invert the value in coreboot
to see the expected behavior. Dev mode is enabled by holding the
button down during boot or by setting switch 2 in the DIP bank to
the ON position.
BUG=none
BRANCH=none
TEST=toggled dev switch on Danger and saw dev screen show up (or
not) as expected
Change-Id: I9369b96b6c9b54553d969b919ed663abdc704dd2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: dce53f1a31919f15f6e46c4a7d1c5ce541c2b318
Original-Change-Id: I737f165d7704e2f73375099367f012b365e3e77d
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/280852
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10839
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This can be a problem with freshly updated devices that are periodically
powered on while closed (as explained in the bug report).
In this case, just don't count down. In case of actual errors (where we
want the system to fall back to the old code), this now means that the
retries have to happen with the lid open.
Bump vboot's submodule revision for the vboot-side support of this.
BUG=chromium:446945
TEST=to test the OS update side, follow the test protocol in
https://code.google.com/p/chromium/issues/detail?id=446945#c43
With a servo, it can be sped up using the EC console interface to start
the closed system - no need to wait 60min and plugging in power to get
to that state.
Change-Id: I0e39aadc52195fe53ee4a29a828ed9a40d28f5e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10851
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
-mno-red-zone is an option that pretty much every barebone software package
(eg. kernel, bootloader, ...) needs to use.
We weren't hurt by it yet, but make sure we won't in the future.
Change-Id: Ide5b63424ec1be5bf7bcade10540190b9871593b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10852
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change the FrameBufferSize field from UINT64 to UINT32 to match the
Platform Initialization 2.4 specification.
BRANCH=none
BUG=None
TEST=Build and run on cyan
Change-Id: I28dc0608675ed5840863ecd15bd2f57e6b2f4c1d
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10834
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix a cut and paste error in the warranty statement.
BRANCH=none
BUG=None
TEST=Build and run on cyan
Change-Id: If64b02f2c0fc2970932f23b99ad64beab5ab754e
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10835
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Jonathan A. Kollasch