[coreboot] dts general question

Myles Watson mylesgw at gmail.com
Fri Oct 31 19:36:55 CET 2008


On Fri, Oct 31, 2008 at 11:25 AM, ron minnich <rminnich at gmail.com> wrote:

> On Thu, Oct 30, 2008 at 8:08 AM, Myles Watson <mylesgw at gmail.com> wrote:
> > Is it a feature that the device scan depends on the order that the
> devices
> > are listed in in the dts?
> >
> > What I'm saying is that if you list the HT tunnel before the PCI bridge
> you
> > get different results than if you list the bridge first.  Is this by
> > design?  Is the dts supposed to be ordered as if it were a depth-first
> > traversal of the devices, or is the device code supposed to be smart
> enough
> > to find the devices as long as they are listed as the children of the
> > correct parents?
> >
>
> I think it is a feature ... but the phase stuff is supposed to allow
> you to ensure ordering.


All right.  I just wanted to make sure I understood the intent.  I'm getting
a lot closer.  I can actually disable devices now.

One of the main problems is that the dts puts devfn numbers in the device
structures, and those are used to match during phase 3.  Because the HT code
collapses the enumeration, all HT devices need to have devfn == 0.  The HT
code could do this, or we could add a ht at a.0 (that's the route I tried
first) so that the devfn is 0 for HT devices.

The latest problem I have is the devfn getting corrupted for some devices.
If you look early in the device log, the devfn for 7_0 is the correct 0x38.
Later it is 0x68!

I'm attaching a boot log, dts, and the patch to flattree.c

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081031/39f35dc3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v3.bare.out
Type: application/octet-stream
Size: 237380 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081031/39f35dc3/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ht_dtc.diff
Type: text/x-patch
Size: 856 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081031/39f35dc3/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: serengeti.dts
Type: application/octet-stream
Size: 1984 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081031/39f35dc3/attachment-0001.obj>


More information about the coreboot mailing list