UartLite for MontaVista - virtex4

 
Hi all,
 
I am implementing the MontaVista linux previewkit a 2.4 Linux kernel for a 
PowerPC405 
on  a custom board based on ML403. Our design used Uartlite instead of Uart, 
I set the 
boot parameter in the kernel to console=ttl0,9600. The system uses a ramdisk 
image.
The problem is after linux trying to boot, there are error messages as shown 
below:
 
 
loaded at: 00400000 005E41E0
board data at: 005E1138 005E1150
relocated to: 0040530C 00405324
zimage at: 004058D7 0047B4A3
initrd at: 0047C000 005E0591
avail ram: 005E5000 04000000
 
Linux/PPC load: root=/dev/ram rw console=ttl0,9600 console=/dev/ttl0
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.20_mvl31-ml300 (devel@localhost.localdomain) (gcc version 
3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #23 Tue Mar 13 14:53:19 
EDT 2007
Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc. 
(source@mvista.com)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram rw console=ttl0,9600 console=/dev/ttl0
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
Calibrating delay loop... 296.55 BogoMIPS
Memory: 62164k available (868k kernel code, 252k data, 48k init, 0k highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Disabling the Out Of Memory Killer
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
Tracer: Initialization complete 
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1425k freed
VFS: Mounted root (ext2 filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 48k init
serial console detected. Disabling virtual terminals.
Xilinx OS Independent Code XAssert: xuartlite.c:195
Code may crash due to unhandled errors.
Xilinx OS Independent Code XAssert: xuartlite.c:195
Code may crash due to unhandled errors.
Xilinx OS Independent Code XAssert: xuartlite.c:195
Code may crash due to unhandled errors.
Xilinx OS Independent Code XAssert: xuartlite.c:195
Code may crash due to unhandled errors.
 
 
We don't know what is causing the problem, any help would be appreciated.
 
Thanks,
Tai.
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jantira Hengmeechai (Tai)
Embedded Software Developer
 
Linear Systems Ltd.
1717 Dublin Avenue, Unit 1
Winnipeg., MB., R3H 0H2, Canada 
Phone: 1 204 632 4300 ext.23, Fax: 1 204 697 2417

Xilinx OS Independent Code XAssert: xuartlite.c:195
Code may crash due to unhandled errors.
Xilinx OS Independent Code XAssert: xuartlite.c:195
Code may crash due to unhandled errors.
Xilinx OS Independent Code XAssert: xuartlite.c:195
Code may crash due to unhandled errors.
Xilinx OS Independent Code XAssert: xuartlite.c:195
Code may crash due to unhandled errors.

This code is...

unsigned int XUartLite_Send(XUartLite *InstancePtr, u8 *DataBufferPtr,
                            unsigned int NumBytes)
{
    unsigned int BytesSent;
    u32 StatusRegister;

    /*
     * Assert validates the input arguments
     */
    XASSERT_NONVOID(InstancePtr !=3D NULL);
    XASSERT_NONVOID(DataBufferPtr !=3D NULL);
    XASSERT_NONVOID(InstancePtr->IsReady =3D=3D XCOMPONENT_IS_READY);
    XASSERT_NONVOID(((signed)NumBytes) >=3D 0); // Line 195

There's a patch against the file xuartlite_serial.c to fix a problem
where a backlog of bytes causes NumBytes to be a negative number.
Grab the latest xuartlite_serial.c file from your EDK distribution.

Tim

Hi Tim,

Could you tell me where exactly to get the  "xuartlite_serial.c" ?

I could not find "xuartlite_serial.c" in the drivers folder generated by EDK 
.
(\ppc405_0\libsrc\linux_mvl31_v1_01_b\linux\drivers\char\xilinx_uartlite)

Look forward to hearing from you.
Thanks,
Tai
-----Original Message-----
From: "Martin, Tim" <redacted>
To: "Jantira Hengmeechai \(Tai\)" <redacted>, 
[off-list ref]
Date: Wed, 14 Mar 2007 11:12:55 -0700
Subject: RE: UartLite for MontaVista - virtex4

  Xilinx OS Independent Code XAssert: xuartlite.c:195
  Code may crash due to unhandled errors.
  Xilinx OS Independent Code XAssert: xuartlite.c:195
  Code may crash due to unhandled errors.
  Xilinx OS Independent Code XAssert: xuartlite.c:195
  Code may crash due to unhandled errors.
  Xilinx OS Independent Code XAssert: xuartlite.c:195
  Code may crash due to unhandled errors.

This code is...

unsigned int XUartLite_Send(XUartLite *InstancePtr, u8 *DataBufferPtr,
                            unsigned int NumBytes)
{
    unsigned int BytesSent;
    u32 StatusRegister;

    /*
     * Assert validates the input arguments
     */
    XASSERT_NONVOID(InstancePtr != NULL);
    XASSERT_NONVOID(DataBufferPtr != NULL);
    XASSERT_NONVOID(InstancePtr->IsReady == XCOMPONENT_IS_READY);
    XASSERT_NONVOID(((signed)NumBytes) >= 0); // Line 195

There's a patch against the file xuartlite_serial.c to fix a problem
where a backlog of bytes causes NumBytes to be a negative number.
Grab the latest xuartlite_serial.c file from your EDK distribution.

Tim
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Could you tell me where exactly to get the  "xuartlite_serial.c"

?

=20
I could not find "xuartlite_serial.c" in the drivers folder

generated by EDK .

(\ppc405_0\libsrc\linux_mvl31_v1_01_b\linux\drivers\char\xilinx_uartlite
)

Here's the relevant snippet for xulite_send_handler():
=20
/*
* if(pxs->thr_chars[0] !=3D 0) then
* throttle/unthrottle character was just sent;
* do not advance pgs->xmit_tail by ByteCount
* in this case.
*/
if (pxs->thr_chars[0] =3D=3D 0) {
pxs->tx_int_cnt +=3D ByteCount;

if (pgs->xmit_cnt >=3D ByteCount) {
pgs->xmit_cnt -=3D ByteCount;
pgs->xmit_tail +=3D ByteCount;
} else {
pgs->xmit_tail +=3D pgs->xmit_cnt;
pgs->xmit_cnt =3D 0;
}
if (pgs->xmit_tail >=3D SERIAL_XMIT_SIZE)
pgs->xmit_tail -=3D SERIAL_XMIT_SIZE;
} else {
pxs->tx_thr_cnt +=3D ByteCount;
}



=20
=09

Hello,

Martin, Tim wrote:

quoted

	Could you tell me where exactly to get the  "xuartlite_serial.c"

?

quoted

	 
	I could not find "xuartlite_serial.c" in the drivers folder

generated by EDK .
(\ppc405_0\libsrc\linux_mvl31_v1_01_b\linux\drivers\char\xilinx_uartlite
)

Here's the relevant snippet for xulite_send_handler():
 
/*
* if(pxs->thr_chars[0] != 0) then
* throttle/unthrottle character was just sent;
* do not advance pgs->xmit_tail by ByteCount
* in this case.
*/
if (pxs->thr_chars[0] == 0) {
pxs->tx_int_cnt += ByteCount;

if (pgs->xmit_cnt >= ByteCount) {
pgs->xmit_cnt -= ByteCount;
pgs->xmit_tail += ByteCount;
} else {
pgs->xmit_tail += pgs->xmit_cnt;
pgs->xmit_cnt = 0;
}
if (pgs->xmit_tail >= SERIAL_XMIT_SIZE)
pgs->xmit_tail -= SERIAL_XMIT_SIZE;
} else {
pxs->tx_thr_cnt += ByteCount;
}

This seems to be a part of the fix. IIRC the "default"
gs_flush_buffer() method doesn't work well for UART Lite.
Hence the fix we have done quite some time ago (see below).
It includes the correction pointed out by Tim, and also adds
custom flush_buffer().
The patch is against a custom tree, but it should be easy to
make it apply to the 2.4 kernel tree Tai is using.
Probably this patch was not posted here just because the linuxppc-2.4
kernel tree had been obsoleted, and there was no support for
UART Lite in the kernel.org tree.

Thanks,
Andrei