Re: Please help me...

Re: Please help me...

[Raphael Bossek]

hi dony,

> Do you know why? How can I programme to make it run?
i thing you have download it into wrong address! i would recompile
the kernel with debugging information and single step your code...
the decompressor and some of the first lines of code of the kernel
are initialisation and possible to debug... check where the
decompressor jump to and compare where the decompressor reads from!
use binutils to get mixed code on your host and compare the lines
with your debuger
let take me a look... the 8xxrom load the kernel elf image to phy
address 0x00200000

> 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?
the decompressor is part of the image but it expects the real image
at a special address which you have to consider before downloading
into ram. this will be done by the 8xxrom from Magnus Damm and some
patches for the 823 avilable at http://www.s4l.de/powerpc.html of
course :-) the 8xxrom resists in flash and load the linux kernel from
a pcmcia ide hd or from flash using a rom-fs but this is an another
solution that can be used in a ready product with little modifications
in image selection...

-- 
Raphael Bossek <raphael.bossek@solutions4linux.de> [ICQ #40047651]
PGP fingerprint: DF 6F 2C 76 46 1E B4 1C  5B A5 2E 1B FC E0 D3 F6
PGP public key: http://www.solutions4linux.de/private/pgpkey.asc

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

Re: Please help me...

[Brendan J Simon]

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.  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 ?  The image must be placed at or above 2MB.  You will
have problems if it is below 2MB.  I have my kernel in Flash at FFE00000 or
FF800000.  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 ?
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.

Can you send the output of "objcopy --headers zImage" to the list.  Also
send the output of the mbxboot loader messages with the loaded and
relocated addresses (if the code is getting that far).

Brendan Simon.


** 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/

Re: Please help me...

[Charles Lepple]

Brendan J Simon wrote:
> >  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

       ^^^^^^^ This section (image) could be your problem if you use a
vxWorks bootloader.

Although the vxWorks loader is written with ELF images in mind,
experience (with a DY4 SVME-177 board) tells me that it ignores ELF
sections that would not be present in a vxWorks executable. I did not
have time to investigate this completely, but the indication that tipped
me off was that the sizes of the sections added up to be much larger
than the sum of the numbers that the boot loader reports. All other test
programs (those without added sections) were loaded correctly.

If the sum of the numbers printed on the screen is significantly less
than the size of the file, then you can assume that anything you need to
load should be in either '.text' or '.data'. If you have the whole
vxWorks toolchain, you can try to find out what other section names are
used in executables loaded by the bootloader (maybe a debugging
section?), or you can work on building a special zImage file.

You can get around this limitation by having the zipped kernel image
inserted directly into the data segment of a wrapper program (see
arch/ppc/chrpboot/, especially piggyback.c).

-- 
Charles Lepple
clepple@mitre.org


** 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...

[dony]

> The zImage contains an uncompress program at the start.  This program then
> copies and uncompresses the kernel to another location in ram.

> If your
> using the kernel from Dan at
>
>     ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/
>
> Then use the debugger to start it at 0x00200000.  Refer to the code in
> arch/ppc/mbxboot/misc.c

Yes, I use the mpc8xx.2.2.13.tgz to compile the kernel "zImage".
Do you mean that when I download the kernel "zImage" to RAM address 0x100000
on our own board (but not mbxboard) , and jump to 0x100000, It will
automatically run the uncompress program to copy and decompress the kernel to
0x200000, then  jump to 0x200000, the decompressed kernel will boot,  right  ?



>
>
> I'm not the expert, Dan is, but he's been teaching me.
>
> jeff
> ----- Original Message -----
> From: "dony" <dony.he@huawei.com.cn>
> To: "Raphael Bossek" <raphael.bossek@solutions4linux.de>; "Brendan Simon"
> <bsimon@ctam.com.au>; "Dan Malek" <dan@netx4.com>; "linuxppc-embed"
> <linuxppc-embedded@lists.linuxppc.org>
> Sent: Thursday, December 30, 1999 9:29 PM
> Subject: Please help me...
>
> >
> > 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...

[dony]

Jeff Millar wrote:

> The zImage contains an uncompress program at the start.  This program then
> copies and uncompresses the kernel to another location in ram.  If your
> using the kernel from Dan at
>
>     ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/
>
> Then use the debugger to start it at 0x00200000.  Refer to the code in
> arch/ppc/mbxboot/misc.c

By the way, what role does the "struct bd_t" play in the function
"decompress_kernel"?
Is it contain the private data for various board? Must I need it?

>
>
> I'm not the expert, Dan is, but he's been teaching me.
>
> jeff
> ----- Original Message -----
> From: "dony" <dony.he@huawei.com.cn>
> To: "Raphael Bossek" <raphael.bossek@solutions4linux.de>; "Brendan Simon"
> <bsimon@ctam.com.au>; "Dan Malek" <dan@netx4.com>; "linuxppc-embed"
> <linuxppc-embedded@lists.linuxppc.org>
> Sent: Thursday, December 30, 1999 9:29 PM
> Subject: Please help me...
>
> >
> > 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...

[dony]

Jeff Millar wrote:

> The zimage arrives at 00200000 and you start it there.  I think it copies
> itself to 00100000 but never looked. The idea is to position the zImage
> in ram low enough to use the first 16M but above the uncompressed kernel and
> its data structure ( from 0M and up)  Putting the zImage at 00200000 is
> a good compromise.
>

In  my case, If I try to download zImage at 0x00200000, it will fail to
download.
I don't know why. but If I download zImage at 0x00100000, it will download
successfully but can not run... It is so strange. Can you share me with some of
your experience?
Thanks.

>
> BTW, the zImage is relocatable and can be loaded anywhere.
> I just learned to copy it to FLASH with a built in debugger
> program and start it there.  This makes the board boot
> automatically without the tftp download.

How can I copy it to Flash?



>
>
> ----- Original Message -----
> From: "dony" <dony.he@huawei.com.cn>
> To: "Jeff Millar" <jeff@wa1hco.mv.com>; "linuxppc-embed"
> <linuxppc-embedded@lists.linuxppc.org>
> Sent: Friday, December 31, 1999 3:37 AM
> Subject: Re: Please help me...
>
> > > The zImage contains an uncompress program at the start.  This program
> then
> > > copies and uncompresses the kernel to another location in ram.
> >
> > > If your
> > > using the kernel from Dan at
> > >
> > >     ftp://linuxppc.cs.nmt.edu/pub/linuxppc/embedded/
> > >
> > > Then use the debugger to start it at 0x00200000.  Refer to the code in
> > > arch/ppc/mbxboot/misc.c
> >
> > Yes, I use the mpc8xx.2.2.13.tgz to compile the kernel "zImage".
> > Do you mean that when I download the kernel "zImage" to RAM address
> 0x100000
> > on our own board (but not mbxboard) , and jump to 0x100000, It will
> > automatically run the uncompress program to copy and decompress the kernel
> to
> > 0x200000, then  jump to 0x200000, the decompressed kernel will boot,
> right  ?
> >
> >
> >
> > >
> > >
> > > I'm not the expert, Dan is, but he's been teaching me.
> > >
> > > jeff
> > > ----- Original Message -----
> > > From: "dony" <dony.he@huawei.com.cn>
> > > To: "Raphael Bossek" <raphael.bossek@solutions4linux.de>; "Brendan
> Simon"
> > > <bsimon@ctam.com.au>; "Dan Malek" <dan@netx4.com>; "linuxppc-embed"
> > > <linuxppc-embedded@lists.linuxppc.org>
> > > Sent: Thursday, December 30, 1999 9:29 PM
> > > Subject: Please help me...
> > >
> > > >
> > > > 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...

[dony]

> When you say the download doesn't work, what do you mean?

When I try to download the "zImage" from  TFTP Server to my RAM 0x00200000 on
board,
the download process will stop . That is to say, it cannot download the whole
"zImage" file
but just a part of the "zImage " file. But it I download the "zImage" to my RAM
0x00100000 on
board, it will succeed to download and show a message "starting at
0x00100000..." and halt.

>
>
> How much RAM do you have?

32M.
Notes that I want to download the "zImage" from remote TFTP Server via EHERNET
instead of  from local flash .
I have downloaded the FADSROM and 8xxROM packages and researched them.
They all seem to download the "zImage" from local flash disk, not from remote
TFTP server via ETHERNET. I think the latter is easy to debug applications,
right?
Do you think it will make any difference between these two cases?
When I download the "zImage" from remote TFTP server  via ethernet to RAM
0x00200000 board , how can I dispose the "zImage" at other address , and when
jumping there it will boot the kernel?
Any ideas?


> Downloading zImage to 2MB should work.  You might
> try downloading to 3 or 4MB.  You need to download the relocatable kernel
> image (zImage) so that entirely fits in RAM, low enough that the top end of
> zImage and any attached initrd doesn't over flow the top of RAM.  The
> bootloader will copy the kernel low using 0x0 and up for its data structures
> and executable.  The zImage must not conflict with the kernel executable or
> data structures.  Putting the zImage at 0x00100000 is too low.  During the
> boot load process, the kernel builds data structures upward in memory
> depending on the size of the kernel and number of options.
>
> Copying the image to flash depends on the hardware and flash ROM chips.  You
> will have to write
> a flash ROM erase and writing program.  Assuming your board has flash, find
> the data sheet and read up on the write programming algorithm.  The zImage
> and initrd can load into ROM and the boot
> loader can execute fromm flash rom.

Sorry, I still don't understand your meaning.
When you say "copy image to flash", what does the image contain?
bootrom codes+kernel+RootFileSystems or kernel+RootFileSystems? If so, in what
file format can I write it into flash?
Best regards,
dony


>
>


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

Re: Please help me...

[dony]

> hi dony,
>
> > Do you know why? How can I programme to make it run?
> i thing you have download it into wrong address! i would recompile
> the kernel with debugging information and single step your code...
> the decompressor and some of the first lines of code of the kernel
> are initialisation and possible to debug...

How can I debug whether the decompress_kernel() and some of the first
lines of code of the kernel in arch/ppc/mbxboot/head.s are running or not?
I think they are not running,  because
I cannot see any startup messages coded in decompress_kernel().

> check where the
> decompressor jump to and compare where the decompressor reads from!
> use binutils to get mixed code on your host and compare the lines
> with your debuger

Yes, I should try check, but I just don't know how to check that .
Can you give me some more detailed information for debug?

>
> let take me a look... the 8xxrom load the kernel elf image to phy
> address 0x00200000

Yes, I have downloaded your 8xxrom codes and read them.
But they seem to read the kernel from flash into RAM 0x00200000 on board,
which is a bit defferent from what I am doing.
Now I will try to express my idea to you as clearly as possibly. Please
give me some helpful suggestions.
I use the monitor program based on vxWorks BSP. This monitor program
initialize all the things after power on (or system reset): MPC860 CPU
initialization, MEMORY initialization, Serial Port initialization(SMC2)
and Ethernet initialization(SCC1) etc. Then it use the BOOTP/TFTP protocol
to download the kernel "zImage" (compressed) or "vmlinux" (uncompressed)
from a linux box Server which has been configured bootpd , tftpd, and nfsd
.Yes , It successfully download the kernel to RAM 0x00200000 on my custom
board. Then I am very confused at this stage. Now questions appears:
1     If I directly jump there 0x00200000 at this time, will it run and
decompress the kernel automatically?
I think there are some bootloader codes (including the
decompress_kernel()) at 0x00200000 at this time , so it should run  the
first lines of the bootloader codes and then decompress_kernel() in order,
right? But it fails at all. After loading the kernel, it just shows a
message "start at 0x00200000..." (which is coded in my monitor program)
and doesn't show some startup messages in decompress_kernel() such as
"loading at... relocated to...  board data at... relocated to... zImage
at... ". I think this means the decompress_kernel() doesn't run, even the
first lines of the bootloader also not run (How can I prove whether the
latter is running or not?)
I also try to put some lighting-led-on-board codes at the very begining of
the arch/ppc/mbxboot/head.S , those red and green leds also don't light.

> > 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?
> the decompressor is part of the image but it expects the real image
> at a special address which you have to consider before downloading
> into ram.

Sorry, I don't know what you are meaning here.


> this will be done by the 8xxrom from Magnus Damm and some
> patches for the 823 avilable at http://www.s4l.de/powerpc.html of
> course :-)

