On Tue, Aug 3, 2010 at 6:31 AM, Juhana Helovuo juhe@iki.fi wrote:
On Thu, 2010-07-29 at 10:18 -0600, Myles Watson wrote:
Clearly something is out of place, but I cannot immediately figure out what to do next. Any suggestions?
Your UMA is conflicting with your Coreboot tables. It is at least part of the problem.
uma_memory_start=0x70000000, uma_memory_size=0x10000000 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000c0000-000000006fffffff: RAM 3. 0000000070000000-000000007fffffff: RESERVED Wrote coreboot table at: 7fffe000 - 7fffe8bc checksum 3af4
Since your UMA is 0x70000000-0x7fffffff, your Coreboot tables should end up at 6fffe000, not 7fffe000.
Ok, thanks again for the tip. This would have taken me ages to figure out by myself.
I could - at least partially - resolve this by disabling the "high tables" configuration option from Coreboot. If there is a better way, I did not yet find it out. (I suppose UMA means the range of main RAM assigned to the use of VGA controller.)
That's right. You probably want to reorder some code for your board so that the UMA area is reserved before the coreboot tables.
Now there is more progress:
- Coreboot successfully loads "coreinfo" payload, which seems to work
nicely (on serial port).
- Coreboot successfully loads grub2 bootloader, which seems to work
also, i.e. keyboard, vga, and ata disks work.
Problems:
- Seabios still does not give any sign of life.
SeaBIOS is loaded into the same location as the coreboot tables, so without hihg tables it won't work.
- Grub can load linux kernel and ramdisk from IDE disk to memory, but
kernel boot process fails.
The Linux kernel sometimes boots up to "Memory: 2056736k/2097152k available" and sometimes to "Inode-cache hash table entries: 131072"
Please see attached Linux boot logs for details. The boot log with original Asus BIOS is for reference.
Since the Linux boot process does not always crash at the same stage, I suspect that this may be some timing problem, such as the Super IO watchdog acting up again.
Since you have 2G of RAM available according to your boot log, I suspect that you're having a conflict with UMA again. I would start there.
To get more suitable ACPI tables, I dumped ACPI DSDT binary from /proc/acpi/dsdt and disassembled it with iasl compiler. This resulted in a rather long and incomprehensible ASL source program.
However, I could not use it, because recompiling it with "iasl -tc" gives a long list of errors (iasl gives up at 200 errors), e.g.
You can look at some of the DSDTs for other boards for hints on how to do forward declarations. Some of the objects may be contained in the SSDT, which may be dynamically generated.
Good luck, Myles