Sandpoint 8240 or 7400

Sandpoint 8240 or 7400

[Roland Dreier]

Hi, I'm trying to get Linux running on a Motorola Sandpoint.  I have a
8240 and a 7400 available.

So far I've tried running the 8240 kernel from the Montevista CDK 1.2.
The boot seems to hang after printing the "OpenPIC timer frequency is
not set" (I left it waiting for quite a while with no luck).  I get
the same thing on both the 8240 and the 7400.

Then I tried the older kernel from

<ftp://ftp.mvista.com:/pub/Area51/sandpoint-8240>

That kernel seems to freeze up at the same place (it prints more
openpic information, but those print statement just seem to have been
taken out of kernel 2.4 -- I can send them if it would help diagnose
the problem).

Has anyone gotten Linux to boot on a Sandpoint system?  I'm especially
interested in the 7400.

Also, if I wanted to build my own kernel for a Sandpoint system, what
source tree should I use?  And (forgive the naive question) how do I
build a kernel image that I can send to the Sandpoint via the serial
port and start from DINK32?  What are the prospects of being able to
build a PPC kernel from Linus's tree?

Thanks,
Roland


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

Re: Sandpoint 8240 or 7400

[Roland Dreier]

    Roland> Also, if I wanted to build my own kernel for a Sandpoint
    Roland> system, what source tree should I use?  And (forgive the
    Roland> naive question) how do I build a kernel image that I can
    Roland> send to the Sandpoint via the serial port and start from
    Roland> DINK32?  What are the prospects of being able to build a
    Roland> PPC kernel from Linus's tree?

Just to add a little info here... I managed to get 2.4.1-pre10 to
build for PPC and I got enough of a clue to boot zvmlinux.  However,
(at least on the 7400 board) that kernel also seems to stop in
openpic.

I guess my question is still whether anyone has booted Linux on a
Sandpoint 7400.

Thanks,
Roland


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

Re: Sandpoint 8240 or 7400

[Dan Malek]

Roland Dreier wrote:

> ..... I get
> the same thing on both the 8240 and the 7400.

Got all of those switches set correctly :-)?

> Has anyone gotten Linux to boot on a Sandpoint system?  I'm especially
> interested in the 7400.

Yeah, I'm working on the 7450 as we speak.  Probably won't sleep
this weekend because I need to have the demo done for Linux world.
The Linux part was easy, the demo sucks :-).  I did the original
8240 long ago, which was some "up to date" 2.3.18 kernel or something
at the time.  I'm sure that is still floating around someplace :-).

> Also, if I wanted to build my own kernel for a Sandpoint system, what
> source tree should I use?

Let me clean mine up a little (I'm actually doing 405 at the moment)
and put it on a server someplace.  No promises, but it should be
better than anything else right now.  The Sandpoint seems to always
be one of those "background" projects that can't gain momentum.

> ......  And (forgive the naive question) how do I
> build a kernel image that I can send to the Sandpoint via the serial
> port and start from DINK32?

What version of DINK do you have?  I'll send you my little downloader
as well if you wish.  The easiest way is I just blow the bits over
the JTAG with my Abatron....

> .....  What are the prospects of being able to
> build a PPC kernel from Linus's tree?

It's getting closer, but this Sandpoint stuff still isn't there.


	-- Dan

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

Re: Sandpoint 8240 or 7400

[Roland Dreier]

    Dan> Got all of those switches set correctly :-)?

Not sure... VxWorks boots fine, does anything need to change for Linux?

    Dan> Let me clean mine up a little (I'm actually doing 405 at the
    Dan> moment) and put it on a server someplace.  No promises, but
    Dan> it should be better than anything else right now.  The
    Dan> Sandpoint seems to always be one of those "background"
    Dan> projects that can't gain momentum.

That would be great.  Let me know when you get a chance to do that.

    >> ......  And (forgive the naive question) how do I build a
    >> kernel image that I can send to the Sandpoint via the serial
    >> port and start from DINK32?

    Dan> What version of DINK do you have?  I'll send you my little
    Dan> downloader as well if you wish.  The easiest way is I just
    Dan> blow the bits over the JTAG with my Abatron....

Actually I figured this out myself a little bit later and managed to
build my own kernel that hung in the same place.

    Dan> It's getting closer, but this Sandpoint stuff still isn't
    Dan> there.

Out of curiousity, what is different about the Sandpoint that requires
changes in the kernel?

Thanks,
Roland

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

Re: Sandpoint 8240 or 7400

[Dan Malek]

Roland Dreier wrote:

> That would be great.  Let me know when you get a chance to do that.

