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

[Mark Bellon]

Mark Bellon wrote:

> Olaf Hering wrote:
>
>> On Mon, Aug 08, Mark Bellon wrote:
>>
>>  
>>
>>> Olaf Hering wrote:
>>>   
>>>
>>>> make sure to also claim the range from _start to _end. The firmware on
>>>> my B50 doesnt claim the client memrange.
>>>>
>>>>
>>>>     
>>>
>>> Doesn't the "_start + ((unsigned long) vmlinux_filesize)" in the 
>>> calculation already do that by never allowing an allocation in that 
>>> address range?  Yes, it's unclaimed but it's also not going to be 
>>> around for very long... [pragmatic approach?]
>>>   
>>
>>
>> If the zimage elf range is claimed, nothing else will get this area, and
>> claim_base could remain zero.
>>
>> something like this after of1275_prominit() is done in my zimage.
>> of1275_claim((unsigned int)_start, (unsigned int)(_end - _start), 0)
>>  
>>
> I see your point. but I've got practical issues that I want to avoid:  
> I've got platforms that claim only part of the space south of 4MB and 
> _start is usually 4MB (a hole); starting at zero would not do nice 
> things in some cases. I felt my coding prevents any possibility of 
> problems by simply removing the chance of a collision.
>
> That initrd image is not claimed in your approach and it sits 
> immediately about _end. It would need to be claimed as well.
>
> How about this? Claim everything in the loaded ELF file from _start 
> explicitly with claim_start initialized at _start?
>
> However I still like my approach saving time especially with a huge 
> INITRD.
>
> Listening and thinking,


How about something like this? (haven't tried it yet).

mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: common_initrd.patch
Type: text/x-patch
Size: 2992 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20050808/e09e0fba/attachment.bin