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