[PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset

Kumar Gala galak at kernel.crashing.org
Thu Apr 3 17:47:31 EST 2008


On Apr 3, 2008, at 1:34 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>>> For a kdump kernel, at least for 64-bit, the physical address has to
>>> be 32MB.  There is no other choice, so there is no possibility of
>>> confusion.
>>
>> But how do you know a vmlinux image is for kdump or not?
>
> By looking at the ELF headers -- either the first PT_LOAD segment or
> the .text section -- and seeing whether the start address is
> 0xc000000002000000 or not.

fair point.

>>> For 85xx, would it be possible to have the kernel figure out what
>>> physical address it has been loaded at, and use that as the base
>>> address, rather than having the base address set at compile time?
>>
>> Yes, that is what CONFIG_RELOCATABLE is all about.
>
> Is there any reason to have that as an option, rather than just always
> doing that?

Concerned about runtime performance of __va() and __pa().

>>> That would solve my objection since it would mean that there would  
>>> no
>>> longer be two things that had to be kept in sync.  You could pass  
>>> any
>>> value to wrapper/mkimage (subject to constraints such as it has to  
>>> be
>>> a multiple of 256M) and it would work.  That value could even come
>>> from a config option in the case where wrapper is invoked as part of
>>> the kernel build, but that config option shouldn't affect anything  
>>> at
>>> all in the vmlinux.
>>
>> Ok, but I still think the issues exists when we config PHYSICAL_START
>> to non-zero and CONFIG_RELOCATABLE=n.  Ideally we get set the phys
>> address the PHDR, but I'm not sure how to get the linker to do that.
>
> If we can do that then the wrapper script can dig it out and pass it
> to mkimage, which would solve the problem.

Ok, so on Segher's recommendation I looked at 'AT' and posted a patch  
that uses that so now regardless of the kernel the PT_LOAD PHDR will  
have the physical address set properly.

So now we can look at the vmlinux and determine the physical offset.   
The question is how best to do that.  Here are the options I see:
* readelf, grep and parse output
* objdump grep and parse output
* simple C program that read's the elf and reports back

[looking for suggestion on what direction you want to take]

The other questions is if we'd ever have a vmlinux with more than one  
PT_LOAD PHDR.  If so which one do we use (the one with the lowest  
physical address)?

- k



More information about the Linuxppc-dev mailing list