Re: [coreboot] Porting to Asus M4A78-EM

[Scott Duplichan]

-----Original Message-----
From: coreboot-bounces+scott=[e-mail] [mailto:coreboot-bounces+scott=[e-mail]] On Behalf Of Juhana
Helovuo
Sent: Thursday, December 02, 2010 08:05 AM
To: Liu Tao
Cc: [e-mail]
Subject: Re: [coreboot] Porting to Asus M4A78-EM

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.

I am not too familiar with memtest86, but an overwrite of the UMA memory
should be easy to debug. From your e820 map, it looks like the DRAM
reserved for UMA use is at 30000000-3fffffff. The frame buffer maps the
same DRAM to a different address, such as D0000000. If the display is
written, then one of these two ranges is getting written. What is your
frame buffer address?

An experiment you could do is add a PCI video card and build without UMA
graphics support.

]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

This looks reasonable if you are using a 1GB DIMM and 256MB
is used by UMA.

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

I think the table memory eventually becomes free for OS use.

]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?

True, memory addresses and port I/O address are unrelated.

Thanks,
Scott

]Best regards,
]Juhana Helovuo