Bug #415
openRESOURCE_ALLOCATION_TOP_DOWN breaks booting
0%
Description
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
Updated by Nico Huber over 2 years ago
- Subject changed from RESOURCE_ALLOCATION_TOP_DOWN breaks edk2 to RESOURCE_ALLOCATION_TOP_DOWN breaks booting (-edk2-)
It turned out that there are a lot of platforms in the tree that still don't report their fixed resources correctly. These should be added inside .read_resources
of device drivers. This commit[1] provides an example how it can look like. Sometimes
.read_resources
is simply missing for a device, or- the device driver is not considered because a PCI device ID is missing, or
- the device driver is accidentally disabled in the mainboard devicetree.
One common mistake is not to reserve the memory-mapped "BIOS" flash. Integrated resources that are handled by blobs can also be easily forgotten (at least Intel provides documentation about the complete memory map, though).
When resources are not reported, the allocator can cause conflicts with them. This can happen already by chance; chances are higher when space is tight. Also, the OS needs to be made aware of such resources or might run into the same problem (alas, this is not tied to .read_resources
in coreboot but needs additional ACPI code at the moment).
Updated by Nico Huber over 2 years ago
- Subject changed from RESOURCE_ALLOCATION_TOP_DOWN breaks booting (-edk2-) to RESOURCE_ALLOCATION_TOP_DOWN breaks booting (<del>edk2</del>)
Updated by Nico Huber over 2 years ago
- Subject changed from RESOURCE_ALLOCATION_TOP_DOWN breaks booting (<del>edk2</del>) to RESOURCE_ALLOCATION_TOP_DOWN breaks booting
Updated by Nico Huber over 2 years ago
- File hermes.log hermes.log added
- File t500.log t500.log added
Updated by Sean Rhodes about 1 year ago
Martin Roth wrote in #note-6:
Is this fixed now?
Technically no - it's now just disabled if the payload is edk2