I worked on it about 40 hours this past weekend, still no go.  The
problem for me still continues to be interrupt routing on this board.
The 8240 or 107 have the EPIC, which is like OpenPIC but not really.
This is further complicated by the 8259 cascade, which the OpenPIC
code assumes is configured a particular way, but doesn't work on
Sandpoint.  It is just a problem of using standard functions and
making the interrupts line up correctly.  Pain in the ass.  The whole
Linux interrupt management is just plain stupid (there is more to
the world than PCs with hardcoded 8259s).

> Out of curiousity, what is different about the Sandpoint that requires
> changes in the kernel?

Ummm, like it is a different board than anything else supported?  We
can use lots of the same code, you just may have to call functions
with slightly different parameters for set up.

I discovered the newer versions of DINK (I'm using 12.0) don't need
any special download program.  I just use 'cu', set the baud rate
to 38400, and just 'cat file_to_download > /dev/cua0'.  The processors
and code are fast enough to just suck it up and write it to memory (I
would hope so, too :-).


	-- Dan

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

Re: Sandpoint 8240 or 7400

[Roland Dreier]

    Dan> I worked on it about 40 hours this past weekend, still no go.
    Dan> The problem for me still continues to be interrupt routing on
    Dan> this board.  The 8240 or 107 have the EPIC, which is like
    Dan> OpenPIC but not really.  This is further complicated by the
    Dan> 8259 cascade, which the OpenPIC code assumes is configured a
    Dan> particular way, but doesn't work on Sandpoint.  It is just a
    Dan> problem of using standard functions and making the interrupts
    Dan> line up correctly.  Pain in the ass.  The whole Linux
    Dan> interrupt management is just plain stupid (there is more to
    Dan> the world than PCs with hardcoded 8259s).

I managed to get my Sandpoint 7400 to boot (it turns out that VxWorks
uses the opposite interrupt polarity so someone had set S5 wrong on
the motherboard).  I used the 2.4.0-pre2 kernel that comes with the
Montevista CDK 1.2, though I had to recompile to build in the 3c59x
driver (since that's the network card I'm using).

After doing that, the kernel boots, gets through the BOOTP, and mounts
its root filesystem via NFS.  However, something screwy seems to be
happening when the kernel tries to run init -- init doesn't seem to be
getting run.  Even if I use sash or a simple program that just prints
something, I don't get any output on the serial console.  I even tried
a program that listens for network connections but I can't connect to
it.  The kernel is still running: I can ping the box, get TCP
connections refused (ARP works), and the serial driver is doing enough
to echo input.  And the NFS mount is working -- the kernel panics
unless /bin/init is a ppc executable.  Anyone have any idea about
what's happening?  Am I missing something obvious?

Thanks,
  Roland

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

Re: Initial stack frame

[Jerry Van Baren]

At 10:05 PM 1/29/01 +0100, Wolfgang Grandegger wrote:

>Hello,
>
>I'm currently debugging a task stack initialization problem in RTAI
>on MPC8xx. The task is switched by calling rt_startup() via "blr"
>(or "rfi" in RTLinux). The objdump of rtai_sched.o shows the following
>function prolog:
>
>rtai_sched.o:     file format elf32-powerpc
>
>Disassembly of section .text:
>
>00000000 <rt_startup>:
>        0:       94 21 ff f0     stwu    r1,-16(r1)
>        4:       7c 08 02 a6     mflr    r0
>        8:       93 c1 00 08     stw     r30,8(r1)
>        c:       93 e1 00 0c     stw     r31,12(r1)
>       10:       90 01 00 14     stw     r0,20(r1)
>       14:       3c e0 00 00     lis     r7,0
>       18:       81 67 00 00     lwz     r11,0(r7)
>
>This means that it will save on the stack:
>
>         SP    Contents
>        -16 -> initial r1 (back chain)
>        -12
>         -8 -> r30
>         -4 -> r31
>          0 ->
>         +4 -> LR
>
>Note that the initial stack pointer (SP) stored in r1 is at 0
>pointing to the end of the stack buffer (kmalloc + stack_size).
>This means that data behind the stack gets overwritten.
>
>I realized that an empty initial stack frame is missing and also a
>16-byte alignment is mandatory. At least that's what I understood
>from the PowerPC Application Binary Interface supplement. There
>should be an initial stack frame initialized as follows:
>
>    Address    Contents
>          0 -> 0 (back chain for first stack frame)
>         +4 ->
>         +8 ->
>        +12 ->
>
>It would be nice is somebody could clarify this. Is the alignment
>really mandatory?
>
>Thanks for any comments in advance.
>
>
>-- Wolfgang

You need to get the ABI and EABI spec
http://www.esofta.com/softspecs.html (also available on the IBM web
site somewhere).

One of the differences between the ABI and EABI is that the EABI
requires 8 byte alignment of the stack and the ABI requires 16 byte
alignment (EABI, p.28).

