Loading kernel on MPC86x

Loading kernel on MPC86x

[Martin Hinner]

Hi,

  I am trying to load kernel 2.6.39 on MPC86x-based Cisco 8xx router
(I need development platform for another embedded project and this
router was first suitable device I have).

So far I have:

- built crosscompiler
- created simple bootloader based on CILO code that can load ELF
(zImage) into memory, relocate and start it
- Modified Linux kernel arch/powerpc/boot directory so as it can
decompress kernel into memory and start it (__start gets executed)
- Created dts for the device (arch/powerpc/boot/main.c is making
printf via correct device without any hacks)

Most of tasks were accomplished by creating temporary debug output to
cpm-uart and finding problems step-by-step, however I am a bit stuck
with kernel now and I would appreciate some help from someone who has
already done similar task.

Hardware info: The MPC86x has 32MB SDRAM located at 0x00000 and
0x80000000 (I have not checked how this is done but it looks like it's
alias as both memory regions have the same data). IMMR is 0xff000000,
ROM is at 0xfff00000. Initial stack is in first 64kB (I left it as
Cisco rommon has set it up).

I had to modify arch/powerpc/boot/main.c so as it loads kernel to a
different location than 0 and does not overwrite rommon's exception
vectors & stack.

arch/powerpc/boot/main.c starts succesfully kernel (I can see debug
output produced by modified '__start' at
arch/powerpc/kernel/head_8xx.S). Unfortunately call to "bl
initial_mmu" fails (there is no exception that rommon catches,
processor just freezes and as I do not have BDM attached to it I have
no idea what is going wrong).

My feeling is that I should load vmlinux to address 0 as there is no
relocation code anywhere. Is this correct? I can live with it (stack
will be relocated in my bootloader, but before I start doing this work
(more than stack relocation is involved) I would like to make sure it
is really my problem).

Second, I would like to ask what else do I have to set-up before
jumping to arch/powerpc/kernel/head_8xx.S ; is vmlinux sitting at
0x00000 and "temporary" stack at safe place (end of mem) enough ? How
about interrupts ? What if some of them were enabled by Cisco
startup/rommon ?

Do I understand correctly that
arch/powerpc/kernel/head_8xx.S:initial_mmu (and then real mm handler)
sets-up MMU so as I can always access IMMR region and print debug
characters on console? (I am sorry I am not yet familiar with MPC8xx
MMU so the code is a bit confusing for me).

I do not understand how kernel base 0xC0000000 works; kernel is
normally loaded at 0, however all references go to 0xC0000000. Does
initial_mmu set-up "mapping" from 0xC0000000 to 0x00000 or do I miss
anything? When switch from 0 to 0xC0000000 happens?

Maybe a link to document describing how kernel on PowerPC starts would
clarify all my question, but all I have found is focused on using
existing bootloaders (U-Boot) with no detailed description ...

Thank you,

Martin

Re: Loading kernel on MPC86x

[Martin Hinner]

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), 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 ?)
- stack? Does it really have to be < 8M ?
- 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.

Martin

Re: Loading kernel on MPC86x

[Scott Wood]

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

Re: Loading kernel on MPC86x

[Martin Hinner]

On Mon, Aug 26, 2013 at 7:14 PM, Scott Wood <scottwood@freescale.com> wrote:
>> 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.

No, in bootloader. I have disabled interrupts and then later did a
syscall which probably enabled them again. As I have overwritten some
of Cisco ROM data it crashed (at random place).

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

How about making CONFIG_PPC_EARLY_DEBUG_CPM_PARRAM that woud carry
address of SMCx parameter RAM (IMMR+0x04180 on MPC866) and this value
would be used in case CONFIG_PPC_EARLY_DEBUG_CPM_ADDR is zero ? This
would allow kernel hackers to still use
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR for assembly debugging (+legacy use)
and everyone else can use it as a more reliable option that does not
rely on particular bootloader behavior. Early debug is good even for
end-users so as they can send debug output if anything goes wrong at
early stage.

Anyway, difference between _PARRAM and _ADDR is only one lwz
instruction, so I guess it is possible to completely discard _ADDR if
there is no legacy use for it. I am also not sure if this works with
SCC UART ports or only CPM SMC UART.

Martin

Re: Loading kernel on MPC86x

[Scott Wood]

On Mon, 2013-08-26 at 20:29 +0200, Martin Hinner wrote:
> On Mon, Aug 26, 2013 at 7:14 PM, Scott Wood <scottwood@freescale.com> wrote:
> >> 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.
> 
> No, in bootloader. I have disabled interrupts and then later did a
> syscall which probably enabled them again. As I have overwritten some
> of Cisco ROM data it crashed (at random place).
> 
> >> 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.
> 
> How about making CONFIG_PPC_EARLY_DEBUG_CPM_PARRAM

PARAM

> that woud carry address of SMCx parameter RAM (IMMR+0x04180 on MPC866) and this value
> would be used in case CONFIG_PPC_EARLY_DEBUG_CPM_ADDR is zero ? This
> would allow kernel hackers to still use
> CONFIG_PPC_EARLY_DEBUG_CPM_ADDR for assembly debugging (+legacy use)
> and everyone else can use it as a more reliable option that does not
> rely on particular bootloader behavior. Early debug is good even for
> end-users so as they can send debug output if anything goes wrong at
> early stage.

If it only works with CPM1 SMC, then that should be in the name of the
symbol.

> Anyway, difference between _PARRAM and _ADDR is only one lwz
> instruction, so I guess it is possible to completely discard _ADDR if
> there is no legacy use for it. I am also not sure if this works with
> SCC UART ports or only CPM SMC UART.

Given that testing can be a challenge on this old hardware (I don't have
easy access anymore, except maybe one 8xx board), I'd rather leave the
existing mechanism in place if you don't have the ability to test all
these cases.  The ability to not care about what type of CPM serial port
it is, is an important simplification.

-Scott