Hi Jason,
On 16.02.2009 10:51, Wang, Qingpei wrote:
Hi, The e820 map form linux dmesg is [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000001bff0000 (usable) [ 0.000000] BIOS-e820: 000000001bff0000 - 000000001c000000 (reserved) [ 0.000000] BIOS-e820: 000000001c000000 - 0000000038000000 (usable) [ 0.000000] BIOS-e820: 0000000038000000 - 0000000040000000 (reserved) And the data.txt is attached.
Thanks! This looks a bit strange.
Can you attach a full Linux boot log (dmesg) and a full coreboot boot log (serial output)?
The ACPI code has a few bugs: - It hardcodes TOM to 1 GB (fixed in the latest coreboot tree) - It hardcodes TOM2 to 0 (not fixed yet, but irrelevant for your problem) - The DSDT is ACPI 1.0 instead of 2.0, so any machine with more than 3 GB RAM won't be able to express memory ranges (patch pending). - It hardcodes PBAD and PBLN to 0 (not sure if this is really a bug).
The DSDT has this code:
/* Data to be patched by the BIOS during POST */ [...] Name(PBAD, 0x0) /* Address of BIOS area (If TOM2 != 0, Addr >> 16) */ Name(PBLN, 0x0) /* Length of BIOS area */
However, that data is never filled in.
Is it guaranteed that PCIe config space is always at 0xE0000000? The DSDT has this code:
Name(PCBA, 0xE0000000) /* Base address of PCIe config space */ Scope(_SB) { /* PCIe Configuration Space for 16 busses */ OperationRegion(PCFG, SystemMemory, PCBA, 0x01000000) /* Each bus consumes 1MB */ Field(PCFG, ByteAcc, NoLock, Preserve) {
Regards, Carl-Daniel