bi_recs

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?

Jon.

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.

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 rewrote prom_init (the interface to OF) 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.

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.

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.

Ben.

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.

quoted

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.

I would be nice to have an extensive and dynamic way to pass info from the bootloader to the kernel.  I believe that Wolfgang has stated he would be willing to change u-boot to match.  I'd be willing to fixup and move Freescale boards over to use something as long as we get u-boot to support it as well.

I've been told that ARM has a solution, in place, to this problem that might always be worth looking at.

- kumar

On Fri, 2004-10-01 at 13:11, Kumar Gala wrote:

I would be nice to have an extensive and dynamic way to pass info from 
the bootloader to the kernel.  I believe that Wolfgang has stated he 
would be willing to change u-boot to match.  I'd be willing to fixup 
and move Freescale boards over to use something as long as we get 
u-boot to support it as well.

I've been told that ARM has a solution, in place, to this problem that 
might always be worth looking at.

I'd rather see you guys sync with what I did on ppc64 and use that 
kind of OF device-tree, we already have all the code for using it
and it would make the mecanism compatible with the prep/chrp/pmac
kernel...

But that's just a suggestion...

Ben.

Benjamin Herrenschmidt wrote:

On Fri, 2004-10-01 at 13:11, Kumar Gala wrote:

quoted

I've been told that ARM has a solution, in place, to this problem that might always be worth looking at.

I asked on their mailing list a while ago in preparation but I think Ben has the best approach.

I'd rather see you guys sync with what I did on ppc64 and use that kind of OF device-tree, we already have all the code for using it
and it would make the mecanism compatible with the prep/chrp/pmac
kernel...

Yeah. I'm going to start ripping through your code at the weekend and figure out how what you've done - not having a nice shiney ppc64 box means I've not yet got an excuse to play with that tree myself. I am however hopefull that my next Powerbook will be a G5 :-).

But that's just a suggestion...

Taken.

Jon.

Hi,

The patch is for 2VP7 or 2VP4 "Virtex-II Pro Development board"
with P160 COMM Module installed.

The supported peripherals are:
- 2x 16x50 compatible UARTs (the 2nd one is on the COMM Module),
- 10/100 Mbit ethernet controller using SGDMA mode
- MTD device for two flash/SRAM chips on the COMM Module (just flash suport)
- 2x16 character LCD
- GPIO (4 LEDs, 3 buttons, DIP switches).

MAC address is supposed to be in the COMM Module's flash. If it is not there
the default (hardcoded) one is used.

The patch relies heavily on the Xilinx Virtex-II Pro support (introduced with
Xilinx ML300 board support).

I know that linuxppc-2.4 is not for patches, but linux-2.4 has no Virtex-II Pro stuff at all.

The patch itself can be found here:
http://source.mvista.com/~ank/memec2vpx.2dot4.04.diff


Best regards,
Andrei Konovalov

On Fri, 01 Oct 2004 12:14:52 +0100, Jon Masters [off-list ref] wrote:

Benjamin Herrenschmidt wrote:

quoted

I'd rather see you guys sync with what I did on ppc64 and use that
kind of OF device-tree, we already have all the code for using it
and it would make the mecanism compatible with the prep/chrp/pmac
kernel...

Yeah. I'm going to start ripping through your code at the weekend and
figure out how what you've done - not having a nice shiney ppc64 box
means I've not yet got an excuse to play with that tree myself. I am
however hopefull that my next Powerbook will be a G5 :-).

Hmmm...

ppc64 head.S and startup looks quite fun. After jumping through a few
hoops you eventually end up in prom_init and start setting up the OF
device-tree (btw it looks like at least one call to prom_panic doesn't
relocate the string it wants to print to real memory - is this what
the comments are referring to out of sheer interest?). I am assuming
that you always expect to see an Open Firmware on ppc64 and simply use
bi_recs to pass accross additional information from the bootloader,
but I've only had a cursory look on the train on the way home from
work this evening so please be gentle.

I'll give this a go through over the weekend and figure out how to get
this hooked in to the ppc32 tree.

Jon.

On Thu, Sep 30, 2004 at 10:11:03PM -0500, Kumar Gala wrote:

quoted

quoted

But on the other hand, I've given up a long time ago trying to 

enforce any

quoted

kind of sane model on ppc32 because the embedded folks only care 

about having

quoted

a quick ugly broken hack to work with their board, thus the 

explosion of

quoted

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.

I would be nice to have an extensive and dynamic way to pass info from 
the bootloader to the kernel.  I believe that Wolfgang has stated he 
would be willing to change u-boot to match.  I'd be willing to fixup 
and move Freescale boards over to use something as long as we get 
u-boot to support it as well.

I've been told that ARM has a solution, in place, to this problem that 
might always be worth looking at.

I know the ARM folks on the list will yell at me, but to be a bit too
simple, it's a linked list of BI_ bits.

