[sodaville] [RFC] [PATCH V3 0/2] Adding DTB to architecture independent vmlinux

Dirk Brandewie dirk.brandewie at gmail.com
Thu Nov 11 08:33:11 EST 2010


On 11/10/2010 10:55 AM, Grant Likely wrote:
> On Wed, Nov 10, 2010 at 11:53 AM, H. Peter Anvin<hpa at linux.intel.com>  wrote:
>> On 11/10/2010 11:06 AM, Dirk Brandewie wrote:
>>> On 11/10/2010 10:46 AM, H. Peter Anvin wrote:
>>>> On 11/10/2010 10:52 AM, dirk.brandewie at gmail.com wrote:
>>>>>
>>>>> The DTB's have been moved into the .init.data section.
>>>>
>>>> Writeable?  (As opposed to .init.rodata)?
>>>>
>>>
>>> That is what I remember from the conversation with Grant but I could be
>>> mistaken.  It is simple enough to move as long as the interested parties agree :-)
>>>
>>
>> Obviously.  I'd like to see it readonly unless there is an explicit
>> reason not to, of course.
>
> Definitely it should be ro
>

So I am a little confused (no big surprise :-)

objdump -h vmlinux shows in part:
3 .rodata       000d61b8  c1358000  01358000  00359000  2**5
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
10 __init_rodata 00003a90  c1450be0  01450be0  00451be0  2**5
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .init.text    0002b297  c1488000  01488000  00489000  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .init.data    0001e5e0  c14b32a0  014b32a0  004b42a0  2**5
                   CONTENTS, ALLOC, LOAD, DATA

There is no .init.rodata section that I can find.

It seems like correct place to park the DTB with the other init data in 
.init.data. section by adding the KERNEL_DTB macro to the INIT_DATA macro in 
vmlinux.lds.h.  This picks up the largest number of architectures that use 
vmlinux.lds.h. INIT_DATA gets picked up by

#define INIT_DATA_SECTION(initsetup_align)				\
	.init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {		\
		INIT_DATA						\
		INIT_SETUP(initsetup_align)				\
		INIT_CALLS						\
		CON_INITCALL						\
		SECURITY_INITCALL					\
		INIT_RAM_FS						\
	}



We could go into the INIT_TEXT macro to get the blobs into a RO section but that 
seems kind of wrong.

IMHO if someone starts modifying things in .init.data and expect the changes to 
stick they deserve what they get.

Comments/Suggestions?

--Dirk



More information about the devicetree-discuss mailing list