The ABI illustrates the stack on page 3-44.  Note that the link
register and back chain are saved on what traditional processors would
call the previous stack (most/all CISC processors pre-decrement the
stack pointer so offset 0 and +4 in your illustrations above would be
"previous stack" locations).  This is odd and confusing to us
traditionalists, but all properly written functions make provisions for
it so it works just fine.

The bottom line is that I don't see anything wrong with what you have
shown above in your stacks.

Your statement about "blr" vs. "rfi" as if they were interchangeable is
somewhat confusing since they are not at all interchangeable.  I
presume you were glossing over a lot of details.  Doing a "rfi" on a
PowerPC requires a very delicate and elaborate dance of instructions
and control register bits.  Ultimately, it returns to the location in
the SRR0 register, not to any location stored on the stack.

gvb


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

Re: Initial stack frame

[Wolfgang Denk]

In message <4.3.2.20010130074919.00bb0a80@falcon.si.com>
Jerry Van Baren wrote:
>
> One of the differences between the ABI and EABI is that the EABI
> requires 8 byte alignment of the stack and the ABI requires 16 byte
> alignment (EABI, p.28).

Yes, ok. But what is implemented by GCC and glibc? The SVR4 ABI or
the EABI?

In other words: Wolfgang Grandegger wants to know if  we  must  align
"private" stack frames on 8 or 16 byte boundaries...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Visit us at Embedded Systems: Feb 14-16 2001, Nuremberg, Halle 12/K01
(with TQ Components); our presentation "Starke Zwerge: Embedded Linux
auf PowerPC-Systemen" on Thursday, Feb 15 2001, 13:30 Forum Halle 11.

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

Re: Initial stack frame

[Kenneth Johansson]

Wolfgang Denk wrote:
>
> In message <4.3.2.20010130074919.00bb0a80@falcon.si.com>
> Jerry Van Baren wrote:
> >
> > One of the differences between the ABI and EABI is that the EABI
> > requires 8 byte alignment of the stack and the ABI requires 16 byte
> > alignment (EABI, p.28).
>
> Yes, ok. But what is implemented by GCC and glibc? The SVR4 ABI or
> the EABI?
>
> In other words: Wolfgang Grandegger wants to know if  we  must  align
> "private" stack frames on 8 or 16 byte boundaries...
>
> Wolfgang Denk
>

linux implements SVR4 with exceptions that we don't return small(8 or less
bytes) structs in r3,r4 as the standard say we should. Could be more things I
have not noticed we are anyway closer to SVR4 than EABI.


--
Kenneth Johansson
Ericsson Business Innovation AB   Tel: +46 8 404 71 83
Viderögatan 3                     Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@inn.ericsson.se

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

Re: Initial stack frame

[Jerry Van Baren]

At 03:46 PM 1/30/01 +0100, Wolfgang Denk wrote:

>In message <4.3.2.20010130074919.00bb0a80@falcon.si.com>
>Jerry Van Baren wrote:
> >
> > One of the differences between the ABI and EABI is that the EABI
> > requires 8 byte alignment of the stack and the ABI requires 16 byte
> > alignment (EABI, p.28).
>
>Yes, ok. But what is implemented by GCC and glibc? The SVR4 ABI or
>the EABI?
>
>In other words: Wolfgang Grandegger wants to know if  we  must  align
>"private" stack frames on 8 or 16 byte boundaries...
>
>Wolfgang Denk
>
>--
>Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
>Visit us at Embedded Systems: Feb 14-16 2001, Nuremberg, Halle 12/K01
>(with TQ Components); our presentation "Starke Zwerge: Embedded Linux
>auf PowerPC-Systemen" on Thursday, Feb 15 2001, 13:30 Forum Halle 11.

The stack frame alignment shouldn't matter as long as it doesn't matter
to the processor (there may be efficiency reasons to align to 16 bytes,
but there doesn't appear to be any operational problems aligning to 8
bytes -- I never knowingly misaligned to 4 bytes so I don't know if
that works).

The difference between 8 and 16 byte alignment is extra padding words
inside the stack frame.  Since C doesn't allow you to access a
function's variables from within a nested function (Pascal is the only
language I can think of that does this), nobody but the local function
should need to know where the variables are inside a given stack
frame.  Since that is the routine that put in the padding, it would
know where the the registers and variables are.  Well, on second
thought, the debugger (gdb) needs to know where the padding is in order
to display variables and parameters of the function, but that is
getting pretty deep into the system.  Stack back-tracing should use the
frame back chain, which is independent of the alignment padding.

The ABI/EABI doesn't specify where the padding should be put in the
frame, but it would logically go in the "Area for constructing
parameter lists for callees" portion of the frame.  The simplest thing
to do would be to compile some example functions and look at the
disassembled output, and then do the same thing -- my favorite method
of programming (plagiarism is a Good Thing in programming :-).

gvb


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