I've been thinking about it, and I do believe that Ben's flattened OF
tree wins the "show me the code" race, so lets go that way.  I'll add in
that for most platforms we'll want to build up the tree at compile time,
but U-Boot, and anything else smart enough can pass one in for real.

Jon, I look forward to your patch. :)

-- 
Tom Rini
http://gate.crashing.org/~trini/

ppc64 head.S and startup looks quite fun. After jumping through a few
hoops you eventually end up in prom_init and start setting up the OF
device-tree (btw it looks like at least one call to prom_panic doesn't
relocate the string it wants to print to real memory - is this what
the comments are referring to out of sheer interest?). I am assuming
that you always expect to see an Open Firmware on ppc64 and simply use
bi_recs to pass accross additional information from the bootloader,
but I've only had a cursory look on the train on the way home from
work this evening so please be gentle.

I'll give this a go through over the weekend and figure out how to get
this hooked in to the ppc32 tree.

bi_recs have been removed completely from ppc64. head.S explains
how the entry is done. You can enter the kernel with r5=NULL if
you provide the flattened device-tree in r3. prom_init does just
that in fact (re-enters the kernel with that setup).

Ben.
 

On Sat, 02 Oct 2004 14:35:32 +1000, Benjamin Herrenschmidt
[off-list ref] wrote:

bi_recs have been removed completely from ppc64.

Sorry. I was getting confused by old references in the prom_init stuff
in 2.6.8.1 and couldn't see how it handled systems without OF - but I
was looking at this the wrong way around.

head.S explains how the entry is done.

Yeah. I hadn't looked at how this is actually linked together (I don't
have ppc64 myself remember so I'm just getting up to speed on which bk
tree is which and so on at this stage). I can clearly see the
multiplatform entry stuff now so thanks. It might help for me to build
a kernel and look at it with objdump (which is what I usually do to
figure out layouts).

You can enter the kernel with r5=NULL if
you provide the flattened device-tree in r3.

I'll get there. Just need a bit of time to get familiar with the code
- I'll probably followup with annoying questions later on in the early
hours UK time :-).

Jon.

Tom Rini wrote:

On Thu, Sep 30, 2004 at 10:11:03PM -0500, Kumar Gala wrote:

quoted

quoted

quoted

But on the other hand, I've given up a long time ago trying to

enforce any

quoted

kind of sane model on ppc32 because the embedded folks only care

about having

quoted

a quick ugly broken hack to work with their board, thus the

explosion of

quoted

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.

I would be nice to have an extensive and dynamic way to pass info from the bootloader to the kernel.  I believe that Wolfgang has stated he would be willing to change u-boot to match.  I'd be willing to fixup and move Freescale boards over to use something as long as we get u-boot to support it as well.

I've been told that ARM has a solution, in place, to this problem that might always be worth looking at.

I know the ARM folks on the list will yell at me, but to be a bit too
simple, it's a linked list of BI_ bits.

I've been thinking about it, and I do believe that Ben's flattened OF
tree wins the "show me the code" race, so lets go that way.  I'll add in
that for most platforms we'll want to build up the tree at compile time,
but U-Boot, and anything else smart enough can pass one in for real.

Jon, I look forward to your patch. :)

Allow me, to cut in and plug my own thing.

If you follow the u-boot-users list, you'll know that some time
ago there was a similar discussion.

I too need to access and use firmware variables from Linux
and the solution I came up is extremely simple.

I just create an argv of all the environment variables of the firmware
and I pass the psysical address of that NULL terminated argv array
to the kernel command line like so... "u-boot-env=0x0f000f00".

I have working patches for u-boot, the kernel parser, a kernel /proc interface
for accessing them and also some patches for busybox which make access
easier as well as supporting saving them to non volatile storage.

I know this is the Nth time this discussion is taking place bu IMO something
must be finally decided. I don't really care if my solution will be selected
as long as something is at last selected.

Regards

Pantelis

P.S. Hope wd is listening in and come forward with his thoughts...

I just create an argv of all the environment variables of the firmware
and I pass the psysical address of that NULL terminated argv array
to the kernel command line like so... "u-boot-env=0x0f000f00".

This would be a variation of the "human readable ASCII format"
technique, right?  I had once ventured to offer my opinion that this
would be a technique that could work for all architectures, which is
a big plus, IMO.   My mistake was suggesting XML, which I think
was [mis]understood by some as requiring a lot more than a few
extra "</" type characters.  I'm offering my opinion not as an expert
but as someone who not too long ago tried to puzzle through the
bootloader/kernel interface and found it unnecessarily obscure.  I
think an ASCIIZ string array of some sort would be immediately
obvious and thus highly maintainable by all.

Mark Chambers

On Mon, 04 Oct 2004 09:07:20 +0300, Pantelis Antoniou [off-list ref] wrote:

Allow me, to cut in and plug my own thing.

