Re: Cross-compile dynamic apps for mpc860 on ix86

Re: Cross-compile dynamic apps for mpc860 on ix86

[Wolfgang Denk]

Dony,

you did not get my point:

In message <388BEE23.A42DFCB5@huawei.com.cn> you write:
>
> > > Yes.  I have successfully built glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2 and binutils-2.9.1.0.19a.
> > > I have copied all the shared libraries to my nfs root filesystem under /lib.  I still get segmentation faults when I try to
> > > run the dynamic application.  Arghh !!!  This is so annoying.
> >
> > Make sure you use ONLY files compiled in your  new  environment,  not
> > ANY files that might exist from older versions in your NFS tree.
> >
> > Make sure the shell you are running is statically linked!
>
> Not needed. Both my shell (sash) and my test app can run dynamically.

Then what do you complain  about  segmentation  faults  when  running
dynamically linked applications???

> > The easiest way to test this is to copy all relevant files to  a  new
> > place (say, /test/bin and /test/lib) and then test with "chroot /test".
>
> In a cross-compile environment, It is impossible to do so.  i.e., You can not run any apps for Powerpc on X86 box.

I did not say you should try. Sorry, I thought at  least  *this*  was
obvious.


Ok, once more in detail:

1. Get your PPC target running with the root filesystem mounted  over
   NFS with a known set of working tools (shell, libraries, ...). For
   instance, you can start with the files from the `mbxroot.full.tgz'
   tarball.

2. Put all your new binaries and libraries in  a  separate  directory
   tree.

3. Run a statically linked shell on your PPC  target.  You  may  also
   want to have some more statically linked tools available.

4. Do a "chroot" to your separate directory tree  with  the  binaries
   and  libraries  you  want to test. Try to execute some dynamically
   linked binaries.

5. Fix the problems.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I have the simplest tastes.  I am always satisfied with the best.
                                                       -- Oscar Wilde

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

Re: Cross-compile dynamic apps for mpc860 on ix86

[Brendan John Simon]

Wolfgang Denk wrote:

> > > Make sure the shell you are running is statically linked!
> >
> > Not needed. Both my shell (sash) and my test app can run dynamically.
>
> Then what do you complain  about  segmentation  faults  when  running
> dynamically linked applications???

I think you are confusing Dony and myself.  Dony has got his dynamic binaries going but I am still having problems.  I am about to
compile ALL my tools again.  binutils-2.9.5.0.24, egcs-1.1.2, glibc-2.1.2.  Hopefully I can get gcc-2.95.2 going at some stage but
this is a lower concern at the moment.


> Ok, once more in detail:
>
> 1. Get your PPC target running with the root filesystem mounted  over
>    NFS with a known set of working tools (shell, libraries, ...). For
>    instance, you can start with the files from the `mbxroot.full.tgz'
>    tarball.

I should try this, but I wanted to steer away from the libc-1.99.  I have no technical reason for this but Dan Malek mentions that
he compiles most things statically.  This requires lots of memory and filesystem space.  I assumed from his statements that linking
dynmaically was not advisable or doesn't work.  This must be false as the mbxroot-min.tgz files are dynamically linked.

Brendan Simon.


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

Please help me...

[dony]

Hi,
      Now I am trying to embed linux onto our MPC860-based board. I have
some questions which may be solved by you embed-linux gurus....
     What I want to do  is the following:
    1     Initialize the MPC860 CPU , memory, serial port, enet port .
    2    Download  the linux powerpc kernel (which I have cross-compiled
on my X86 box)
           from the TFTP server to RAM on board.
    3    run the kernel.
Now the 1 and 2 step work well, but when I download the kernel to RAM on
board, It just cannot run.Do you know why? How can I programme to make
it run? Since the kernel is a compressed image (zvmlinux), need I make
some codes to decompress it and then run it? if so, how to do it?
 Thank you very much :-))
 Merry christmas & happy year.

dony

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

