Re: problem on MPC8xx

Re: problem on MPC8xx

[LiuTao]

Hi:

> Hmmmm... Well, I remember when I got to this point it took a week or so to
> get the bash prompt to actually come out.  It was rather irritating being
> 95% of the way and stumped.  Try this, since bash is the first real process
> that runs it really stresses the board and the memory timings, etc.  Make
> sure that the libraries are being loaded and it isn't hanging half-way.  Try
> modifying fs/namei.c and put a printk at the top of open_namei to print the
> pathname.... that should dump which files are being loaded... email me the
> results of that.
I added printk() in open_namie(), the output is:

pathname:/dev/conle
pathname:/sbin/init
pathname:/etc/init
pathname:/bin/initstarting /bin/sh...

pathname:/bin/sh
pathname:/lib/ld.so.1
pathname:/etc/ld.so.preload
pathname:/etc/ld.so.cache
pathname:/lib/libtermcap.so.2
pathname:/lib/libdl.so.2
pathname:/lib/libc.so.6

Is that all right?
Another question, I don't have a PowerPC box, I build Linux on a x86 box
with cross compile environment, can I make a ramdisk? The ramdisk I am
using
is a little large, I want to make a smaller one.

Thanks!

LiuTao

> Hi Jason:
>
> I am sorry that another problem appeared.
> After the /bin/sh ran, I can't see anything from console.
> I open the compile switch "SERIAL_DEBUG_INTR" in uart.c,
> then I can see the following message on console:
>
> THRE...rs_interrupt_single(0, 2)...end.
> THRE...rs_interrupt_single(0, 2)...end.
> .
> .
> .
>
> It means that the transmit interrupt is triggered, right?
> But why I can't see anything?
> And can you tell me that when shell outputs message to console,
> which function it uses in uart.c? I think it should be
> rs_8xx_write(), right? But I found that this function was not
> called before interrupt happened.
>
> Thanks!
>
> LiuTao
>
> >
> > I'm glad to hear you resolved your problem.  If I can lend you any other
> > assistance, let me know, I have gone all the way through porting the
> kernel
> > to a custom 860 board now and are familiar with solutions to some
> stumbling
> > blocks.
> >
> > Jason
> >
> > -----Original Message-----
> > From: LiuTao [mailto:tliu@ict.ac.cn]
> > Sent: Thursday, March 02, 2000 5:24 AM
> > To: Jason Wohlgemuth
> > Subject: Re: problem on MPC8xx
> >
> > Hi Jason:
> >
> > Thanks for your attention!
> > I found the problem in uart.c, the BRG is setup incorrectly.
> > I have resolved the problem.
> > Now, I can see message from console port.
> >
> > Thanks.
> >
> > LiuTao
>

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

Re: problem on MPC8xx

[LiuTao]

Hi Jason:

I am sorry that another problem appeared.
After the /bin/sh ran, I can't see anything from console.
I open the compile switch "SERIAL_DEBUG_INTR" in uart.c,
then I can see the following message on console:

THRE...rs_interrupt_single(0, 2)...end.
THRE...rs_interrupt_single(0, 2)...end.
.
.
.

It means that the transmit interrupt is triggered, right?
But why I can't see anything?
And can you tell me that when shell outputs message to console,
which function it uses in uart.c? I think it should be
rs_8xx_write(), right? But I found that this function was not
called before interrupt happened.

Thanks!

LiuTao

>
> I'm glad to hear you resolved your problem.  If I can lend you any other
> assistance, let me know, I have gone all the way through porting the kernel
> to a custom 860 board now and are familiar with solutions to some stumbling
> blocks.
>
> Jason
>
> -----Original Message-----
> From: LiuTao [mailto:tliu@ict.ac.cn]
> Sent: Thursday, March 02, 2000 5:24 AM
> To: Jason Wohlgemuth
> Subject: Re: problem on MPC8xx
>
> Hi Jason:
>
> Thanks for your attention!
> I found the problem in uart.c, the BRG is setup incorrectly.
> I have resolved the problem.
> Now, I can see message from console port.
>
> Thanks.
>
> LiuTao

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

