A few months ago the topic was already in Leadership meeting + Mailinglist.
It is about creating a spec that specifies the handoff between coreboot and
payload via FDT. It is not just for coreboot though (u-boot, oreboot and
EDK2 as well). Its been a while now, the spec grew and I don't want to keep
the community in the dark.
For more information here is the spec:
https://docs.google.com/document/d/1WxEUlCsXpc17DkJhL3XVkOW7e_KIt_zcc9tQ1tr…
Feel free to review (do your worst so that we get something decent),
contribute and enter the meeting that is going on every week:
https://meet.google.com/gha-shza-wnw
greetings
Max
Issue #514 has been reported by Patrick Georgi.
----------------------------------------
Feature #514: Determine SMM memory requirements on build time
https://ticket.coreboot.org/issues/514
* Author: Patrick Georgi
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-11-17
----------------------------------------
When I tried to normalize the ramstage's heap size, and increase it on most platforms while doing so, I broke resume on a bunch of boards because SMM couldn't cache the ramstage properly anymore. This led to a [revert](https://review.coreboot.org/c/coreboot/+/78850) and so we're back to a few ground rules plus tons of exceptions for the heap size, all of which seem to be determined experimentally.
All necessary information is known at compile time, so we should be able to verify the memory layout and make it break the build if it doesn't work out.
Some thoughts that might help implement this:
- We need to do a full verification if CONFIG_TSEG_STAGE_CACHE == y.
- The constraints are that
- CONFIG_SMM_TSEG_SIZE needs to be larger than the sum of smm (tseg code + data), CONFIG_SMM_RESERVED_SIZE, CONFIG_IED_REGION_SIZE, and AMD's HIGH_MEMORY_SCRATCH (currently: 0x30000) if CONFIG_DRIVERS_AMD_PI is enabled
- CONFIG_SMM_RESERVED_SIZE must be large enough to hold ramstage + postcar + refcode (as loaded by the stage loader, ie. uncompressed) + ~64 byte overhead for IMD headers
- STM has additional requirements (reach out to Eugene Myers who's our domain expert on STM), among others:
- memory requirements per CPU, calculated by a formula (this could be based on CONFIG_MAX_CPUS, I guess?)
- The easiest approach might be to build a tool at build time which includes config.h (so we have all the CONFIG_* around), and various coreboot library portions:
- CBFS adapted to work from a file loaded from disk
- IMD that works on a memory buffer (sized from CONFIG_SMM_RESERVED_SIZE)
- The tool would be spliced into the build process using the build system's INTERMEDIATE facility, copying a coreboot.rom to another coreboot.rom if and only if the tool decides that the memory map is properly dimensioned.
With such build time verification we should be able to clean up various memory sizing configuration values by a fair amount, so there's less variability on them. Creating a tool that computes a full memory map is more complex because it requires rebuilding/relinking a couple of stages (e.g. build ramstage to determine its size, then rebuild it with the computed memory layout that includes ramstage size)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #513 has been reported by Bill XIE.
----------------------------------------
Bug #513: clear_memory() triggers null dereference exception when running coreboot in long (64-bit) mode
https://ticket.coreboot.org/issues/513
* Author: Bill XIE
* Status: New
* Priority: Low
* Category: coreboot common code
* Target version: master
* Start date: 2023-11-17
* Affected versions: master
* Affected hardware: X200
----------------------------------------
Enabling CONFIG_USE_EXP_X86_64_SUPPORT and CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT in the mean time on my X200 triggers null dereference exception. Register dump in attached log suggests that clearing DRAM 0000000100000000-0000000180000000 triggers the exception, and the used memset() implementation in src/arch/x86/memset.c seems unable to handle such usage when built against X86_64.
---Files--------------------------------
clrmem-amd64-nulderef.log (5.21 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #415 has been updated by Sean Rhodes.
Martin Roth wrote in #note-6:
> Is this fixed now?
Technically no - it's now just disabled if the payload is edk2
----------------------------------------
Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting
https://ticket.coreboot.org/issues/415#change-1705
* Author: Sean Rhodes
* Status: New
* Priority: Low
* Target version: none
* Start date: 2022-09-07
* Affected versions: master
----------------------------------------
CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs.
---Files--------------------------------
resource_allocatorv4.txt (94 KB)
up_squared.log (47.9 KB)
hermes.log (575 KB)
t500.log (585 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #415 has been updated by Martin Roth.
Is this fixed now?
----------------------------------------
Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting
https://ticket.coreboot.org/issues/415#change-1704
* Author: Sean Rhodes
* Status: New
* Priority: Low
* Target version: none
* Start date: 2022-09-07
* Affected versions: master
----------------------------------------
CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs.
---Files--------------------------------
resource_allocatorv4.txt (94 KB)
up_squared.log (47.9 KB)
hermes.log (575 KB)
t500.log (585 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #426 has been updated by Martin Roth.
Status changed from New to Resolved
Fixed.
https://review.coreboot.org/c/coreboot/+/68752 - Documentation/measured_boot.md: document new TPM options
https://review.coreboot.org/c/coreboot/+/68751 - Documentation/measured_boot.md: fix SRTM/DRTM explanations
----------------------------------------
Documentation #426: Document existing and added TPM event log formats and PCR usage
https://ticket.coreboot.org/issues/426#change-1703
* Author: Krystian Hebel
* Status: Resolved
* Priority: Normal
* Category: Documentation
* Target version: none
* Start date: 2022-10-12
----------------------------------------
Documentation should mention at least:
- what formats are available and where they are described
- what are possible consumers of each format
- which hashing algorithms can be used
- what additional info is added to that required by specification, if any
- which component is extended to which PCR for each of supported scheme (may be in form of example event log)
Additionally, existing vboot documentation should be fixed, especially parts describing SRTM and DRTM.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #425 has been updated by Martin Roth.
Status changed from New to Resolved
Fixed: https://review.coreboot.org/c/coreboot/+/68749 - util/cbmem: add parsing of TPM logs per specs
----------------------------------------
Feature #425: Add parsing of new TPM event log formats to cbmem utility
https://ticket.coreboot.org/issues/425#change-1702
* Author: Krystian Hebel
* Status: Resolved
* Priority: Normal
* Category: userspace utilities
* Target version: none
* Start date: 2022-10-12
* Related links: https://review.coreboot.org/c/coreboot/+/51583
----------------------------------------
All existing and newly implemented formats must be parse-able by cbmem. It should be able to automatically recognize used format and parse it accordingly, so there are no significant differences in invocation of this tool by end users. Crypto agile format will require implementation of additional unmarshaling.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #431 has been updated by Martin Roth.
Status changed from New to Closed
These issues are not harmful and have been marked as intentional in coverity.
----------------------------------------
Bug #431: fix src/arch/x86/smbios issues
https://ticket.coreboot.org/issues/431#change-1701
* Author: Martin Roth
* Status: Closed
* Priority: Normal
* Assignee: Solomon Alan-Dei
* Category: coreboot common code
* Target version: none
* Start date: 2022-10-20
----------------------------------------
There are currently 20 coverity issues affecting smbios code in src/arch/x86/smbios*
https://scan6.scan.coverity.com/reports.htm#v55284/p10744https://docs.google.com/spreadsheets/d/1hacitQU1zn7CU44eXP3xVdvq-OjnIF_h8LR…
---Files--------------------------------
Outstanding+Issues+in+smbios.csv (3.61 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #444 has been updated by Martin Roth.
These tests are disabled and will be deleted unless fixed.
----------------------------------------
Bug #444: Flaky gitconfig tests are breaking builds
https://ticket.coreboot.org/issues/444#change-1700
* Author: Martin Roth
* Status: New
* Priority: Normal
* Category: build system
* Target version: none
* Start date: 2022-12-20
----------------------------------------
The gitconfig tests are failing when they can't delete a directory they created in /tmp, and this is causing builds to fail randomly.
Because it's not a part of the test itself, but part of the cleanup, the failure doesn't get captured, and jenkins appears to be failing for no good reason.
Someone should figure out what's causing the rm -rf to fail and fix it so that the builders stop failing.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account