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.
Quoted 10 lines · Jon Masters
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.
Quoted 8 lines · Benjamin Herrenschmidt
Quoted 5 lines · Jon Masters
Hi all,
Would someone (Tom, Matt, Cort, Paul or Dan?) please tell me what the status is of
bi_recs?
Quoted 7 lines
Quoted 5 lines
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_recswere supposed to evolve in that direction but that never happened.
Right. That needs fixing.
Quoted 2 lines
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 ;-).
Quoted 1 line
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).
Quoted 4 lines
so that instead of tapping kenrel
globals directly and generating structdevice_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 bypassprom_init.
I thought about that as an approach. Great - you do it already how I thought.
Quoted 4 lines
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.
Quoted 4 lines
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_infostructures 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 8 lines
Quoted 1 line
But on the other hand, I've given up a long time ago trying to
enforce any
Quoted 1 line
kind of sane model on ppc32 because the embedded folks only care
about having
Quoted 1 line
a quick ugly broken hack to work with their board, thus the
explosion of
Quoted 1 line
various incompatible
boot_infostructures that we have nowadays.
Quoted 7 lines
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
Quoted 9 lines · Kumar Gala
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.
Quoted 3 lines · Benjamin Herrenschmidt
Quoted 1 line · Kumar Gala
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.
Quoted 3 lines
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 :-).
Quoted 1 line
But that's just a suggestion...
Taken.
Jon.
PATCH 1/1 for linuxppc-2.4 tree: adds Memec 2VP7 / 2VP4 board support
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
Quoted 11 lines · Jon Masters
Quoted 4 lines · Benjamin Herrenschmidt
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.
Quoted 12 lines
ppc64
head.Sand startup looks quite fun. After jumping through a few hoops you eventually end up inprom_initand start setting up the OF device-tree (btw it looks like at least one call toprom_panicdoesn'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 usebi_recsto 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.
Quoted 2 lines
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.
Quoted 1 line · Benjamin Herrenschmidt
bi_recshave 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.
Quoted 1 line
head.Sexplains 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).
Quoted 2 lines
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.
Quoted 16 lines · Kumar Gala
Quoted 8 lines
Quoted 1 line
But on the other hand, I've given up a long time ago trying to
enforce any
Quoted 1 line
kind of sane model on ppc32 because the embedded folks only care
about having
Quoted 1 line
a quick ugly broken hack to work with their board, thus the
explosion of
Quoted 1 line
various incompatible
boot_infostructures that we have nowadays.Quoted 7 lines
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.
Quoted 8 lines
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. :)
Signature · 2 lines
Tom Rini http://gate.crashing.org/~trini/
Quoted 32 lines · Tom Rini
Quoted 18 lines · Kumar Gala
Quoted 18 lines
Quoted 2 lines
But on the other hand, I've given up a long time ago trying to
enforce any
Quoted 2 lines
kind of sane model on ppc32 because the embedded folks only care
about having
Quoted 2 lines
a quick ugly broken hack to work with their board, thus the
explosion of
Quoted 2 lines
various incompatible
boot_infostructures 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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 8 lines
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...
Quoted 6 lines
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
Quoted 1 line · Pantelis Antoniou
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.
Quoted 2 lines
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 :-).
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 4 lines · Jon Masters
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
Quoted 8 lines · Dan Malek
Quoted 4 lines · Jon Masters
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.
Quoted 6 lines
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. :)
Signature · 2 lines
Tom Rini http://gate.crashing.org/~trini/
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
Not really. I already explained on the U-Boot list why such a patch will not make it into U-Boot. Please read _all_ of the discussion before wasting your time.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: [email protected] As far as we know, our computer has never had an undetected error. -- Weisert
Quoted 1 line · Pantelis Antoniou
Tom Rini wrote:
[snip]
Quoted 9 lines
Quoted 8 lines
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]
Quoted 3 lines
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]
Quoted 3 lines
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.
Signature · 2 lines
Tom Rini http://gate.crashing.org/~trini/
Quoted 21 lines · Tom Rini
Quoted 1 line · Pantelis Antoniou
Tom Rini wrote:
[snip]
Quoted 9 lines
Quoted 8 lines
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]
Quoted 3 lines
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.
Quoted 7 lines
[snip]
Quoted 3 lines
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.
Same here, I see that no one has raised a technical issue with the flattened device tree method. Since it is a working mechanism AND it unifies the arch, it's the clear choice over reinventing the wheel. All we need is an implementation.
-Matt
Quoted 15 lines · Matt Porter
Quoted 4 lines · Tom Rini
Quoted 1 line · Pantelis Antoniou
Tom Rini wrote:
[snip]
Quoted 1 line
Quoted 1 line
I've been thinking about it, and I do believe that Ben's=20
flattened OF
Quoted 1 line
Quoted 1 line
Quoted 1 line
tree wins the "show me the code" race, so lets go that way.=A0=20=
I'll add in
Quoted 1 line
Quoted 1 line
Quoted 1 line
that for most platforms we'll want to build up the tree at=20
compile time,
Quoted 1 line
Quoted 1 line
Quoted 1 line
but U-Boot, and anything else smart enough can pass one in for=20=
real.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 3 lines
Jon, I look forward to your patch. :)
Allow me, to cut in and plug my own thing.
[snip]
Quoted 1 line
I just create an argv of all the environment variables of the=20
firmware
Quoted 1 line
Quoted 1 line
and I pass the psysical address of that NULL terminated argv =
array
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
to the kernel command line like so... "u-boot-env=3D0x0f000f00".
The 'problem' I forsee with this is that we still have two methods=20=
for
Quoted 1 line
getting stuff in, an OF tree or env array.=A0 If we got with a fake =
OF
Quoted 11 lines
Quoted 4 lines
tree, we have just one method and we can always use it.
[snip]
Quoted 1 line
I know this is the Nth time this discussion is taking place bu=20
IMO something
Quoted 1 line
Quoted 1 line
must be finally decided. I don't really care if my solution will=20=
be selected
Quoted 3 lines
Quoted 1 line
as long as something is at last selected.
As far as I'm concerned, unless some horrible problem springs up =
that
Quoted 6 lines
Quoted 1 line
we can't resolve, this is it.
Same here, I see that no one has raised a technical issue with the
flattened device tree method. Since it is a working mechanism AND it unifies the arch, it's the clear choice over reinventing the wheel. All we need is an implementation.
I'm in agreement with Matt and Tom. We should only have one solution=20 to this problem.
- kumar
Quoted 4 lines · Matt Porter
Same here, I see that no one has raised a technical issue with the flattened device tree method. Since it is a working mechanism AND it unifies the arch, it's the clear choice over reinventing the wheel. All we need is an implementation.
Well don't go writing it as I'll get there sometime soon - just need chance to fit it in with worky stuff this week. If you don't see a patch from me by the weekend then you're welcome to hit me with large pointy sticks at next OLS.
Jon.
Jon,
Do you mind writing up a bit about what you have learned on the ppc64 side and sending that to the list. I'm significantly deficient on my open firmware knowledge. (If you do this I might be able to help or find help to get this moved into ppc32)
thanks
- kumar
Quoted 3 lines · In message <[email protected]> you wrote:
I too need to access and use firmware variables from Linux and the solution I came up is extremely simple.
...and known to have problems.
Quoted 1 line
P.S. Hope wd is listening in and come forward with his thoughts...
I do, but I won't repeat all the arguments again.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: [email protected] core error - bus dumped