Linux boot on a ppc 405

Linux boot on a ppc 405

[Ricardo Severo]

Hi all,

I am working with a Xilinx Virtex II Pro  evaluation board, wich has two 
PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14. 
Until now I've manged to make it uncompress the kernel, but it doesn't boot.
My question is how the initial execution (the one who uncompresses the 
kernel image) transfers the processor to the kernel itself. I've looked 
in the arch/ppc/boot/simple/relocate.S code and it jumps to the position 
0x0 after uncompressing, is it right? The kernel is uncompressed at that 
position?

Thanks,

-- 
Ricardo Ayres Severo <severo.ricardo@gmail.com>

Re: Linux boot on a ppc 405

[David Baird]

On Jan 27, 2008 9:20 AM, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> Hi all,
>
> I am working with a Xilinx Virtex II Pro  evaluation board, wich has two
> PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
> Until now I've manged to make it uncompress the kernel, but it doesn't boot.
> My question is how the initial execution (the one who uncompresses the
> kernel image) transfers the processor to the kernel itself. I've looked
> in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
> 0x0 after uncompressing, is it right? The kernel is uncompressed at that
> position?
>
> Thanks,

It should branch to the beginning of arch/ppc/kernel/head_4xx.S, which
I think was 0x0.

Some things to check are:

- Comment/remove the weak embed_config in arch/ppc/boot/simple/misc-embedded.c
- Did you use ttyUL0 or ttyS0 as your console?

If that fails, you can use XMD to set a breakpoint at 0x0 and then
read the memory to see if it matches up with an objdump of vmlinux.

Re: Linux boot on a ppc 405

[Grant Likely]

On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> Hi all,
>
> I am working with a Xilinx Virtex II Pro  evaluation board, wich has two
> PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
> Until now I've manged to make it uncompress the kernel, but it doesn't boot.
> My question is how the initial execution (the one who uncompresses the
> kernel image) transfers the processor to the kernel itself. I've looked
> in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
> 0x0 after uncompressing, is it right? The kernel is uncompressed at that
> position?

Post your output log please.

If your getting a message that the kernel is uncompressing, but you
don't have any output beyond that then most likely your console is not
setup correctly.  If you've got a debugger, look at memory at the
__log_buf location to see if there are any boot logs there.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Linux boot on a ppc 405

[Ricardo Ayres Severo]

Grant,

my output is the following:

loaded at:     00400000 004E919C

board data at: 00000000 0000007C

relocated to:  00404040 004040BC

zimage at:     00404E2C 004E620A

avail ram:     004EA000 8DA05119


Linux/PPC load: console=ttyUL0,9600

Uncompressing Linux...done.

Now booting the kernel



nothing shows up next.
I tried to look at __log_buf but the debugger doesn't recognize it.
The debugger only knows the code of the part that boots the kernel.
I also tried setting ttyUL0 and ttyS0 for the linux console.
Any ideas of how I can get the real position of __log_buf?

Thanks,

On Jan 27, 2008 7:15 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> > Hi all,
> >
> > I am working with a Xilinx Virtex II Pro  evaluation board, wich has two
> > PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
> > Until now I've manged to make it uncompress the kernel, but it doesn't boot.
> > My question is how the initial execution (the one who uncompresses the
> > kernel image) transfers the processor to the kernel itself. I've looked
> > in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
> > 0x0 after uncompressing, is it right? The kernel is uncompressed at that
> > position?
>
> Post your output log please.
>
> If your getting a message that the kernel is uncompressing, but you
> don't have any output beyond that then most likely your console is not
> setup correctly.  If you've got a debugger, look at memory at the
> __log_buf location to see if there are any boot logs there.
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>



-- 
Ricardo Ayres Severo <severo.ricardo@gmail.com>

RE: Linux boot on a ppc 405

[Stephen Neuendorffer]

You have to look at the System.map file, find the __log_buf symbol, and
then look at the address manually.

Steve

> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Ricardo
Ayres Severo
> Sent: Monday, January 28, 2008 2:53 PM
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux boot on a ppc 405
>=20
> Grant,
>=20
> my output is the following:
>=20
> loaded at:     00400000 004E919C
>=20
> board data at: 00000000 0000007C
>=20
> relocated to:  00404040 004040BC
>=20
> zimage at:     00404E2C 004E620A
>=20
> avail ram:     004EA000 8DA05119
>=20
>=20
> Linux/PPC load: console=3DttyUL0,9600
>=20
> Uncompressing Linux...done.
>=20
> Now booting the kernel
>=20
>=20
>=20
> nothing shows up next.
> I tried to look at __log_buf but the debugger doesn't recognize it.
> The debugger only knows the code of the part that boots the kernel.
> I also tried setting ttyUL0 and ttyS0 for the linux console.
> Any ideas of how I can get the real position of __log_buf?
>=20
> Thanks,
>=20
> On Jan 27, 2008 7:15 PM, Grant Likely <grant.likely@secretlab.ca>
wrote:
> > On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> > > Hi all,
> > >
> > > I am working with a Xilinx Virtex II Pro  evaluation board, wich
has two
> > > PowerPC 405 and I'm trying to boot a vanilla linux kernel
2.6.23.14.
> > > Until now I've manged to make it uncompress the kernel, but it
doesn't boot.
> > > My question is how the initial execution (the one who uncompresses
the
> > > kernel image) transfers the processor to the kernel itself. I've
looked
> > > in the arch/ppc/boot/simple/relocate.S code and it jumps to the
position
> > > 0x0 after uncompressing, is it right? The kernel is uncompressed
at that
> > > position?
> >
> > Post your output log please.
> >
> > If your getting a message that the kernel is uncompressing, but you
> > don't have any output beyond that then most likely your console is
not
> > setup correctly.  If you've got a debugger, look at memory at the
> > __log_buf location to see if there are any boot logs there.
> >
> > Cheers,
> > g.
> >
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> >
>=20
>=20
>=20
> --
> Ricardo Ayres Severo <severo.ricardo@gmail.com>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Linux boot on a ppc 405

[Ricardo Ayres Severo]

Steve,

I tried that, but the System.map is not the real memory address, it's
processed by the mmu isn't it?

This is my System.map: c01e0cc4 b __log_buf
when I try to look at the position 0xc01e0cc4 the debugger returns:
Error: Cannot access memory at address 0xc01e0cc4

Am I doing something wrong?

Thanks,

On Jan 28, 2008 8:55 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> You have to look at the System.map file, find the __log_buf symbol, and
> then look at the address manually.
>
> Steve
>
>
> > -----Original Message-----
> > From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
> > bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Ricardo
> Ayres Severo
> > Sent: Monday, January 28, 2008 2:53 PM
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: Linux boot on a ppc 405
> >
> > Grant,
> >
> > my output is the following:
> >
> > loaded at:     00400000 004E919C
> >
> > board data at: 00000000 0000007C
> >
> > relocated to:  00404040 004040BC
> >
> > zimage at:     00404E2C 004E620A
> >
> > avail ram:     004EA000 8DA05119
> >
> >
> > Linux/PPC load: console=ttyUL0,9600
> >
> > Uncompressing Linux...done.
> >
> > Now booting the kernel
> >
> >
> >
> > nothing shows up next.
> > I tried to look at __log_buf but the debugger doesn't recognize it.
> > The debugger only knows the code of the part that boots the kernel.
> > I also tried setting ttyUL0 and ttyS0 for the linux console.
> > Any ideas of how I can get the real position of __log_buf?
> >
> > Thanks,
> >
> > On Jan 27, 2008 7:15 PM, Grant Likely <grant.likely@secretlab.ca>
> wrote:
> > > On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> > > > Hi all,
> > > >
> > > > I am working with a Xilinx Virtex II Pro  evaluation board, wich
> has two
> > > > PowerPC 405 and I'm trying to boot a vanilla linux kernel
> 2.6.23.14.
> > > > Until now I've manged to make it uncompress the kernel, but it
> doesn't boot.
> > > > My question is how the initial execution (the one who uncompresses
> the
> > > > kernel image) transfers the processor to the kernel itself. I've
> looked
> > > > in the arch/ppc/boot/simple/relocate.S code and it jumps to the
> position
> > > > 0x0 after uncompressing, is it right? The kernel is uncompressed
> at that
> > > > position?
> > >
> > > Post your output log please.
> > >
> > > If your getting a message that the kernel is uncompressing, but you
> > > don't have any output beyond that then most likely your console is
> not
> > > setup correctly.  If you've got a debugger, look at memory at the
> > > __log_buf location to see if there are any boot logs there.
> > >
> > > Cheers,
> > > g.
> > >
> > >
> > > --
> > > Grant Likely, B.Sc., P.Eng.
> > > Secret Lab Technologies Ltd.
> > >
> >
> >
> >
> > --
> > Ricardo Ayres Severo <severo.ricardo@gmail.com>
>
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>



