Age | Commit message (Collapse) | Author |
|
When we added CONFIG_VBOOT_MIGRATE_WORKING_DATA, the idea was that on
some Arm platforms the original working data buffer was in SRAM, which
stays accessbile for the whole runtime of the system. There is no reason
to migrate it into CBMEM on those platforms because ramstage and the
payload could continue to access it in SRAM.
Now that we've had a couple of months of experience with this option, we
found that most of our Arm platforms have some issue that requires
migrating anyway, because BL31 often claims SRAM for itself and makes it
inaccessible to the payload. On the remaining platforms, accessing SRAM
from the payload is possible but still an issue, because libpayload
doesn't have enough memory layout information to set up proper page
tables for it, so we're accessing it uncached and at risk of alignment
errors.
Rather than having to figure out how to map the right SRAM range for
every platform in the payload, let's just get rid of the option.
memcpy()ing 12KB isn't worth this much hassle.
Change-Id: I1b94e01c998f723c8950be4d12cc8f02b363a1bf
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
Bootblock space is tight on this SoC and recent changes increased it
ever so slightly to make this a problem.
Since the bootblock is well-tested, we can get by without console.
Change-Id: I7496a3e313b2c6ee6fb3c4671eac64376d84e0dc
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33068
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
<types.h> is supposed to provide <stdint.h> and <stddef.h>.
When <types.h> is included, <stdint.h> and/or <stddef.h> is removed.
Change-Id: I2db0a647bc657a3626cb5e78f23e9198e290261a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
|
|
This patch fixes up all code that would throw a -Wtype-limits warning.
This sometimes involves eliminating unnecessary checks, adding a few odd
but harmless casts or just pragma'ing out the warning for a whole file
-- I tried to find the path of least resistance. I think the overall
benefit of the warning outweighs the occasional weirdness.
Change-Id: Iacd37eb1fad388d9db7267ceccb03e6dcf1ad0d2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32537
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Increase ramstage to 2M, required to actually embed the 7.2mb uImage
into the coreboot.rom, increase the postram cbfs cache in order for the
fit image to be loadable (without this increase the fit payload is found
but not loaded)
Change-Id: Iee0ed9f7958588ceda54bb32253c84cac68abea2
Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The name OPROM is somewhat inaccurate, since other steps to bring
up display and graphics are needed depending on mainboard/SoC.
This patch cleans up OPROM code nomenclature, and works towards
the goal of deprecating vboot1:
* Rename CONFIG_VBOOT_OPROM_MATTERS to
CONFIG_VBOOT_MUST_REQUEST_DISPLAY and clarify Kconfig
description
* Remove function vboot_handoff_skip_display_init
* Remove use of the VbInit oflag VB_INIT_OUT_ENABLE_DISPLAY
* Add |flags| field to vboot_working_data struct
* Create VBOOT_FLAG_DISPLAY_REQUESTED and set in vboot_handoff
BUG=b:124141368, b:124192753, chromium:948529
TEST=make clean && make test-abuild
TEST=build and flash eve device; attempt loading dev/rec modes
BRANCH=none
Change-Id: Idf111a533c3953448b4b9084885a9a65a2432a8b
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32262
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Trusted Firmware places some components in SRAM on RK3399 and therefore
restricts accesses to SRAM to the secure world. This makes the vboot
working data inaccessible to normal world payloads, so we need to
migrate it into CBMEM.
Change-Id: Ic7c95790f2f118ccbdd897550f13b5f987bdd831
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
|
|
Change-Id: Ib843eb7144b7dc2932931b9e8f3f1d816bcc1e1a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/26796
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: David Guckian
|
|
Change-Id: Ie21c390ab04adb5b05d5f9760d227d2a175ccb56
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Change-Id: I23bc0191ca8fcd88364e5c08be7c90195019e399
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: David Guckian
|
|
Drop 'include <string.h>' when it is not used and
add it when it is missing.
Also extra lines removed, or added just before local includes.
Change-Id: Iccac4dbaa2dd4144fc347af36ecfc9747da3de20
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
RK3399 SoC code still manually excludes the BL31 region from the memory
map, even though that is now automatically done with the BL31()
memlayout region. CB:31123 and CB:31538 just forgot to remove this line.
The resulting memory map stays the same.
Change-Id: I87458fa09f437b038af10e0fd9d76ef6d9394bc5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31914
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ting Shen <phoenixshen@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch is a raw application of
find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g'
Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I7e181111cd1b837382929071a350b94c3afc1aaa
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
MMIO operations are arch-agnostic so the include
path should not be arch/.
Change-Id: I0fd70f5aeca02e98e96b980c3aca0819f5c44b98
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31691
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I91158452680586ac676ea11c8589062880a31f91
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31692
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When <symbols.h> was first introduced, it only declared a handful of
regions and we didn't expect that too many architectures and platforms
would need to add their own later. However, our amount of platforms has
greatly expanded since, and with them the need for more special memory
regions. The amount of code duplication is starting to get unsightly,
and platforms keep defining their own <soc/symbols.h> files that need
this as well.
This patch adds another macro to cut down the definition boilerplate.
Unfortunately, macros cannot define other macros when they're called, so
referring to region sizes as _name_size doesn't work anymore. This patch
replaces the scheme with REGION_SIZE(name).
Not touching the regions in the x86-specific <arch/symbols.h> yet since
they don't follow the standard _region/_eregion naming scheme. They can
be converted later if desired.
Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The BL31 on RK3399 is split into multiple segments... the majority goes
into DRAM, but small parts must be put into SRAM and PMUSRAM. With
CB:31123 only the DRAM part was added to memlayout, so the SRAM parts
will not be correctly marked in bootmem and BL31 loading fails the
selfload check. This patch adds the remaining regions to fix the
problem.
Change-Id: Ia0597216c08512c47361a1dc0beb34d022a8994f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31538
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ting Shen <phoenixshen@google.com>
|
|
After CL:31122, we can finally define a memory type specific for BL31,
to make sure BL31 is not loaded on other reserved area.
Change-Id: Idbd9a7fe4b12af23de1519892936d8d88a000e2c
Signed-off-by: Ting Shen <phoenixshen@google.com>
Reviewed-on: https://review.coreboot.org/c/31123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This is spotted using ./util/lint/kconfig_lint
To work around the issue, rename the prefix from `CONFIG_` to `CONF_`.
Change-Id: Ia31aed366bf768ab167ed5f8595bee8234aac46b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/31049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Invert the default instead of selecting it everywhere. Restores the
ability to use its Kconfig prompt.
Beside Qemu targets, the only platforms that didn't select it seem
to be samsung/exynos5420, intel/cannonlake, and intel/icelake. The
latter two were about to be patched anyway.
Change-Id: I7c5b671b7dddb5c6535c97c2cbb5f5053909dc64
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/30891
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Makes vboot measured boot mode available for all boards.
* Increase Tegra210 and Rockchip3228 SRAM for
romstage/verstage.
* Add missing files for Intel apollolake and
AMD stoneyridge as TPM driver target.
Change-Id: I35a85b8f137f28cd9960f2c5ce95f8fa31185b82
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/29840
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This removes CEIL_DIV and div_round_up() altogether and
replace it by DIV_ROUND_UP defined in commonlib/helpers.h.
Change-Id: I9aabc3fbe7834834c92d6ba59ff0005986622a34
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/29847
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
The dependencies of CONSOLE_SERIAL and DRIVERS_UART were somehow
backwards. Fix that. Now, CONSOLE_SERIAL depends on DRIVERS_UART,
because it's using its interface. The individual UART drivers
select DRIVERS_UART, because they implement the interface and
depend on the common UART code.
Some guards had to be fixed (using CONSOLE_SERIAL now instead of
DRIVERS_UART). Some other guards that were only about compilation
of units were removed. We want to build test as much as possible,
right?
Change-Id: I0ea73a8909f07202b23c88db93df74cf9dc8abf9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/29572
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Change-Id: I89e03b6def5c78415bf73baba55941953a70d8de
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29302
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Iab0bd1c5482331a0c048a05ab806bf5c4dbda780
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29303
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I40f8b4c7cbc55e16929b1f40d18bb5a9c19845da
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I17c4fc4e3e2eeef7c720c6a020b37d8f7a0f57a4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I6a9d71e69ed9230b92f0f330875515a5df29fc06
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29312
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I6c77f4289b46646872731ef9c20dc115f0cf876d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Id07e1c7fbd35393ffafda53fc7a15ec0e157d075
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/29049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Change-Id: Ib0839933f8b59f0c87cdda4e5374828bd6f1099f
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/23759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
Change-Id: I689c5663ef59861f79b68220abd146144f7618de
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I8053d0f0863aa4d93692487f1ca802195c2d475f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
RK3288 has always been notoriously low on SRAM, to the point where its
boards have less than 100 bytes left in both their bootblock/verstage
sections. This becomes a problem every time we try to add a tiny amount
of code to common coreboot interfaces that are included in them.
This patch manages to add another KB to each, one from the CBMEM console
(which now might get cut off a bit, but that's life) and one by moving
the TTB_SUBTABLES to PMUSRAM. PMUSRAM is a weird world where write
accesses must always be exactly 4 bytes long or they hang the CPU, so we
mostly ignore it... but thankfully, page table entries are exactly 4
bytes long and that's the only thing we write to this region, so it
works out in this case.
Change-Id: I5aecd66db40b3f52299b270322b8c8784dbe7e6f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Change-Id: Ia024fb418f02d90c38b9a35ff819c607b9ac4965
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Use of device_t has been abandoned in ramstage.
Change-Id: Idf47ea3b29c3fab7256d7a6722c7978594001d8d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Iedb78e24a286a51830c85724af0179995ed553be
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/26434
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
This patch enables the new bootblock compression feature on RK3399,
which requires moving MMU initialization into the decompressor stage and
linking the decompressor (rather than the bootblock) into the entry
point jumped to by the masked ROM.
RK3399's masked ROM seems to be using a bitbang SPI driver to load us
(very long pauses between clocking in each byte), with an effective data
rate of about 1Mbit. Bootblock loading time (as measured on a SPI
analyzer) is reduced by almost 100ms (about a third), while the
decompression time is trivial (under 1ms).
Change-Id: I48967ca5bb51cc4481d69dbacb4ca3c6b96cccea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Sometimes when bringing up a new board it can take a while until you
have all the peripheral drivers ready. For those cases it is nice to be
able to bitbang certain protocols so that you can already get further in
the boot flow while those drivers are still being worked on. We already
have this support for I2C, but it would be nice to have something for
SPI as well, since without SPI you're not going to boot very far.
This patch adds a couple of helper functions that platforms can use to
implement bit-banging SPI with minimal effort. It also adds a proof of
concept implementation using the RK3399.
Change-Id: Ie3551f51cc9a9f8bf3a47fd5cea6d9c064da8a62
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/25394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The <gpio.h> API is supposed to include a gpio_set() function that just
toggles the state of a GPIO already configured as an output, even though
we rarely need it since gpio_output() can already be used to initialze a
GPIO to a default value while configuring it as an output. This function
was forgotten on Rockchip, so this patch adds it now.
Change-Id: I201288139a2870e71f55a7af0d79d4a460b30a0c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/25393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch passes the coreboot table base address to ARM TF on RK3399
devices to be able to use the new coreboot table parsing support.
Change-Id: I5cb2f13ce71e374207d0fa7a71c38852d680dc56
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/23557
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The Rockchip UARTs are tied directly to the 24MHz oscillator and are
thus clocked with exactly 24MHz. The reasons why our code instead uses
some 23.xxMHz value have long been lost in time. For the current shared
8250 implementation, the baud rate divisor for 115200 would be the same.
Correcting this does make the information in the coreboot table more
accurate and help payloads chose a better divisor, though.
Change-Id: Ieceb07760178f8ddbb5936f8742b78f8def4072d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/23556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This header uses common types and macros so it needs to include the
headers that provide those itself.
Change-Id: Ieceb0deadbeef8ddbbb00b13542b78f8def4072d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/23559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
We found when ambient temperature low, with now saradc frequency and
delay between saradc power up and start command, there may get wrong
adc value, then get the wrong ramid or boardid, so lower the saradc frequency
and add the delay time between power up and start command.
BUG=b:70692504
BRANCH=gru
TEST=test on Dru in 0C temperature, always get right adc value
Change-Id: I42e49ca63299479912fa05e2a62cba6f2de4b337
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: https://review.coreboot.org/23515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Some panels need to transfer initial code, and some of them will be
over 3 bytes, so support LONG_WRITE type in driver. Refactor mipi
dsi transfer function to support it.
Change-Id: I212c14165e074c40a4a1a25140d9e8dfdfba465f
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: https://review.coreboot.org/23299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This patch fixes 2 edp display issues:
1. When rk_edp_prepare fails >3 times, edp_init isn't run because
while-condition is not satisfied. Then, only a partial init sequence is
ran. This causes all aux transactions to fail.
2. If rk_edp_prepare never succeeds, coreboot never leaves link training
stage due to infinite loop. Boot process is stuck.
TEST=Boot past eDP initialization stage and make sure AP logs don't have
show aux transaction fails.
Change-Id: I44c3f53e8786558c43078d4afe9acde4d64796e7
Signed-off-by: Ege Mihmanli <egemih@google.com>
Reviewed-on: https://review.coreboot.org/23152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Due to a schematic error, our code was written to configure more I2S0
pins than are actually used. We're also pinmuxing the whole bank of pins
over to the I2S controller even though we don't need them all. Restrict
the GPIO initialization and pinmuxing to the pins we really need so the
other ones can be correctly used as SKU ID pins on Scarlet.
Also, move the "audio" IO voltage domain selection to the other such
selections in the bootblock, since that covers two whole banks of GPIOs
and there's no guarantee that they're all used for audio (and thus not
needed before ramstage).
BUG=b:69373077
TEST=Booted Scarlet, confirmed correct SKU ID (7) was detected on rev2.
Change-Id: I9314617e725fe83d254984529f269d4442e736f1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22791
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
|
|
This option should've been selected by RK3399 the whole time since the
SoC supports the <soc/gpio.h> interface. It wasn't really a big deal
until now where I'm trying to use a the base2 read helper, though.
Change-Id: Ib7a5f00a6680163105fc0598ce77d03f3645f05a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22744
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Support kd097d04 dual mipi panel on Scarlet.
Change-Id: Ie8bc0cbb79840f1924a8cc111f2511292203731f
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: https://review.coreboot.org/22472
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|