Toru Nishimura wrote:
>> I've switched to the ABLE firmware these days.  I haven't seen any size 
>> problems with that, even when tftp booting - plus you can now boot the ELF 
>> kernels directly.
>>     
>
> It's the question I want to ask next.  Thanks.  It seems worthwhile to upgrade
> CATS bootloader to ABLE.  I have v206 image at hand.
>   
Certainly the ABLE firmware has more active development, and cats will
boot from ABLE (given the right kernel option, perhaps it's time to
switch the option over and make it the default, and cyclone support
becomes the option).  Although you do need to pass in the option
root=wd0, as ABLE has a Linux view of the disks.
>> I see my disk being downgraded from UDMA-2 to UDMA-1 (but it normally 
>> doesn't go further than that).  There's something very dodgy with the PCI 
>> timing going on somewhere (but it might well be in the hardware).  I've 
>> had similar problems with cd-rom drives (and especially with cd-rw drives).
>>     
>
> The DMA issue may be removed since transfer error symptom might be
> caused by ARM (Footbridge?) dependent code.
>
>   
There are other interesting bugs that occur with cats, eg if you get 2
very active disks running things tend to break.  However I believe that
this happens on other OS's, so probably some kind of hardware bug.
>> I also suspect that this may also be responsible for some of the other 
>> hacks that I have to use (to fix the mii probing in the tulip ethernet 
>> card,
>>     
>
> tlp0 was found complete useless for 2.1 and 3.0 kernel.  I hooked sip0
> instead.  It's somehow relieving to see that USB is quite stable.  USB
> keyboard, USB bar code scanner, SCSI HD disguise memory disk,
> and USB serial adaptor work well for me.
>   
USB is pretty good, but our handling of USB isn't that intelligent for
priorities, as all USB devices will operate at SPLBIO, even if they're
not, eg usb audio and network devices should be higher priority. 
(although the same is also true for ISA as well, where it maps to an
interrupt on the pci bus)
> And here is today's special.  ARM Atheros WLAN can work well for
> ARM architecture (artificially crafted applause audio effect here)
>
> ath0: interrupting at irq 18
> ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> ath0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> ath0: turboG rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> ath0: mac 5.9 phy 4.3 radio 3.6
> ...
> $ /sbin/ifconfig ath0
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         ssid GW-AP54SGX
>         powersave off
>         bssid 00:90:cc:0f:70:42 chan 6
>         address: 00:02:6f:21:ed:6d
>         media: IEEE802.11 autoselect (OFDM18 mode 11g)
>         status: active
>         inet 192.168.24.57 netmask 0xffffff00 broadcast 192.168.24.255
>         inet6 fe80::202:6fff:fe21:ed6d%ath0 prefixlen 64 scopeid 0x1
>   
Nice, how well does it actually perform?

Thanks,
Chris