[LinuxBIOS] [PATCH] e820 table correction

Lu, Yinghai yinghai.lu at amd.com
Sat Feb 3 01:17:28 CET 2007


Actually that is because of Andi's patch cause the problem.

I was wondering why we can not use these ram.

It is good if update kernel instead.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Roman Kononov
Sent: Wednesday, January 31, 2007 2:37 PM
To: LinuxBIOS
Subject: [LinuxBIOS] [PATCH] e820 table correction

Hello,

I have this situation:

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 <kononov195-lbl at yahoo.com>
---


-------------- next part --------------
A non-text attachment was scrubbed...
Name: x.diff
Type: application/octet-stream
Size: 2716 bytes
Desc: x.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070202/63baa08a/attachment.obj>


More information about the coreboot mailing list