[coreboot] v3 HT

Myles Watson mylesgw at gmail.com
Tue Oct 28 03:42:23 CET 2008

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.



More information about the coreboot mailing list