Date: Wed, 12 Feb 2003 17:24:54 +0900 From: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> To: freebsd-arch@freebsd.org Cc: "Glenn Gombert" <freebsd@fastmail.fm>, julian@elischer.org, ikob@freebsd.org Subject: You may want to have FireWire.... Message-ID: <ybsd6lxsy7d.wl@ett.sat.t.u-tokyo.ac.jp> In-Reply-To: <20030209193737.D91611DEAB@www.fastmail.fm>
next in thread | previous in thread | raw e-mail | index | archive | help
Do you think this useful? /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html -------------------------------- * What's dcons and fwchat for? I wrote this driver(dcons(4)) and utility(fwchat(8)) for a replacement of the serial console. This framework exploits physical access faculty of the IEEE1394 OHCI chip(fwochi(4)). This means that you cannot access this console until the OHCI is initialized on target system but once it's initialized, there is no need of OS support to do transactions on the FireWire bus until next bus reset occurs. This enables us to use this console as DDB/GDB port too. By analogy with pty(4), dcons(4) acts like a slave device and fwchat(8) acts like a master device, but they are on different machines and interact via FireWire. Please note dcons(4) is device(FireWire)-independent by itself. (And almost plathome independent) dcons(4) can be loaded as a modules but I recommend you to link it to kernel statically for several reasons especially when used with gdb. On -current, thanks to multiple console device support(conscontrol(8)), we can use syscons(4) and dcons(4) as console and DDB port at the same time. On -stable, because the only one console device is allowed, we have to hijack the console port from syscons(4) to use dcons(4) as the console. (Define FORCE_CONSOLE to 1 in dcons.c for this.) Even it is not used as console, it can still be used as GDB(not DDB) port. I have tested them on i386 -current mainly. But I expect that they should work on -stable and other architecture too. I'm not sure whether fwochi(4) driver is working on other plathomes like sparc64 and ia64. Even it doesn't work, it shouldn't be so difficult to make it work because we only need initialization step to work on the target system at least. My VAIO C1 has no serial port, no ethernet port nor SCSI bus but a i.Link(FireWire) port. Now it has two virtual serial port by dcons(4), a virtual ethernet port by if_fwe(4) and native SBP(SCSI) bus by sbp(4) :-) * Open problem: buffer allocation fwchat(8) needs to know the physical address of the buffer on the target, this is the most pain part for users. If we can allocated the buffer at some fixed physical address, it's very useful. (4 bytes buffer should be enough to hold a pointer to the real buffer.) I need some help from someone familiar with bootstrap process on each architecture! But I still don't want dcons(4) to be architecture dependent too much. there are several scenarios when the initialization routine is called. (1) called from cninit(): dcons(4) is statically compiled into kernel and its (console) priority is higher than any other devices. In this case, we can not use (contig)malloc yet. Currently I allocated static buf for this case. (2) called in SI_SUB_DRIVERS stage ( i) statically linked but low priority we can use contigmalloc'ed and static buf. ( ii) loaded as module in loader. we can use contigmalloc'ed and static buf. (iii) loaded as module after boot. we have to use contigmalloc because static buf might be fragmented in physical address space. I'm not sure how many developpers and administrators use serial console extensively and how many of them think this framework is useful. Any comments and suggestions are welcome! The current development code can be find under: http://people.freebsd.org/~simokawa/firewire with name "dcons-XXX.tar.gz". Hidetoshi Simokawa <simokawa@sat.t.u-tokyo.ac.jp>, <simokawa@freebsd.org> FWCHAT(8) FreeBSD System Manager's Manual FWCHAT(8) NAME fwchat - Proxy between dcons over FireWire and TCP/IP SYNOPSIS fwchat [-brv] [-p base port] -t target eui64 -a address --------- ------------ ------- DESCRIPTION The fwchat utility is designed to provide a way for users to access dcons(4) (dumb console device) on a target system. The fwchat interacts with dcons over FireWire and interact with a user over TCP/IP. The fwchat and dcons(4) communicate using 2 port, one for console port and the other for remote gdb port. The user is supposed to access fwchat using telnet and/or gdb. The fwchat listens on local- host:base port for console port and localhost:(base port + 1) for gdb - - port. By analogy with pty(4) device, the dcons(4) acts as a slave device and fwchat acts as a master device with telnetd(8). -b Translate Ctrl-C to ALT BREAK(CR + ~ + Ctrl-B) on gdb port. - -r Disable adhoc workaround for telnet and forward raw data on con- sole port. It might be useful when you access fwchat using other than telnet. -v Verbose debug output. Multiple '-v' increase verbosity. -p base port --------- Specify base port. Currently, default is 5555. - -t target eui64 ------------ Specify the 64bit extended unique identifier of the target. -a address ------- Specify the physical address of dcons buffer. See dcons(4) for details. EXAMPLE To run fwchat, you have to specify the eui64 of the target and the pyhsi- cal address of the dcons buffer. You can obtain EUI64 by running fwcontorl(4) without options. The first EUI64 is of the host running fwcontrol and others on the bus follow. # fwcontrol 2 devices (info len=2) - node EUI64 status 1 7766554433221100 0 0 0011223344556677 1 The EUI64 doesn't change unless you chage the hardware as the ethernet address. Getting the physical address of the dcons buffer is somewhat a pain. There are several ways to obtain it but only one method is explained here. See dcons(4) for the other methods. The method explained here needs kernel image including symbol table but can be done on host side without help of the target. # sysctl hw.firewire.fwmem.eui64 hi=0x00112233 - # sysctl hw.firewire.fwmem.eui64 lo=0x44556677 - # gdb -k kernel.debug /dev/fwmem0 (kgdb) p/x dcons paddr - $1 = 0x123450 Now we can run the fwchat. # fwchat -vb -p 12345 -t 0x00112233445566677 -a 0x123450 Currently, fwchat doesn't become a daemon. Open another window and run: % telnet localhost:12345 You'll get console output of the target and login prompt if a getty is running on dcons. You can break to DDB with ALT BREAK (CR + ~ + Ctrl-B) - if DDB and ALT BREAK TO DEBUGGER is enabled in the target kernel. - - - Using gdb port is almost the same as remote gdb over serial line except using TCP/IP instead of /dev/cu*. See "On-line Kernel Debuggind Using Remote GDB" section of The FreeBSD Developpers Handbook. % gdb -k kernel.debug (kgdb) target remote :12346 Once gdb is attached and you specified '-b' option to fwchat, typing "Ctrl-C" on gdb causes break to debugger. FILES /dev/fwmem0 SEE ALSO ddb(4), firewire(4), fwohci(4), fwcontrol(8,) gdb(1), telnet(1) AUTHORS Hidetoshi Shimokawa <simokawa@FreeBSD.org> BUGS This utility is still under development and it could have serious secu- rity problem. FreeBSD 4.7 February 11, 2003 FreeBSD 4.7 DCONS(4) FreeBSD Kernel Interfaces Manual DCONS(4) NAME dcons - dumb console device driver SYNOPSIS device dcons options DDB options ALT BREAK TO DEBUGGER - - - device fwohci device firewire DESCRIPTION The dcons device is the simple console device which just reads from and writes to an allocated buffer for input and output respectivly. It is no use by itself and it is supposed that the buffer is accessed via a bus like FireWire(4) for interaction. The buffer consists of 4 channels. There are 2 ports, one for console tty and other is GDB ports then each port has a input channel and a out- put channel. The physical address of the buffer is sometimes neccesary to acess the buffer. You can get the address by sysctl(8) or dmesg(8) EXAMPLE If you want to run getty(8) on dcons, insert following line into /etc/ttys(5) and send a HUP signal to init(8) using kill(1). dcons "/usr/libexec/getty std.9600" vt100 on secure You can use either of the following commands to obtain physical address of the buffer. % sysctl kern.dcons.paddr kern.dcons.paddr: 4732704 % dmesg | grep dcons: | tail -1 dcons: virtual 0xc0483720 physical 0x483720 quad 0x120dc8 In this example, the buffer is located at 4732704 in decimal and 0x483720 in hex. Once fwochi(4) device is initialized to allow physical access, the buffer can be accessed from another host via FireWire bus using fwchat(8) appli- cation. See fwchat(8) for more details. FILES /dev/dcons /dev/dconsctl /etc/ttys SEE ALSO ddb(4), firewire(4), fwohci(4), fwchat(8), fwcontrol(8), ttys(5) AUTHORS Hidetoshi Shimokawa <simokawa@FreeBSD.org> BUGS This driver is still under development. FreeBSD 4.7 February 11, 2003 FreeBSD 4.7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybsd6lxsy7d.wl>