<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Korsgaard wrote:
<blockquote cite="mid:87pscap5zq.fsf@sleipner.barco.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">"David" == David H Lynch <a
class="moz-txt-link-rfc2396E" href="mailto:dhlii@dlasys.net"><dhlii@dlasys.net></a> writes:
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
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.</pre>
</blockquote>
I am not nearly as familiar with your driver and David B. Early
serial patches as I am with my own.<br>
But I can assure you that the early serial init code occurs well
before the call to probe.<br>
<br>
If that is not the case then there is no reason for the early
serial code to even exist.<br>
<br>
Does David B.'s patch include support for early_serial_init(struct
uart_port *) ?<br>
<br>
Look at other BSP's, most have early serial support.<br>
<br>
One of the reasons I modeled my driver off the 8250 was because it
had boot to bash support.<br>
If the 8250 did something in a particular way I did the same for
the uartlite - unless I really deeply understood why <br>
I needed not to. I implimented every relevant 8250 feature every
step of the way.<br>
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, <br>
and you can call it directly for debugging.<br>
<br>
<br>
<br>
<blockquote cite="mid:87pscap5zq.fsf@sleipner.barco.com" type="cite">
<pre wrap="">
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?
</pre>
</blockquote>
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.<br>
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.<br>
<br>
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<br>
the sequence is the same.<br>
The serial_init() call initializes the mini_driver in
arch/ppc/boot/simple - in the case of uartlite that would be
uartlite_tty.c<br>
keyhole_init() or uartlite_init() is in arch/ppc/syslib - in the
case of uartlite uartlite_dbg.c<br>
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,
<br>
uartlite_dbg.c is probably unneeded but it is trivial and damn
near identical to uartlite_tty.c<br>
early_serial_init() is followed nearly immediately with
keyhole_console_setup() or uartlite_console_setup()<br>
Much late Linux starts initializing the serial drivers and calls
probe.<br>
<br>
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.<br>
<br>
I do not know what hardware you are using or how your BSP is
constructed.<br>
The whole early serial text system has little use for a system that
is working perfectly.<br>
But it could be a life saver for somebody doing board bringup.<br>
<br>
<br>
<br>
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<br>
<br>
.<br>
Loading zImage.elf.<br>
[keyhole] serial_init()<br>
<br>
loaded at: 00800000 00ABC13C<br>
board data at: 0FFFFF60 0FFFFF7C<br>
relocated to: 00804030 0080404C<br>
zimage at: 00804E01 00AB9C2E<br>
avail ram: 00ABD000 0FFFFFFF<br>
<br>
Linux/PPC load: root=/dev/ram<br>
Uncompressing Linux...done.<br>
Now booting the kernel<br>
id mach(): done<br>
MMU:enter<br>
MMU:hw init<br>
MMU:mapin<br>
MMU:setio<br>
MMU:exit<br>
setup_arch: enter<br>
setup_arch: bootmem<br>
keyhole_init()<br>
keyhole:early_serial_setup()<br>
arch: exit<br>
<br>
keyhole_console_setup()<br>
Linux version 2.6.19-rc2 (<a class="moz-txt-link-abbreviated" href="mailto:root@pico.dlasys.net">root@pico.dlasys.net</a>) (gcc version 3.4.1) #2
Tue Oct 31 11:24:48 EST 2006<br>
Pico Virtex-4 port<br>
Port by DLA Systems (<a class="moz-txt-link-abbreviated" href="mailto:info@dlasys.net">info@dlasys.net</a>)<br>
Zone PFN ranges:<br>
DMA 0 -> 65535<br>
Normal 65535 -> 65535<br>
early_node_map[1] active PFN ranges<br>
0: 0 -> 65535<br>
Built 1 zonelists. Total pages: 65024<br>
Kernel command line: root=/dev/ram<br>
Xilinx INTC #0 at 0x41200000 mapped to 0xF5FFD000<br>
PID hash table entries: 1024 (order: 10, 4096 bytes)<br>
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)<br>
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)<br>
Memory: 255488k available (1272k kernel code, 724k data, 2052k init, 0k
highmem)<br>
Mount-cache hash table entries: 512<br>
NET: Registered protocol family 16 <br>
NET: Registered protocol family 2<br>
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)<br>
TCP established hash table entries: 8192 (order: 3, 32768 bytes)<br>
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)<br>
TCP: Hash tables configured (established 8192 bind 4096)<br>
TCP reno registered<br>
io scheduler noop registered (default)<br>
Serial: Xilinx uartlite driver $Revision: 0.10 $ 1 ports<br>
Serial: Pico keyhole driver $Revision: 0.20 $*<br>
keyhole_device_probe()<br>
ttyS0 at MMIO 0x70000000 (irq = -1) is a keyhole<br>
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize<br>
TCP cubic registered<br>
NET: Registered protocol family 17<br>
Freeing unused kernel memory: 2052k init<br>
command='/bin/sh' action='2' terminal='/dev/ttyS0'<br>
command='/etc/init.d/rcS' action='1' terminal='/dev/ttyS0'<br>
command='/sbin/init' action='128' terminal='/dev/ttyS0'<br>
command='/sbin/reboot' action='32' terminal='/dev/ttyS0'<br>
command='/sbin/swapoff -a 2>/dev/null' action='64'
terminal='/dev/ttyS0'<br>
command='/bin/umount -a -r' action='64' terminal='/dev/ttyS0'<br>
Starting DHCP client: udhcpc a<br>
BusyBox v1.2.0 (2006.07.21-07:20+0000) Built-in shell (ash)<br>
Enter 'help' for a list of built-in commands.<br>
/ $ <br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 <a
class="moz-txt-link-abbreviated" href="mailto:dhlii@dlasys.net">dhlii@dlasys.net</a> <a
class="moz-txt-link-freetext" href="http://www.dlasys.net">http://www.dlasys.net</a>
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
</pre>
</body>
</html>