Yes, I have downloaded your 8xxrom and studied these two functionss
elf_bootz (), bootvm() in elf.c. After reading the kernel "zImage" from
flash to RAM 0x00200000, you seem to handle them to strip the elf header
before you call start_loc() to run the bootloader. Am I right?
So when I download the "zImage" to RAM 0x00200000 on my custom board ,Need
I do the same thing as you before jumping there directly to run the
bootloader?

Thank you very much:-))
dony



> the 8xxrom resists in flash and load the linux kernel from
> a pcmcia ide hd or from flash using a rom-fs but this is an another
> solution that can be used in a ready product with little modifications
> in image selection...

> --
> Raphael Bossek <raphael.bossek@solutions4linux.de> [ICQ #40047651]
> PGP fingerprint: DF 6F 2C 76 46 1E B4 1C  5B A5 2E 1B FC E0 D3 F6
> PGP public key: http://www.solutions4linux.de/private/pgpkey.asc


** 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]

Brendan J Simon wrote:

> dony wrote:
>
> >       I want to cross-compile a very simple test program which have only one line:
> >
> >              printf("jsut a test.");
>
> I used puts("Brendan was here") as it is much simpler, but printf should work as well.
>
> >  But  the powerpc-linux-gcc seems to complain I lack of "crt1.o".
> > So what other tools I need to cross-compile my application except the powerpc-linux-*?
> > Thanks  very much.
> > dony
>
> I have crt1.o, crti.o and crtn.o in $prefix/$target/lib.  Initially they were put there
> when I unpacked the rpm files from the yellowdog distribution.  I was following some
> instructions from Kai Ruottu when I was trying to get my cross-compiler built.  I think
> I built glibc libraries from the source afterwards which should have replaced those ones
> but I'm not sure.
> Have you built glibc yet ?

