Device tree flattening code not copying properties from blob

[Grant Likely]

On Wed, 12 Jun 2013 21:12:39 +0200, Walter Goossens <waltergoossens at home.nl> wrote:
> On 06/12/13 20:23, Grant Likely wrote:
> > On Wed, Jun 12, 2013 at 6:33 PM, Collins, Rod
> > <Rod.Collins at saabsensis.com> wrote:
> >> The blob is built into the zImage.initramfs.gz image which is put into
> >> flash. The zImage.initramfs.gz is self copied from flash to RAM, then
> >> uncompressed to the running area. I will dig into the location of the
> >> blob in the image and report back.
> > Thanks. If it is appended to the zImage wrapper, then things should be
> > fine (this is the expected way to do when not passed in from the
> > bootloader). If a *.dtb.o target has been used to embedded it into the
> > kernel-proper (vmlinux) then you will have a problem. The *.dtb.S
> > target puts the dtb data into the dtb.init.rodata section which gets
> > discarded.
> >
> > g.
> 
> Hi Grant,
> 
> you're right that's exactly what nios2 is doing...
> I guess we could modify the section where it gets loaded but that sounds
> to me a bit like a hack... What is the best target to look at for a
> clean, similar solution? Arm with CONFIG_ARM_APPENDED_DTB?

My first recommendation would be the way it is described in
Documentation/arm/Booting and Documentation/devicetree/booting-without-of.txt,
by which I mean passing the dtb into the kernel from the bootloader.
This is the preferred approach on both PowerPC and ARM, but I do
undertstand that doesn't work in all situations; such as if there is no
bootloader.

The second choice is to attach it to the kernel image as a
post-processing step. On ARM that is enabled by CONFIG_ARM_APPENDED_DTB
which makes it possible to merely dd the DTB onto the end of the kernel
image. PowerPC uses a slighly different approach where a script takes
care of linking the DTB into the bootwrapper. See the
arch/powerpc/boot/wrapper script for details.

Either way, I don't think it is a good architectural decision to link
the dtb directly into the kernel proper because doing so precludes ever
having a single kernel image bootable on multiple platforms. On an FPGA
platform it is particularly useful not having to rebuild the kernel
every time the FPGA design changes.

g.