-- 
Ricardo Ayres Severo <severo.ricardo@gmail.com>

RE: Linux boot on a ppc 405

[Stephen Neuendorffer]

I've you've reset the processor, then the MMU has been reset too, in
which case your
log_buf will most likely be at 1e0cc4.  The 'trick' is that resetting
the processor
leaves the memory intact.

Steve

> -----Original Message-----
> From: Ricardo Ayres Severo [mailto:severo.ricardo@gmail.com]
> Sent: Monday, January 28, 2008 3:00 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux boot on a ppc 405
>=20
> Steve,
>=20
> I tried that, but the System.map is not the real memory address, it's
> processed by the mmu isn't it?
>=20
> This is my System.map: c01e0cc4 b __log_buf
> when I try to look at the position 0xc01e0cc4 the debugger returns:
> Error: Cannot access memory at address 0xc01e0cc4
>=20
> Am I doing something wrong?
>=20
> Thanks,
>=20
> On Jan 28, 2008 8:55 PM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > You have to look at the System.map file, find the __log_buf symbol,
and
> > then look at the address manually.
> >
> > Steve
> >
> >
> > > -----Original Message-----
> > > From:
linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> > [mailto:linuxppc-embedded-
> > > bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of =
Ricardo
> > Ayres Severo
> > > Sent: Monday, January 28, 2008 2:53 PM
> > > Cc: linuxppc-embedded@ozlabs.org
> > > Subject: Re: Linux boot on a ppc 405
> > >
> > > Grant,
> > >
> > > my output is the following:
> > >
> > > loaded at:     00400000 004E919C
> > >
> > > board data at: 00000000 0000007C
> > >
> > > relocated to:  00404040 004040BC
> > >
> > > zimage at:     00404E2C 004E620A
> > >
> > > avail ram:     004EA000 8DA05119
> > >
> > >
> > > Linux/PPC load: console=3DttyUL0,9600
> > >
> > > Uncompressing Linux...done.
> > >
> > > Now booting the kernel
> > >
> > >
> > >
> > > nothing shows up next.
> > > I tried to look at __log_buf but the debugger doesn't recognize
it.
> > > The debugger only knows the code of the part that boots the
kernel.
> > > I also tried setting ttyUL0 and ttyS0 for the linux console.
> > > Any ideas of how I can get the real position of __log_buf?
> > >
> > > Thanks,
> > >
> > > On Jan 27, 2008 7:15 PM, Grant Likely <grant.likely@secretlab.ca>
> > wrote:
> > > > On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> > > > > Hi all,
> > > > >
> > > > > I am working with a Xilinx Virtex II Pro  evaluation board,
wich
> > has two
> > > > > PowerPC 405 and I'm trying to boot a vanilla linux kernel
> > 2.6.23.14.
> > > > > Until now I've manged to make it uncompress the kernel, but it
> > doesn't boot.
> > > > > My question is how the initial execution (the one who
uncompresses
> > the
> > > > > kernel image) transfers the processor to the kernel itself.
I've
> > looked
> > > > > in the arch/ppc/boot/simple/relocate.S code and it jumps to
the
> > position
> > > > > 0x0 after uncompressing, is it right? The kernel is
uncompressed
> > at that
> > > > > position?
> > > >
> > > > Post your output log please.
> > > >
> > > > If your getting a message that the kernel is uncompressing, but
you
> > > > don't have any output beyond that then most likely your console
is
> > not
> > > > setup correctly.  If you've got a debugger, look at memory at
the
> > > > __log_buf location to see if there are any boot logs there.
> > > >
> > > > Cheers,
> > > > g.
> > > >
> > > >
> > > > --
> > > > Grant Likely, B.Sc., P.Eng.
> > > > Secret Lab Technologies Ltd.
> > > >
> > >
> > >
> > >
> > > --
> > > Ricardo Ayres Severo <severo.ricardo@gmail.com>
> >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
>=20
>=20
>=20
> --
> Ricardo Ayres Severo <severo.ricardo@gmail.com>

Re: Linux boot on a ppc 405

[Grant Likely]

On 1/28/08, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> Steve,
>
> I tried that, but the System.map is not the real memory address, it's
> processed by the mmu isn't it?
>
> This is my System.map: c01e0cc4 b __log_buf
> when I try to look at the position 0xc01e0cc4 the debugger returns:
> Error: Cannot access memory at address 0xc01e0cc4

Drop the kernel offset of 0xc0000000

So; 0xc01e0cc4 becomes 0x001e0cc4 after reset.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.