Re: Please help me...

[Brendan J Simon]

dony wrote:

> Brendan J Simon wrote:
>
> > dony wrote:
> >
> > > Hi,
> > >       Now I am trying to embed linux onto our MPC860-based board. I have
> > > some questions which may be solved by you embed-linux gurus....
> > >      What I want to do  is the following:
> > >     1     Initialize the MPC860 CPU , memory, serial port, enet port .
> > >     2    Download  the linux powerpc kernel (which I have cross-compiled
> > > on my X86 box)
> > >            from the TFTP server to RAM on board.
> > >     3    run the kernel.
> > > Now the 1 and 2 step work well, but when I download the kernel to RAM on
> > > board, It just cannot run.Do you know why? How can I programme to make
> > > it run? Since the kernel is a compressed image (zvmlinux), need I make
> > > some codes to decompress it and then run it? if so, how to do it?
> >
> > So I take it that you have written your own boot loader that is in
> > ROM/Flash which fetches the kerenl from a TFTP server and places it in RAM
> > somewhere.
>
> Yes, you are right. The monitor program I use is based on vxWorks BSP .
> All the implement details about BOOTP/TFTP are wraped in some functions
> supplied by vxWorks along with some share libraries. What I should do is just
> to call these functions and compiled them under its IDE .
>
> > Good.  How does your bootloader know where to put the code ?
> > Does it look at the internals of the elf image or is it an s-record file
> > you are downloading ?
>
> Yes, It will handle the Elf headers after downloading the kernel from tftp
> server, and then jump there to start. but it failed to run.
>
> > The image must be placed at or above 2MB.  You will
> > have problems if it is below 2MB.
>
>  If I try to downloaded it to 2MB, it cannot download succesfully and halt. But
> If I download it to 1MB, it can do successfully. Why?

I don't know.  Our bootloader is very simple.  It has 3 basic functions.
1) Basic hardware diagnostics (RAM check, etc).
2) Program an S-Record into flash if a dipswitch is set.
3) Run application code from flash if present.

There is no OS involved.  I have never used vxWorks so I don't know how it
allocates it's memory or what.  Is it that you have a vxWorks bootloader that is
expecting a vxWorks kernel and that the kernel is expected to be compiled for a
certain location ?  If so, you will probably have to modify your bootloader to
cater for a linux kernel (or any elf program).


> > I have my kernel in Flash at FFE00000 or
> > FF800000.
>
> If you translate FF8000000 into decimal, it is so huge! Does the 860 support
> it?

Why translate it to decimal ?  It is a big number whether it is in decimal,
hexadecimal, octal or binary.
The MPC860 has a 32 bit address space which means it can access memory from
0x00000000-0xFFFFFFFF.  You program the chip selects with the appropriate base
address and size to your liking for RAM, Flash and other peripherals.


> And how you put it in flash?

Our bootloader has routines to receive S-records and program them into our flash
modules.


> > Once the kernel is loaded, you have to jump to the start
> > address.
> >
> > I assume you are using the mbxboot code for the kernel.  Are you ?  What
> > board are you using ?
>
> Yes. And I use our own MPC860-based board.

Have you made any modifications to the linux kernel to cater for your board
differences (if any).  The main thing is that the console is on SMC1 and ethernet
on SCC1.  I think the mbx board MAY use COM1 instead of SMC1 for the console.  You
better double check that.


> > The mbxboot code will copy the iteself to location 0x100000 (1MB) and jump
> > to that address so it is running from RAM.  It then decompress the kernel
> > image to location 0 and jumps to the start of the kernel.
>
> Do you mean the mbxboot code will copy itself from FF800000 to 1MB?

Yep.


> > Can you send the output of "objcopy --headers zImage" to the list.
>
> The "powerpc-linux-objcopy --headers zImage" cannot work. Maybe the semantics
> is wrong?

My mistake.  It should be objdump instead of objcopy.

Brendan Simon.


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

