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

[Mark Bellon]

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,

mark