Peter Korsgaard wrote:
I am not nearly as familiar with your driver and David B. Early serial patches as I am with my own."David" == David H Lynch <[EMAIL PROTECTED]> 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. 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. 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.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? 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 ([EMAIL PROTECTED]) (gcc version 3.4.1) #2 Tue Oct 31 11:24:48 EST 2006 Pico Virtex-4 port Port by DLA Systems ([EMAIL PROTECTED]) 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='' terminal='/dev/ttyS0' command='/etc/init.d/rcS' action='' terminal='/dev/ttyS0' command='/sbin/init' action='' terminal='/dev/ttyS0' command='/sbin/reboot' action='' terminal='/dev/ttyS0' command='/sbin/swapoff -a 2>/dev/null' action='' terminal='/dev/ttyS0' command='/bin/umount -a -r' action='' 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 [EMAIL PROTECTED] 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 |
_______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
