[PATCH] Xilinx UART Lite 2.6.18 driver
David H. Lynch Jr.
dhlii at dlasys.net
Wed Nov 1 04:26:04 EST 2006
Peter Korsgaard wrote:
>>>>>> "David" == David H Lynch <dhlii at dlasys.net> writes:
>>>>>>
>
> David> There is a substantial time/code difference between the
> David> time ulite_console_setup() is called and the time the platform
> David> device is initiallized.
>
> Huh?
>
> (gdb) br ulite_probe
> Breakpoint 2 at 0xc00f7530: file drivers/serial/uartlite.c, line 397.
> (gdb) br ulite_console_setup
> Breakpoint 3 at 0xc00f7454: file drivers/serial/uartlite.c, line 342.
> (gdb) c
> Continuing.
>
> Breakpoint 2, ulite_probe (pdev=0xc00ddb50) at drivers/serial/uartlite.c:397
> 397 return -EINVAL;
> (gdb) c
> Continuing.
>
> Breakpoint 3, ulite_console_setup (co=0xc00e2f14, options=0xc00fe00f "115200")
> at drivers/serial/uartlite.c:342
> 342 if (co->index < 0 || co->index >= ULITE_NR_UARTS)
>
> _probe get's called before console_setup, so we have all the
> information to output console data right away.
I am not nearly as familiar with your driver and David B. Early
serial patches as I am with my own.
But I can assure you that the early serial init code occurs well
before the call to probe.
If that is not the case then there is no reason for the early serial
code to even exist.
Does David B.'s patch include support for early_serial_init(struct
uart_port *) ?
Look at other BSP's, most have early serial support.
One of the reasons I modeled my driver off the 8250 was because it
had boot to bash support.
If the 8250 did something in a particular way I did the same for the
uartlite - unless I really deeply understood why
I needed not to. I implimented every relevant 8250 feature every
step of the way.
I actually started with the early serial code long before I started
with the driver. It was fairly trivial. It gets you fairly far into the
boot process,
and you can call it directly for debugging.
> David> But for now, if you are not going to bother making
> David> console_settup() work you might as well not put the rest of the
> David> early serial code in at all.
>
> Not going to make it work? What doesn't work?
>
If you impliment early_serial_setup(struct uart_port *) then you
must initialize the driver at the time of that call using a uart_port
struct.
Unless you are going to redefine early_serial_setup() specifically
for the uartlite - maybe that is possible, I don't know, but it sounds
like a bad idea.
I have attached the boot text from a Pico E14 - this one using my
Keyhole port serial driver not the uartlite drive - but since I
patterned them both after the 8250
the sequence is the same.
The serial_init() call initializes the mini_driver in
arch/ppc/boot/simple - in the case of uartlite that would be uartlite_tty.c
keyhole_init() or uartlite_init() is in arch/ppc/syslib - in the
case of uartlite uartlite_dbg.c
that is followed immediately by early_serial_init() - basically
meaning unless you make heavy use of progress() calls - and with
early_serial_init() you can call printk and receive output immediately,
uartlite_dbg.c is probably unneeded but it is trivial and damn
near identical to uartlite_tty.c
early_serial_init() is followed nearly immediately with
keyhole_console_setup() or uartlite_console_setup()
Much late Linux starts initializing the serial drivers and calls probe.
If you do not impliment early_serial_setup, then you will be blind
from that point until the probe call occurs. If anything goes wrong you
will have to try to dump the printk buffer in memory to find out what
went wrong.
I do not know what hardware you are using or how your BSP is
constructed.
The whole early serial text system has little use for a system that
is working perfectly.
But it could be a life saver for somebody doing board bringup.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
.
Loading zImage.elf.
[keyhole] serial_init()
loaded at: 00800000 00ABC13C
board data at: 0FFFFF60 0FFFFF7C
relocated to: 00804030 0080404C
zimage at: 00804E01 00AB9C2E
avail ram: 00ABD000 0FFFFFFF
Linux/PPC load: root=/dev/ram
Uncompressing Linux...done.
Now booting the kernel
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
keyhole_init()
keyhole:early_serial_setup()
arch: exit
keyhole_console_setup()
Linux version 2.6.19-rc2 (root at pico.dlasys.net) (gcc version 3.4.1) #2
Tue Oct 31 11:24:48 EST 2006
Pico Virtex-4 port
Port by DLA Systems (info at dlasys.net)
Zone PFN ranges:
DMA 0 -> 65535
Normal 65535 -> 65535
early_node_map[1] active PFN ranges
0: 0 -> 65535
Built 1 zonelists. Total pages: 65024
Kernel command line: root=/dev/ram
Xilinx INTC #0 at 0x41200000 mapped to 0xF5FFD000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 255488k available (1272k kernel code, 724k data, 2052k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
io scheduler noop registered (default)
Serial: Xilinx uartlite driver $Revision: 0.10 $ 1 ports
Serial: Pico keyhole driver $Revision: 0.20 $*
keyhole_device_probe()
ttyS0 at MMIO 0x70000000 (irq = -1) is a keyhole
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
TCP cubic registered
NET: Registered protocol family 17
Freeing unused kernel memory: 2052k init
command='/bin/sh' action='2' terminal='/dev/ttyS0'
command='/etc/init.d/rcS' action='1' terminal='/dev/ttyS0'
command='/sbin/init' action='128' terminal='/dev/ttyS0'
command='/sbin/reboot' action='32' terminal='/dev/ttyS0'
command='/sbin/swapoff -a 2>/dev/null' action='64' terminal='/dev/ttyS0'
command='/bin/umount -a -r' action='64' terminal='/dev/ttyS0'
Starting DHCP client: udhcpc a
BusyBox v1.2.0 (2006.07.21-07:20+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/ $
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii at dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20061031/4c1dd475/attachment.htm
More information about the Linuxppc-embedded
mailing list