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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
