Re: Going from 2.2.12 to 2.2.17pre10

On Tue, Jul 11, 2000 at 10:37:11AM +0100, Adrian Cox wrote:

Matt Porter wrote:

quoted

Back to original point, I'm not against using a residual data or
device tree if it doesn't have to have dozens of fixups applied.
I just don't see that coming out of the proprietary hardware/software
houses to use their broken data...

Residual data is useful for things like finding the memory size, and for
chips designed inside Apple. For almost everything else Linux already
contains a device tree, built by PCI probing when the kernel boots^*. I
don't see much need for a parallel, architecture specific, device tree.

Whoa...you mentioned the key phrase here...it's really only useful or
required for chips design inside Apple where you can't get documentation.
"Residual data" and defined in the PReP spec is only found on PReP systems
where all the hardware is fully documented so it's easy to size the
memory by other means.  It's not that hard to read board registers or
the memory controller setup.

I can see why the Mac folks have to deal with the broken OF device tree.

A architecture specific (PPC) device tree (or residual data, if you will)
would be part of a "standard" OpenSource firmware project.  It's only
use would be to provide information for board bringup, etc.  It has it's
advantages and disadvantages...

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 12 Jul 2000, Matt Porter wrote:

quoted

Residual data is useful for things like finding the memory size, and for
chips designed inside Apple. For almost everything else Linux already
contains a device tree, built by PCI probing when the kernel boots^*. I
don't see much need for a parallel, architecture specific, device tree.

Whoa...you mentioned the key phrase here...it's really only useful or
required for chips design inside Apple where you can't get documentation.
"Residual data" and defined in the PReP spec is only found on PReP systems
where all the hardware is fully documented so it's easy to size the
memory by other means.  It's not that hard to read board registers or
the memory controller setup.

Indeed, but there is one thing which is very hard to guess: interrupt
routing (due to the utterly stupid original Intel/IBM design which was
obsolete already before Neanderthal).

Actually very similar boards may have quite different interrupt routing
and break an unsuspecting kernel. I also hate all these tables with magic
values in the kernel (beside the fact that they don't work with
multifunction boards).

I can see why the Mac folks have to deal with the broken OF device tree.

A architecture specific (PPC) device tree (or residual data, if you will)
would be part of a "standard" OpenSource firmware project.  It's only
use would be to provide information for board bringup, etc.  It has it's
advantages and disadvantages...

For ISA devices and interrupt routing, I consider it a big plus... For PCI
devices just ignore it if present.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/