From 57e700f4f467afdad89e75820a7fae47f6b8b7ae Mon Sep 17 00:00:00 2001 From: Roman Kononov Date: Thu, 1 Feb 2007 00:44:27 +0000 Subject: great check-in message: Linuxbios boots an Opteron motherboard with 1GB memory. Linuxbios directly loads a recent linux kernel. The memory layout is like this: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 00000000000f0400 - 0000000040000000 (usable) The f0000-f0400 region contains IRQ and ACPI tables. At some point the kernel builds a resource table containing all physical address ranges and type of hardware the addresses are mapped to. The table is accessible via /proc/iomem: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 As you can see, the 00000000000f0400-0000000040000000 region is not listed. It is not listed because the kernel unconditionally adds "000f0000-000fffff : System ROM" first (look for "request_resource(&iomem_resource, &system_rom_resource)"), and then the attempt to add f0400-40000000 range fails because of overlapping. The kernel does not care that the range is not listed there. Kexec does. It uses the /proc/iomem file to instruct the kexec system call how to place the segments of a new kernel in the physical memory. Kexec fails to start a new kernel because it cannot locate enough physical memory. This must be fixed either in linux or linuxbios. Assuming that linuxbios is to be fixed, I cooked a patch which provides this memory layout: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000040000000 (usable) The /proc/iomem contains: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM 00100000-3fffffff : System RAM 00100000-00203c61 : Kernel code 00203c62-00248c3f : Kernel data e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 Kexec is happier with the patch. Regards, Signed-off-by: Roman Kononov Acked-by: Stefan Reinauer git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2542 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1 --- src/arch/i386/boot/linuxbios_table.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'src/arch') diff --git a/src/arch/i386/boot/linuxbios_table.c b/src/arch/i386/boot/linuxbios_table.c index 402f7f90e0..f1be49bbc6 100644 --- a/src/arch/i386/boot/linuxbios_table.c +++ b/src/arch/i386/boot/linuxbios_table.c @@ -382,8 +382,9 @@ unsigned long write_linuxbios_table( low_table_start, low_table_end - low_table_start); /* Record the pirq table, acpi tables, and maybe the mptable */ + table_size=rom_table_end-rom_table_start; lb_add_memory_range(mem, LB_MEM_TABLE, - rom_table_start, rom_table_end - rom_table_start); + rom_table_start, table_size<0x10000?0x10000:table_size); /* Note: * I assume that there is always memory at immediately after -- cgit v1.2.3