src/fw/coreboot.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
From: Raul E Rangel <rrangel@chromium.org>
Date: Tue, 14 Jan 2020 14:19:00 -0700
There seems to be a mismatch between the ACPI table coreboot writes, and
what SeaBIOS is scanning:
SeaBIOS:
Scanning: 0x00000000 : 0x00001000
Scanning: 0xade50000 : 0xb0000000
Coreboot:
IMD ROOT 0. affff000 00001000
IMD SMALL 1. afffe000 00001000
FSP MEMORY 2. aeffe000 01000000
CONSOLE 3. aefde000 00020000
TIME STAMP 4. aefdd000 00000910
TSEG 5. adfdd000 01000000
RAMSTAGE 6. adede000 000ff000
REFCODE 7. ade8e000 00050000
ACPI GNVS 8. ade8d000 00001000
COREBOOT 9. ade85000 00008000
ACPI 10. ade61000 00024000
TPM2 TCGLOG11. ade51000 00010000
SMBIOS 12. ade50000 00000800
BUG=none
TEST=Dali is able to boot
Change-Id: I1db339f08d0754b836f84fe87cbf1139f27270e1
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on:
https://chromium-review.googlesource.com/c/chromiumos/third_party/seabios/+/2001559
Reviewed-by: Martin Roth <martinroth@chromium.org>
Commit-Queue: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
---
The real bug should be fixed here.
src/fw/coreboot.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c
index 7c0954b..b95c680 100644
--- a/src/fw/coreboot.c
+++ b/src/fw/coreboot.c
@@ -243,10 +243,19 @@ void coreboot_debug_putc(char c)
static void
scan_tables(u32 start, u32 size)
{
+ if (size > 0x100000) {
+ dprintf(5, "Size is too large: %d\n", size);
+ size = 0x100000;
+ }
void *p = (void*)ALIGN(start, 16);
void *end = (void*)start + size;
- for (; p<end; p += 16)
+ dprintf(5, "Scanning: %p : %p\n", p, end);
+ for (; p<end; p += 16) {
copy_table(p);
+ // dprintf(5, ".");
+ }
+
+ dprintf(3, "\nDone Scanning\n");
}
void
@@ -266,9 +275,12 @@ coreboot_platform_setup(void)
int i, count = MEM_RANGE_COUNT(cbm);
for (i=0; i<count; i++) {
struct cb_memory_range *m = &cbm->map[i];
+
+ dprintf(3, "Looking at type: %x\n", m->type);
if (m->type == CB_MEM_TABLE)
scan_tables(m->start, m->size);
}
+ dprintf(3, "Done relocating coreboot bios tables\n");
find_acpi_features();
}
--
2.25.1
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org
This was a hack for our own branch. I never did a proper fix because we
were only using seabios short term.
On Mon, Mar 16, 2020 at 10:44 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
> From: Raul E Rangel <rrangel@chromium.org>
> Date: Tue, 14 Jan 2020 14:19:00 -0700
>
> There seems to be a mismatch between the ACPI table coreboot writes, and
> what SeaBIOS is scanning:
>
> SeaBIOS:
> Scanning: 0x00000000 : 0x00001000
> Scanning: 0xade50000 : 0xb0000000
>
> Coreboot:
> IMD ROOT 0. affff000 00001000
> IMD SMALL 1. afffe000 00001000
> FSP MEMORY 2. aeffe000 01000000
> CONSOLE 3. aefde000 00020000
> TIME STAMP 4. aefdd000 00000910
> TSEG 5. adfdd000 01000000
> RAMSTAGE 6. adede000 000ff000
> REFCODE 7. ade8e000 00050000
> ACPI GNVS 8. ade8d000 00001000
> COREBOOT 9. ade85000 00008000
> ACPI 10. ade61000 00024000
> TPM2 TCGLOG11. ade51000 00010000
> SMBIOS 12. ade50000 00000800
>
> BUG=none
> TEST=Dali is able to boot
>
> Change-Id: I1db339f08d0754b836f84fe87cbf1139f27270e1
> Signed-off-by: Raul E Rangel <rrangel@chromium.org>
> Reviewed-on:
>
> https://chromium-review.googlesource.com/c/chromiumos/third_party/seabios/+/2001559
> Reviewed-by
> <https://chromium-review.googlesource.com/c/chromiumos/third_party/seabios/+/2001559Reviewed-by>:
> Martin Roth <martinroth@chromium.org>
> Commit-Queue: Martin Roth <martinroth@chromium.org>
> Tested-by: Martin Roth <martinroth@chromium.org>
> ---
> The real bug should be fixed here.
>
> src/fw/coreboot.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c
> index 7c0954b..b95c680 100644
> --- a/src/fw/coreboot.c
> +++ b/src/fw/coreboot.c
> @@ -243,10 +243,19 @@ void coreboot_debug_putc(char c)
> static void
> scan_tables(u32 start, u32 size)
> {
> + if (size > 0x100000) {
> + dprintf(5, "Size is too large: %d\n", size);
> + size = 0x100000;
> + }
> void *p = (void*)ALIGN(start, 16);
> void *end = (void*)start + size;
> - for (; p<end; p += 16)
> + dprintf(5, "Scanning: %p : %p\n", p, end);
> + for (; p<end; p += 16) {
> copy_table(p);
> + // dprintf(5, ".");
> + }
> +
> + dprintf(3, "\nDone Scanning\n");
> }
>
> void
> @@ -266,9 +275,12 @@ coreboot_platform_setup(void)
> int i, count = MEM_RANGE_COUNT(cbm);
> for (i=0; i<count; i++) {
> struct cb_memory_range *m = &cbm->map[i];
> +
> + dprintf(3, "Looking at type: %x\n", m->type);
> if (m->type == CB_MEM_TABLE)
> scan_tables(m->start, m->size);
> }
> + dprintf(3, "Done relocating coreboot bios tables\n");
>
> find_acpi_features();
> }
> --
> 2.25.1
>
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org
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 _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
> Before it didn’t boot? Or did it just take a very long time? It just took 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 > ``` > Ideally we could avoid scanning and just lookup: ACPI 10. ade61000 00024000 _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org
© 2016 - 2024 Red Hat, Inc.