mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: Mark Bellon <mbellon@mvista.com>
Cc: linux-kernel@vger.kernel.org, linuxppc64-dev@ozlabs.org, akpm@osdl.org
Subject: Re: [PATCH]  PPC64: large INITRD causes kernel not to boot [UPDATE]
Date: Wed, 7 Sep 2005 09:42:13 +1000	[thread overview]
Message-ID: <17182.10581.159598.839256@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <431E1D1A.2090601@mvista.com>

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).

> +	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?

Paul.

  reply	other threads:[~2005-09-06 23:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-06 22:50 Mark Bellon
2005-09-06 23:42 ` Paul Mackerras [this message]
2005-09-06 23:49   ` Mark Bellon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17182.10581.159598.839256@cargo.ozlabs.ibm.com \
    --to=paulus@samba.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=mbellon@mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®