Re: problem on MPC8xx

[LiuTao]

Hi:

I can see everything on console port now.
The last a few messages are:

CPM UART driver version 0.02
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0100 is a SCC
ttyS02 at 0x0200 is a SCC
RAM disk driver initialized:  16 RAM disks of 4096K size
eth0: CPM ENET Version 0.2, 00:00:00:00:00:00
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
mount_initrd:1,dev:256,256,ma:1,mi:0Freeing unused kernel memory: 32k in

Then, what should happen? Is that all right?

Thanks!

LiuTao

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

Re: problem on MPC8xx

[LiuTao]

Hi Jason:

> Which CPM port do you need to use, I have modified the kernel for our custom
> board to support serial consoles on all the SMC's and SCC's.  The
> ramdisk.image.gz of mbx is probably aimed at SMC1 or ttyS0, you will
> probably just want to make your own from a slightly modified minroot.

I just use SMC1 as my console port. I show you all messages from
log_buf:

<4>Linux version 2.2.13 (tliu@Saxophone)
 (gcc version egcs-2.91.66 19990314
 (egcs-1.1.2 release))
  #166 Mon Feb 28 20:55:48 GMT+82000.
<4>Boot arguments: root=/dev/ram.
<4>time_init: decrementer frequency = 240000000/60.
<4>Calibrating delay loop... 63.69 BogoMIPS.
<4>Memory: 13412k available
 (640k kernel code, 412k data, 32k init) [c0000000,c1000000].
<4>DENTRY hash table entries: 262144 (order: 9, 2097152 bytes).
<4>Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes).
<4>Page-cache hash table entries: 4096 (order: 2, 16384 bytes).
<4>POSIX conformance testing by UNIFIX.
<6>Linux NET4.0 for Linux 2.2.
<6>Based upon Swansea University Computer Society NET3.039.
<6>NET4: Unix domain sockets 1.0 for Linux NET4.0..
<6>NET4: Linux TCP/IP 1.0 for NET4.0.
<6>IP Protocols: ICMP, UDP, TCP, IGMP.
<4>TCP: Hash tables configured (ehash 16384 bhash 16384).
<4>Starting kswapd v 1.5 .
<6>CPM UART driver version 0.02.
<6>ttyS00 at 0x0280 is a SMC.
<6>ttyS01 at 0x0100 is a SCC.
<6>ttyS02 at 0x0200 is a SCC.
<4>RAM disk driver initialized:  16 RAM disks of 4096K size.
<4>eth0: CPM ENET Version 0.2, 00:00:00:00:00:00.
<5>RAMDISK: Compressed image found at block 0.
<4>VFS: Mounted root (ext2 filesystem)..
<4>Freeing unused kernel memory: 32k .
<4>rs_open ttyS0, count= 1.
<4>starting up ttys0 (irq 4)
...rs_open ttys0 successful.....



> Methods of testing, sure whether or not characters are coming out of the
> serial port.

I mean that what I should write to test it. eg. printf() or write() or
etc.

> Most likely you will need to modify m8xx_tty.c and not uart.c, from what I

I have modified m8xx_tty.c successfully, but you know, that's not the
true serial driver. I can see the following on serial port:

loaded at:     00200000 0020B1BC
board data at: 0020013C 00200158
relocated to:  001F0100 001F011C
zimage at:     002301B4 002873CC
initrd at:     002873CC 0045E209
avail ram:     0045F000 00FFFFFF

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

But after the Linux boot up, I can't see anything.

> remember uart.c works just fine but you have to have the /dev/console link
> correct.  Let me know which port you want to use and I will look into it.
I don't hope to modify uart.c too.
I am using SMC1 to be serial port.

Thanks for your help!

LiuTao

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

problem on MPC8xx

[LiuTao]

Hi:

I am debugging Linux on my customized board.
The messages in log_buf are all right. The shell in RAM disk
also runs. But I can't see anything on serial port.
I want to know:
1. May I use ramdisk.image.gz of mbx as my ramdisk?
2. Need I modify the uart.c? If I need, which part I should modify?
3. Is there any meathod to test if the serial port is OK?

Thanks!

LiuTao

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