On 12-Mar-2006 Jochen Kunz wrote:
>> I've seen a few CHRP IBM machines that
>> still provided residual if you asked for it.
> Residual data will not help. The machine has a different memory map,
> i.e. the physical addresses where the PCI bus is mapped. This adresses
> are global compile time constants in port-prep. (struct
> powerpc_bus_space prep_.*_space_tag in arch/prep/prep/machdep.c) Part of
> my work on port-ofppc was to make the memory map / bus_space
> initialisation platform dependent. This is needed to support CHRP and
> PReP/OFW machines with a single port. The final goal is to read the
> memory map via OFW. Currently they are hard coded in a platform
> dependent way.
> 
> BTW: Why do you wane remove struct platform from port-prep? What is bad
> with having a struct platform?

Yay.  Now I get to answer both questions at once.

Currently the space tags are hardcoded, however, on most of the machines, they
do not need to be.  The exception to that that I know of is the 6015.. however
I'm still working on that to see if I can decode it properly.

The exciting truth is, that the residual provides the data to properly set up
the pci and isa bus space tags.  Take a look at the residual dumps I have
collected from some of the machines.  You will find that the values in the
PCI_BRIDGE all match the values hardcoded in the space tags.   This just
happens to work for now, but like Michael Stevens wrote, his MPC750 required a
slightly different map.

The right thing to do here, is to gather that mapping data from the residual. 
Then the port should just magically boot on both the 7043 and on the MPC750. 
And, if your 7043-150 happens to prodive residual, then it will magically work
there as well.  (which is why I'm very interested in seeing a prep kernel boot
attempt on the 7043-150, as it would be an excellent target to test out an
alternate PCI mapping)

Which brings me to why struct platform needed to die.  Up until now, if you had
a machine that was fundamentally supported by prep, but was missing an entry in
the platform tab, then it wouldn't boot, or would boot with the horked defaults
provided by the *_unknown() calls.  But thats not needed.  The residual was
designed by IBM to provide them with a complete description of the machine so
they didn't have to hardcode things.  They can ask the residual "what is your
interrupt map?"  "is your pci bridge direct or indirect configured?" "What is
the physical memory layout of your PCI and ISA crap?".  That means that if
motorolla spits out a new machine that provides all the right data, AIX would
just work on it.

The same should be true for us.  Any random machine that provides compliant
residual data, should just boot and work.  Thats my goal for the prep kernel,
is to make one that just magically figures out what needs to be mapped where,
to make it work on any prep machine.  (specific weird drivers/busses not
withstanding)

> If you are interrested in helping me with port-ofppc and you don't have
> hardware: I can provide access to a remote debugging facility. There you
> can netboot target machines, control them via serial console and remote
> power cycle them.

I am very interested in ressurecting ofppc.. but my primary goal right now is
to get prep into shape.  That being said, the two ports have a great deal of
crossover.. and I think I can likely help you alot with it.  I think ofppc is
far more bitrotten than prep was.

---
Tim Rightnour <root@garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
Genecys: Open Source 3D MMORPG: http://www.genecys.org/