-----Original Message----- From: linuxbios-bounces@linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Ed Swierk Sent: Tuesday, December 12, 2006 10:51 AM To: LinuxBIOS Subject: [LinuxBIOS] More MCP55 hacking
I've resumed hacking on LinuxBIOS on an Athlon socket AM2 board with an nVidia MCP55 southbridge and a C51XE between the two. I'm using the CK804 southbridge code with updated PCI IDs, and Yinghai's socket AM2 code.
That is called 590 by Nvidia. (C51+MCP55)
I've gotten a Linux kernel to boot, but I am stuck on a few issues:
- I haven't gotten interrupt routing to work yet, and the IRQ routing
table I extract from the factory BIOS seems broken. When I boot with the factory BIOS, however, Linux uses ACPI for interrupt routing, which I think bypasses the routing table altogether. Should I try to fix the routing table or try to get ACPI working? Linux searches for a device to act as an interrupt router; which device on my board would play that role?
Forget about ACPI for irq routing, They said dsdt is under IBV copyright. I don't think you can prove to implement one dsdt in clean room. (If you can access the system with BIOS, you are contaminated.)
- I'm not sure whether HT unitid assignment is correct; the meanings
of HT_CHAIN_UNITID_BASE, HT_CHAIN_END_UNITID_BASE, SB_HT_CHAIN_ON_BUS0 and SB_HT_CHAIN_UNITID_OFFSET_ONLY are very unclear despite comments in the code.
- The PCI device IDs assigned during HyperTransport device
enumeration don't match up with those assigned by the factory BIOS, e.g. the southbridge HT interface (device 10de:0369) is assigned to device 1 on LinuxBIOS but device 8 on the factory BIOS. I'm not sure whether this is a big deal, but is there some way to get them assigned in the same way?
##HT Unit ID offset, default is 1, the typical one default HT_CHAIN_UNITID_BASE=0x06
##real SB Unit ID, default is 0x20, mean dont touch it at last default HT_CHAIN_END_UNITID_BASE=0x01
(it will put c51 on unitid 6, and mcp55 on unitid 1), there will be some device overlap.
===>
##HT Unit ID offset, default is 1, the typical one #default HT_CHAIN_UNITID_BASE=0x06
##real SB Unit ID, default is 0x20, mean dont touch it at last #default HT_CHAIN_END_UNITID_BASE=0x01
(it will put c51 on unitid 1, and mcp55 on unitid ?)
YH
* Lu, Yinghai yinghai.lu@amd.com [061212 20:24]:
Forget about ACPI for irq routing, They said dsdt is under IBV copyright. I don't think you can prove to implement one dsdt in clean room. (If you can access the system with BIOS, you are contaminated.)
We need to be very careful here.
So, since ACPI is also used for bus enumeration these days, am I contaminated after running lspci on such a system? I can draw conclusions on their bus mapping from that.
If I look at their interrupt mapping because my linux kernel prints it out with a debug option, am I contaminated then?
How can we _reliably_ find out where the border is here?
On 12/12/06, Stefan Reinauer stepan@coresystems.de wrote:
- Lu, Yinghai yinghai.lu@amd.com [061212 20:24]:
Forget about ACPI for irq routing, They said dsdt is under IBV copyright. I don't think you can prove to implement one dsdt in clean room. (If you can access the system with BIOS, you are contaminated.)
We need to be very careful here.
So, since ACPI is also used for bus enumeration these days, am I contaminated after running lspci on such a system? I can draw conclusions on their bus mapping from that.
There are two lines. There is the line that is real, and the line that the IBV will want you to think is real. Obviously, since they don't like the idea of a free bios, they are going to want you to think that they own everything in ACPI, and that you violate a copyright everytime you do an lspci. But, ACPI represents real hardware. The hardware is wired as it is wired .If you learn about how a wire is connected from ACPI, it is hard for me to see how an IBV can own that datum.
If I look at their interrupt mapping because my linux kernel prints it out with a debug option, am I contaminated then?
I am sure the IBV would love for you to to think so. I don't see how this is possible.
That said, can we poke at hardware registers etc. to determine what we need?
It's not surprising that ACPI is turning into another form of DRM. It's a lousy standard, designed to make the world ever safer for the status quo of proprietary BIOS and OS implementations. I'm not surprised that the IBV's are now using it as a cudgel.
How can we _reliably_ find out where the border is here?
who knows ...
ron
On 12/12/06, Lu, Yinghai yinghai.lu@amd.com wrote:
===>
##HT Unit ID offset, default is 1, the typical one #default HT_CHAIN_UNITID_BASE=0x06
##real SB Unit ID, default is 0x20, mean dont touch it at last #default HT_CHAIN_END_UNITID_BASE=0x01
(it will put c51 on unitid 1, and mcp55 on unitid ?)
After commenting out these two options as you suggest, it looks like a lot more devices are getting initialized; I had to increase HEAPSIZE to 64 KB to avoid overflowing the heap.
Now, I'm getting an exception during PCI device init; see the attached boot log.
Does it make sense that the same devices (e.g. 10de:0378) are showing up on both bus 0 and bus 4?
--Ed