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

[Mark Bellon <mbellon@mvista.com>]

Paul Mackerras wrote:

> Mark Bellon writes:
>
>  
>
> > Simply put the existing code has a fixed reservation (claim) address and 
> > once the kernel plus initrd image are large enough to pass this address 
> > all sorts of bad things occur. The fix is the dynamically establish the 
> > first claim address above the loaded kernel plus initrd (plus some 
> > "padding" and rounding). If PROG_START is defined this will be used as 
> > the minimum safe address - currently known to be 0x01400000 for the 
> > firmwares tested so far.
> >    
>
> The idea is fine, but I have some questions about the actual patch:
>
>  
>
> > -void *claim(unsigned int, unsigned int, unsigned int);
> > +void *claim(unsigned long, unsigned long, unsigned long);
> >    
>
> What was the motivation for this change?  Since the zImage wrapper is
> a 32-bit executable, int and long are both 32 bits.  I would prefer to
> leave the parameters as unsigned int to force people to realize that
> the parameters are 32 bits (even if said people have been working on
> 64-bit programs recently).
>
>  
The function, claim, is found in prom.c uses longs. The long is the 
usual idiom for hiding a pointer, not an int, so I fixed accordingly. 
I'm open to further discussion of course.

On a 64 bit machine long and int are different sizes. This would make 
things "proper" if things changed in the future.

> > +	claim_base = _ALIGN_UP((unsigned long)_end, ONE_MB);
> > +
> > +#if defined(PROG_START)
> > +	/*
> > +	 * Maintain a "magic" minimum address. This keeps some older
> > +	 * firmware platforms running.
> > +	 */
> > +
> > +	if (claim_base < PROG_START)
> > +		claim_base = PROG_START;
> > +#endif
> >    
>
> This appears to be the meat of the patch, the rest is "cleanup", right?
>  

Correct. The preceding comment explains what is going on. Removing the 
magic numbers seemed like a good idea.

mark

> Paul.
>  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/