kernel course no. 1

kernel course no. 1

[Jure Menart]

Hello,
I am checking kernel source from penguinppc.org (development tree), and try to
boot it... but, when I checked code in head_4xx.h I saw that code from
'_start' doesn't jump to 'start_here' because of 'strange coding' (sorry, but
it really seems strange to me ;-):

	li	r4,MSR_KERNEL
	lis	r3,start_kernel@h
	ori	r3,r3,start_kernel@l
	mtspr	SRR0,r3
	mtspr	SRR1,r4
	rfi /* enable MMU and jump to start_kernel */

In this part it stops... why don't we just use 'bl start_here'? I tried and it
works, but seems strange why would it be so complicated without a reason. Is
there a reason? :-)

Next thing I would like to know is in 'start_here' at the end... it jumps to
function (?) named '2f'. I can't find what is this '2f' (with other words - I
can't figure out, where code continues)?

OK, just one more thing... is there any 'roadmap' or some other kind of
documentation that would describe this early stage of kernel booting? (like at
first it is '_start', which do this and this and then jumps to 'start_here'
which does initizalization of... etc etc).

That would be it, thanks for answeres in advance...
Jure


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: kernel course no. 1

[Benjamin Herrenschmidt]

>
>Hello,
>I am checking kernel source from penguinppc.org (development tree), and
try to
>boot it... but, when I checked code in head_4xx.h I saw that code from
>'_start' doesn't jump to 'start_here' because of 'strange coding' (sorry, but
>it really seems strange to me ;-):
>
>	li	r4,MSR_KERNEL
>	lis	r3,start_kernel@h
>	ori	r3,r3,start_kernel@l
>	mtspr	SRR0,r3
>	mtspr	SRR1,r4
>	rfi /* enable MMU and jump to start_kernel */
>
>In this part it stops... why don't we just use 'bl start_here'? I tried
and it
>works, but seems strange why would it be so complicated without a reason. Is
>there a reason? :-)

Yes, and a big one ! Normally, at that point, you are running with MMU off,
you need to re-enable it before entering the kernel, that's what the "rfi"
does for you when the proper value is set into SRR1.

>Next thing I would like to know is in 'start_here' at the end... it jumps to
>function (?) named '2f'. I can't find what is this '2f' (with other words - I
>can't figure out, where code continues)?

At this point, it disables the MMU. That is it uses the same trick as
above to get the address of the label "2". The writing xb and xf when "x"
is a number means respectively "previous label number x" and "next label
number x". In your case, it loads SRR0 with the address of the label "2:"
just below, SRR1 with an MSR value in which the MMU translations are off,
and then do the rfi.

>OK, just one more thing... is there any 'roadmap' or some other kind of
>documentation that would describe this early stage of kernel booting?
(like at
>first it is '_start', which do this and this and then jumps to 'start_here'
>which does initizalization of... etc etc).
>
>That would be it, thanks for answeres in advance...
>Jure
>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: kernel course no. 1

[Jure Menart]

Hi again,
On Thu, Aug 30, 2001 at 05:29:04PM +0200, Benjamin Herrenschmidt wrote:
> >I am checking kernel source from penguinppc.org (development tree), and try to
> >boot it... but, when I checked code in head_4xx.h I saw that code from
> >'_start' doesn't jump to 'start_here' because of 'strange coding' (sorry, but
> >it really seems strange to me ;-):
> >
> >	li	r4,MSR_KERNEL
> >	lis	r3,start_kernel@h
> >	ori	r3,r3,start_kernel@l
> >	mtspr	SRR0,r3
> >	mtspr	SRR1,r4
> >	rfi /* enable MMU and jump to start_kernel */
> >
> >In this part it stops... why don't we just use 'bl start_here'? I tried and it
> >works, but seems strange why would it be so complicated without a reason. Is
> >there a reason? :-)
>
> Yes, and a big one ! Normally, at that point, you are running with MMU off,
> you need to re-enable it before entering the kernel, that's what the "rfi"
> does for you when the proper value is set into SRR1.