Yes but failed. I following the following steps:

##################################
Cross Development for Linux/PPC

LibC
Get
ftp://sourceware.cygnus.com/pub/glibc/glibc-2.1.tar.gz
ftp://sourceware.cygnus.com/pub/glibc/glibc-linuxthreads-2.1.tar.gz
ftp://ftp.funet.fi/pub/gnu/funet/glibc-crypt-2.1.tar.gz
Build
ln -sf $CVS_LINUX_TOP/include/asm /usr/local/powerpc-linux/include/asm
ln -sf $CVS_LINUX_TOP/include/linux /usr/local/powerpc-linux/include/linux
tar zxf glibc-2.1.tar.gz
cd glibc-2.1
tar zxf ../glibc-crypt-2.1.tar.gz
tar zxf ../glibc-linuxthreads-2.1.tar.gz
mkdir build
cd build
CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib ../configure
--host=powerpc-linux --with-headers=$CVS_LINUX_TOP/include
--enable-add-ons=crypt,linuxthreads --prefix=/usr/local/powerpc-linux
make
make install
############################################

All except the last step are right. When I do "make install" , I get the following error:

########################################
../sysdeps/unix/sysv/linux/i386/profil-counter.h: In function `profil_counter':
In file included from ../sysdeps/unix/sysv/linux/powerpc/profil-counter.h:2,
                 from ../sysdeps/posix/profil.c:54,
                 from ../sysdeps/unix/sysv/linux/profil.c:3:
../sysdeps/unix/sysv/linux/i386/profil-counter.h:26: structure has no member named `regs'
../sysdeps/posix/profil.c:39: warning: inlining failed in call to `profil_count'
../sysdeps/unix/sysv/linux/i386/profil-counter.h:26: warning: called from here
make[2]: *** [/usr/local/powerpc-linux/glibc-2.1/build/gmon/profil.o] Error 1
make[2]: Leaving directory `/usr/local/powerpc-linux/glibc-2.1/gmon'
make[1]: *** [gmon/subdir_lib] Error 2
make[1]: Leaving directory `/usr/local/powerpc-linux/glibc-2.1'
make: *** [install] Error 2
################################

Since the glibc package is very very large, locating the file where errors occur (ie, where
struct singcontext is defined?) is a bit difficult.
Do you have any experience?

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:

> ##################################
> Cross Development for Linux/PPC
>
> LibC
> Get
> ftp://sourceware.cygnus.com/pub/glibc/glibc-2.1.tar.gz
> ftp://sourceware.cygnus.com/pub/glibc/glibc-linuxthreads-2.1.tar.gz
> ftp://ftp.funet.fi/pub/gnu/funet/glibc-crypt-2.1.tar.gz
> Build
> ln -sf $CVS_LINUX_TOP/include/asm /usr/local/powerpc-linux/include/asm
> ln -sf $CVS_LINUX_TOP/include/linux /usr/local/powerpc-linux/include/linux
> tar zxf glibc-2.1.tar.gz
> cd glibc-2.1
> tar zxf ../glibc-crypt-2.1.tar.gz
> tar zxf ../glibc-linuxthreads-2.1.tar.gz
> mkdir build
> cd build
> CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib ../configure
> --host=powerpc-linux --with-headers=$CVS_LINUX_TOP/include
> --enable-add-ons=crypt,linuxthreads --prefix=/usr/local/powerpc-linux
> make
> make install
> ############################################
>
> All except the last step are right. When I do "make install" , I get the following error:
>
> ########################################
> ../sysdeps/unix/sysv/linux/i386/profil-counter.h: In function `profil_counter':
> In file included from ../sysdeps/unix/sysv/linux/powerpc/profil-counter.h:2,
>                  from ../sysdeps/posix/profil.c:54,
>                  from ../sysdeps/unix/sysv/linux/profil.c:3:
> ../sysdeps/unix/sysv/linux/i386/profil-counter.h:26: structure has no member named `regs'
> ../sysdeps/posix/profil.c:39: warning: inlining failed in call to `profil_count'
> ../sysdeps/unix/sysv/linux/i386/profil-counter.h:26: warning: called from here
> make[2]: *** [/usr/local/powerpc-linux/glibc-2.1/build/gmon/profil.o] Error 1
> make[2]: Leaving directory `/usr/local/powerpc-linux/glibc-2.1/gmon'
> make[1]: *** [gmon/subdir_lib] Error 2
> make[1]: Leaving directory `/usr/local/powerpc-linux/glibc-2.1'
> make: *** [install] Error 2
> ################################
>
> Since the glibc package is very very large, locating the file where errors occur (ie, where
> struct singcontext is defined?) is a bit difficult.
> Do you have any experience?

