This code that stores the initial timestamp is not being used,
instead the timestamp is passed to romstage_main().
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I0e0fa1ba74ab93d4454fdfa12208e712d2ae913c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234402
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
When turning up the CPU frequency set it to turbo if that is
a possibility. Also only set the frequency on the boot CPU
since that is all we need it on, this will allow the 1-core
turbo ratio.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: Ib5ad746767ee0a56bc7e59de679a9342f053c0e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234401
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to avoid a 300ms timeout waiting for mbp_cleared flag
to be set there is a new flow for the ME10 1.5MB firwmare that
we can follow which will save significant boot time.
This requires sending new commands that do not generate an ACK
message, and ensuring an HMRFPO LOCK message is sent.
In addition now that the delay is removed clean up the ME path
to do the work in init() step and add a final() step that does
the disabling of the PCI device.
BUG=chrome-os-partner:30637,chrome-os-partner:34134
BRANCH=samus,auron
TEST=build and boot on samus, measure ~300ms speedup in boot time
Change-Id: I753087ecd65f6ebed9f812318a359f893e01da9f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234400
Reviewed-by: Aaron Durbin <adurbin@chromium.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_early_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_early_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234062
Reviewed-by: Aaron Durbin <adurbin@chromium.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: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234061
Reviewed-by: Aaron Durbin <adurbin@chromium.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.
Since Kconfig is weird and we cannot disable an option that is enabled
by default with 'select', we need to rearrange menu groups so that
'mainboard' and 'chipset' come before 'General setup', which allows the
subdirectory Kconfig files sourced by them to override the generic
defaults specified later.
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>
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: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224524
Trybot-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.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.
Add some redundancy, the waiting time hopes to achieve 10us.
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: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0
Signed-off-by: DaiLunXue <dlx@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/232894
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com>
Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com>
Files necessary for the SOC bringup are added to the CBFS as raw
blobs.
Ipq8064 specific MBN header will allow to determine were the blobs
should be loaded and what start address should be used.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=build storm firmware and verify that the right components are added:
$ emerge-storm coreboot chromeos-bootimage
$ cbfstool /build/storm/firmware/image.bin print
image.bin: 8192 kB, bootblocksize 32488, romsize 2883584, offset 0x7f40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x7f40 raw 376
ddr.mbn 0x8100 raw 25820
rpm.mbn 0xe640 raw 78512
tz.mbn 0x21940 raw 85360
fallback/verstage 0x36700 stage 39500
fallback/romstage 0x401c0 stage 15652
fallback/ramstage 0x43f40 stage 24328
config 0x49e80 raw 2701
fallback/payload 0x4a940 payload 65592
u-boot.dtb 0x5a9c0 (unknown) 2922
(empty) 0x5b580 null 2509336
$
Change-Id: Id642ae68ef07750624f85b31ad891752d8af99bf
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233672
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Used for audio on Rush/Ryu. I2S1/DAP2 provides the audio
'stream' for the dev/rec mode 'beeps'.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=With follow-on CLs that make use of this support,
audio beeps (via VbExBeep) can be heard on Rush. Built
both Rush and Ryu OK.
Change-Id: Ia8c32303979f25300e22b5a14609d9d9d5ce3132
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233670
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: I904b2d23ca35f765c000f9bee7637044f674eff9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233713
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Tested-by: Alexandru Stan <amstan@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
WPT-LP has 4 SATA ports. Current code assumes 6 SATA ports and as a result,
some reserved bits are written with 1. No specific issue has been observed
so far.
BUG=None
BRANCH=None
TEST=Verify SATA PCI configure space dump on Auron
Change-Id: I9c53ac86e2bf72901647bd2cfa48ac0ce31abea0
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/233661
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit 257aaee9e3 (arm: Add bootblock_mainboard_early_init() for
pre-console initialization) inadvertently moved the timer initialization
after console initialization for IPQ806x, which is apparently not a good
idea for this platform. This patch solves the issue by moving
init_timer() to bootblock_mainboard_early_init(), which is the new hook
explicitly provided to perform pre-console tasks.
BRANCH=None
BUG=None
TEST=Built and booted Storm with 257aaee9e reverted. Noticed that it was
already broken. Bisected coreboot and tracked down breakage to commit
a126a62f (ipq8064: use the new utility to build bootblock). Built and
booted successfully with this patch and a revert of a126a62f to confirm
that the bug in question here is fixed.
Change-Id: Ie4aa2d06cb6fda6d5ff8dd5ea052257fb7b8a24b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233290
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
CONFIG_COLLECT_TIMESTAMPS seems more like a user-configurable option
than a hardcoded property of the SoC, so let's not select if by default
(this is more in line with previous boards).
BRANCH=None
BUG=None
TEST=Booted Pinky, made sure 'cbmem -t' fails.
Change-Id: I06fc28f4a57a38bdd0be1f98a4766633ccb347ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232615
Reviewed-by: Aaron Durbin <adurbin@chromium.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: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232614
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The first blob in the Storm bootimage is a concatenation of the
Uber-sbl produced by the qca-firmware ebuild and the coreboot
bootblock.
The new tool is used to add the bootblock to uber-sbl and update the
size values in the combined header.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=no execution tests yet, the build succeeds.
Change-Id: Iec3c1e943f1f9ee5ca20320a6365fc4aa5516e38
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232310
Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Reviewed-by: David Hendricks <dhendrix@chromium.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: Ifcc755326832755cfbccd6f0a12104cba28a20af
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229975
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229974
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some SPI controllers (like Imgtec Pistachio), have a hard limit on SPI
read and write transactions. Limiting transfer size in the wrapper
allows to provide the API user with unlimited transfer size
transactions.
The tranfer size limitation is added to the spi_slave structure, which
is set up by the controller driver. The value of zero in this field
means 'unlimited transfer size'. It will work with existion drivers,
as they all either keep structures in the bss segment, or initialize
them to all zeros.
This patch addresses the problem for reads only, as coreboot is not
expected to require to write long chunks into SPI devices.
BRANCH=none
BUG=chrome-os-partner:32441, chrome-os-partner:31438
TEST=set transfer size limit to artificially low value (4K) and
observed proper operation on both Pistachio and ipq8086: both
Storm and Urara booted through romstage and ramstage.
Change-Id: I9df24f302edc872bed991ea450c0af33a1c0ff7b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232239
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
With this descriptor added ramstage properly allocates memory
resources and creates entries in coreboot table. This also allows to
proceed to booting depthcharge, as it now can be loaded into the
existing memory.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the set of patches applied the firmware properly finds
depthcharge in CBFS, uncompresses it and attempts to start:
...
Booting payload fallback/payload from cbfs
Loading segment from rom address 0x9b000058
code (compression=1)
New segment dstaddr 0x80124020 memsize 0x2099a0 srcaddr 0x9b000090 filesize 0xbbe
Loading segment from rom address 0x9b000074
Entry Point 0x80124038
Loading Segment: addr: 0x0000000080124020 memsz: 0x00000000002099a0 filesz: 0x0000000000000bbe
lb: [0x0000000080000000, 0x0000000080013858)
Post relocation: addr: 0x0000000080124020 memsz: 0x00000000002099a0 filesz: 0x0000000000000bbe
using LZMA
[ 0x80124020, 8012596c, 0x8032d9c0) <- 9b000090
Clearing Segment: addr: 0x000000008012596c memsz: 0x0000000000208054
dest 80124020, end 8032d9c0, bouncebuffer 8ffd4f50
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 129 run 34579421 exit 129
Jumping to boot code at 80124038
ERROR: dropped a timestamp entry
CPU0: stack: 9a00c800 - 9a00d800, lowest used address 9a00d498, stack used: 872 bytes
entry = 80124038
Change-Id: Ifed5550f2c18430e9ae06ad1ecacaa13191b5995
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232571
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With the code now running on the FPGA board it makes sense to correct
the memory layout definitions to match the actual hardware.
Note that the latest FPGA board firmware introduced support of the
additional 128KB of SRAM (called GRAM) at base address of 0x9a000000.
These are still interim values, which will be tweaked when the actual
bring up board is available.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=the code put into SPI NOR flash boots all the way to ramstage.
Change-Id: I50183c2d5f9017801d5c8a7a7addf08efa492b35
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229203
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Using REG_PCI_POLL32 to check if the LINK is active with 50ms timeout.
BRANCH=none
BUG=chromium:431169
TEST=Test on Enguarde, compile ok and boot OS
Change-Id: I490e6ffa40979628edf52a7444808b6d25a6e83d
Signed-off-by: Kevin Hsieh <kevin.hsieh@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/231777
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
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: Ia56c0599a15f966d087ca39181bfe23abd262e72
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231942
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On most platforms, enabling the console and exception handlers are
amongst the very first things you want to do, as they help you see
what's going on and debug errors in other early init code. However, most
ARM boards require some small amount of board-specific initialization
(pinmuxing, maybe clocks) to get the UART running, which is why
bootblock_mainboard_init() (and with it almost all of the actual
bootblock code) always had to run before console initialization for now.
This patch introduces an explicit bootblock_mainboard_early_init() hook
for only that part of initialization that absolutely needs to run before
console output. The other two hooks for SoC and mainboard are moved
below console_init(). This model has already proven its worth before in
the tegra124 and tegra132 custom bootblocks.
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Daisy, Storm and Ryu.
Change-Id: I4257b5a8807595140e8c973ca04e68ea8630bf9a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231941
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.
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: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231940
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
32K is a more appropriate room for Pistachio bootblock.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=there is no bootblock overflow even when compiled with -O0.
Change-Id: I74b6674aea95b1138e2168527239e2cfb4a7ad42
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232291
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The CPU on/off functions are the method for the Kernel to support CPU
hot-plug function in PSCI. To support this, we still need flow controller
support to capture the WFI from the CPU and inform PMC to power gate the
CPU core. On the other path, we turn on the CPU by toggling the PMC and
use flow controller to let go when the power is steady.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=built the kernel with PSCI enabled,
check both of the CPUs are coming up,
test the CPU hot-plug is working on Ryu
Change-Id: Ie49940adb2966dcc9967d2fcc9b1e0dcd6d98743
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/231267
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Adding this configuration option enables romstage console output.
Ideally this setting should be enabled automatically in case the
bootblock console is enabled.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=romstage messages show up on the console
Change-Id: I710e05ce24e1aeccc90aead50336f00dec52fff0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229202
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Update non-vboot2 memlayout:
1) Add timestamp region
2) Increase ramstage size
3) Change name from memlayout_vboot.ld to memlayout.ld so that any non-vboot
upstream board can also use this layout.
BUG=None
BRANCH=None
TEST=Compiles and boots to kernel prompt on ryu with vboot selected instead of
vboot2.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I91accd54efc53ab563a2063b9c6e9390f5dd527f
Reviewed-on: https://chromium-review.googlesource.com/231547
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Instead of having unified CBFS_CACHE and limiting the POSTRAM Cache size, split
them into PRERAM and POSTRAM CBFS_CACHE.
BUG=None
BRANCH=None
TEST=Compiles successfully for both rush and ryu. Boots to kernel prompt on ryu.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Iab21ff5c7ca880b6bd18846e5d8d71c26dff56cf
Reviewed-on: https://chromium-review.googlesource.com/231546
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Enable display code only if mainboard selects
MAINBOARD_DO_NATIVE_VGA_INIT. Otherwise build breaks for boards that do not
support display init yet.
BUG=chrome-os-partner:31936
BRANCH=None
TEST=Compiles for both rush and ryu. Display comes up for ryu in both normal and
dev mode.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib4a3c32f1ebf5c6ed71c96a24893dcdee7488b16
Reviewed-on: https://chromium-review.googlesource.com/231545
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
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: Ica031d2d52deb539c1a0a56968786d6952b3d0e8
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/231336
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
In order to start CPUs while in secmon/psci one needs to
set up the proper SoC state. Therefore, refactor the current
CPU startup API to allow for this by adding cpu_prepare_startup()
and start_cpu_silent().
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted kernel.
Change-Id: I842a391d3e27ddbfcdef1a2d60e3c66e60f99c77
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231936
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The romstage_main routine takes three parameters: bist, tsc_low and
tsc_hi. However in cache_as_ram.inc only the bist value is being
passed. This patch adds the two halves of the TSC value.
BRANCH=none
BUG=None
TEST=Build and run on Samus
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Change-Id: I34fb21e493dcb3a44426ba7964cd72a319a4254e
Reviewed-on: https://chromium-review.googlesource.com/231173
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The bootblock on Rush had bumped up into the verstage
allocation, causing the build to break. Reduced verstage from
60K to 58K and increased bootblock from 20K to 22K. Rush and
Ryu both build fine now.
BUG=none
BRANCH=none
TEST=Built both Rush and Ryu OK. Verifed verstage size
using cbfstool and it's around 55K, so plenty of room.
Change-Id: I7018f027d72d5e8aeb894857a5ac6a0bdc1de388
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/230824
Reviewed-by: Aaron Durbin <adurbin@chromium.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: I61214f55e96bc1dcda9b0f700e5db11e49e5e533
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/219050
Reviewed-by: Julius Werner <jwerner@chromium.org>
The kernel does not correctly function without PLLD being enabled.
Additionally, PLLD can be the source for other clocks in the system.
Therefore, initialize PLLD to 300MHz unconditionally at BS_DEV_INIT
time in ramstage.
BUG=chrome-os-partner:33825
BRANCH=None
TEST=Built and booted ryu with display coming up both in dev mode as
well as normal mode.
Change-Id: Ic5905e25051a042cea5010b8c6d61b1fb89a0a81
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230774
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Provide an explicit name for configuring PLLD. The new name,
clock_configure_plld(), provides an explicit semantic to
what it is doing. Also, provide the printk() about actual
frequency vs requested frequency as most of the callers
were doing this themselves.
BUG=chrome-os-partner:33825
BRANCH=None
TEST=Built and booted on ryu.
Change-Id: If744332b466d9486f83b08d0ab4e9006fadfecdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230773
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
This was copied and pasted more than it should have been...
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I2af9a30f3df733af147e8759f78a9802d2296c0f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230753
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These are board specific adjustments that can be made for each
USB3 port.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: Iab92ff7b0218d4abd9eba8a94d34ddd9a30ddb87
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230231
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Framebuffer line size and number of lines can have different
values than panel's resolution.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: Iedeef796f02286bb03920413420f8952cf34334a
Reviewed-on: https://chromium-review.googlesource.com/229915
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
