On Wed, Oct 07, 2009 at 03:18:04PM +1000, Julian Calaby wrote:
On Wed, Oct 7, 2009 at 14:49, Grant Likely [off-list ref] wrote:
quoted
On Tue, Oct 6, 2009 at 10:29 PM, Grant Likely [off-list ref] wrote:
quoted
So here goes. I've begun the work to merge and clean up the OF device
tree handling code and this is my first set of patches. Not fully
tested yet, but I'm getting them out to the lists so that I can start
responding to comments and collecting acks. This first batch isn't
anything exciting, just a merge of common code
Good work, for what it's worth, this all looks good to me.
quoted
However, I've completely devoted to this work for at least the next
two months, so there are plenty more patches to follow. Once I've
got all the common code merged between Microblaze, PowerPC and Sparc
I'll be fix the endian problems and making it easily usable by other
architectures like ARM and MIPS. Lots of work to be done.
On the subject of merging code, I know that the SUN3 code in m68k uses
a similar prom interface to the sparc32 code. (and I've also
considered unifying that and ... well ... see above) Does anyone know
if it has an OpenFirmware interface for it's devices? Is OF on SUN3
even remotely useful? Does Linux on SUN3 even work with modern
kernels?
Sun3 doesn't have OF, though I've got some dormant patches to add an
OF emulation layer to make it easier to reuse Sparc drivers on
Sun3... Never finished enough to submit, so it probably shouldn't
affect anything you're doing here.
As for recent kernels, I think 2.6.19 was the last sun3 I distributed
patches for, so modern might be pushing it...
-- Sam
Sun3 doesn't have OF
When I was first developing Open Boot for the SPARCstation-1, I was also
simultaneously trying to do it for a Sun-3 system that was being built
at the same time.
It proved to be too much to do both jobs at the same time, especially in
light of all the hardware debugging that is part of a new system
bringup. So I gave up on Sun 3 and just focused on SS-1.
That particular Sun-3 machine never sold very well, while the SS-1 was
very popular. That was Sun's last 680x0 machine.
Personally, I think that continuing to support Sun-3 in Linux is not
useful in a practical sense. To the extent that supporting
long-obsolete platforms and devices makes the job harder for current
systems, it is actually harmful. Portability and generality is good in
some theoretical "rightness" sense, but there are practical limits.
Code can become so heavily layered that approaching it requires a huge
commitment of effort to learn all the artificial layers. Sometimes you
have to prune the dead branches so the living ones can get light and air.
Taking this one step further, I don't see any real good reason to
continue supporting Sun4 going forward. I got rid of my Sun4 systems
long ago because it was just too hard to keep them working - after
having used them long after most people had moved on. Dropping Sun3 and
Sun4 eliminates all vestiges of the sunmon interface and also allows
dropping support for OBP version 1, which only shipped on SS1-class
machines - the first machines in the Sun4c subclass.
On Wed, Oct 07, 2009 at 09:52:43AM -0400, Sam Creasey wrote:
On Wed, Oct 07, 2009 at 03:18:04PM +1000, Julian Calaby wrote:
quoted
On the subject of merging code, I know that the SUN3 code in m68k uses
a similar prom interface to the sparc32 code. (and I've also
considered unifying that and ... well ... see above) Does anyone know
if it has an OpenFirmware interface for it's devices? Is OF on SUN3
even remotely useful? Does Linux on SUN3 even work with modern
kernels?
Sun3 doesn't have OF, though I've got some dormant patches to add an
OF emulation layer to make it easier to reuse Sparc drivers on
Sun3... Never finished enough to submit, so it probably shouldn't
affect anything you're doing here.
I was also looking at using the OF code on m68k, but for a different
reason. My goal was to get macio_bus working so we can merge a few
of the m68k Mac drivers into the ppc Mac drivers. The simplest way
to do that seemed to be supporting OF since macio_dev is a wrapper
for of_device. It was also a nice way to build up a table of all the
onboard devices in memory. Hopefully it would enable better user-space
device detection as well.
I got the framework built against an older kernel, but it wasn't enough
to be useful at that point. This set of patches could help quite a bit.
Brad Boyer
flar@allandria.com