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
r...@saabsensis.com
-----Original Message-----
From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] 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.coll...@saabsensis.com> 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.
-
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