Re: Please help me...

[Brendan J Simon]

dony wrote:

> > > > Can you send the output of "objcopy --headers zImage" to the list.
> > >
> > > The "powerpc-linux-objcopy --headers zImage" cannot work. Maybe the semantics
> > > is wrong?
> >
> > My mistake.  It should be objdump instead of objcopy.
>
> Now you remind me that "objdump --headers zImage" can produce the following results
> directly which I ask you how to do before:
>
> ***********************************************************
>  Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
> 0 .text         00004870  ff801000  ff801000  00001000  2**2
>                    CONTENTS, ALLOC, LOAD, READONLY, CODE
>    1 .rodata       00000470  ff805870  ff805870  00005870  2**4
>                    CONTENTS, ALLOC, LOAD, READONLY, DATA
>    2 .data         00000300  ff806000  ff806000  00006000  2**2
>                    CONTENTS, ALLOC, LOAD, DATA
>    3 .bss          0000bbac  ff807000  ff807000  00007000  2**2
>                    ALLOC
>    4 image         00061104  ff807000  ff807000  00007000  2**0
>                    CONTENTS, ALLOC, LOAD, DATA
> *************************************************************

Is this the dump of YOUR zImage ?
I chose 0xFF800000 for the base address of Flash memory on our system.  If you are
downloading into RAM then you will have to change the script I sent you so that the
base address is at 0x200000.  This assumes that the DRAM controller is setup by your
bootloader.  I also had problems with the caches so I went through the source code and
disabled all the caches.  I think this is because my bootloader doesn't setup the
UPM correctly and it goes a little crazy on burst accesses.  I recommend that you do
something similar for now.  I also had to change the NFS transfer size from 4096 to
1024 in one of the header files so that I could have a root filesystem on NFS.  Don't
worry about the NFS stuff for now, lets just get the kernel booting.

Good luck,
Brendan Simon.


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

Cannot booting the kernel...

[dony]

Hello,

      With your help, Now I can starting my kernel.  I search linux-ppc lists and find
that I have similar problems as you. Here is the messages:

        Linux/PPC load:
        Uncompressing Linux...done.
        Now booting the kernel

Then nothing happens. I also follow some suggestions which Dan advise you and modify
arch/ppc/kernel/head.S to disable and unlock and invalidate the cache, but it seems to
make no difference. Can you give me some advice ?
Thank you :-))
dony


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

Re: Cannot booting the kernel...

[Brendan J Simon]

dony wrote:

> Hello,
>
>       With your help, Now I can starting my kernel.  I search linux-ppc lists and find
> that I have similar problems as you. Here is the messages:
>
>         Linux/PPC load:
>         Uncompressing Linux...done.
>         Now booting the kernel
>
> Then nothing happens. I also follow some suggestions which Dan advise you and modify
> arch/ppc/kernel/head.S to disable and unlock and invalidate the cache, but it seems to
> make no difference. Can you give me some advice ?

I disabled the caches in arch/ppc/kernel/head.S and arch/ppc/mbxboot/head.S.  The kernel
boots every time now (touch wood).

When my linux system is fully functioning (telnet, snmp, etc) then I will look at the
cache problems.  The gurus think that it is probably a UPM setup problem.

Brendan Simon.


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

Re: Cross-compile Applications for 860 on x86

[dony]

Hi,
     When I compile the SASH  with "-static" options and then replace /bin/sh with sash.
When reseting my MPC860 based board, the kernel boot normally and can show the boot messages. But at last it
cannot show the "bash#" prompt. If I input "ls" or such commands,
It justs shows :

    ls
    pid 8: killed (signal 11)
    ls
    pid 9: killed (signal 11)
    ls
    pid 10: killed (signal 11)

Do you know why? What do I miss?
Thanks very much.
dony


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

Re: Cross-compile Applications for 860 on x86

[Brendan J Simon]

dony wrote:

> Hi,
>      When I compile the SASH  with "-static" options and then replace /bin/sh with sash.
> When reseting my MPC860 based board, the kernel boot normally and can show the boot messages. But at last it
> cannot show the "bash#" prompt. If I input "ls" or such commands,
> It justs shows :
>
>     ls
>     pid 8: killed (signal 11)
>     ls
>     pid 9: killed (signal 11)
>     ls
>     pid 10: killed (signal 11)
>
> Do you know why? What do I miss?

Maybe.  Did you redefine SASH to 1 in init/main.c ?
I'm not sure if it is necessary but it might help.  It looks like SASH is running but you do not have a prompt.

Typing "ls" causes the ls executable in /bin to run (or try to).  You are getting signal 11 (seg fault) because
of shared library problems.  I too haven't solved these yet :(

Type "help" and you will see the list of builtin commands.  Try "-ls" and you should get a directory listing
using the builtin version of ls instead of /bin/ls.

Brendan Simon.


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

Re: Cross-compile dynamic apps for mpc860 on ix86

[Brendan J Simon]

dony wrote:

> In fact, I have posted ALL howtos (not brief howtos)  that I have done when compiling the cross-compile environment. And
> these are all stealed from CrossGcc FAQ. See http://www.objsw.com.
> I do these successfully on SuSE linux (European version), kernel 2.2.13. But the same steps on Redhat linux cannot work
> and some errors occur. I don't know why and are checking these.
> Since Redhat linux is widely used by most linux fans, I will research some effective and stable steps on this. I will
> post to this mail list later when I succeed on Redhat linux.

I am using RedHat-5.2 and I don't have any problems.  There might be some problems with RedHad-6.0 and/or RedHat-6.1.  I
have heard of some people having problems with RedHat-6.x but I think that might be with RTEMS.  Anyway, RedHat-5.2 works
for me.


> > He is using egcs-1.1.2, glibc-2.1 and binutils-2.9.1.0.19a.
> >
> > I have just managed to cross-compile glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2.  I haven't tested them out yet but
> > will do it this week.  I am running with the embedded-2.2.5.tgz kernel and should upgrade to mpc8xx-2.2.13.tgz
> > kernel.  I assume things should still work with the 2.2.5 kernel and I will let you know soon.
> >
> > I couldn't get glibc-2.1.1 nor glibc-2.1.2 to compile using the cpu=860 flag.  I was setting CC="powerpc-linux-gcc
> > -mcpu=860".
>
> I think maybe you should use "export CC=powerpc-linux-gcc" and not use "-mcpu=860". I don't know why, but I do this and
> succeed.

Yes.  I have successfully built glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2 and binutils-2.9.1.0.19a.
I have copied all the shared libraries to my nfs root filesystem under /lib.  I still get segmentation faults when I try to
run the dynamic application.  Arghh !!!  This is so annoying.

I'm using embedded-2.2.5 sourece.  Maybe I should try mpc8xx-2.2.13 or linux-2.2.14 ?
Dony, have you modified any of the kernel source code ?

Does any body out there in linuxppc-embedded land have a clue as to what could be causing the segfaults ?
Can someone suggest a way of getting more debugging information.  I'm using nfsd with "-F -d" call options at the moment.
I can see the ld.so.1 gets called which causes lots of reads from ld-2.1.2.so and then that's it.  I would expect to get
calls to libc.so.6 but it never gets that far.


> > I also tried with the --nfp configure flag but I couldn't get any combination to work.
>
> I don't know this option , so not use it.

It is "supposed" to exclude generation of hardware floating point code.
I imagine this should work better in the next release of glibc (whenever that is) as all the fpu code is in a seperate fpu
directory for the powerpc target.

Brendan Simon.


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

Re: Cross-compile dynamic apps for mpc860 on ix86

[Wolfgang Denk]

