Re: Excellent job on the firewire support!

(sorry for resending)

At Sun, 18 Jul 2004 21:04:53 +0100,
Doug Rabson wrote:
> > It would be nice to remove my Comtrol Rocketport serial card, and the
> > 8 serial cables leading across the middle of the room to my shelf of
> > machines and replace it with one firewire cable leading to a firewire
> > hub. But, as a firewire newbie, I have some questions:
> >
> > 1) Is any firewire PCI adapter just as good as any other in terms of
> >    performance, and FreeBSD support? (prices seem to range from $10
> > to $100)
> 
> Any should do about as well as any other. I probably wouldn't want to 
> spend more than ~$50 on one.

I got some bad report about Lucent chip(some Mac's have it)
but I haven't heard any other compatibility issue.
I think the price of the adapter doesn't matter but you may
have trouble with some bad cables. If have some problem,
use lower speed(S100) or change cables.

> >
> > 2) Is dcons usable after a panic (ie, DDB or KDB_TRACE)?  Or is it
> >    only usable for remote-gdb?
> 
> Dcons provides two full duplex streams - one for console and one for 
> gdb. You can use DDB on the console just like normal.

It's designed for such panic/debugging situation.
Actually, it's rather inefficient for usual situation
but the speed of FireWire hide the problem ;-)

> >
> > 3) Is dcons endian and pointer-size agonstic?  Can I run consoles to
> >    an amd64 and a powerpc box from an x86?
> 
> I haven't actually tried that and I imagine that there might be issues 
> here and there. Any problems are likely to be in the dconschat program 
> but that should be pretty easy to fix since its entirely userland.

I should have no problem with 64bit arch and big endian.
I have tested with sparc64, powerpc and amd64.

> >
> > 4) Does the loader know about dcons?  Eg, can I do "unload <ret> boot
> >    kernel.test" using dcons?
> 
> Actually thats the only downside of dcons. It doesn't cut in until the 
> firewire controller attaches. It relies on the fact that the fwohci 
> driver allows access to physical memory from any node on the bus 
> (implemeted in hardware so you can examine the memory of a hung 
> machine). The dconschat program uses this feature to access the dcons 
> ring buffers in the target machine.
> 
> I could imagine a dcons driver in the loader which just enabled physical 
> access and used some kind of loader trick to hand off the ring buffers 
> to the kernel dcons driver. It doesn't exist though - say nice things 

You are right.

> to the author and he might find the time for it :-)

It is not enough :-< I lack the knowledge of BIOS/PCI(and ACPI?).
Once we can access the OHCI register via PCI in the loader,
the remaining part is relatively easy as you described.
I need some help for this part. I suppose that implementing dcons 
in the loader is architecture dependent.

/\ Hidetoshi Shimokawa
\/  simokawa_at_sat.t.u-tokyo.ac.jp
PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html