Kernel choices for 824x with ext3 FS

[Ron Bianco]

Greetings,

I've been scouting out kernel alternatives for porting to our custom 8240 board.
We've been running a port of 2.3.16 for a few years now, but need to upgrade for
a couple of reasons.
I've been looking at Denx's 2.4.4 port, linuxppc 2.5, linux 2.4.22 and the
latest 2.6.0-test trees.

BTW, many thanks to Wolfgang Denk for making available the ELDK and his ( and
others ) embedded PPC specific work!

Unfortunately we can't use 2.4.4 as ext3 FS support is not present.
FYI, we may also have a need to use RTAI.

I am looking for some advice on which tree to use as a starting point for a new
embedded ppc port.
It is desirable to use the most up to date, yet robust for ppc, kernel possible
and this is somewhat awkward timing vis a vis the status of the 2.6.0 kernel.
But most pertinent ppc related patches seem to be included in 2.6.0 now along
with other enhancements, such as reduced latency, that are not present in
2.4.22.   So it is a bit of a quandary for me, and perhaps for others as well.

A short? hardware overview:
The board is a bare bones design used strictly for scsi ( symbios 53c895 ),
ethernet ( intel 82559 ), and interfaces to our custom backplane in a digital
audio matrix mixer.  The board's flash chip and boot sequence are controlled by
the system's main DSP board.
The backplane interface is via a 16k word dual port RAM and the firmware images
are transferred to SDRAM during startup thru it.
A rather unique situation and it is complicated by the fact that the board has
no UART.  In hindsight a very dumb omission, but this was worked around by
hacking a dummy serial port buffer scheme.
Anyway, it's been working well, and we've managed to cope with the rather large
linux 2.3.x interrupt latency variance in our custom device driver that handles
the backplane interface.   A driver improvement to use the 8240 DMA units helped
too, but there is still a 166 usec. interrupt and the driver can only cope with
getting behind up to 3 interrupts.
We used raw access to the scsi disks with a primitve 'FS' for audio storage and
had done some hacks to the driver set to enable auto switching quickly to a
backup drive if the active drive failed.  The system can be powered down at any
time, which precluded using a non-journalled FS.

But now we have new product specifications that requires the use of a journaling
FS and hardware RAID level 1, and I wish to take the opportunity to improve the
interrupt latency situation too.

Any comments appreciated.

regards, Ron


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