In message <388BC036.7BC21AE1@ctam.com.au> you write:
>
> I am using RedHat-5.2 and I don't have any problems.  There might be some problems with RedHad-6.0 and/or RedHat-6.1.  I
> have heard of some people having problems with RedHat-6.x but I think that might be with RTEMS.  Anyway, RedHat-5.2 works
> for me.

RH-6.0 and 6. work fine for me and several of my customers.

> Yes.  I have successfully built glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2 and binutils-2.9.1.0.19a.
> I have copied all the shared libraries to my nfs root filesystem under /lib.  I still get segmentation faults when I try to
> run the dynamic application.  Arghh !!!  This is so annoying.

Make sure you use ONLY files compiled in your  new  environment,  not
ANY files that might exist from older versions in your NFS tree.

Make sure the shell you are running is statically linked!

The easiest way to test this is to copy all relevant files to  a  new
place (say, /test/bin and /test/lib) and then test with "chroot /test".


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"It's when they say 2 + 2 = 5 that I begin to argue."    - Eric Pepke

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

Re: Cross-compile dynamic apps for mpc860 on ix86

[dony]

Brendan J Simon wrote:

> dony wrote:
>
> > In fact, I have posted ALL howtos (not brief howtos)  that I have done when compiling the cross-compile environment. And
> > these are all stealed from CrossGcc FAQ. See http://www.objsw.com.
> > I do these successfully on SuSE linux (European version), kernel 2.2.13. But the same steps on Redhat linux cannot work
> > and some errors occur. I don't know why and are checking these.
> > Since Redhat linux is widely used by most linux fans, I will research some effective and stable steps on this. I will
> > post to this mail list later when I succeed on Redhat linux.
>
> I am using RedHat-5.2 and I don't have any problems.  There might be some problems with RedHad-6.0 and/or RedHat-6.1.  I
> have heard of some people having problems with RedHat-6.x but I think that might be with RTEMS.  Anyway, RedHat-5.2 works
> for me.

Yes, I have problems with Redhat-6.0.

>
>
> > > He is using egcs-1.1.2, glibc-2.1 and binutils-2.9.1.0.19a.
> > >
> > > I have just managed to cross-compile glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2.  I haven't tested them out yet but
> > > will do it this week.  I am running with the embedded-2.2.5.tgz kernel and should upgrade to mpc8xx-2.2.13.tgz
> > > kernel.  I assume things should still work with the 2.2.5 kernel and I will let you know soon.
> > >
> > > I couldn't get glibc-2.1.1 nor glibc-2.1.2 to compile using the cpu=860 flag.  I was setting CC="powerpc-linux-gcc
> > > -mcpu=860".
> >
> > I think maybe you should use "export CC=powerpc-linux-gcc" and not use "-mcpu=860". I don't know why, but I do this and
> > succeed.
>
> Yes.  I have successfully built glibc-2.1.1 and glibc-2.1.2 with egcs-1.1.2 and binutils-2.9.1.0.19a.
> I have copied all the shared libraries to my nfs root filesystem under /lib.  I still get segmentation faults when I try to
> run the dynamic application.  Arghh !!!  This is so annoying.

Hi, Brendan:
    Here are some notes:
    1      Make sure you copy all your libraries under $(prefix)/$(target)/lib and $(prefix)/lib/gcc-lib to your target's root
filesystem /lib.
   2        Make sure you keep their property unchangeable. i.e, if a library is symbol link , you must keep it unchangeable
after copying. Especially, libc.so.6 is a symbol link pointing to libc-2.1.so .
   3         Make sure all  these libraries you are copying are generated when buiding your cross-compile environment.
  4          When cross-compiling your test app, you can specify its running share libraries path using "-Wl,--rpath,/lib".
i.e:
               powerpc-linux-gcc -O2 -mcpu=860 -Wl,--rpath,lib -o mytest mytest.c
              An easyest way to test this is to replace your target NFS root filesystem's /bin/sh with the above "mytest" and
