Prev: Inferring mutipliers
Next: ISE tools not detecting IOSTANDARD conflicts within bank
From: Joe Chisolm on 27 Apr 2010 13:26
On Mon, 26 Apr 2010 22:50:19 +0200, Martin Brückner wrote:

> Hello,
>
> I'm writing a boot loader to start Linux on the PowerPC440 (Virtex5FXT).
> At first the program copies the kernel into the RAM at address
> 0x00400000 and afterwards it boots Linux with the following lines:
>
> #define LINUX_START_ADDRESS 0x004002b4
>
> int main()
> {
> void (*linux)();
> linux = (void*) LINUX_START_ADDRESS;
>
> ... // here is the code which copies the kernel into ram
>
> (*linux)();
> }
>

Did you setup the stack pointer? The above is going to try and push
the return address on the stack. Compile with -S and look at the
resulting asm output.

[snip]

> Best Regards
> Martin Brückner


--
Joe Chisolm
Marble Falls, Tx.
From: glen herrmannsfeldt on 27 Apr 2010 14:23
Joe Chisolm <jchisolm6(a)earthlink.net> wrote:
> On Mon, 26 Apr 2010 22:50:19 +0200, Martin Br?ckner wrote:

>> I'm writing a boot loader to start Linux on the PowerPC440 (Virtex5FXT).
>> At first the program copies the kernel into the RAM at address
>> 0x00400000 and afterwards it boots Linux with the following lines:

>> #define LINUX_START_ADDRESS 0x004002b4
(snip)
>> (*linux)();

> Did you setup the stack pointer? The above is going to try and push
> the return address on the stack. Compile with -S and look at the
> resulting asm output.

Not knowing at all about the linux boot process, I would have
assumed that one of the first thing that the booting kernel does
would be to set up its own stack.

It might, though, depend on a previous level of boot program
to have set up a stack for it. I wouldn't expect the boot
ROM to have done it, but often there are multiple levels of
boot programs.

-- glen
From: Martin Brückner on 27 Apr 2010 18:12
Am Tue, 27 Apr 2010 11:17:03 +0100
schrieb Brian Drummond <brian_drummond(a)btconnect.com>:

> On Tue, 27 Apr 2010 10:03:34 +0200, Martin Brückner
> <bj2spam(a)alice-dsl.net> wrote:
>
> >Am Mon, 26 Apr 2010 22:08:02 +0000 (UTC)
> >schrieb glen herrmannsfeldt <gah(a)ugcs.caltech.edu>:
> >
> >> Martin Br?ckner <bj2spam(a)alice-dsl.net> wrote:
> >>
> >> > I'm writing a boot loader to start Linux on the PowerPC440
> >> > (Virtex5FXT). At first the program copies the kernel into the RAM
> >> > at address 0x00400000 and afterwards it boots Linux with the
> >> > following lines:
> >>
> >> > #define LINUX_START_ADDRESS 0x004002b4
> >>
> >> (snip)
> >>
> >> > (*linux)();
> >>
> >> With the assumption that data pointers can be properly
> >> cast to function pointers, that line should jump to
> >> location 0x4002b4 and start executing the code there.
>
> I haven't used the PPC since the V2Pro, but...
>
> Xilinx example code typically has boilerplate to do things like
> invalidate caches and set up interrupt state before handing over to
> "real" code. It is possible that using XMD to reset the CPU does that
> for you.
>
> Have you covered these bases in your own code?

When I started with this project I was sure that Linux invalidates
caches and sets up the interrupt state and the comments in
arch/powerpc/kernel/head_44x.S seems to confirm that (I am not deep
enough into PowerPC Assembler to understand all of its code).
Probably there might be a bug in this initializing code.

Anyway, all I tried out yet was disabling the cache but that did not
help. Do you know where to find more Xilinx-Commands to handle Cache
and MMU?

>
> - Brian
Martin
From: Martin Brückner on 27 Apr 2010 18:15
Am Tue, 27 Apr 2010 18:23:11 +0000 (UTC)
schrieb glen herrmannsfeldt <gah(a)ugcs.caltech.edu>:

> Joe Chisolm <jchisolm6(a)earthlink.net> wrote:
> > On Mon, 26 Apr 2010 22:50:19 +0200, Martin Br?ckner wrote:
>
> >> I'm writing a boot loader to start Linux on the PowerPC440
> >> (Virtex5FXT). At first the program copies the kernel into the RAM
> >> at address 0x00400000 and afterwards it boots Linux with the
> >> following lines:
>
> >> #define LINUX_START_ADDRESS 0x004002b4
> (snip)
> >> (*linux)();
>
> > Did you setup the stack pointer? The above is going to try and push
> > the return address on the stack. Compile with -S and look at the
> > resulting asm output.
>
> Not knowing at all about the linux boot process, I would have
> assumed that one of the first thing that the booting kernel does
> would be to set up its own stack.
>
> It might, though, depend on a previous level of boot program
> to have set up a stack for it. I wouldn't expect the boot
> ROM to have done it, but often there are multiple levels of
> boot programs.
>
> -- glen

As I wrote before (answering Brian), I also assumed that Linux would
manage that.

What I found out this day is, that the Linux syslog-buffer is empty.

Martin
From: Martin Brückner on 28 Apr 2010 05:29
Am Tue, 27 Apr 2010 04:07:41 -0700 (PDT)
schrieb Marc Jet <jetmarc(a)hotmail.com>:

> Martin Brückner wrote:
> > void (*linux)();
> > ...
> > (*linux)();
>
> Wouldn't the last line have to be just this?
>
> linux();

The result of (*linux)() and linux() is the same.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Inferring mutipliers
Next: ISE tools not detecting IOSTANDARD conflicts within bank