[coreboot] Porting to Asus M4A78-EM

Juhana Helovuo juhe at iki.fi
Thu Dec 2 15:04:51 CET 2010

30.11.2010 3:46, Liu Tao kirjoitti:
> Hi Juhana,
> Is the problem possiable caused by ACPI tables?
> Maybe you can remove HAVE_ACPI_TABLES from mainboard Kconfig file
> and have a try.

Hello Liu and others,

I tried commenting out HAVE_ACPI_TABLES, but the result was the same. I 
think ACPI tables are not accessed from SeaBIOS (or FILO, or Grub, or 
syslinux) at all. I think the first read access to ACPI tables is from 
Linux kernel. (Except for BIOS e820 calls to query available RAM.)

On the other hand, there is more progress with this port:

FILO works nicely. It recognizes IDE CD and SATA disk, and can load 
Linux kernel and initrd from SATA.

However, trying to boot that kernel results in "Decompressing Linux ... 
Out of memory while allocating output buffer."

I guess this is some kind of problem with RAM allocation. Someone is 
confused about what RAM is available and where.

Also a modified Memtest86 can be executed from SeaBIOS, but clearly it 
gets a wrong idea of memory regions to test and quickly overwrites the 
VGA buffer (display trashed) and its own executable (crash with register 
dump). If the memtest is quickly interrupted to configuration menu and 
the test region is limited to only, e.g. addresses 300M - 1G, then it 
seems to run ok. Memtest claims that it is reading the coreboot tables 
to find out RAM areas to test.

Now that I look again at the various memory maps, something seems out of 
place. Coreboot log shows that there is RAM available in two regions:

coreboot memory table:
  0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
  1. 0000000000001000-000000000009ffff: RAM
  2. 00000000000c0000-000000002ffeffff: RAM
  3. 000000002fff0000-000000002fffffff: CONFIGURATION TABLES
  4. 0000000030000000-000000003fffffff: RESERVED
  5. 00000000e0000000-00000000efffffff: RESERVED

Then later from SeaBIOS:

e820 map has 6 items:
   0: 0000000000000000 - 000000000009f400 = 1
   1: 000000000009f400 - 00000000000a0000 = 2
   2: 00000000000f0000 - 0000000000100000 = 2
   3: 0000000000100000 - 000000002ffef000 = 1
   4: 000000002ffef000 - 0000000040000000 = 2
   5: 00000000e0000000 - 00000000f0000000 = 2

Now e820 map is not marking Coreboot map region 0, "configuration 
tables" as reserved (=2) but usable (=1). Can this be correct?

Also, the PCI resource allocation puts resources to addresses
1000 - 3fff, but maybe those are IO ports and have nothing to do with 
memory addresses?

Best regards,
Juhana Helovuo

More information about the coreboot mailing list