[U-Boot-Users] Open Firmware support questions

[Jon Loeliger]

On Mon, 2006-10-09 at 08:36, Jerry Van Baren wrote:
> Hi All,

Hi Jerry,

> I've been working with the u-boot OF support and have some questions, 
> but don't know who to ask.

Well, several of us (Matt, myself, Mark Greer, Vitaly, etc)
might be able to help some.

> It appears that Pantelis Antoniou submitted the original ft_build.[ch] 
> code <http://patchwork.ozlabs.org/linuxppc/patch?id=2238> but there is 

Yes.

> no copyright or license information in the files.  Are these files his 
> or did they come from somewhere else?

He wrote them and made them freely available.

> My current state of affairs (not quite ready for prime time) is in:
> http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary

Cool.

> Things I'm working on:
> * Added a "of" command to dump the blob
>    * Works well enough but is not in its final form
>    * Required a change to vsprintf to parse a "ll" (long long) attribute
>        as well as the existing "q" attribute for 64 bit entries.

Changes like that were submitted to the list here
last January by myself, and then by Matt McClintock
around May, (IIRC), and can currently be found in
various trees supporting OF concepts such as his tree
on opensource.freescale.com and mine on jdl.com,
called u-boot-86xx. (It also has 85xx bits in it too.)


>    * Printing a 64 bit entry (example: interrupt "reg" value has two 32
>        bit entries) doesn't work properly.  Example print:
>          interrupt-controller at f8200000 {
>              linux,phandle = <0xf8200000>;
>              #address-cells = <0x00000000>;
>              #interrupt-cells = <0x00000002>;
>              interrupt-controller;
>              reg = <0x00000000f8200004>;
>              built-in;
>              device_type = "pci-pic";
>          };
>        The reg value
>          <0x00000000f8200004>
>        should print
>          <0xf8200000f8200004>
>        or, better(?),
>          <0xf8200000 f8200004>
>        The "better" format listed above is how it appears in the *.dts
>        tree definition, but the ft_dump.c routine doesn't appear to do
>        that format.  It sees the size value of 8 and prints it as a
>        single long long rather than two longs (should be just a
>        formatting issue, but currently the print is broken).  Note that
>        the tree itself appears to be OK, looking at the ASM output file.

You might compare your support here with what Matt and I
have made available too.

> * Looking at improving(?) the build mechanism
>    * Use the "asm" output format rather than a binary dump and then
>        regeneration via xxd.

We've removed the binary parts out of U-Boot entirely.
It now downloads the .dtb files directly.

>    * My thought (unimplemented as of yet) is to append "_of" to the
>        configuration so "PQ2FADS-ZU_lowboot_config" would become
>        "PQ2FADS-ZU_lowboot_config_of" for the OF version.  The
>        configuration mechanism would then add the definition
>          FTOBJS  := pq2fads.o
>        to the "include/config.mk" file.
>    * Questions:
>      * Is the "_of" tag reasonable or is there a better way?  I'm
>          assuming we don't want to force everybody with an ADS-type board
>          over to using OF.
>      * Where should we put the original *.dts files?  I picked up the
>          original mpc8260ads.dts file from the kernel source, Vitaly
>          Bordug's repository:
>            linux-2.6-PQ/arch/powerpc/boot/dts/mpc8272ads.dts 

If Vitaly isn't coordinating with us, we'll need
to smack him around some. :-)

>          I forgot what the agreement ended up being for ownership between
>          the kernel people and Wolfgang (if there was any agreement ;-).
> gvb

Well, if you managed to coordinate your patches
with the work Matt, Vitaly and I have been doing,
it would be much appreciated!

Thanks,
jdl