Age | Commit message (Collapse) | Author |
|
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>
|
|
Some SOCs (like pistachio, for instance) provide an 8250 compatible
UART, which has the same register layout, but mapped to a bus of a
different width.
Instead of adding a new driver for these controllers, it is better to
have coreboot report UART register width to libpayload, and have it
adjust the offsets accordingly when accessing the UART.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the rest of the patches integrated depthcharge console messages
show up when running on the FPGA board
Change-Id: I30b742146069450941164afb04641b967a214d6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42
Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240027
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9738
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
we use Kconfig define sdram size before, but there may use
different sdram size in the same overlay, so we must detect
sdram size at runtime now. If we use 4G byte sdram, we can
use[0x00000000:0xff000000], since the [0xff000000:0xffffffff]
is the register space.
BUG=chrome-os-partner:35521
TEST=Boot from mighty
BRANCH=None
Change-Id: I7a167c268483743c3eaed8b71c7ec545a688270c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ad4f27dd08c467888eee87e3d9c4ab3077751898
Original-Change-Id: Ib32aed50c9cae6db495ff3bab28266de91f3e73b
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243139
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9734
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We've traditionally tucked the framebuffer at the end of memory (above
CBMEM) on ARM and declared it reserved through coreboot's resource
allocator. This causes depthcharge to mark this area as reserved in the
kernel's device tree, which may be necessary to avoid display corruption
on handoff but also wastes space that the OS could use instead.
Since rk3288 boards now have proper display shutdown code in
depthcharge, keeping the framebuffer memory reserved across the handoff
(and thus throughout the lifetime of the system) should no longer be
necessary. For now let's just switch the rk3288 implementation to define
it through memlayout instead, which is not communicated through the
coreboot tables and will get treated as normal memory by depthcharge.
Note that this causes it to get wiped in developer/recovery mode, which
should not be a problem because that is done in response to VbInit()
(long before any images are drawn) and 0 is the default value for a
corebootfb anyway (a black pixel).
Eventually, we might want to think about adding more memory types to
coreboot's resource system (e.g. "reserved until kernel handoff", or
something specifically for the frame buffer) to model this situation
better, and maybe merge it with memlayout somehow.
CQ-DEPEND=CL:239470
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes
than before (curiously not 0x80000 bytes, I guess there's some alignment
waste in the kernel somewhere). Made sure the memory map output from
coreboot looks as expected, there's no visible display corruption in
developer/recovery mode and the 'cbmem' utility still works.
Change-Id: I12b7bfc1b7525f5a08cb7c64f0ff1b174df252d4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2
Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240819
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9732
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The current display init code causes Brain to crash when trying
to allocate resources. This just avoids doing display init if a
config variable is set. Once code has been implemented to properly
setup different types of displays we can get rid of this hack.
BUG=none
BRANCH=none
TEST=built and booted (to depthcharge) on Brain, compiled for
pinky with FEATURES=noclean and ensured config variable is 0
Change-Id: I9a7266c6bff5b7a6eb05b2b21fb65797bee392d6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 804632ca67eaaf4174ca597d83b8923cb9abd1b7
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I04c9e8181c58fa0608fd20776fa8c4798a023474
Original-Reviewed-on: https://chromium-review.googlesource.com/235922
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9720
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch activates the chip driver for Winbond SPI flash (which,
incidentally, looks 99.9% the same as the Gigadevice driver but still
requires some extra 500+ bytes of object code... there's definitely room
for improvement here). Shuffle around rk3288 memlayout to make a little
more room in the bootblock.
BRANCH=veyron
BUG=chrome-os-partner:34176
TEST=Booted Pinky. Checked bootblock and verstage memsz of final binary
and noticed that both only have less than 500 bytes left against their
memlayout boundary. The next piece of code we add will cause some
serious headaches...
Change-Id: I97ea6ac334104e4219e310afc557c164b2ff19d9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8769e5a34ad3cd417132646fbb58ff51c29fb640
Original-Change-Id: Id2f1204c30aa28251cf85cb80d7ca44947388dba
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236977
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9719
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
we use the delay 200ms to meet the edp power timing request before,
it waste time, so we use the HPD function to detect the edp panel now.
In previous version, the hardware may not support the edp HPD function,
so in the code it will spend 200ms to detect hpd single, if it don't get
the hpd single, it will contiue the edp initialization process, to compatible
all of the hardware version.
BUG=chrome-os-partner:35623
TEST=Boot from Mighty, and display normal
BRANCH=None
Change-Id: I82c6a80e37fa42eef3521e6ebbf190d7e80fcece
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 7a5343eb9af12cae9a15284217762a91ae24bac6
Original-Change-Id: I21c0ef6ce4643e90a192d8b86659264895b5fda9
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242792
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9659
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Our use of the bucks may exceed their default maximum inductor current.
Just set it to the highest possible value for every buck we configure to
avoid problems... the kernel can later fine-tune the values further if
needed. (Also some slight grammar updates while I'm in there.)
BRANCH=veyron
TEST=Build and Boot on Jerry
BUG=None
Change-Id: If8258cf4feefe191604365405bff1f20c8ab8746
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 065a163bb902b8c96d05bfef6ed4885aa20f31cc
Original-Change-Id: I3801cabeb93d7bf7ecc02db0e69d4932c9394db9
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242785
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: http://review.coreboot.org/9655
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
tMRD request 10nCK in LPDDR3, we set the DDR_PCTL_TMRD BIT0~BIT2 to generate
this signal, but the max value we can set is 7, so the standard can not be met.
So, now we send the Mode Register Set command manually, and hence we can add
the delay manually.
BUG=chrome-os-partner:34608
TEST=loop reboot
BRANCH=veyron
Change-Id: Id974ab935c2df6ea35dcdd240378ffc68de0204d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: b60a4de6ff3ad3720c2c06ed7de03ed942360e6c
Original-Change-Id: I0d29ea9cd82ef018e835ae53090a47d0299ef61d
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242176
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9654
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
We want a reset signal to last 200us. The length of a reset signal is
represented by BIT0~BIT16 in DDR_PUBL_PTR2. When DDR memory runs at
667MHz, the calculated value for the reset signal is 0x20850, which is
bigger than the maximum value that can be described with 17 bits
(0x1ffff). As a result, the memory controller only sees 0x850, which
generates a 3.5us reset cycle instead, which violates the standard and
negatively impacts memory stability.
So instead, we now set it to the maximum value (0x1ffff) to prevent this
overflow, resulting in a reset signal of 196us for 667MHz DDR memory.
BUG=chrome-os-partner:34875
TEST=loop reboot
BRANCH=veyron
Change-Id: Ia01f8a0414b49fa3ecf4d543cfa1822e29ee4cc4
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 767a4a3cb8dff47cb15064d335b78ffa5815914d
Original-Change-Id: I9b410e1605c87f12a5ca96ead12f8527ca4f417f
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242175
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9653
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
decode_edid() parses the whole EDID buffer, regardless of whether there
is an extension buffer, so we pass the size of the EDID actually read to
prevent EDID parser getting the wrong data.
BUG=chrome-os-partner:35053
TEST=Boot from jerry
BRANCH=veyron
Change-Id: I5951b670f129cf4765a5199cb58ac6abff5478a6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4d508647efc0a9d48b2a4b23c12a54b63af2813e
Original-Change-Id: I8cd8e09025520322461fe940b01e4af3995b5ecd
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/240643
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9645
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This adds RTC functions to the existing RK808 driver.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=with eventlog patches applied to pinky, booted and saw eventlog
entries generated with correct timestamps:
localhost ~ # mosys -k eventlog list
entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096"
entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0"
entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode"
Change-Id: I1df70a2ca94ff463ffea8d9f02d951d6c62e6b08
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a304f7e6954f585f04feef54c4902dcb25a39fcc
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I3a240e342a54b2e7023da71708d0d70f5131f0b9
Original-Reviewed-on: https://chromium-review.googlesource.com/238525
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9643
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This moves PMIC_BUS from each mainboard's board.h file to a per-
mainboard Kconfig variable. To prevent humans from forgetting to
set a valid value, an invalid default is set in the rk3288 Kconfig
and checked in rk808.c so that compilation will fail if the mainboard
Kconfig does not override it.
Originally, PMIC_BUS was only used by mainboard code as an argument
to RK808 PMIC functions. To conform to the generic RTC API, however,
the RK808 code needs to have the bus number globally defined somewhere
since the rtc_get() and rtc_set() functions don't take any args.
Since CONFIG_PMIC_BUS is globally visible, we no longer need to pass
bus number to the PMIC functions.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I73783878e507b2e7b1526dd2f81cfbdf8f1e2a55
Reviewed-on: https://chromium-review.googlesource.com/240203
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9642
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This patch implements support for the CRYPTO module in RK3288 and ties
it into the new vboot vb2ex_hwcrypto API. We only implement SHA256 for
now, since the engine doesn't support SHA512 and it's very unlikely that
we'll ever use SHA1 for anything again.
BRANCH=None
BUG=chrome-os-partner:32987
TEST=Booted Pinky, confirmed that it uses the hardware crypto engine and
that firmware body hashing time dropped to about 1.5ms (from over 70ms).
Change-Id: I91d0860b42b93d690d2fa083324d343efe7da5f1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e60d42cbffd0748e13bfe1a281877460ecde936b
Original-Change-Id: I92510082b311a48a56224a4fc44b1bbce39b17ac
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236436
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9641
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This switches all the rk3288 platforms to use the common CBFS wrapper
instead of implementing its own CBFS media driver. It also happens
that veyron_* platforms use Gigadevice SPI flash (at least for now).
As we use more SPI-related stuff, for example eventlog and vboot data in
Brain's case, we will need to use more of the SPI API anyway. This
prevents us from having to duplicate pieces of it for rk3288.
BUG=none
BRANCH=none
TEST=built and booted on Pinky
Change-Id: Ie462456814646fdc277485d9e2d8c901fd4936e7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2d6df2fe6d78bc8eee8689019b9aaf29c82b6b30
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Id307bd5fb6cc8f79411d8c66e1370e80c58d017b
Original-Reviewed-on: https://chromium-review.googlesource.com/235882
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9678
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
We use the devicetree to pass the backlight control gpio before,
but if there have different board version, and it uses different
io to control backlight, it will hard to distinguish it. So, we
move the backlight control to mainboard, and use board_id
to distinguish the backlight control.
BUG=None
TEST=emerge veyron_pinky and Boot the pinky board
BRANCH=None
Change-Id: Ifa81eb2455296f4b4285b681208f4393f266fb34
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2ff7f65134dcf97f97757750eab41dcf8c7765d3
Original-Change-Id: I1ec8e04f4982c3a8c7e31d8dc2c75311b7199ffc
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234711
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9630
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Like Nyan, Veyron boards use a GPIO to reset the system so that we can
make the accompanying TPM reset secure and unforgeable. The normal
kernel reboot driver knows that, but the SoC-internal watchdog doesn't.
This patch implements a check for the global reset status register in
the early bootblock and triggers a hard_reset() when it matches "first
global watchdog reset" or "second global watchdog reset". Seems that
the difference between the two is is a choice controlled by
wdt_glb_srst_ctrl (unconfirmed), and we want this code to run in both
cases.
BRANCH=None
BUG=chrome-os-partner:33141
TEST=Run 'mem w 0xff800000 0x9' from the command line, watch how you end
up in recovery without this patch but can boot normally with it.
Change-Id: Ice79648831e1e97d22325711da9e82bbf6bf3c75
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 5d7cb52b2c2dcb2fff0bf83fc168439dade4b1b7
Original-Change-Id: I2581bde84f0445c15896060544e9acb60de91c8c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231734
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9629
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The only way to reliably reset an SD card in an unknown state is by
power-cycling. Since a kernel may crash and reboot at any point, SD
cards may be left in one of them fancy high-throughput modes that
depthcharge (or, in fact, a newly booting kernel without prior
knowledge) doesn't support, so we need to reset the card on every boot.
This patch adds support to turn off an RK808 regulator completely and
uses that to turn off SD card power rails in early romstage. The time
until configure_sdmmc() in ramstage turns them back on should be more
than enough to drain the power rail for an effective power-cycle.
BRANCH=None
BUG=chrome-os-partner:34289
TEST=Booted a Pinky from SD card, noticed that it works before and
after this patch.
Change-Id: Iaa5f7adaa59da69a964785c5e369ad73c6620224
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 95fba21907f1f3f686cb5a95b993736247db8f96
Original-Change-Id: I904b2d23ca35f765c000f9bee7637044f674eff9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233713
Original-Reviewed-by: Alexandru Stan <amstan@chromium.org>
Original-Tested-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9626
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This function was added in upstream but was missing in Chromium OS
Change-Id: I35debf65153e5f280343eebfe91438ecf665ba22
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9677
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Freeing up memory on rk3288 is like squeezing water out of a stone right
now, but I still managed to get a few drops here and there. Let's hope
this will be enough.
BRANCH=None
BUG=None
TEST=Pinky builds and boots again. memsz is ~15K in bootblock and ~39K
in verstage.
Change-Id: Icf7ff3369bf367426a34f1490e0a041ae9bd6367
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9a3737ab535cdef228a1607433860f881db04412
Original-Change-Id: I90d9eab5b5d3af7a2e4b836a9c7b735b7c1c48e6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235870
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9609
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Since we can now reduce our vboot2 work buffer by 4K, we can use all
that hard-earned space for the CBMEM console instead (and 4K are
unfortunately barely enough for all the stuff we dump with vboot2).
Also add console_init() and exception_init() to the verstage for
CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model
requires those functions to be called again at the beginning of every
stage... even though some consoles like UARTs might not need it, others
like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is
expected to be done by the platform-specific verstage entry wrapper, and
already in place for the only implementation we have for now (tegra124).
(Technically, there is still a bug in the case where EARLY_CONSOLE is
set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would
run init_console_ptr() as if they were there first, so the romstage
overwrites the verstage's output. I don't think it's worth fixing that
now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless
use-case and I think we should probably just get rid of the
CONFIG_BOOTBLOCK_CONSOLE option eventually.)
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I87914df3c72f0262eb89f337454009377a985497
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c
Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232614
Reviewed-on: http://review.coreboot.org/9607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa
Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234062
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9606
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some boards spread their timer implementation out in multiple files with
one function each for no discernable reason. Let's clean that up to make
things a little simpler to find.
BRANCH=None
BUG=None
TEST=Booted Pinky, compiled Daisy and Pit.
Change-Id: I8b543d1a0d9af37bde5433b0c9271d687b2404b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 887765e1bd88d7aa49ad9a5e98b8831c10da6c10
Original-Change-Id: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234061
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9601
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch doubles the ACLK peripheral clock for the PD_BUS power domain
to 297MHz, which is the closest to the maximum of 300MHz we can reach by
dividing GPLL. This frequency directly translates into SRAM speed, so
maximizing it has a huge impact on boot speed (especially with the lack
of SRAM caching).
BUG=chrome-os-partner:32987
TEST=Booted Veyron_Pinky. Hacked timestamps into vboot and confirmed
that the (visibly) long signature verification times are nearly halved.
Change-Id: Iafa3044854a4058a7f885c775119d964a6295de4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c230585f4344d0eab4f8eeaa761869965f2da08a
Original-Change-Id: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224524
Original-Trybot-Ready: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9600
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch uses the new bootblock_mainboard_early_init() hook to run the
UART pinmuxing on rk3288-based boards before initializing the console.
This allows us to get rid of the hacky second console_init() call in
bootblock_soc_init(). We can also simplify the pinmux selection a bit
since we know that a given board always uses the same UART (still keep
an assert around to be sure, though).
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky.
Change-Id: I3da8b0e4bd609f33cedd934ce51cb20b1190024b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: caabda8fc1ddb4805d86fd9a0d5d2f3cf738bfaf
Original-Change-Id: Ia56c0599a15f966d087ca39181bfe23abd262e72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231942
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9604
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch makes some slight changes to the way bootblock_cpu_init() and
bootblock_mainboard_init() are used on ARM. Experience has shown that
nearly every board needs either one or both of these hooks, so having
explicit Kconfigs for them has become unwieldy. Instead, this patch
implements them as a weak symbol that can be overridden by mainboard/SoC
code, as the more recent arm64_soc_init() is also doing.
Since the whole concept of a single "CPU" on ARM systems has kinda died
out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had
already been done on Storm/ipq806x, which is now adjusted to directly
use the generic hook.) Also add a proper license header to
bootblock_common.h that was somehow missing.
Leaving non-ARM32 architectures out for now, since they are still using
the really old and weird x86 model of directly including a file. These
architectures should also eventually be aligned with the cleaner ARM32
model as they mature.
[pg: this was already partly upstreamed. These are the remains.
Further cleanup is necessary and on the short-term TODO, but beyond
the scope of this commit]
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Storm and confirmed in the
disassembly that bootblock_soc_init() is still compiled in and called
right before the (now no-op) bootblock_mainboard_init().
Change-Id: Idf655894c4fec8fce7d3348d3b3e43b1613b35db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 257aaee9e3aeeffe50ed54de7342dd2bc9baae76
Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9602
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
After DDR PHY reset de-asserted, DLL automatically starts to
lock, and the lock time is maximum 5.12us. The output clock of
DLL supplies the clocks of DDR controller and PHY digital logic.
So before DLL lock, the clocks of DDR controller and PHY digital
logic are indeterminate. When programming DDR in the period of
DLL unlock, the programming maybe unstable because of the
indeterminate clocks. So we need wait for at least 5.12us after
de-asserting reset, then start to program DDR registers.
10us provide some safety margin.
BUG=chrome-os-partner:33148
TEST=I'm using the following command line test ok(15000 cycles).
"while sleep 4 && dut-control cold_reset:on sleep:.1 cold_reset:off;
do : ; done"
BRANCH=None
Change-Id: Ie7d615f5a2264c615c4b4413d6b828cd3d78cd2b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 54e1a439c0e29aaf4fc542ae756f7bb036ceaf3e
Original-Change-Id: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0
Original-Signed-off-by: DaiLunXue <dlx@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/232894
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com>
Original-Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com>
Reviewed-on: http://review.coreboot.org/9578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
edp must reset when device power up, otherwise the edp
register maybe uncertain, now the edp source clock default
select 27M, and in pinky and jerry board we use 24M as edp
sourec clock, if we want to reset edp, we must after the clock
source select 24M.
BUG=chrome-os-partner:34023
TEST=Booted Veyron jerry and read edid normal
BRANCH=None
Change-Id: I4b03dbabe5d3d595d2d56efb0cd82f510f8d2e1b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2292da77cc2322b85c4b4f4f20e4ebcc4c4d060d
Original-Change-Id: Ica031d2d52deb539c1a0a56968786d6952b3d0e8
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231336
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9555
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Implement VOP and eDP drivers, vop and edp clock configuration,
framebuffer allocation and display configuration logic.
The eDP driver reads panel EDID to determine panel dimensions
and the pixel clock used by the VOP.
The pixel clock is generating using the NPLL.
BUG=chrome-os-partner:31897
TEST=Booted Veyron Pinky and display normal
BRANCH=None
Change-Id: I01b5c347a3433a108806aec61aa3a875cab8c129
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e4f863b0b57f2f5293ea8015db86cf7f8acc5853
Original-Change-Id: I61214f55e96bc1dcda9b0f700e5db11e49e5e533
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9553
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
LDO7 (VCC10_LCD_PWREN_H) is essentially just a glorified GPIO that turns
the real VCC10 regulator on or off. We tried setting it to 3.3V since it
matches the VCC33_SYS voltage on the input of that regulator. However,
we didn't notice that the LDO only supports going up to 2.5V.
This patch changes the voltage to the allowed maximum, which should
still work fine as an enable line (and is the same value used by the
kernel). This removes an assertion error in the ramstage.
Also change the PMIC driver to assert maximum VSEL values based on the
LDO, because the lower-voltage ones support one more setting. (LDO3 is
actually listed to only go up to 0b1111 in the manual, and has a weird
jump from 0b1101 -> 2.2V (skipping over 0b1110) to 0b1111 -> 2.5V. I
don't know if that's a documentation error or what they were smoking
when they designed that, but we don't need to care for now.)
BRANCH=None
BUG=None
TEST=Booted on Pinky, no more ASSERTION FAILED.
Change-Id: I38bf99e38822fd0883fd4d0bd9a1b01143545a95
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 70f3149efbc3aa9a03ab3fd5be99d17d9c5e1c87
Original-Change-Id: I68a3bb882cf25d98aca8922ede2a17e1ef6524de
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228292
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: Jerry Parson <jwp@chromium.org>
Reviewed-on: http://review.coreboot.org/9547
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This moves vboot1 and vboot2 files to their designated directory. Common
code stays in vendorcode/google/chromeos.
BUG=none
BRANCH=none
TEST=built cosmos, veyron_pinky, rush_ryu, nyan_blaze, samus, parrot,
lumpy, daisy_spring, and storm.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Ia9fb41ba30930b79b222269acfade7ef44b23626
Original-Reviewed-on: https://chromium-review.googlesource.com/222874
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit cbfef9ad40776d890e2149b9db788fe0b387d210)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia73696accfd93cc14ca83516fa77f87331faef51
Reviewed-on: http://review.coreboot.org/9433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|