Age | Commit message (Collapse) | Author |
|
On one particular TV the TV was holding SDA low when it came up. It
would release the SDA when the SCL went low the first time.
Unfortunately the HDMI i2c port wouldn't transmit until the SDA was
released.
Let's detect this case and insert a bogus clock pulse to try to get the
other side to release SDA.
It's unclear why the kernel doesn't have this problem.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia TV works now
Change-Id: Ic9d27eb69bdc9c5fb11a68258e0c755cdc8b79d7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 356ee7503f04e741a41be37ad573b588067b7114
Original-Change-Id: I4b6361877e0576cc4ea2f643f073f1aab660e434
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309258
Original-Reviewed-by: Agnes Cheng <agnescheng@google.com>
Original-Commit-Queue: Agnes Cheng <agnescheng@google.com>
Original-Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Original-Tested-by: Agnes Cheng <agnescheng@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/309546
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12451
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When we first added ARM support to coreboot, it was clear that the
bootblock would need to do vastly different tasks than on x86, so we
moved its main logic under arch/. Now that we have several more
architectures, it turns out (as with so many things lately) that x86 is
really the odd one out, and all the others are trying to do pretty much
the same thing. This has already caused maintenance issues as the ARM32
bootblock developed and less-mature architectures were left behind with
old cruft.
This patch tries to address that problem by centralizing that logic
under lib/ for use by all architectures/SoCs that don't explicitly
opt-out (with the slightly adapted existing BOOTBLOCK_CUSTOM option).
This works great out of the box for ARM32 and ARM64. It could probably
be easily applied to MIPS and RISCV as well, but I don't have any of
those boards to test so I'll mark them as BOOTBLOCK_CUSTOM for now and
leave that for later cleanup.
BRANCH=None
BUG=None
TEST=Built Jerry and Falco, booted Oak.
Change-Id: Ibbf727ad93651e388aef20e76f03f5567f9860cb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12076
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
'edid->hdmi_monitor_detected' would indicate whether the monitor
interface is HDMI or DVI.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=Previously, my LG monitor couldn't show dev screen. But now I can see
dev screen have been posted normally.
Change-Id: Id71f051b2cd792712e52bee7a763db383c1962a8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 88101589a22d06f0bc25e0750b2862cf66b55391
Original-Change-Id: I157861d327926b834e1e8606b0b676f413491c70
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/309056
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12346
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
Previously if we tried to read the HDMI EDID several times and failed
each time then we're return from hdmi_read_edid() with no error. Then
we'd interpret whatever happened to be in memory at the time as an
EDID--not so great.
Let's actually look at the error.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Monitor that can't read EDID not shows that in the log
Change-Id: I6e64b13ae3f8c61bf1baaa1cfc8b24987bd75cf3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 44bda7311f9ee677235e4dc8db669226518b3895
Original-Change-Id: I9089755b75118499bec37bdb96d1635f66252e65
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309298
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12231
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
It's no longer used.
BUG=none
BRANCH=none
TEST=it compiles
Change-Id: I3d9385e0e1f14977c1632f3a8dda771c684ce458
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5381b6434996da10706dd358928f98703ac0892c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Ib0cfaf1bb173a7150f7ff504b9f58a62eb82e781
Original-Reviewed-on: https://chromium-review.googlesource.com/302634
Reviewed-on: http://review.coreboot.org/12138
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
BUG=chrome-os-partner:42054
BRANCH=none
TEST=tested with subsequent patch
Change-Id: I92d67ff4b706c16677661ead1edd5c190ccc6d95
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: dced0fcbc35457d7326d590948ce5fe098a5e735
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I7b29c647380046ac41a290b19fdfba186bcb2127
Original-Reviewed-on: https://chromium-review.googlesource.com/302632
Reviewed-on: http://review.coreboot.org/12136
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
BUG=chrome-os-partner:41201
BRANCH=firmware-veyron
TEST=tested with subsequent patch on mickey
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I7081d92be128f522e1a33eee6f3de9dfbbf042ea
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a390c927ad8ed035520c8a813db808715dc5e527
Original-Change-Id: I3ce0f7b2772c8c652b7f461749d01cc7b669b6cf
Original-Reviewed-on: https://chromium-review.googlesource.com/300616
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12134
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Currently coreboot expects the loader to clear the bss section
for all stages. i.e. stages don't clear their own bss. On ARM
SoCs the BootROM would be responsible for this. To do that
one needs to include the bss section data (all zeros) in the
bootblock.bin file. This was previously being attempted by
keeping the .bss info in the .data section because objcopy
happened zero out non-file allocated data section data.
Instead go back to linking bootblock with the bss section
but mark the bss section as loadable allocatable data. That
way it will be included in the binary properly when objcopy
-O binary is emplyed. Also do the same for the data section
in the case of no non-zero object values are in the data
section.
Without this change the trick of including .bss in .data
was not working when there wasn't a non-zero value object
in the data section.
BUG=None
BRANCH=None
TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains
the cleared bss.
Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11680
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This changes the API to rkclk_configure_cpu() such that we can pass
in the desired APLL frequency in each veyron board's bootblock.c.
Devices with a constrainted form facter (rialto and possibly mickey)
will use this to run firmware at a slower speed to mitigate risk
of thermal issues (due to the RK808, not the RK3288).
BUG=chrome-os-partner:42054
BRANCH=none
TEST=amstan says rialto is noticably cooler (and slower)
Change-Id: I28b332e1d484bd009599944cd9f5cf633ea468dd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d10af5e18b4131a00f202272e405bd22eab4caeb
Original-Change-Id: I960cb6ff512c058e72032aa2cbadedde97510631
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297190
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11582
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Some of the Chrome OS boards were directly calling vboot
called in some form after contorting around #ifdef preprocessor
macros. The reasoning is that Chrome OS doesn't always do display
initialization during startup. It's runtime dependent. While
this is a requirement that doesn't mean vboot functions should be
sprinkled around in the mainboard and chipset code. Instead provide
one function, display_init_required(), that provides the policy
for determining display initialization action. For Chrome OS
devices this function honors vboot_skip_display_init() and all
other configurations default to initializing display.
Change-Id: I403213e22c0e621e148773597a550addfbaf3f7e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11490
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Due to HDMI need to set dclk_rate to 27Mhz, and we can't
caclu a suitable config paramters for this rate, so we
need to multiple rate unless the vco larger then VCO_MAX.
When NPLL rate multiple to 54MHz, pll_para_config could
caclu a right paramters, and I have verify the clock jitter
is okay to HDMI output.
Jitter Reports:
Dclk Rate NPLL Rate nr/no/nf jitter Margin
27MHz 54MHz 2/10/45 449.0ps +51.0%
BRANCH=None
BUG=chrome-os-partner:42946
TEST=Mickey board, show right recovery picture on TV,
and 480p clock jitter test passed
Change-Id: Iaa0a6622e63d88918ed465900e630bdf16fde706
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 59f1552026889f61167cfeaec3def668ba709c10
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Change-Id: Iab274b41f163d2d61332df13e5091f0b605cb65c
Original-Reviewed-on: https://chromium-review.googlesource.com/288416
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290331
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If an HDMI display is detected (EDID can be read), set the
display mode to 480p. If for some reason 480p is not supported
then we'll fall back to the automatically detected display mode.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=dev mode screen shows up on Mickey at 480p resolution
Change-Id: I2c431eff6673392d3c09e1b66c66ba12ecc6eeb0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 76203a683c4501f368c50fe24101f68746ddb7f0
Original-Change-Id: I90dea37daa2d78628230d7d47f7ef0e917cbd7bb
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290554
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11392
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Assume that HDMI implies usage of an external display, and that we
want to try bringing up display if we can read an EDID.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=none; need a display with corrupt EDID to test with
Change-Id: I11cc61140d905d70798a7b46db7847f3a1b3c886
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: ace7773623eac57f068ecd50baa9108ce028cf1b
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I9e22984a98b1a5f8cd9645b92dc9b87e8d968f01
Original-Reviewed-on: https://chromium-review.googlesource.com/293548
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11391
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
[pg: extended to also cover peach_pit, daisy and lenovo/t530]
Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9
Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289964
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Struct edid defien pvsync & phsync as an character,
like '+' or '-', so we need to check sync polarity
by comparing with characters '+' and '-' instead of
treating as boolean.
BRANCH=None
BUG=chrome-os-partner:42946
TEST=Mickey board, light monitor normally
Change-Id: I92d233e19b6df8917fb8ff9a327ccb842c152d65
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 2d22d4b6e7108474f67200e0fb1e4894cd88db85
Original-Change-Id: I14c72aa8994227092a1059d2b25c1dd2249b9db1
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/289963
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11380
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add CHROMEOS dependencies to selects for the following Kconfig
symbols:
CHROMEOS_RAMOOPS_DYNAMIC
CHROMEOS_RAMOOPS_NON_ACPI
CHROMEOS_VBNV_CMOS
CHROMEOS_VBNV_EC
CHROMEOS_VBNV_FLASH
EC_SOFTWARE_SYNC
LID_SWITCH
RETURN_FROM_VERSTAGE
SEPARATE_VERSTAGE
VBOOT_DISABLE_DEV_ON_RECOVERY
VBOOT_EC_SLOW_UPDATE
VBOOT_OPROM_MATTERS
VBOOT_STARTS_IN_BOOTBLOCK
WIPEOUT_SUPPORTED
This gets rid of these sorts of Kconfig errors:
warning: BOARD_SPECIFIC_OPTIONS selects CHROMEOS_VBNV_EC which has
unmet direct dependencies (MAINBOARD_HAS_CHROMEOS && CHROMEOS)
Note: These two boards would never actually have CHROMEOS enabled:
intel/emeraldlake2 has MAINBOARD_HAS_CHROMEOS commented out
google/peach_pit doesn't have MAINBOARD_HAS_CHROMEOS
Change-Id: I51b4ee326f082c6a656a813ee5772e9c34f5c343
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I54650671adaef3bc129c662d6e972474c869afaa
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10859
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
BUG=None
BRANCH=None
TEST=Compiles successfully for veyron_pinky
Original-Change-Id: I3862e9bf2c32085c921adae4c1dcdf88ff0f3ff3
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/227243
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 0fabdbb05826160beb8ee8f89339b18a49e87ab8)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I4504d29a43084d4bd406626899b25903200fa6d7
Reviewed-on: http://review.coreboot.org/10740
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Now that we have functioning display code for all platforms,
we can just get rid of this ugly hack used on non-Chromebook
veyrons.
BUG=none
BRANCH=none
TEST=built for Brain, Rialto, Mickey, Romy
Change-Id: Ibe248c7cc74940811345c249d66992d74fe85fe5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9c627b087ba9fc07b4ec4a6d55d2e0203bdd4ff5
Original-Change-Id: I946eddb4e8ce1dbaa20212a2bb417e71a31b2ba3
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/282049
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10785
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
BUG=none
BRANCH=none
TEST=built w/ follow-up rialto patch
Change-Id: I166c75673c199e8c6860f601db6759cdc3cb9c96
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ba0e0b639f12654ec54216d4366c688baa5b3253
Original-Change-Id: Id21c87ace2f4d381a1e374e1d5fe15cf1cd96da0
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/282047
Reviewed-on: http://review.coreboot.org/10779
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We currently select either HDMI or EDP (default). This patch
allows us to use HDMI as a fallback for devices that may have
a display connected on either interface. It also renames the
enums to sound a little more sensible in other contexts (more
on that in the follow-up patches).
VOP_MODE_AUTO is added to the mode enum which will make it explicit
that a board can support either. In AUTO_MODE we will try EDP first
and then fallback to HDMI. Other modes can be set to force a certain
behavior such as HDMI-only on Mickey where it doesn't make sense to
try EDP.
A follow-up patch will add logic for when we explicitly don't want
to probe for any display (headless devices).
BUG=none
BRANCH=none
TEST=On veyron_danger, connected EDP and HDMI displays and saw dev
mode screen appear on EDP display. Unplugged EDP and then dev mode
screen showed up on HDMI.
Change-Id: I22b38031c4ab3d79fbb182f7a906da1197f35543
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3f57ed3758c4e516d9fd226ad9499b102b81b423
Original-Change-Id: I352dcde16f7f3ebbf5796852b685685e541eb794
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/281076
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10775
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
CRU request (24MHz * nf) / nr > 440MHz, but now ddr 300MHz
setting can't meet this request, so modify it
BRANCH=None
BUG=None
TEST=Set ddr frequency to 300MHz and boot from mickey
Change-Id: I00324f5864f5ce8c1a3768268e402e0beca214c6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3d292b67245e714cb03ed35ee28c9b838d514da5
Original-Change-Id: I885704542293ed55e429a0b4b30135af7978990f
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/282445
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10772
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some basic MMU setup is required to allow unaligned memory accesses that
happen across our entire codebase.
Change-Id: If5a84e19a7a3e47d6009fd073b1323dfb25e6a06
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10753
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Where vboot verification can start, and how the code flow looks like is more a
property of the SoC (and its properties, like amount of SRAM) rather than the
board.
Change-Id: I610153ea4ceddc226d8cc3e17a515e41fc0479cf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10662
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
this is an brief hdmi driver which config with simple
display parameter, const encoder input & output color
format and 8bit color depth, and only 48KHz audio support.
what's more to prevent TV have not show an right things
before coreboot switch to kernel space, we have to add
an terrible 2s delay to driver (2s come from test many
times), cause we have to wait TV to respond (we got no
flag to check whether it is ready).
BUG=chrome-os-partner:40337
TEST=Booted Veyron Jerry and display normal
BRANCH=None
Change-Id: Icd33467e95de6219e1b614616f0112afc52097b6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7e5b699aff75a579116aae63d858c834b2f648e8
Original-Change-Id: Iedc87c011c5b62ce5f16a296dd9c3e0c2eaba59b
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/272565
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: http://review.coreboot.org/10625
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The HAVE_UART_MEMORY_MAPPED symbol is no longer present, so these
don't actually select anything.
Change-Id: I6d0eb610e48a4506ac7449ac677ee67981d0ff0d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10608
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
BUG=none
BRANCH=none
TEST=Boot from mickey board
Change-Id: I6eadf52bddcf89011a112a8e5dee5e752556add9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e3c865f0bf8567c3183d7948a0f9e8361db70695
Original-Change-Id: I438527ee0870044f48b23a6842986e7cf166e191
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/276290
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/10477
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch adds a few bit counting functions that are commonly needed
for certain register calculations. We previously had a log2()
implementation already, but it was awkwardly split between some C code
that's only available in ramstage and an optimized x86-specific
implementation in pre-RAM that prevented other archs from pulling it
into earlier stages.
Using __builtin_clz() as the baseline allows GCC to inline optimized
assembly for most archs (including CLZ on ARM/ARM64 and BSR on x86), and
to perform constant-folding if possible. What was previously named log2f
on pre-RAM x86 is now ffs, since that's the standard name for that
operation and I honestly don't have the slightest idea how it could've
ever ended up being called log2f (which in POSIX is 'binary(2) LOGarithm
with Float result, whereas the Find First Set operation has no direct
correlation to logarithms that I know of). Make ffs result 0-based
instead of the POSIX standard's 1-based since that is consistent with
clz, log2 and the former log2f, and generally closer to what you want
for most applications (a value that can directly be used as a shift to
reach the found bit). Call it __ffs() instead of ffs() to avoid problems
when importing code, since that's what Linux uses for the 0-based
operation.
CQ-DEPEND=CL:273023
BRANCH=None
BUG=None
TEST=Built on Big, Falco, Jerry, Oak and Urara. Compared old and new
log2() and __ffs() results on Falco for a bunch of test values.
Change-Id: I599209b342059e17b3130621edb6b6bbeae26876
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3701a16ae944ecff9c54fa9a50d28015690fcb2f
Original-Change-Id: I60f7cf893792508188fa04d088401a8bca4b4af6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/273008
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
CPU_HAS_BOOTBLOCK_INIT is only declared once and selected elsewhere
(with no overlap), and never read. Remove it.
Change-Id: I3f294b0724a87876a7e2f274e6933fe10321a69d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10253
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The struct rockchip_spi_media type is no longer used;
nor is initialize_rockchip_spi_cbfs_media(). Remove them.
Change-Id: I2c24be249e0cd89e2dd328e05cdd24a178fe37e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10214
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change switches all SOC vendors and southbridges
to be autoincluded by Makefile.inc, rather than having to be
mentioned explicitly in soc/Makefile.inc or in
soc/<vendor>/Makefile.inc.
This means, vendor and SOC directories are now "drop
in", e.g. be placed in the coreboot directory hierarchy
without having to modify any higher level coreboot files.
The long term plan is to enable out of tree components to be
built with a given coreboot version (given that the API did not
change).
Change-Id: Iede26fe184b09c53cec23a545d04953701cbc41d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9799
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
RTC drivers now select RTC, so that code which depends on them
can implement fallback behavior for systems that lack the
hardware or driver.
Change-Id: I0f5a15d643b0c45c511f1151a98e071b4155fb5a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9953
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Upstream coreboot regularly runs Coverity over the code base. Turns out
that's a good idea since it's really easy to screw yourself over with a
missing parenthesis and some unfortunately deceptive line breaking.
This patch fixes a bug in LPDDR3 initialization due to an incorrect
operator precedence assumption ( ?: does not bind stronger than | ). In
effect, instead of setting MR11[1:0] to 0b11 or 0b00 based on ODT, we're
unconditionally setting MR0[1:0] to 0b11. Thankfully, MR0[1:0] seems to
contain read-only bits so this might have not been a problem when ODT is
off (which is currently true for all LPDDR boards).
Also adding a redundant LPDDR_OP() around the 0 to make the intent
clearer and changing 3 and 0 to 0x3 and 0x0 to make it more obvious that
these are bit masks (right?).
BRANCH=veyron
BUG=None
TEST=Running reboot loop on a Minnie, looks good so far...
Change-Id: I06464aaa57e693b1973846a5771162244f7a1c57
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan
Original-Commit-Id: 5bd9eba39fb7b0f940fead963bbc1878b031b2cb
Original-Change-Id: I701ce059472078b5de09a45dd31f54b65a51e641
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/264135
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Jinkun Hong <jinkun.hong@rock-chips.com>
Original-Tested-by: Jinkun Hong <jinkun.hong@rock-chips.com>
Reviewed-on: http://review.coreboot.org/9911
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BOARD_ID functionality is not what requires the GPIO lib,
but it is the mainboard specific implementations that do.
The option essentially says whether the SoC provides
<soc/gpio.h> (with the interface required by the common
GPIO code). Right now, x86 and Samsung's Exynos SOCs
don't have support for this interface.
So this should be selected by the SOC, not by
BOARD_ID_SUPPORT.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
BUG=none
BRANCH=none
TEST=emerge-storm coreboot still successfully compiled an image
Change-Id: I0ce2bd7ce023f22791d31a6245833b61135504b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0dd4dea521372194eedf11b077d95fd3b15ad9f7
Original-Change-Id: I3dea6c2fb42a23fcb9d384c3bbfa7fc8e217be2d
Original-Reviewed-on: https://chromium-review.googlesource.com/262743
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9899
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The code to calculate the RK3288 SPI controller's internal clock divisor
is wrong: it assumes that the divisor register was an "n-1" divisor when
it actually isn't (due to some misleading kernel code that was copied in
here). This means that all SPI clocks are currently running lower than
expected.
This patch fixes the calculation and changes all callers such that the
effective speeds stay the same.
BRANCH=veyron
BUG=chrome-os-partner:38352
TEST=Booted Jerry with and without the patch, dumping the divisor for
flash and EC clocks. Made sure it stays the same.
Change-Id: I2336e2b81c2384b5076175fcf32717a3ab2ba0c5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1fd5b990f937019a9bee7bd693c91d6e2fca1adb
Original-Change-Id: I094d57a5933c8b849f5c66194e6cc2952ab68b90
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262269
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9887
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch is a manual cleanup of all the rubble left by coccinelle
waltzing through our code base. It's generally not very good with line
breaks and sometimes even eats comments, so this patch is my best
attempt at putting it all back together.
Also finally remove those hated writel()-style macros from the headers.
BRANCH=none
BUG=chromium:444723
TEST=None (depends on next patch)
Change-Id: Id572f69c420c35577701feb154faa5aaf79cd13e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 817402a80ab77083728b55aed74b3b4202ba7f1d
Original-Change-Id: I3b0dcd6fe09fc4e3b83ee491625d6dced98e3047
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254865
Reviewed-on: http://review.coreboot.org/9837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch is a raw application of the following spatch to src/:
@@
expression A, V;
@@
- writel(V, A)
+ write32(A, V)
@@
expression A, V;
@@
- writew(V, A)
+ write16(A, V)
@@
expression A, V;
@@
- writeb(V, A)
+ write8(A, V)
@@
expression A;
@@
- readl(A)
+ read32(A)
@@
expression A;
@@
- readb(A)
+ read8(A)
BRANCH=none
BUG=chromium:444723
TEST=None (depends on next patch)
Change-Id: I5dd96490c85ee2bcbc669f08bc6fff0ecc0f9e27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 64f643da95d85954c4d4ea91c34a5c69b9b08eb6
Original-Change-Id: I366a2eb5b3a0df2279ebcce572fe814894791c42
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254864
Reviewed-on: http://review.coreboot.org/9836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch is a raw application of the following spatch to the
directories src/arch/arm(64)?, src/mainboard/<arm(64)-board>,
src/soc/<arm(64)-soc> and src/drivers/gic:
@@
expression A, V;
@@
- write32(V, A)
+ writel(V, A)
@@
expression A, V;
@@
- write16(V, A)
+ writew(V, A)
@@
expression A, V;
@@
- write8(V, A)
+ writeb(V, A)
This replaces all uses of write{32,16,8}() with write{l,w,b}()
which is currently equivalent and much more common. This is a
preparatory step that will allow us to easier flip them all at once to
the new write32(a,v) model.
BRANCH=none
BUG=chromium:451388
TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky.
Change-Id: I16016cd77780e7cadbabe7d8aa7ab465b95b8f09
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93f0ada19b429b4e30d67335b4e61d0f43597b24
Original-Change-Id: I1ac01c67efef4656607663253ed298ff4d0ef89d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254862
Reviewed-on: http://review.coreboot.org/9834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
if DCDC_UV_ACT_REG setted, when the buck voltage drop to 85%,
rk808 will reset this buck, but now when the current consumption large,
rk808 may miscarriage of justice this status, so we must disable this function
BUG=chrome-os-partner:34834
TEST=Boot from jerry, and do RUNIN test sucess
BRANCH=None
Change-Id: I08cef73b88d6c2722b389c632c7db29605f4545d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 858c8abc11a824fc3d991a39a49710243f4b1473
Original-Change-Id: I46ebe332c576eebd3386b5042b146a8b57a5c194
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/254496
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9831
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The wrong offsets were being used for the GRF_SOC_CON2 register. This also
configures odt based on the value of odt in the sdram_params for lpddr systems.
BUG=chrome-os-partner:37346
TEST=boot veyron_speedy and veyron_jerry
BRANCH=None
Change-Id: I13ec3d0df162fe73fabf8af40dd5472e15d6f6af
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 403ab13de17290dc3766bd6f1a03b6effbe58b41
Original-Change-Id: Ic0c18cc7ccf861ef8749e6c950fab9a2802e5f26
Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255584
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9828
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When using single-channel ddr, DMC channel 1 need to reset dll,
otherwise it will lead to pmdomain idle request fails.
BUG=chrome-os-partner:35654
BRANCH=veyron
TEST=boot rialto
Change-Id: Id6b673187c688d238e9a391b3d98720c783e3af4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 927e8426104f8869e139c3f60a04cd49bf726e61
Original-Change-Id: I8be1567040ddb5f2a2b0d06568e517d794ead87a
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/250060
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9819
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The ramstage is loaded from romstage, so the LZMA scratchpad buffer used
to decompress it is part of the romstage BSS in SRAM. On RK3288, SRAM
cannot be cached which makes the decompression so slow that it's faster
to just load an uncompressed image from SPI. Disable ramstage
compression on this SoC to account for that.
[pg: implementation avoids restructuring all of Kconfig]
BRANCH=None
BUG=None
TEST=Built for Pinky and Falco, confirmed that the former didn't have
COMPRESS_RAMSTAGE in its .config and the latter still did. Measured a
speed-up of about 35ms on Pinky. (For some weird reason, the
decompression of the payload also takes way longer than on other
platforms, although not as long as the ramstage. I have no explanation
for that and can't really think of a good way to figure it out... maybe
the Cortex-A12 is just terrible at some operation that LZMA uses a lot?)
Change-Id: I9f67f7537696ec09496483b16b59a8b73f4cb11b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234192
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9792
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch adds the necessary platform glue to allow the use of
software-driven I2C bit banging on the RK3288. This is just a debugging
feature that can be used to reproduce certain I2C failure cases.
Also fix Makefile verstage linking for the feature and add some new
rk3288 IOMUX macros as needed.
BRANCH=None
BUG=None
TEST=Added "CONFIG_SOFTWARE_I2C=y" to configs/config.veyron_jerry,
wrapped Jerry's bootblock and verstage in software_i2c_attach/detach()
calls, confirmed that both PMIC and TPM could be driven correctly with
software I2C driver. Tried out different combinations of
software_i2c_wedge_ack() and software_i2c_wedge_read() on the PMIC and
observed transfer results with the hardware controller after reboot...
the worst that would happen is that the first register read-modify-write
(DCDC_ILMAX) would fail to read, but all later transfers would be fine.
Since that register is written twice (due to current BUCK1 ramp
implementation) and is not terribily important anyway, I think we don't
need to worry about wedging problems.
Change-Id: Iba801ee61d30fb1fd3aef8300612c67fa50c441b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 24dfca9bab38a20c40ef0c2dd4c775b8d8f47487
Original-Change-Id: I96777300a57c85471bad20e23a455551e9970222
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/247890
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9757
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Many ChromeOS devices use a GPIO to reset the system, in order to
guarantee that the TPM cannot be reset without also resetting the CPU.
Often chipset/SoC hardware watchdogs trigger some kind of built-in
CPU reset, bypassing this GPIO and thus leaving the TPM locked. These
ChromeOS devices need to detect that condition in their bootblock and
trigger a second (proper) reboot.
This patch adds some code to generalize this previously
mainboard-specific functionality and uses it on Veyron boards. It also
provides some code to add the proper eventlog entry for a watchdog
reset. Since the second reboot has to happen before firmware
verification and the eventlog is usually only initialized afterwards, we
provide the functionality to place a tombstone in a memlayout-defined
location (which could be SRAM or some MMIO register that is preserved
across reboots).
[pg: Integrates
'mips: Temporarily work around build error caused by <arch/io.h> mismatch]
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Run 'mem w 0xff800000 0x9' on a Jerry, watch how a "Hardware
watchdog reset" event appears in the eventlog after the reboot.
Change-Id: I0a33820b236c9328b2f9b20905b69cb934326f2a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fffc484bb89f5129d62739dcb44d08d7f5b30b33
Original-Change-Id: I7ee1d02676e9159794d29e033d71c09fdf4620fd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242404
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: c919c72ddc9d2e1e18858c0bf49c0ce79f2bc506
Original-Change-Id: I509c842d3393bd810e89ebdf0dc745275c120c1d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242504
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9749
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Turns out there are uses for memlayout regions not specific to vboot2.
Rather than add yet another set of headers for a single region, let's
make the vboot2 one common for chromeos.
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm.
Change-Id: I228e0ffce1ccc792e7f5f5be6facaaca2650d818
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b
Original-Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242630
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9748
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|