[coreboot] domain vs device statictree order

[Myles Watson]

On Wed, Jan 7, 2009 at 10:29 AM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> >> I guess it's not really breadth first.  It's just parents before
>> >> siblings.
>
> Will our scheme with 6 phases all processing devices in one and the
> same way fit all hardware?

I can't think of a time when a child expects to be initialized
(whatever phase) before its parent.

> Maybe the bus scan order needs to be settable, maybe by Kconfig,
> maybe even at runtime?
>
> I'll try to clarify:
>
> Geode and Mart needs parents before siblings for phase2 to have VSA
> init before the NAND enable, VSA is in domain.p2 and NAND in ide.p2.
>
> I can imagine that one algorithm for deciding the order of processing
> all devices in the system will not be enough however.
>
> We'll see more dynamic hardware, which will require us to be better
> at running code in the right order.

Those porting the code can choose what phase things need to go in if
it is clear what order things are called.  If that's not clear it
seems very hard to write the code.

> HT speed reconfiguration may be another example, or does it run
> already before any of the phases?

It runs in stage 1.

> Does that also require parents
> before siblings, or is something else (breadth first?) more
> appropriate there?
>
> If we can actually get by with just one simple algorithm that's
> great of course. Can we?

I think so.  It seems like the only downside is that for_all_devices
was simpler than the tree traversal.  I guess it also reaches devices
which weren't found in phase3, but it seems like if phase3 can't find
them you shouldn't do phase4-6.

>> > I don't think having different phases run in different order is a
>> > good idea, as it can lead to unexpected code execution orders all
>> > over again.
>>
>> I agree.
>
> Yes, me too, in the sense that whoever is filling out phases will
> need code for different devices to run in some particular order, and
> instead of trying to guess and document what we think is sufficient,
> it would be nice to have infrastructure that allows each phase filler
> to specify the order they need in a very easy way.
>
>
>> Without this patch Phase1, Phase2, and Phase6 are done in
>> statictree order, and Phase3, Phase4, and Phase5 are done
>> Parents before children.
>
> The merit of statictree order is that it's the only thing available
> before the dynamic bus scans in phase3, or?

There are always two orders available.  When stage2 starts we have the
device tree, which contains children, sibling, and next pointers.  I'm
not sure we ever care to use the next pointers.  Dynamic devices are
not available until after phase3, no matter which way you traverse the
devices.

>> I don't see Phase1 being used anywhere.  Phase2 is handled with the
>> patch.  I think Phase6 should be updated, and I can send a patch.
>
> --8<-- doc/design/newboot.lyx
> Phase 1 -- very early setup
> This phase existed to make printk work and has been obsoleted.
> The simple traversal (forall devices) is used for this phase.
>
> Phase 2 -- fixup.
> Fix broken devices if needed. Typically used by mainboard device.
>
> These are functions that are required before any PCI operations of
> any kind are run.
> The simple traversal (forall devices) is used for this phase.
> -->8--
>
> I suggest moving VSA init to domain.phase1. It's certainly very early
> setup because it _creates_ the PCI devices that are to be fixed up in
> phase2.
If phase1 is really obsolete, then phase2 is as early as you get.  Do
we need to reinstate phase1?

Thanks,
Myles