LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Martin Hinner <martin@hinner.info>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Loading kernel on MPC86x
Date: Mon, 26 Aug 2013 12:14:09 -0500	[thread overview]
Message-ID: <1377537249.3033.26.camel@snotra.buserror.net> (raw)
In-Reply-To: <CAPVwjkyPKo0SmoEkJttzz0fXrTcyuv7K1nuhOzW9CdGXD+t7_A@mail.gmail.com>

On Sat, 2013-08-24 at 19:15 +0200, Martin Hinner wrote:
> Hello again,
> 
>   just a quick update: I have spent some more time on this and now I
> can boot into kernel (it works even with initramfs and simple assembly
> HelloWorld, so it's time to compile userland now). The problem was
> that kernel must be at location 0. Another problem was that interrupts
> got re-enabled during execution of my bootloader (I am doing some
> syscalls -> goes  to Cisco rom),

Do you mean you're calling into the rom after Linux has already started
executing?  That's not normal for 8xx.

>  otherwise it crashed randomly. And
> finally it seems that stack must be < 8M. After this kernel boots.
> 
> Anyway, I would still appreciate clarification on vmlinux:__start
> entry conditions:
> 
> - must be loaded at 0 (but why arch/powerpc/boot/main.c has option to
> allocate space for kernel at nonzero addr ?)

arch/powerpc/boot/main.c is not just for 8xx.

> - stack? Does it really have to be < 8M ?

The stack is allocated by the kernel.  It shouldn't matter what is in r1
when you initially enter the kernel.

> - interrupts disabled (really ;-) )
> - MSR.PR=0/LE=0/EE=0, but what other bits (RI? IP=0? ME?)
> - IMMR 0xff000000
> - and of course correct entry arguments in registers
> 
> anything else?
> 
> I am also curious why CONFIG_PPC_EARLY_DEBUG_CPM uses
> CONFIG_PPC_EARLY_DEBUG_CPM_ADDR as pointer to transmit SMC buffer and
> not address of CPM/SCM parameter RAM ? TX buffer address can be read
> from SMC parameter RAM. Wouldn't this solution be more portable? At
> least this way I do it when I take over console from Cisco
> startup/rommon.

The point was to keep things as simple as possible (e.g. for use in
temporary handcoded asm as needed).  This is a hacky debugging feature
that assumes you know what you're doing and can set the address to match
what the loader does (and that the loader's choice of address is
static).  If you have an improvement that keeps it simple, feel free to
send a patch.

-Scott

  reply	other threads:[~2013-08-26 17:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-24 14:54 Loading kernel on MPC86x Martin Hinner
2013-08-24 17:15 ` Martin Hinner
2013-08-26 17:14   ` Scott Wood [this message]
2013-08-26 18:29     ` Martin Hinner
2013-08-27  0:39       ` Scott Wood

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=1377537249.3033.26.camel@snotra.buserror.net \
    --to=scottwood@freescale.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=martin@hinner.info \
    /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