I do not have the solution to your installation problem but I would just like to make a
suggestion for CC= when configuring for your mpc860 target.  Try CC="powerpc-linux-gcc
-mcpu=860" if the 860 is not your default processor when invoking gcc.  I think you can do
this at the configuration stage when building your cross-compiler or you can manually change
the specs file.

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

[Wolfgang Denk]

In message <387EDEF5.DBD612FA@huawei.com.cn> you write:
> 
>      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,

"sash" is the standalone shell, not bash; it  will  display  a  ">  "
prompt - not "bash# ".

> It justs shows :
> 
>     ls
>     pid 8: killed (signal 11)

Maybe you have a problem  with  you  shared  libraries.  Try  running
statically  link  versions  of  some  programs first. Does this work?
[Well, it should when you be able to run a shell...]

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Drun'? 'm not drun'! You woudn' dare call m' drun' if I was sober!
                                     - Terry Pratchett, _Men at Arms_

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

Re: Cross-compile Applications for 860 on x86

[Wolfgang Denk]

In message <387F0D81.48F7CABE@iname.com> Jim Chapman wrote:
> 
> Do "-ls" at the prompt, not "ls". Prepending "-" runs sash's builtin
> versions, otherwise it will try to find a ls on your ramdisk like any
> other shell. See sash's man page about all available builtin commands.

