Age | Commit message (Collapse) | Author |
|
Initialize timestamp table with data from psp_verstage on bootblock.
PSP keeps its own timestamp and pass it in transfer_buffer. However PSP
timestamp and TSC may be out of sync so we can't just merge two tables
without modification.
info->timestamp contains PSP's clock value (in us) when x86 processor
released and base_timestamp contains TSC value when bootblock is
started. The time between x86 release and bootblock entry should be very
short so we can think those two happened at the same time and use them
for sync.
In some cases there will be underflow in timestamp entries but cbmem
utility can handle wrap-over in entries. Few timestamp values including
1st timestamp can be very large but we can still get the time spent on
boot without any problem.
BUG=b:159220781, b:167148121, b:171422583
BRANCH=zork
TEST=boot to kernel, run 'cbmem -t' and check verstage timestamps are
included in the result.
Change-Id: I5e89bb54f478153fb40ba51b5ab61fa20af3b99a
Signed-off-by: Kangheui Won <khwon@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45059
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The PSP will now pass us data on the PSP boot mode and the production
silicon level. Print these values out to save in the log.
These definitions are in a vendorcode include directory that was
previously only included in verstage. Add the include directory
to all stages.
BUG=b:170237834
TEST=Build & Boot - See values printed.
BRANCH=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Iee87413d1473786cf0e148a8088d27f8d24a47a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
|
|
The transfer buffer check had gotten large enough to deserve a function
of its own, so break it out.
BUG=None
TEST=Build
Branch=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Idf46f8edb6b70c63f623522e2bcd2f22d6d4790b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46112
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
BUG=b:169199392
TEST=Corrupt vboot signature to force an error, see that the system
halts instead of rebooting forever.
BRANCH=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I949f94e78d25720f6cd7e81de8d030084e267f29
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45964
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of halting if the vboot workbuf is not passed to coreboot by the
PSP, reset and reboot into recovery mode.
This process is made more difficult because if the workbuf isn't
available, we can't reboot directly into recovery - the workbuf is
needed for that process to be done through the regular calls, and we
don't want to go around the vboot API and just write into VBNV directly.
To overcome this, we set a CMOS flag, and reset the system.
PSP_verstage checks for this flag so it will update VBNV and reset the
system after generating the workbuf.
BUG=b:152638343
TEST=Simulate the workbuf not being present and verify the reboot
process.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I049db956a5209904b274747be28ff226ce542316
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44538
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Check for the workbuf in bootblock if psp_verstage is being used.
BUG=b:158124527
TEST=Build & boot Trembyle with psp_verstage
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I0ec8d2c953bce4c44cde5102d2765e0ab9b5875e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42810
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
We are currently relying on the assumption that the amdcompress tool
will zero out the bss section. Instead of relying on this assumption,
lets explicitly clear it.
The implementation was copied from assembly_entry.S.
BUG=b:147042464
TEST=Cold boot trembyle and also s3 resume trembyle
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifb4f4cc6932dd4c3c92d4e7647569f9a0c69ea4c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change is required so we have a defined entry point on S3. Without
this, the S3_RESUME_EIP_MSR register could in theory be written to
later which would be a security risk.
BUG=b:147042464
TEST=Resume trembyle and see bootblock start.
coreboot-4.12-512-g65779ebcf73f-dirty Thu Jun 4 22:38:17 UTC 2020 smm starting (log level: 8)...
SMI# #6
SMI#: SLP = 0x0c01
Chrome EC: Set SMI mask to 0x0000000000000000
Chrome EC: Set SCI mask to 0x0000000000000000
Clearing pending EC events. Error code EC_RES_UNAVAILABLE(9) is expected.
EC returned error result code 9
SMI#: Entering S3 (Suspend-To-RAM)
PSP: Prepare to enter sleep state 3... OK
SMU: Put system into S3/S4/S5
Timestamp - start of bootblock: 18446744070740509170
coreboot-4.12-512-g65779ebcf73f-dirty Thu Jun 4 22:38:17 UTC 2020 bootblock starting (log level: 8)...
Family_Model: 00810f81
PMxC0 STATUS: 0x200800 SleepReset BIT11
I2C bus 3 version 0x3132322a
DW I2C bus 3 at 0xfedc5000 (400 KHz)
Timestamp - end of bootblock: 18446744070804450274
VBOOT: Loading verstage.
FMAP: area COREBOOT found @ c75000 (3715072 bytes)
CBFS: Locating 'fallback/verstage'
CBFS: Found @ offset 61b80 size cee4
PROG_RUN: Setting MTRR to cache stage. base: 0x04000000, size: 0x00010000
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4b0b0d0d576fc42b1628a4547a5c9a10bcbe9d37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
The PSP does the memory training and setting up of MSRs for
TOP_MEM and TOM2. Set caching up for all the DRAM areas:
Enable WB caching for 1MiB->TOP_MEM, 4GiB->TOM2.
Enable WC caching fro 0->1MiB except 0xa0000->0xc0000.
BUG=b:155426691
Change-Id: I83916a220ea4016d4438dd4fb5be82dec5506f80
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
sb_reset_i2c_slaves is called in fch_pre_init.
BUG=b:153675916
TEST=Builds on trembyle
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I157e473984257d633ceb3ef9df45c71a31c5c00b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
fch_early_init already calls i2c_soc_early_init().
BUG=b:153675916
TEST=Boot trembyle and only see 1 i2c initialization message
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I689616fb617904df1781be3abe9d1dc580608173
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40866
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Unlike prior AMD devices, picasso cannot rely on the cache-as-RAM
setup code to properly enable MTRRs. Add that capability to the
bootblock_c_entry() function. In addition, enable an MTRR to cache
(WP) the flash boot device and another for WB of the non-XIP bootblock
running in DRAM.
BUG=b:147042464
TEST=Boot trembyle to payload and make sure bootblock isn't abnormally
slow.
Change-Id: I5615ff60ca196e622a939b46276a4a0940076ebe
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38691
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The original plan for Picasso was to combine the features of bootblock
with romstage due to its unique way of coming out of reset. Early in
development, all bootblock support was removed from the directory.
All Picasso designs will now use a bootblock as their first stage. The
reason being that it requires less invasive changes than using a hybrid
romstage.
Add a basic bootblock back to the directory, and compatible with the
design of lib/bootblock.c. The files support RESET_VECTOR_IN_RAM
and add appropriate settings in Kconfig. Make Makefile.inc calculates
the size and base of bootblock from known parameters.
* Future work may attempt to streamline this further, in conjunction
with changes in amdfwtool. See b/154957411.
BUG=b:147042464, b:153675909
Change-Id: I1d0784025f2b39f140b16f37726d4a7f36df6c6c
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37490
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Iaf370e04adb04eb81555a57e81812ebe3339971d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Remove all Picasso bootblock support. CAR is not a supportable
feature, and the first code executed at the reset vector will be
a hybrid romstage. Details for this implementation may be found
in Documentation/soc/amd/picasso/family17h.md.
TEST=None
BUG=b:130804851
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I8edf45c02dc5bfcdca03abf1294db4be508682cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
So that everyone can see what's being updated from stoney, we're
starting with a direct copy of the stoney directory. There are
arguments both for and against doing it this way, but I believe
This the most transparent way. We've moved much of the duplicated
stoney code into the soc/amd/common directory and will continue
that work as it becomes obvious that we have unchanged code between
the SOCs.
Makefile.inc has been renamed as makefile.inc so that it won't
build in jenkins until the directory is updated.
Other than that change, this is an exact copy of the stoneyridge
SOC directory which will be updated in the follow-on commits in
the patch train.
TEST=None
BUG=b:130804851
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|