Pantelis Antoniou panto at
Mon Oct 4 16:07:20 EST 2004

Tom Rini wrote:

>On Thu, Sep 30, 2004 at 10:11:03PM -0500, Kumar Gala wrote:
>>>>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
>>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 
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.



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

More information about the Linuxppc-embedded mailing list