FireWire/dcons support in loader (Re: Excellent job on the firewire support!)

OK, I spent this weekend to implement dcons in i386 loader and
experimental loader binary is available at:

http://www.freebsd.org/~simokawa/firewire/loader/loader.fw-20040926

Though there are still some limitations, you can interact with loader
using dconschat(8).

- FireWire OHIC is detected using PCI BIOS and initialized.

- dcons(4) is enabled in loader as an additional console by default.
  This means that you can use both dcons and vidconsole or comconsole
  simultaneously as usual dcons(4) in kernel.
  If you want to use this dual console, please make sure you don't have
  'console=XXXconsole' line in loader.conf. This overrides dual console
  settings. If you want to use serial console and dcons
  simulataneously, put /boot.config with '-h' or ' '-hD'.

- I recommand you to use dconschat(8) with '-r' (replay) option.

- dcons(4) in loader and kernel use different buffer. This means that
  dcons(4) is disconnected since loader executes kernel until
  fwohci/dcons is initialized in kernel.
  See below for detail.

- This depends on PCI BIOS to detect FireWire OHCI.
  If we can share loader binary between i386 and amd64, I assumes that
  this loader can work well on amd64 too.
  Any volunteers for test?

- I need some more work to clean up the source tree, but 
  I can send the current source tree to interested people.
  Please contact me.

At Tue, 20 Jul 2004 04:42:56 +0100,
Bruce M Simpson wrote:
> 
> On Tue, Jul 20, 2004 at 11:41:52AM +0900, Hidetoshi Shimokawa wrote:
> > 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.
> 
> Very much so, to begin with. Let's consider the i386 case.
> 
> libi386/biospci.c wants FireWire device classes added to it for its probe.
> Some BIOS wrapper functions to manipulate PCI configuration registers need
> to be added too.

I have added some functions to biospci.c.

> Then a fwconsole driver much like comconsole could be written, i.e.
> fwc_probe(), fwc_init() etc. I believe it's safe to assume that V==P
> for address space at this point. I guess this could act as a shim before

Unfortunately, V!=P. I need PTOV() to access OHCI registers.

> the driver actually gets loaded. kenv could be used to tell dcons where
> the loader had allocated the buffer before the kernel actually starts.

Yes, kenv can pass the address.

> There would have to be a comfortable handover between loader and dcons
> in the kernel, but because it just uses a ring buffer, I imagine this is
> somewhat easier than it would be otherwise.

The most messy part is that console in kernel is initialize before
VM subsystem is initialized. We can easily locate physical address
of dcons buffer but we have some problems.

- What is the virtual address of the buffer BEFORE VM is initialized?
- What is the virtual address of the buffer AFTER VM is initialized?
- Can we make above two addresses to be same?
- What is the best way to prevent the OS to reuse the physical pages for
  other purpose?

> I am about to get some long overdue sleep, otherwise I'd begin hacking this
> myself. ;-)
> 
> BMS

Have a fun,

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