Here's a start on a few of these topics:
I think before we go much further you should all review: statictree.c from serengeti
This file is generated by the code in util/dts - especially see util/dts/flattree.c It contains the logical structure of the device tree, including parents, links, busses, and any other information we include in the dts. Each entry in the dts becomes a device struct, with each device having 3 links.
My observations: 1. It's awkward to have 3 HT busses because they each create a device structure, even though they're all part of the same device. I always end up with the other two links as "left over" devices.
2. It's not clear to me when the "bridge" property should be set. The 8132 is a bridge, but if you set that property it breaks the dts, by making a loop. I think part of the problem is that it's a bridge and a tunnel, which complicates it.
static.c from serengeti
? I'm assuming you mean stage1.c?
This stage writes initial values into the HT routing registers, calls enumerate_ht, calls enable_rom, and enable_serial. I'm not sure what enable_rom does since we're already executing out of it.
In stage1.c I'd love it if the information there could be generated. It seems like it could be if we started from a base configuration and added interesting features like southbridge number and a few bus numbers.
how the links[] array works.
The links array is an array of bus structures. Bus structures hold information like the device that controls the bus, the operations for the bus, etc.
How the config space addressing is setup in in stage1 and how it is used in stage2.
Config space should be set up in stage1 so that all configuration reads go to the link that the southbridge is on. After the southbridge gets enumerated, then the other busses can get enumerated so that the southbridge stays on bus 0 at a low device.
This is very hard to follow in the code because there are so many #defines. I'd love to see them all go away.
the interaction of the 18.1 routing tables and the allocation of mem, prefmem, and IO spaces by the resource code.
This is another area where the #defines make the code ugly. It seems like we should be able to support 64-bit BARs and relocating them by just changing the tolm. The fact that it is a lot more complicated then that in the code makes me worry.
Why there are three 18.1 devices and that interaction with resource allocators.
Where would I find the answer to this question?
From my reading there are a few little bits there you have to get right. I may be wrong but I am not sure all those issues are being taken into consideration.
A writeup of all this by a person who'd never looked at it before would be really useful. Why? because they won't take things for granted -- they'll look at it with a fresh perspective.
Feel free to ask more questions and I'll try to find more answers.
Stefan and I are going to walk this stuff as well.
Great!
Thanks, Myles