[coreboot] [PATCH 0/7] ASUS M2V support (v2)

Scott Duplichan scott at notabs.org
Fri Oct 29 16:19:03 CEST 2010

-----Original Message-----
From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Tobias Diedrich
Sent: Friday, October 29, 2010 06:56 AM
To: coreboot at 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.


]Tobias						PGP: http://8ef7ddba.uguu.de

More information about the coreboot mailing list