Or just type "help"

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Overdrawn?  But I still have checks left!

** 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 Applications for 860 on x86

[dony]

Jim Lewis wrote:

> dony wrote:
>
> > Hi,
> >
> > I download a older version of sash and now it works. It can run any built-in commands , but it fails to run
> > external programs , such as my test program "mytest". I put it both on / and /bin.
> > "-printenv" shows "PATH=/bin:/usr/bin:/etc". When I type "mytest" or "/bin/mytest" on the command prompt ">" , it
> > says "No such file or directory". And I cannot find some lines
> > about  "SASH"  in init/main.c.
> > Do you know why?
>
> Sounds like it  cannot find shared objects such as libc.so. You have two choices:
> 1) when you link the program, add the "-static" option

If I compile my test program which have only one "printf" line with "-static", It is about 1M size!  So I don't think
it's a good idea for me now.

>
> 2) put the necessary libraries in /lib

"rpc.nfsd -F -d call" says that it cannot find /etc/ld.so.cache and /etc/ld.so.preload. Yes, I have not these two files
after I decompress mbxroot.full.tgz.
Would you please send me a copy of these files? Thank you very much.h.


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

Re: Cross-compile Applications for 860 on x86

[Jim Lewis]

dony wrote:

> Hi,
>
> I download a older version of sash and now it works. It can run any built-in commands , but it fails to run
> external programs , such as my test program "mytest". I put it both on / and /bin.
> "-printenv" shows "PATH=/bin:/usr/bin:/etc". When I type "mytest" or "/bin/mytest" on the command prompt ">" , it
> says "No such file or directory". And I cannot find some lines
> about  "SASH"  in init/main.c.
> Do you know why?

