On Fri, 01 Oct 2004 09:21:50 +1000, Benjamin Herrenschmidt
[off-list ref] wrote:

On Fri, 2004-10-01 at 09:02, Jon Masters wrote:

quoted

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.