reset your board. And running "rpc.nfsd -F -d call" on your x86 host to monitor whether it can run correctly. If not, what file
it cannot find? In my case , First , it can not find "/etc/ld.so.preload" and "/etc/ld.so.cache". then I run "touch
/tftpboot/etc/{ld.so.preload,ld.so.cache}". Then reset. And continue monitoring.
In my case, this time it cannot find some libraries under /usr/local/lib.Copy all the files it cannot find to its proper
place(where rpc.nfsd reports). In fact you can specify its running share libraries path using "-Wl, --rpath, /lib" to avoid
these.
Keep patient and you will find you are succeeding at this moment.

>
>
> I'm using embedded-2.2.5 sourece.  Maybe I should try mpc8xx-2.2.13 or linux-2.2.14 ?

I use mpc8xx-2.2.13. But I think it makes no difference.

>
> Dony, have you modified any of the kernel source code ?

No.

>
>
> Does any body out there in linuxppc-embedded land have a clue as to what could be causing the segfaults ?
> Can someone suggest a way of getting more debugging information.  I'm using nfsd with "-F -d" call options at the moment.

I think this is enough to debug your problem. This is what I use.

>
> I can see the ld.so.1 gets called which causes lots of reads from ld-2.1.2.so and then that's it.  I would expect to get
> calls to libc.so.6 but it never gets that far.

Then where does it go after it accesses ld.so.1?
dony


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

Re: Cross-compile dynamic apps for mpc860 on ix86

[Wolfgang Denk]

In message <388BF52B.213CCD61@huawei.com.cn> dony wrote:
>
>     Here are some notes:
>     1      Make sure you copy all your libraries under $(prefix)/$(target)/lib and $(prefix)/lib/gcc-lib to your target's root
> filesystem /lib.

I don't think you will need the gcc-lib files on your target (as long
as you don't want to compile / linke on the target).

>                powerpc-linux-gcc -O2 -mcpu=860 -Wl,--rpath,lib -o mytest mytest.c
>               An easyest way to test this is to replace your target NFS root filesystem's /bin/sh with the above "mytest" and

Adding "init=<your_path>/mytest" will do as well.

[I don't think it is a good idea to modify files on  the  NFS  server
just for testing things. You might forget to change something back to
the  original state, or in bigger projects there might be other users
trying to use the same NFS server.]

> reset your board. And running "rpc.nfsd -F -d call" on your x86 host to monitor whether it can run correctly. If not, what file
> it cannot find? In my case , First , it can not find "/etc/ld.so.preload" and "/etc/ld.so.cache". then I run "touch
> /tftpboot/etc/{ld.so.preload,ld.so.cache}". Then reset. And continue monitoring.

Again, I don't think this is a good idea. You will be  creating  some
files  that are not really needed. For instance, "/etc/ld.so.preload"
is *NOT* needed at all.

> > Does any body out there in linuxppc-embedded land have a clue as to what could be causing the segfaults ?
> > Can someone suggest a way of getting more debugging information.  I'm using nfsd with "-F -d" call options at the moment.
>
> I think this is enough to debug your problem. This is what I use.

Grrrgh. You cannot really debug anything this way.

For instance, you will never be able to know if a failing attempt  to
open  a  non-existing  file (like "/etc/ld.so.preload") is a critical
error or just a feature that may beuseful  under  some  very  special
circumstances.

> > I can see the ld.so.1 gets called which causes lots of reads from ld-2.1.2.so and then that's it.  I would expect to get
> > calls to libc.so.6 but it never gets that far.
>
> Then where does it go after it accesses ld.so.1?

Good question - do you still claim you can  find  this  out  just  by
looking at the NFS transfers?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
You young'uns. That was *long* before AltaVista,  DejaNews,  or  even
(gasp) the *Web*! In fact, we typed that thread on steam-powered card
punchers, and shipped it around via Pony Express.
            -- Randal Schwartz in <8cwww1cd0d.fsf@gadget.cscaper.com>

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