Device tree flattening code not copying properties from blob

Device tree flattening code not copying properties from blob

[Collins, Rod]

[-- Attachment #1.1.1: Type: text/plain, Size: 2377 bytes --]

I have been chasing a problem where a module device driver that uses the
device tree I install, cannot find a compatible match when I know the
device tree has the match for my driver.

 

So I wrote a small module device driver that dumps the device tree
information. I add it to the device driver list using insmod dtdump.ko.
If I add the insmod to the start of the rc (using uCLinux distribution)
file then I get the proper contents. If I add insmod at the end of the
rc file then the device tree is bad.

 

The problem is in the file fdt.c and the function unflatten_dt_node.

 

When the unflattened tree is created the memory is allocated for the
nodes and the property structures, however the pointers are just
inserted into the property structure. The pointers are pointing in the
memory area freed after initialization. This will work if the embedded
__init memory is not freed but freeing this memory ends up with tree
nodes that have invalid properties and thus the device tree is no good.

 

I am working on a fix to the unflatten_dt_node function. Allocate space
for the property name and value and copy them in also as the node name
is done.

 

Does anyone know if there is already a fix for this?

 

Rod Collins

Principal Software Engineer

Saab Sensis Corporation

315-445-5784

rodc-eu1g02Y2shuDvotElmWtJA@public.gmane.org <mailto:rodc-eu1g02Y2shuDvotElmWtJA@public.gmane.org> 

 

 

-
This message is intended only for the addressee and may contain information that is company confidential or privileged.  Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. 
-                                                                                                                                                                                                                                                       

[-- Attachment #1.1.2: Type: text/html, Size: 5898 bytes --]

[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 13229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Device tree flattening code not copying properties from blob

[Grant Likely]

On Wed, Jun 12, 2013 at 3:32 PM, Collins, Rod
<Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> wrote:
>
> I have been chasing a problem where a module device driver that uses the device tree I install, cannot find a compatible match when I know the device tree has the match for my driver.
>
> So I wrote a small module device driver that dumps the device tree information. I add it to the device driver list using insmod dtdump.ko. If I add the insmod to the start of the rc (using uCLinux distribution) file then I get the proper contents. If I add insmod at the end of the rc file then the device tree is bad.
>
> The problem is in the file fdt.c and the function unflatten_dt_node.
>
> When the unflattened tree is created the memory is allocated for the nodes and the property structures, however the pointers are just inserted into the property structure. The pointers are pointing in the memory area freed after initialization. This will work if the embedded __init memory is not freed but freeing this memory ends up with tree nodes that have invalid properties and thus the device tree is no good.

If your fdt blob is getting freed, then you've got a bug. How are you
loading the device tree? Normally the device tree is passed in from
the bootloader and the kernel marks the whole region as reserved.

> I am working on a fix to the unflatten_dt_node function. Allocate space for the property name and value and copy them in also as the node name is done.

unflatten_dt_node is actually doing the right thing. If the dt blob is
in an __init section, then it needs to be copied into non-init memory
before unflattening.

g.

RE: Device tree flattening code not copying properties from blob

[Collins, Rod]

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.

Rod

Rod Collins
Principal Software Engineer
Saab Sensis Corporation
315-445-5784
rodc-eu1g02Y2shuDvotElmWtJA@public.gmane.org



-----Original Message-----
From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On Behalf Of
Grant Likely
Sent: Wednesday, June 12, 2013 12:03 PM
To: Collins, Rod
Cc: devicetree-discuss
Subject: Re: Device tree flattening code not copying properties from
blob

On Wed, Jun 12, 2013 at 3:32 PM, Collins, Rod
<Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> wrote:
>
> I have been chasing a problem where a module device driver that uses
the device tree I install, cannot find a compatible match when I know
the device tree has the match for my driver.
>
> So I wrote a small module device driver that dumps the device tree
information. I add it to the device driver list using insmod dtdump.ko.
If I add the insmod to the start of the rc (using uCLinux distribution)
file then I get the proper contents. If I add insmod at the end of the
rc file then the device tree is bad.
>
> The problem is in the file fdt.c and the function unflatten_dt_node.
>
> When the unflattened tree is created the memory is allocated for the
nodes and the property structures, however the pointers are just
inserted into the property structure. The pointers are pointing in the
memory area freed after initialization. This will work if the embedded
__init memory is not freed but freeing this memory ends up with tree
nodes that have invalid properties and thus the device tree is no good.

If your fdt blob is getting freed, then you've got a bug. How are you
loading the device tree? Normally the device tree is passed in from the
bootloader and the kernel marks the whole region as reserved.

> I am working on a fix to the unflatten_dt_node function. Allocate
space for the property name and value and copy them in also as the node
name is done.

unflatten_dt_node is actually doing the right thing. If the dt blob is
in an __init section, then it needs to be copied into non-init memory
before unflattening.

g.
-
This message is intended only for the addressee and may contain information that is company confidential or privileged.  Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. 
-                                                                                                                                                                                                                                                       

Re: Device tree flattening code not copying properties from blob

[Grant Likely]

On Wed, Jun 12, 2013 at 6:33 PM, Collins, Rod
<Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> 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.

Re: Device tree flattening code not copying properties from blob

[Walter Goossens]

On 06/12/13 20:23, Grant Likely wrote:
> On Wed, Jun 12, 2013 at 6:33 PM, Collins, Rod
> <Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> 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?

Walter
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

RE: [Nios2-dev] Device tree flattening code not copying propertiesfrom blob

[Collins, Rod]

It seems to be that any section that blob is loaded into except the
--init section would be ok. The main purpose is to keep it in accessible
memory.

Walter, what are your concerns with moving it to a non __init memory
section? Seems like all of the other approaches essentially are doing
that.

Rod

Rod Collins
Principal Software Engineer
Saab Sensis Corporation
315-445-5784
rodc-eu1g02Y2shuDvotElmWtJA@public.gmane.org


-----Original Message-----
From: nios2-dev-bounces-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH@public.gmane.org
[mailto:nios2-dev-bounces-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH@public.gmane.org] On Behalf Of Walter
Goossens
Sent: Wednesday, June 12, 2013 3:13 PM
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: nios2-dev
Subject: Re: [Nios2-dev] Device tree flattening code not copying
propertiesfrom blob

On 06/12/13 20:23, Grant Likely wrote:
> On Wed, Jun 12, 2013 at 6:33 PM, Collins, Rod 
> <Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> 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?

Walter
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

_______________________________________________
Nios2-dev mailing list
Nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH@public.gmane.org
http://sopc.et.ntust.edu.tw/cgi-bin/mailman/listinfo/nios2-dev
-
This message is intended only for the addressee and may contain information that is company confidential or privileged.  Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. 
-                                                                                                                                                                                                                                                       

RE: Device tree flattening code not copying properties from blob

[Collins, Rod]

Grant

What is considered the correct way to include the blob in the build so
that it is not removed?

Rod

Rod Collins
Principal Software Engineer
Saab Sensis Corporation
315-445-5784
rodc-eu1g02Y2shuDvotElmWtJA@public.gmane.org


-----Original Message-----
From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On Behalf Of
Grant Likely
Sent: Wednesday, June 12, 2013 12:03 PM
To: Collins, Rod
Cc: devicetree-discuss
Subject: Re: Device tree flattening code not copying properties from
blob

On Wed, Jun 12, 2013 at 3:32 PM, Collins, Rod
<Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> wrote:
>
> I have been chasing a problem where a module device driver that uses
the device tree I install, cannot find a compatible match when I know
the device tree has the match for my driver.
>
> So I wrote a small module device driver that dumps the device tree
information. I add it to the device driver list using insmod dtdump.ko.
If I add the insmod to the start of the rc (using uCLinux distribution)
file then I get the proper contents. If I add insmod at the end of the
rc file then the device tree is bad.
>
> The problem is in the file fdt.c and the function unflatten_dt_node.
>
> When the unflattened tree is created the memory is allocated for the
nodes and the property structures, however the pointers are just
inserted into the property structure. The pointers are pointing in the
memory area freed after initialization. This will work if the embedded
__init memory is not freed but freeing this memory ends up with tree
nodes that have invalid properties and thus the device tree is no good.

If your fdt blob is getting freed, then you've got a bug. How are you
loading the device tree? Normally the device tree is passed in from the
bootloader and the kernel marks the whole region as reserved.

> I am working on a fix to the unflatten_dt_node function. Allocate
space for the property name and value and copy them in also as the node
name is done.

unflatten_dt_node is actually doing the right thing. If the dt blob is
in an __init section, then it needs to be copied into non-init memory
before unflattening.

g.
-
This message is intended only for the addressee and may contain information that is company confidential or privileged.  Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. 
-                                                                                                                                                                                                                                                       

Re: Device tree flattening code not copying properties from blob

[Grant Likely]

On Thu, Jun 13, 2013 at 11:49 PM, Collins, Rod
<Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> wrote:
> Grant
>
> What is considered the correct way to include the blob in the build so
> that it is not removed?

Don't put it in an __init section.  :-p

However, I realized that the .dtb.S target does exactly that under the
assumption that multiple blobs may be linked into the kernel, but only
one actually used. The correct thing to do in your case is indeed copy
the blob at boot.

Actually, the best thing to do is to not link the dtb into the kernel
at all. Either append it as another payload or pass it in via the
bootloader and make the kernel mark the dtb memory as reserved.
Statically linking into the kernel proper means the kernel needs to be
rebuilt for each and every target which neuters one of the reasons for
using device tree in the first place.

g.

RE: Device tree flattening code not copying properties from blob

[Collins, Rod]

Grant

That makes perfect sense, but I find that the DTB is included in the
vmlinux.lds.h file which lives in source/include/asm-generic.

This seems to always want to put the dtb in the init section which gets
removed. To fix this the asm-generic/vmlinux.lds.h file would need to be
changed.

Forgive me ahead of time for not understanding all of the versions and
the intents. We are using the 3.7 kernel in the uCLinux distribution.

It seems to me that it should always be added to rodata when linked in,
unless it is passed as a command line parameter?

Rod


/* init and exit section handling */
#define INIT_DATA
\
	*(.init.data)
\
	DEV_DISCARD(init.data)
\
	CPU_DISCARD(init.data)
\
	MEM_DISCARD(init.data)
\
	KERNEL_CTORS()
\
	MCOUNT_REC()
\
	*(.init.rodata)
\
	FTRACE_EVENTS()
\
	TRACE_SYSCALLS()
\
	DEV_DISCARD(init.rodata)
\
	CPU_DISCARD(init.rodata)
\
	MEM_DISCARD(init.rodata)
\
	KERNEL_DTB()

#define RO_DATA(align)  RO_DATA_SECTION(align)

Change to

#define RO_DATA(align)  RO_DATA_SECTION(align) \
	KERNEL_DTB()

Rod Collins
Principal Software Engineer
Saab Sensis Corporation
315-445-5784
rodc-eu1g02Y2shuDvotElmWtJA@public.gmane.org


-----Original Message-----
From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On Behalf Of
Grant Likely
Sent: Thursday, June 13, 2013 7:48 PM
To: Collins, Rod
Cc: devicetree-discuss
Subject: Re: Device tree flattening code not copying properties from
blob

On Thu, Jun 13, 2013 at 11:49 PM, Collins, Rod
<Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> wrote:
> Grant
>
> What is considered the correct way to include the blob in the build so

> that it is not removed?

Don't put it in an __init section.  :-p

However, I realized that the .dtb.S target does exactly that under the
assumption that multiple blobs may be linked into the kernel, but only
one actually used. The correct thing to do in your case is indeed copy
the blob at boot.

Actually, the best thing to do is to not link the dtb into the kernel at
all. Either append it as another payload or pass it in via the
bootloader and make the kernel mark the dtb memory as reserved.
Statically linking into the kernel proper means the kernel needs to be
rebuilt for each and every target which neuters one of the reasons for
using device tree in the first place.

g.
-
This message is intended only for the addressee and may contain information that is company confidential or privileged.  Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. 
-                                                                                                                                                                                                                                                       

Re: Device tree flattening code not copying properties from blob

[Grant Likely]

On Wed, 12 Jun 2013 21:12:39 +0200, Walter Goossens <waltergoossens-CmkmPbn3yAE@public.gmane.org> wrote:
> On 06/12/13 20:23, Grant Likely wrote:
> > On Wed, Jun 12, 2013 at 6:33 PM, Collins, Rod
> > <Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> 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.

Re: Device tree flattening code not copying properties from blob

[Walter Goossens]

On 06/15/13 15:14, Grant Likely wrote:
> On Wed, 12 Jun 2013 21:12:39 +0200, Walter Goossens <waltergoossens-CmkmPbn3yAE@public.gmane.org> wrote:
>> On 06/12/13 20:23, Grant Likely wrote:
>>> On Wed, Jun 12, 2013 at 6:33 PM, Collins, Rod
>>> <Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> 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.
Nios2 also supports passing a devicetree through u-boot if I'm not mistaken.
> 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.
dd-ing the dtb onto the end sounds nice.
> 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.
Yes I know, it's just one of the supported ways of passing the
devicetree. It's just easier to explain to new users who might not have
much experience with linux/uboot.
Thanks for all the advice!

Walter

> g.
>
>

Re: Device tree flattening code not copying properties from blob

[Grant Likely]

On Sat, Jun 15, 2013 at 7:59 PM, Walter Goossens <waltergoossens-CmkmPbn3yAE@public.gmane.org> wrote:
> On 06/15/13 15:14, Grant Likely wrote:
>> 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.
>
> Nios2 also supports passing a devicetree through u-boot if I'm not mistaken.

Okay, good. I'm glad to hear it.

>> 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.
>
> dd-ing the dtb onto the end sounds nice.

:-)

>> 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.
>
> Yes I know, it's just one of the supported ways of passing the
> devicetree. It's just easier to explain to new users who might not have
> much experience with linux/uboot.
> Thanks for all the advice!

It's /sort of/ supported. That mechanism isn't intended to be the
primary way of getting a dtb into the kernel. If it is used, the
assumption is that the kernel may have multiple DTBs to choose from,
and once it chooses the correct dtb, it copies it into safe memory
before all the __init sections get discarded.

As an aside, I'm also plan to use that facility as part of the DT
selftest code so that it can load an overlay of testcase data at
runtime, and then discard it again at init section removal.

g.

Re: Device tree flattening code not copying properties from blob

[Grant Likely]

On Fri, Jun 14, 2013 at 4:55 PM, Collins, Rod
<Rod.Collins-eu1g02Y2shuDvotElmWtJA@public.gmane.org> wrote:
> Grant
>
> That makes perfect sense, but I find that the DTB is included in the
> vmlinux.lds.h file which lives in source/include/asm-generic.
>
> This seems to always want to put the dtb in the init section which gets
> removed. To fix this the asm-generic/vmlinux.lds.h file would need to be
> changed.
>
> Forgive me ahead of time for not understanding all of the versions and
> the intents. We are using the 3.7 kernel in the uCLinux distribution.
>
> It seems to me that it should always be added to rodata when linked in,
> unless it is passed as a command line parameter?

Linking the DTB into the kernel-proper (by that I mean the vmlinux
binary) is actually not the typical use case for DT. Normally the DTB
is either passed in by the bootloader (preferred), or attached (not
linked) to the kernel binary as part of the zImage wrapper (for
backwards compatibility with non-DT enabled bootloaders). Both PowerPC
and ARM support both methods. Linking into the vmlinux image has
problems that I've discussed in my other reply. If the linked-in
method is used, then it is *required* for the kernel to copy it into
safe memory before unflattening the tree. The assumption with the
dtb.S target is that multiple DTBs may be linked into the kernel, but
only one will actually get used. In that situation the kernel should
discard all the unused DTB data. The easiest way to do that is put all
the DTBs in the __init rodata section and then copy only the DTB that
is actually used.

g.