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
- 0000000000001000-000000000009ffff: RAM
- 00000000000c0000-000000006fffffff: RAM
- 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.)
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.
* 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.
I got the impression that the kernel initializes some devices by following instructions from ACPI tables. Currently I am using ACPI source codes for AMD Tilapia mainboard from Coreboot sources. At least the Super IO chip type is different there. Maybe this accidentally enables the watchdog again?
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.
Maximum error count (200) exceeded DSDT.dsl 271: Notify (_SB.PWRB, 0x02) Error 4062 - Object does not exist ^ (_SB.PWRB)
DSDT.dsl 619: LNKC, Error 4062 - ^ Object does not exist (LNKC)
DSDT.dsl 627: LNKD, Error 4062 - ^ Object does not exist (LNKD)
[...]
DSDT.dsl 5471: If (LEqual (STCL, 0x0101)) Error 4094 - ^ syntax error, unexpected PARSEOP_IF
DSDT.dsl 5885: Device (SMBS) Error 4055 - ^ Name already exists in scope (SMBS)
DSDT.dsl 5888: OperationRegion (SMBS, PCI_Config, Zero, 0x0100) Error 4055 - Name already exists in scope ^ (SMBS)
DSDT.dsl 5904: Scope { Error 4094 - ^ syntax error, unexpected PARSEOP_SCOPE, expecting $end
Most of the errors are "Object does not exist", so I presume I am missing some kind of library or #include code, but where to get those?
Additionally, I have tried to generate IRQ routing table with the "getpir" utility included with coreboot. It claims to find and extract a table, generates C code, which compiles ok, but booting with it does not work. When writing the table to memory during boot, coreboot complains that the table length is wrong and checksum does not match.
Any pointers to getting working ACPI and IRQ tables for Linux? Or how to fix the ACPI information extracted from Asus BIOS?
Best regards, Juhana Helovuo