>Dear Chris, Kevin, and other Linux/MIPS-ers,
>I have just started to work on a port of Linux (with
>the intention of RT-Linux in a later stage)
>to the Algorithmics P4032-board, based on the newly
>released MIPS port for the P5064 and Atlas boards.
>Dominic Sweetman already told me there are more people
>interested in or working on this P4032 port.
>I would be obliged if you could help me with
>a status overview so far, and where work is still needed
>mostly. Although MIPS and P4032 are new to me,
>I am surrounded by pSOS-oriented colleagues with lots
>of P4032 experience, and I am willing to invest time
>in this port.
>And to start with a silly question:
>So far I have not found a ready-to-use cross compilation
>environment; I have just started to build a gcc-2.95.2
>mips cross compiler; monday I will try to solve the
>first errors which stopped the compilation...
>Any pointers (other than the CrossGCC FAQ and gcc doc) that
>I should be aware of ?
I think Ralf Baechle has already responded to your compiler
enquiry, and I would follow his recommendation and use the
information (and tools) provided on the www.linux.sgi.com site.
We did do a couple of things at MIPS to try to make the
P4032 port simpler, or at least to open the possibility
of having a single binary kernel that could run on both
the P5064 and the P4032. We fixed the TLB miss handlers
and CPU configuration logic to (a) know and (b) handle correctly
the 32 TLB entries of the R4300, and wherever possible we
made things like the address offsets to/from PCI space
and kernel debugger port bindings configurable at boot time
from the platform setup code. This is not to say that I would
suggest going for a dual-boot kernel right off the bat, only
that some work in that direction has been done, and that
you should try not to do anything that would actively prevent
it from working.
The ncr53c8xx.c SCSI driver should work with little or
no modification - perhaps someone else on the linux-porters
list can comment as to whether the platform-supplies-scsi-clock
option needs to be specified for the P4032 as it does for
the P5064. The tulip.c driver is theoretically capable
of handling the 21041 as well as the 21043 on the P5064,
but that needs to be verified.
What needs to be done (in my opinion) is to:
a) set up a subtree arch/mips/algor/p4032 that parallels
(and maybe even copies, to begin with) arch/mips/algor/p5064
b) replace/modify the PCI bridge configuration and setup code.
This will probably be the most time-consuming element.
c) modify the platform-dependent "IRQ" binding and PCI-BIOS
fixup code as appropriate.
d) tweak the existing drivers as necessary, if necessary.