Dear Raul,
Am 16.03.20 um 17:48 schrieb Raul Rangel:
This was a hack for our own branch. I never did a proper fix because we were only using seabios short term.
No problem. From your commit message it’s not clear, what problem this caused.
TEST=Dali is able to boot
Before it didn’t boot? Or did it just take a very long time?
I am currently looking into this. Testing with coreboot for QEMU Q35 with SeaBIOS as payload, corebooot writes the coreboot table below.
``` Writing coreboot table at 0x7ff99000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000c0000-000000007ff73fff: RAM 3. 000000007ff74000-000000007ffa1fff: CONFIGURATION TABLES 4. 000000007ffa2000-000000007ffd1fff: RAMSTAGE 5. 000000007ffd2000-000000007fffffff: CONFIGURATION TABLES 6. 00000000b0000000-00000000bfffffff: RESERVED 7. 0000000100000000-000000017fffffff: RAM ```
Dumping the coreboot table from SeaBIOS, it merges regions four to six.
``` Relocating coreboot bios tables CBMEM table has 6 items: 0: 0000000000000000 - 0000000000000fff = 0x10 (16) 1: 0000000000001000 - 000000000009ffff = 0x1 (1) 2: 00000000000c0000 - 000000007ff73fff = 0x1 (1) 3: 000000007ff74000 - 000000007fffffff = 0x10 (16) 4: 00000000b0000000 - 00000000bfffffff = 0x2 (2) 5: 0000000100000000 - 000000017fffffff = 0x1 (1) Looking at type 0x10 (start: 0x0, size 4096/0x1000) Looking at type 0x1 (start: 0x1000, size 651264/0x9f000) Looking at type 0x1 (start: 0xc0000, size 2146123776/0x7feb4000) Looking at type 0x10 (start: 0x7ff74000, size 573440/0x8c000) Copying SMBIOS entry point from 0x7ff74000 to 0x000f5700 Copying ACPI RSDP from 0x7ff75000 to 0x000f56e0 Looking at type 0x2 (start: 0xb0000000, size 268435456/0x10000000) Looking at type 0x1 (start: 0x100000000, size -2147483648/0x80000000) ```
Kind regards,
Paul