OK, thanks for information (I presumed that it is 'catch' with rfi :-), but
I've got problem with booting my kernel anyway. I was wondering why would
booting stop when this 'rfi' occurs... I was thinking it might be problem with
the stack, but I'm not be sure. I don't know how to tell kernel where the
stack 'lies' in memory (I don't use boot that comes with kernel).
Could problem be somewhere else?

[snip]
> >OK, just one more thing... is there any 'roadmap' or some other kind of
> >documentation that would describe this early stage of kernel booting? (like
> >at first it is '_start', which do this and this and then jumps to
> >'start_here' which does initialization of... etc etc).
?

Thanks for any answers...

best wishes, Jure


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: kernel course no. 1

[Paul Mackerras]

Jure Menart writes:

> OK, thanks for information (I presumed that it is 'catch' with rfi :-), but
> I've got problem with booting my kernel anyway. I was wondering why would
> booting stop when this 'rfi' occurs...

How do you know that it stops there exactly?

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: kernel course no. 1

[Jure Menart]

Hi,
On Mon, Sep 03, 2001 at 08:44:10AM +1000, Paul Mackerras wrote:
> > OK, thanks for information (I presumed that it is 'catch' with rfi :-), but
> > I've got problem with booting my kernel anyway. I was wondering why would
> > booting stop when this 'rfi' occurs...
>
> How do you know that it stops there exactly?

well, I have two LEDs on my board for 'very hardware debug' (I know it's VERY
cheap, but it's very useful too ;-), so I try to turn one LED on before the
jump ('rfi' call) and another at the beginning of 'start_here' procedure. As
you can guess - first LED turned on but second didn't.

Any idea? Could be something wrong with my cross-compiler? Initialization of
MMU? Stack?
I'm pretty much down on this :-(

Regards, Jure


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: kernel course no. 1

[Benjamin Herrenschmidt]

>well, I have two LEDs on my board for 'very hardware debug' (I know it's VERY
>cheap, but it's very useful too ;-), so I try to turn one LED on before the
>jump ('rfi' call) and another at the beginning of 'start_here' procedure. As
>you can guess - first LED turned on but second didn't.
>
>Any idea? Could be something wrong with my cross-compiler? Initialization of
>MMU? Stack?
>I'm pretty much down on this :-(

Beware, when doing such debugging, that the IOs you use for your LED are
actually mapped in virtual memory space before accessing them.

The head.S entry does approximately this:

 - first it calls early_init(). It does so before touching the MMU
or changing anything to the CPU setup, it's still running at whatever
address it was loaded, early_init() handles interaction with the
firmware, like grabbing the OF device-tree on OF based machines.

 - then, it turns off the MMU, sanitize it (clear_bats & flush_tlbs),
prepares a fixed mapping (via BATs on desktop CPUs) of the first
16Mb of RAM at KERNELBASE (0xc0000000). The MMU is prepared but not
yet turned ON.

 - it copies itself down to 0 physical (it's final location). MMU is
off, so it shouldn't take an exception, which is what we want currently.

 - it turns back ON the MMU with the temporary mapping setup above.
At this point, only mappings setup with BATs exist in the MMU, that
is the first 16Mb of RAM mapped at KERNELBASE, and eventually, the
framebuffer via the special "display BAT" hack. Your IOs are not reachable
here, unless you have hacked some mapping for them earlier.

 - With that MMU setup, it enters start_here. That function will setup
the initial stack pointer, setup the remaining CPU features, and calls
machine_init (arch/ppc/kernel/setup.c) and MMU_init (arch/ppc/mm/init.c).
Those must take care of not touching memory above the 16Mb mapped by
the BAT and have no access to any IO but the eventually mapped
framebuffer.

 - Finally, upon exit from MMU setup, is goes back unmapped, setup the
MMU with whatever MMU_init decided, and jumps to start_kernel with
the MMU back on.

So unless you have done some io_block_mapping calls or ioremap calls
inside MMU_init for your board, your LEDs will not be available neither
at start_kernel time. You have to ioremap them before use. You may have
been able to use them while running with MMU on as the entire physical
space is then available, but beware, it is also cacheable which can be
a real problem when dealing with IOs.

Hope this helps,

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: kernel course no. 1

[Jure Menart]

Hi,
> Beware, when doing such debugging, that the IOs you use for your LED are
> actually mapped in virtual memory space before accessing them.
>
> The head.S entry does approximately this:
>
>  - first it calls early_init(). It does so before touching the MMU
> or changing anything to the CPU setup, it's still running at whatever
> address it was loaded, early_init() handles interaction with the
> firmware, like grabbing the OF device-tree on OF based machines.
[snip]

You are talking about arch/ppc/kernel/head.S, but we're using head_4xx.S,
because we are using IBMs 405gp CPU.
In our case 'early_init()' isn't called before start_here(), but in
start_here(). MMU is initialized before even calling start_here() and is
turned on when 'rfi' is called - at this stage our system freezes.

> So unless you have done some io_block_mapping calls or ioremap calls
> inside MMU_init for your board, your LEDs will not be available neither
> at start_kernel time. You have to ioremap them before use. You may have

When I spoke about my 'hardware debugger' (two LEDs on 0x58000000 physical
address - they are controlled by CPLD which is mapped on CS3) - we were
writing on this address after turning on MMU (after 'rfi' call),
apparently this crashed the system. But the question is - how can I write
to this physical address ( = to which virtual address is CS3 mapped)?

Thanks...

Jure


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/