Due to CL https://chromium-review.googlesource.com/231250,
depthcharge now detects gpio state based on gpio configurations
done by coreboot instead of redoing configuration at
depthcharge. However, PWR button and LID open pins have not
been configured in coreboot. So, add the missing code here.
Otherwise, TOT coreboot/depthcharge rush build can not load
in kernel.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build rush and test with pwr button press and lid switch
Change-Id: I6c322cd987967920f236aae653294db079678408
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233322
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>
Before the change to use vb2_api.h, coreboot needed to know where to
find the vboot2 header files. Now those are all included by
vb2_api.h, so coreboot doesn't need to know about
firmware/2lib/include (and in fact, the 2lib directory is about to go
away).
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
Change-Id: I7f69ca9cf8d45c325219efceca0cb8d1340f7736
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233223
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This reverts commit c29a5e368d.
This option is not used any longer.
BUG=None
BRANCH=None
TEST=Config not used.
Change-Id: I0718bd701c5588b39b69e36d8e2b510a82cf1372
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233075
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This will allow vboot2 to continue refactoring without breaking
coreboot, since there's now only a single file which needs to stay in
sync.
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
CQ-DEPEND=CL:233050
Change-Id: I74cae5f0badfb2d795eb5420354b9e6d0b4710f7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233051
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Turn on CBMEM console support now that we have all the pieces in place,
and also (re-)enable timestamps on Pinky (which have previously been
taken out of the config file there, but not on Jerry and Mighty).
BRANCH=None
BUG=None
TEST=Booted Pinky, confirmed 'cbmem -c' and 'cbmem -t' show correct
results (except for the dual init in the bootblock, which CL:231942
will take care of).
Change-Id: I424902f237537c9f1a65b9266a53e971ca25c09e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232616
Reviewed-by: Aaron Durbin <adurbin@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
Apparently our initial submission of 16K was a little too generous for
the vboot2 work buffer, and I hear that we should also be well within
bounds for 12K. This patch reduces the minimum asserted by memlayout so
some of our low-mem boards can get a few more kilobytes back for
discretionary spending. Also changes the required minimum alignment to 8
since that's what the current vboot code aligns it to anyway, and add a
warning comment to make it clearer that this is a dangerous number
people should not be playing with lightly.
BRANCH=None
BUG=None
TEST=Built and booted on Pinky.
Change-Id: Iae9c74050500a315c90f5d5517427d755ac1dfea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232613
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
With the Storm image layout reworked, the very first blob read out of
NOR SPI flash by the IPQ8064 maskrom is supposed to be a concatenation
of three binaries: one to run on RPM, another one to run on AP, and
the third one - the actual coreboot bootblock.
This layout allows to greatly reduce the size and complexity of the
two first blobs, as they do not need to include the SPI driver.
The first binary in the input file list starts with the combined
header, describing the rest of the blob. This utility copies the first
input file into output, updating the combined header with the total
size of the concatenated binaries.
The second and third binaries in the combined image are required to be
aligned at 256 byte offset in the file as calculated off the end of
the combined header. The new utility allows to concatenate two or
three files, always expecting the first file to be prepended by the
combined header.
For further reference below is the utility's help message:
mbncat.py: [-v] [-h] [-o Output MBN] sbl1 sbl2 [bootblock]
Concatenates up to three mbn files: two SBLs and a coreboot bootblock
-h This message
-v verbose
-o Output file name, (default: sbl-ro.mbn)
BRANCH=none
BUG=chrome-os-partner:34161
TEST=run the new utility and compared the result with the output of
the vendor provided tool. The output files are exactly the same.
Change-Id: I00724f7c75703fc90d7971c3cb337c33ca96f2b5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232047
Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch changes the ram_media CBFS backend implementation to no
longer detect an absolute address that is inside the "memory region"
used to back the CBFS image (which on x86 is really just the
memory-mapped flash due to a depthcharge implementation detail). This
was (as far as I know only) used to support the ugly CBFS header pointer
situation with SeaBIOS, which is now resolved. It is a very dangerous
feature, since it's perfectly possible for a negative offset relative to
the end of the image to overlap that region. We only get lucky that in
our existing use cases the embedded CBFS is further away from the end of
the ROM than it's own size... if we instead had a 3MB image from
0xfffd0000 to 0xffff0000, then we might want to pass in an address like
0xfffe8000 (interpreted as a relative offset from the end) to refer to
the absolute address 0xfffd8000, but this feature would prevent that
since it fits inside the window when interpreted absolutely. (Also, it
is unlikely but possible that a non-memory-mapped architecture which
starts DRAM at 0x0 may put its bounce buffer within the first few
megabyte of the address space, so that a relative offset from the start
of the image could be interpreted as an absolute offset inside the
buffer.
CQ-DEPEND=CL:229962
BRANCH=None
BUG=None
TEST=Built and booted on Falco and Nyan_Blaze, confirmed that legacy
mode still works as well as before.
Change-Id: I0c9149d725adeecef2520342b307ce7ea52990c1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229976
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@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
This patch fixes up our board configs to conform to the new relationship
between CBFS_SIZE and ROM_SIZE, and to remove the FLASHMAP_OFFSET which
now has a useful default.
BRANCH=None
BUG=None
TEST=Tested with other patches.
Change-Id: I4781df455ee15ddc91b51d2c42cdeedd60089027
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231576
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
This CL makes slight changes to the ChromeOS-specific GPIO definitions
of Tegra and Rockchip boards to prepare them for new features in
depthcharge. It adds descriptions for the EC in RW and reset GPIOs,
changes the value Tegra writes into the (previously unused) 'port' field
to describe the complete GPIO information, and removes code to sample
some GPIOs that don't need to be sampled at coreboot time (to help
depthcharge detect errors and avoid using a stale value for something
that should always represent the current state).
BRANCH=None
BUG=None
TEST=None (tested together with depthcharge patches)
Change-Id: I36bb16c8d931f862bf12a5b862b10cf18d738ddd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231222
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since CL:226662, all TPMP accessing should be removed as well,
else it will cause fox_wtm2 coreboot failed on build.
BUG=none
BRANCH=none
TEST=./setup_board --board=fox_wtm2 && emerge-fox_wtm2 coreboot
CQ-DEPEND=CL:226662
Change-Id: Ia0eebb1924bbb23979c880f7d05600a0cf1e4ca3
Signed-off-by: Harry Pan <harry.pan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/232165
Reviewed-by: Wei Shun Chang <wei.shun.chang@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Until proper MIPS cache management is available it is necessary to
disable data and instruction caches, otherwise code placed in memory
stays in data cache and is not available for instruction fetched.
BRANCH=none
BUG=chrome-os-partner:31438,chrome-os-partner:34127
TEST=coreboot loading rombase and rambase now succeeds.
Change-Id: Ib195ed6e5f08ccaa6bbe3325c2199171bfb63b88
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232191
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>
fmap_find used to read 4096 bytes from the fmap offset blindly. instead, we read
the fmap header first to calcurate the size of the fmap. Then, we read flash
again exactly as much as the discovered fmap.
BUG=none
BRANCH=ToT
TEST=Booted Storm and Peppy. Built all current boards.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ie5058d181e6565acb70bf108464682dd0e6c1f64
Reviewed-on: https://chromium-review.googlesource.com/231685
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The total bootprom size is 2MB, so coreboot should fit into
512KB. FMAP is placed in the depthcharde device tree definition at
0xe0000.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the appropriate chromeos-bmpblk and deptcharge changes,
chromeos-bootimage now builds successfully.
Change-Id: I5eb086a7529947e00cdee626e164b3328ff86ccb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232238
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Low level 64 bit division and modulo functions are not available for
MIPS platforms, but are required by the printk formatter.
Modify the code to avoid 64 bit math when building for MIPS. In case
the user does print a value exceeding 2^32, send a few junk characters
to the output to indicate a corrupted value printed.
BRANCH=none
BUG=none
TEST=startup code on Urara properly prints CBFS address values which
are passed as 64 bit integers.
Change-Id: I25b8a900b3ba4ec1da3446dcc5f03101d5cdb757
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232294
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit 9c0978d944.
The underlying assumption was that the only format specification which
required 64 bit division was '%L', and it was used on x86 only. It
turns out, that '%ll' also uses 64 bit division, and this format
specification is more popular in the code, which in turn results in
incorrect values printed when the caller passes in 64 bit numbers.
An alternative solution will be presented in the next patch.
BRANCH=none
BUG=none
TEST=none
Change-Id: Ie671d49a5026eb3b0c3c250f365d725e3b19bb25
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232293
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>
With support for initializing registers based on values saved by primary CPU, we
no longer need to invalidate secondary CPU stack cache lines. Before jumping to
C environment, we enable caching and update the required registers.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I738250f948e912725264cba3e389602af7510e3e
Reviewed-on: https://chromium-review.googlesource.com/231563
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
startup.c provides function to enable CPU in any stage to save register data
that can be used by secondary CPU (for normal boot) or any CPU (for resume
boot). stage_entry.S defines space for saving arm64_startup_data. This can be
filled by:
1) Primary CPU before bringing up secondary CPUs so that the secondary can use
register values to initialize MMU-related and other required registers to
appropriate values.
2) CPU suspend path to ensure that on resume the values which were saved are
restored appropriately.
stage_entry.S provides a common path for both normal and resume boot to
initialize saved registers. For resume path, it is important to set the
secondary entry point for startup since x26 needs to be 1 for enabling MMU and
cache.
This also ensures that we do not fall into false memory cache errors which
caused CPU to fail during normal / resume boot. Thus, we can get rid of the
stack cache invalidate for secondary CPUs.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu without mmu_enable and stack
cache invalidate for CPU1.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I527a95779cf3fed37392b6605b096f54f8286d64
Reviewed-on: https://chromium-review.googlesource.com/231561
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Some registers are available only at EL3. Add conditional read/write functions
that perform operations only if currently we are in EL3.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ia170d94adb9ecc141ff86e4a3041ddbf9045bc89
Reviewed-on: https://chromium-review.googlesource.com/231549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
TCR at EL1 is 64-bit whereas at EL2 and EL3 it is 32-bit. Thus, use 64-bit
variables to read / write TCR at current EL. raw_read_tcr_elx will handle it
automatically by accepting / returning 32-bit / 64-bit values.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I459914808b69318157113504a3ee7cf6c5f4d8d1
Reviewed-on: https://chromium-review.googlesource.com/231548
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
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>
A couple of regs need to be poked to allow audio output
from this part on Ryu P0/P1. It will be replaced by two
non-configurable amps on P3.
BUG=none
BRANCH=none
TEST=Build/flashed on Ryu P1, dumped AD4567 (I2C6 dev 0x34)
regs and confirmed settings.
Change-Id: I8999843646927dbd07a179ede973ba5f1eb97167
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/231384
Reviewed-by: Aaron Durbin <adurbin@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>
This patch adds Cypress gen5 trackpad device supported in auron
platform.
The new Cypress gen5 trackpad's I2C address is 0x24 which is different
from the old trackpad device's I2C address 0x67.
BRANCH=None
BUG=None
TEST=None
Signed-off-by: Dudley Du <dudley.dulixin@gmail.com>
Change-Id: I4a80d6a5b63b4ec3a0d38258886b1979a12377ea
Reviewed-on: https://chromium-review.googlesource.com/230254
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dudley Du <dudl@cypress.com>
Tested-by: Dudley Du <dudl@cypress.com>
Commit-Queue: Shawn Nematbakhsh <shawnn@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>
