-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Tobias Diedrich Sent: Friday, October 29, 2010 06:56 AM To: coreboot@coreboot.org Subject: [coreboot] [PATCH 0/7] ASUS M2V support (v2)
]An update to this patch series: ]I found the gpio that was keeping the pcie slots in reset. ]Azalia HDAC is also working now. ] ]Remaining problems: ]- While my ati pcie graphics card works in the peg slot, a network ] card (x1 link) doesn't, but with the asus bios both work. ]- ACPI still giving stop 0xa5 (next debugging target)
The stop A5 can be easy to debug if you go through the pain of setting up a checked build with windbg. For me the first thing it reported was e820 ranges overlapping with other (ACPI) ranges. I found Windows wants no range reserved in e820 unless it is truly off limits to the OS ands its drivers. The exception is mmconf, which is often reserved in e820. An annoyance with checked build (at least win7) is the e820 range error message prints garbage. The reason is that the DbgPrint format string and arg list do not match. One is 32-bit and the other 64-bit. It will work if patched in memory before executing. Another problem is that Windows wants ACPI to report the address space available to the PCI bus. Here is how mine looks. It is hard-coded for 2MB TOM at the moment:
// starts at TOM and ends at first E820 reserved range (mmconf) DWORDMemory(ResourceProducer,PosDecode,MinFixed,MaxFixed,Cacheable,ReadWrite,0,0x80000000,0xf7ffffff, 0,0x78000000)
Need one for I/O too: WORDIO(ResourceProducer,MinFixed,MaxFixed,PosDecode,EntireRange, 0,0x0D00,0xffff, 0,0xf300)
I would like to come up with a clean way for ACPI to find TOM, then submit a patch. The current way coreboot shares info with ACPI is kind of scary.
Thanks, Scott
]-- ]Tobias PGP: http://8ef7ddba.uguu.de