Re: [LinuxBIOS] More MCP55 hacking

[Lu, Yinghai]

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 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

[LinuxBIOS] More MCP55 hacking

[Stefan Reinauer]

* Lu, Yinghai  [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?

[LinuxBIOS] More MCP55 hacking

[ron minnich]

On 12/12/06, Stefan Reinauer  wrote:
> Lu, Yinghai  [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

[LinuxBIOS] More MCP55 hacking

[Ed Swierk]

On 12/12/06, Lu, Yinghai  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