[Fwd: [PATCH] PPC64: large INITRD causes kernel not to boot]

[Mark Bellon]

Milton Miller wrote:

>
> On Aug 10, 2005, at 10:49 AM, Mark Bellon wrote:
>
>> Milton Miller wrote:
>>
>>>>
>>>> -    printf("\n\rzImage starting: loaded at 0x%x\n\r", 
>>>> (unsigned)_start);
>>>> +    printf("\n\rzImage starting: loaded at 0x%lx\n\r", (unsigned 
>>>> long) _start);
>>>> +
>>>> +    /*
>>>> +     * The first available claim_base must be above the end of the
>>>> +     * the loaded kernel file (_start to _end) and rounded up to a
>>>> +     * nice 1 MB boundary.
>>>> +     */
>>>> +
>>>> +    claim_base = ((((unsigned long) _end) + ONE_MB - 1) / ONE_MB) 
>>>> * ONE_MB;
>>>>
>>>>
>>>
>>> _start and _end here are the linked runtime range of the zImage program
>>> not the kernel image contained therein.  This also contains the
>>> initrd.
>>>
>>> Milton
>>>
>> Exactly. The claim_base needs to start after the kernel and initrd. 
>> Since _end is above the "top" of the initrd it's perfect to use as 
>> the base for the round up calculation for the starting claim_base.
>>
>> mark
>>
>
> My unstated request was to fix the misleading comment.  Change
> "loaded kernel file" to something like "this running program" or
> "image" or something.

I posted an update yesterday with improved comments and a tweak. Thanks 
for the comment. I was a bit unclear in my response.

> Something to be aware of: the program gets loaded at load-base and
> then the sections get moved to their linked area.  It is explicitly
> stated that while the fw has to maintain the elf header, it does
> *NOT* need to worry about overlaping source and desitination.

True, as long as the address returned from claim is not in the middle of 
the image of the loaded kernel wrapper file (which is what was happening).

> In other words, there is an implied copy from elf file loaded into
> ram at ram-base to the _start,_end range that doesn't look for
> overlap.


OK.

>
> milton
>