[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