Drive SPKR_RST_L (GPP_A19) high at boot to take audio amps out of
reset.
BUG=b:78122599
BRANCH=none
TEST="emerge-nocturne coreboot chromeos-bootimage", boot to kernel,
and verify sound works via "aplay /dev/random"
Change-Id: Ia49931f2dc7802edc8a46114b081e4a96eeee604
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/26317
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
CpuMemoryTest in FSP tests 0 to 1M of the RAM after MRC init. With
PAGING_IN_CACHE_AS_RAM enabled for GLK, there was no page table
entry for this range which caused a page fault. Since this test
is anyway not exhaustive, we will skip the memory test in FSP.
There is an option to do PCIe power sequence from within FSP if provided
with the GPIOs used for PERST to FSP. Since we do this from coreboot,
will skip the PCIe power sequence done by FSP.
FSP does not know what the clock requirements are for the device on
SPI bus, hence it should not modify what coreboot has set up. Hence
skipping SPI clock programming in FSP.
CQ-DEPEND=CL:*627827
BUG=b:78599939, b:78599576, b:76058338
BRANCH=None
TEST=Build coreboot for Octopus board.
Change-Id: I4fa7a73fbb4676bb7af2416c8a33bf10ef41dd53
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Reviewed-on: https://review.coreboot.org/26284
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use of device_t has been abandoned in ramstage.
The function prototype for "struct device *add_cpu_device"
is already correct and doesn't need to be fixed.
Change-Id: I7bd8b93922f113bdaf7ba460acf6a7d62c4df013
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26067
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The TP_Perf_STRUCT was missing from pi/00670F00. So I copied the file
from src/vendorcode/amd/pi/00630F01/Include/IdsPerf.h and removed
everything that we don't need. I did have to change
MAX_PERFORMANCE_UNIT_NUM so it matches the size used by pi/00670F00.
This struct is used to extract the timestamps from AGESA.
BUG=b:64549506
TEST=built on grunt
Change-Id: I06ec82348e3d10f2430c1192a925a49389ae4414
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/26235
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add 64KB to the reserved memory used for stage_cache. This corrects
an error observed when using a debug build of the AGESA blob.
Messages on initial boot
AGESA: Saving stage to cache
Error: Can't add stage_cache 57a9e101 to imd
and during resume
AGESA: Loading stage from cache
Error: Can't find stage_cache 57a9e101 in imd
TEST=boot/suspend/resume Grunt with debug and release builds
BUG=b:79154155
Change-Id: I3f27059fcef37e335d0301142ba4dedb3809e369
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/26386
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The firmware_Mosys FAFT test does not allow RW_SECTION_A, RW_SECTION_B or
RW_SHARED to be 0-sized, nor located at offset 0x00000000.
Swap UNIFIED_MRC_CACHE and RW_SECTION_A to pass this test.
BUG=b:79865447
TEST=test_that -b grunt ${IP} firmware_Mosys
Change-Id: If60919fd998ac786d58a5a258d7b5ded727db64b
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/26356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch enables the new bootblock compression feature on RK3399,
which requires moving MMU initialization into the decompressor stage and
linking the decompressor (rather than the bootblock) into the entry
point jumped to by the masked ROM.
RK3399's masked ROM seems to be using a bitbang SPI driver to load us
(very long pauses between clocking in each byte), with an effective data
rate of about 1Mbit. Bootblock loading time (as measured on a SPI
analyzer) is reduced by almost 100ms (about a third), while the
decompression time is trivial (under 1ms).
Change-Id: I48967ca5bb51cc4481d69dbacb4ca3c6b96cccea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Masked ROMs are the silent killers of boot speed on devices without
memory-mapped SPI flash. They often contain awfully slow SPI drivers
(presumably bit-banged) that take hundreds of milliseconds to load our
bootblock, and every extra kilobyte of bootblock size has a hugely
disproportionate impact on boot speed. The coreboot timestamps can never
show that component, but it impacts our users all the same.
This patch tries to alleviate that issue a bit by allowing us to
compress the bootblock with LZ4, which can cut its size down to nearly
half. Of course, masked ROMs usually don't come with decompression
algorithms built in, so we need to introduce a little decompression stub
that can decompress the rest of the bootblock. This is done by creating
a new "decompressor" stage which runs before the bootblock, but includes
the compressed bootblock code in its data section. It needs to be as
small as possible to get a real benefit from this approach, which means
no device drivers, no console output, no exception handling, etc.
Besides the decompression algorithm itself we only include the timer
driver so that we can measure the boot speed impact of decompression. On
ARM and ARM64 systems, we also need to give SoC code a chance to
initialize the MMU, since running decompression without MMU is
prohibitively slow on these architectures.
This feature is implemented for ARM and ARM64 architectures for now,
although most of it is architecture-independent and it should be
relatively simple to port to other platforms where a masked ROM loads
the bootblock into SRAM. It is also supposed to be a clean starting
point from which later optimizations can hopefully cut down the
decompression stub size (currently ~4K on RK3399) a bit more.
NOTE: Bootblock compression is not for everyone. Possible side effects
include trying to run LZ4 on CPUs that come out of reset extremely
underclocked or enabling this too early in SoC bring-up and getting
frustrated trying to find issues in an undebuggable environment. Ask
your SoC vendor if bootblock compression is right for you.
Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds more parameters to bootblock_main_with_timestamp() to
give callers the opportunity to add additional timestamps that were
recorded in the platform-specific initialization phase.
Change-Id: Idf3a0fcf5aee88a33747afc69e055b95bd38750c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