Yeah cool. btw, I looked at the ppc64 stuff (having eventually
realised I need to be using the bk tree for everything ppc64 rather
than 2.6.8.1) and I see what benh is getting at now - so I am figuring
out the best way to proceed on that front. None of my boards support
2.6 yet so I either fix that this week or get up and running with 2.4
first. Anyway, I'm working on it in my spare time.

If you follow the u-boot-users list, you'll know that some time
ago there was a similar discussion.

I don't, but I will sign up to the list at some point. Currently I use
my own firmware as I was too lazy to go figure out the ins and outs of
uboot :-).

I just create an argv of all the environment variables of the firmware
and I pass the psysical address of that NULL terminated argv array
to the kernel command line like so... "u-boot-env=0x0f000f00".

I think that's an approach which works up to a point. It's nice to
have a hierachy of devices like with OF because then we can infer
things like order of devices on a bus that need to be shutdown for a
suspend. This can be done as a flat list but I the reason ben put me
off my original idea of going with tagged records is that OF is
clearly the better approach.

I have working patches for u-boot, the kernel parser, a kernel /proc
interface for accessing them and also some patches for busybox

That's great. So seriously worth looking at then.

I know this is the Nth time this discussion is taking place bu IMO

So we probably need to decide. I think Mark's XML idea also works, but
I don't see anything wrong with a flattened OF type tree either since
it's ASCII strings also, just layed out in a slightly more involved
fashion than having a long list of parameters.

I'm going to get this OF thing sorted anyway because it's worth having
that option - but I'm indifferent towards what is ultimately decided
(as long as something is agreed upon). If we went with a solution such
as yours then I would prefer Mark's idea of a structured set of data.
This way I can say which PCI bridge device X lives behind in a nicer
fashion.

Blah.

Jon.

On Mon, Oct 04, 2004 at 09:07:20AM +0300, Pantelis Antoniou wrote:

Tom Rini wrote:

[snip]

quoted

I've been thinking about it, and I do believe that Ben's flattened OF
tree wins the "show me the code" race, so lets go that way.  I'll add in
that for most platforms we'll want to build up the tree at compile time,
but U-Boot, and anything else smart enough can pass one in for real.

Jon, I look forward to your patch. :)

Allow me, to cut in and plug my own thing.

[snip]

I just create an argv of all the environment variables of the firmware
and I pass the psysical address of that NULL terminated argv array
to the kernel command line like so... "u-boot-env=0x0f000f00".

The 'problem' I forsee with this is that we still have two methods for
getting stuff in, an OF tree or env array.  If we got with a fake OF
tree, we have just one method and we can always use it.

[snip]

I know this is the Nth time this discussion is taking place bu IMO something
must be finally decided. I don't really care if my solution will be selected
as long as something is at last selected.

As far as I'm concerned, unless some horrible problem springs up that
we can't resolve, this is it.

-- 
Tom Rini
http://gate.crashing.org/~trini/

On Oct 4, 2004, at 8:45 AM, Jon Masters wrote:

I think that's an approach which works up to a point. It's nice to
have a hierachy of devices like with OF because then we can infer
things like order of devices on a bus that need to be shutdown for a
suspend.

The problem with a hierarchy of devices is that isn't the kind of
information we need in an embedded system.  With the embedded
system, you have a pretty good idea what you have.  We need
_environment_ information, such as MAC addresses, memory sizes
and other information tidbits are are likely to vary within an embedded
system.  This is something an OF tree doesn't give us.

The OF tree is great for workstations or other highly configurable
systems where you don't know what kind of device is plugged into
a PCI bus and you have an OF function to initialize that device.
When you have a bunch of integrated peripherals, you know they
are present and you need unique configuration information for
them, not where they are located on the address bus (because
you already know that).

Thanks.


	-- Dan

On Mon, Oct 04, 2004 at 12:43:21PM -0400, Dan Malek wrote:

On Oct 4, 2004, at 8:45 AM, Jon Masters wrote:

quoted

I think that's an approach which works up to a point. It's nice to
have a hierachy of devices like with OF because then we can infer
things like order of devices on a bus that need to be shutdown for a
suspend.

The problem with a hierarchy of devices is that isn't the kind of
information we need in an embedded system.  With the embedded
system, you have a pretty good idea what you have.  We need
_environment_ information, such as MAC addresses, memory sizes
and other information tidbits are are likely to vary within an embedded
system.  This is something an OF tree doesn't give us.

There's nothing saying that what we know to Always Be True must be Put
Into The Tree.  We can just have say, /ethN/mac for the mac address we
yank out of firmware somehow, but leave the addresses we know as part of
the OCP table, or whatever.

No one is saying we have to have a tree that fully describes every bit
of the system.  Just a tree that describes what we don't know at compile
time.  The tree for what we know is in OCP already. :)

-- 
Tom Rini
http://gate.crashing.org/~trini/