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 >>>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...
