Port-ofppc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: dev/ofw/ofdisk.c



Tim Rightnour wrote:

> [...] until ppcoea-rennovation is merged (which should be soon)

Very good! I nearly wanted to ask... :)


> it would be helpful to know which tree you are referring to.

I'm usually working with current source, and ppcoea-renovation "mapped in"
at sys/arch.


> I've let the HEAD rot because I'm focusing all of my
> efforts on the rennovation branch.

But it should really be merged back as soon as possible. The current source
in ofppc is useless.


> I do realize that the current ppcoea-rennovation code for ofppc is not
> 100% ideal.

But it is a good start. It is important that something happens at all!


> There are certainly lots of things in there that can and
> should be done better, however, I just didn't have the hardware to play
> around with it.

You can use me any time for Pegasos2 and Efika. I will also get a PowerMac
this week (to have a OFW machine which really works with NetBSD ;).


> I'm not married to most of the ways I set things up in
> there, but my general philosophy on ofppc on the rennovation branch is
> thus:
> 
> 1) We should be talking directly to hardware to use it.  We shouldn't be
> sending bytes through the RTAS or OFW to write to the disks.

Absolutely! The OFW-device approach has proven to be worthless several times.
You cannot seriously work with such a system.


> 2) We should be using the RTAS/OFW/whatever at all times to *find*
> devices, and when appropriate, use it to set them up. I think this is
> primarily true for devices that are at the top of a tree.. such as PCI
> bridges. I think we should find the bridge with OFW, and then use standard
> PCI routines to talk to the bridge to find it's children. (those routines
> however, can certainly involve RTAS/OFW calls as much as they need, I
> simply mean we shouldn't just walk the ofw tree looking for pci children,
> because we will likely miss nonstandard cards)

I can only agree, and I guess nobody here will disagree.

I worked on the PCI-bridge code for the Pegasos2 yesterday, and while
implementing direct access to the Marvell registers, like the OpenBSD port
did, I realized that it makes no sense. The code would be plain ugly, and the
Marvell would need to be mapped at a different location than the io or mem
space of the bridge.

I really would like a PCI-config method like Jochen has done! What do you
think about it?

-- 
    _  Frank Wille (frank%phoenix.owl.de@localhost)
 _ //  http://sun.hasenbraten.de/~frank/
 \X/   Phx @ #AmigaGer




Home | Main Index | Thread Index | Old Index