bi_recs

[Jon Masters]

On Fri, 01 Oct 2004 09:21:50 +1000, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> 
> 
> On Fri, 2004-10-01 at 09:02, Jon Masters wrote:
> > Hi all,
> >
> > Would someone (Tom, Matt, Cort, Paul or Dan?) please tell me what the
> > status is of bi_recs?
> >
> > I first discussed the idea of this at the FOSDEM and not much has come
> > of it - but I would be happy to work on getting flexible system
> > configuration to the kernel on ppc without OF as this will then allow
> > a stock kernel without any need for builtin notions of memory layout.
> > Am I missing something that's already been implemented?
> 
> bi_recs were supposed to evolve in that direction but that never happened.

Right. That needs fixing.

> On the other hand, on ppc64, I took a different approach and decided that
> an OF tree would be mandatory, but you don't need OF to have one.

I thought about this too when Jonathan Corbett was talking about sysfs
ages ago. I thought I might have come up with something - but as usual
it seems that you got there first ;-).

> I rewrote prom_init (the interface to OF)

(I know the ppc32 code but have not looked at the ppc64 code - in fact
tonight on the train I was looking at a FIXME in the ftr_fixup code
and a few other bits I plan to look at).

> so that instead of tapping kenrel
> globals directly and generating struct device_node, it generates a flattened
> version of the device-tree and passes that to the kernel. That means that
> if you can provide a "blob" with such a tree in it, you can bypass prom_init.

I thought about that as an approach. Great - you do it already how I thought.

> The tree doesn't need to be complete (like it doesn't need to contain all
> the PCI devices) and generating such a flattened tree from userland, from
> a text file for example, should be easy, or generate one from whatever
> infos your bootloader provides.

That's what I thought. I'm motivated by horrible *ugly* broken Xilinx
hacks (EDK MHS) which try to bastardise a HAL on to Linux that really
doesn't want to be there - they should have instead been able to pass
their autogenerated output to the kernel at boot time rather than have
it compiled in as they do now.

> But on the other hand, I've given up a long time ago trying to enforce any
> kind of sane model on ppc32 because the embedded folks only care about having
> a quick ugly broken hack to work with their board, thus the explosion of
> various incompatible boot_info structures that we have nowadays.

Yes indeed. It's ugly and needs fixing so I'll take a look at it - I
just don't want to do this if everyone here already knows of a better
solution which will work.

Then Xilinx et al can generate memory maps and we can head towards
having a single kernel binary bootable on multiple different ppc
boards.

Cheers,

Jon.