Sounds like it  cannot find shared objects such as libc.so. You have two choices:
1) when you link the program, add the "-static" option
2) put the necessary libraries in /lib

If you have access to a linux-ppc machine, the command ldd with tell you what libraries will be loaded when the
command executes.

>
> Thank you very much.
>
> Jim Chapman wrote:
>
> > > In message <387EDEF5.DBD612FA@huawei.com.cn> you write:
> > > >
> > > >      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,
> > >
> > > "sash" is the standalone shell, not bash; it  will  display  a  ">  "
> > > prompt - not "bash# ".
> > >
> > > > It justs shows :
> > > >
> > > >     ls
> > > >     pid 8: killed (signal 11)
> > >
> > > Maybe you have a problem  with  you  shared  libraries.  Try  running
> > > statically  link  versions  of  some  programs first. Does this work?
> > > [Well, it should when you be able to run a shell...]
> > >
> >
> > Do "-ls" at the prompt, not "ls". Prepending "-" runs sash's builtin
> > versions, otherwise it will try to find a ls on your ramdisk like any
> > other shell. See sash's man page about all available builtin commands.
> > BTW, don't expect all standard command switches to work on those
> > builtins, since sash's versions are _very_ minimized.
> >
> > -Jim

-Jim Lewis


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

Re: Cross-compile Applications for 860 on x86

[Jim Lewis]

dony wrote:

> Jim Lewis wrote:
>
> > dony wrote:
> >
> > > Hi,
> > >
> > > I download a older version of sash and now it works. It can run any built-in commands , but it fails to run
> > > external programs , such as my test program "mytest". I put it both on / and /bin.
> > > "-printenv" shows "PATH=/bin:/usr/bin:/etc". When I type "mytest" or "/bin/mytest" on the command prompt ">" , it
> > > says "No such file or directory". And I cannot find some lines
> > > about  "SASH"  in init/main.c.
> > > Do you know why?
> >
> > Sounds like it  cannot find shared objects such as libc.so. You have two choices:
> > 1) when you link the program, add the "-static" option
>
> If I compile my test program which have only one "printf" line with "-static", It is about 1M size!  So I don't think
> it's a good idea for me now.
>
> >
> > 2) put the necessary libraries in /lib
>
> "rpc.nfsd -F -d call" says that it cannot find /etc/ld.so.cache and /etc/ld.so.preload. Yes, I have not these two files
> after I decompress mbxroot.full.tgz.
> Would you please send me a copy of these files? Thank you very much.h.

You don't really need those files. If they are not there, the loader will just look in the default places for the
libraries. A hello-world program will probably need /lib/ld.so.1 and /lib/libc.so.

If you do want those files, it would be best to build ldconfig and run it to generate ld.so.cache.


--
Jim Lewis


** 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/

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/