Learning about NAS chipsets
For gpl-violations.org, I've been analyzing a number of NAS devices recently. While most of them are based on some kind of more or less general purpose CPU (Intel StrongARM based IOP or e.g. VIA's embedded x86) plus standard peripherals, there appear to be more and more special purpose SoC's for this purpose.
To some extent, this is only a logical development. NAS appliances seem to be a growing market, and the desire to achieve higher integration by e.g. moving the SATA/IDE controllers into the SoC make development easier and reduce BOM cost.
It's quite amazing how much effort some companies actually go through. One series of chips that particularly caught my attention is the Stormlink Gemini series of NAS CPU's, e.g. the SL-3516. Looking at the public data sheets is particularly boring since they only have two pages. Instead of that, I'd recommend looking through the kernel sources that their downstream appliance vendors publish. They actually have hardware crypto, hardware IPsec acceleration, TSO (TCP segmentation offloading), hardware NAT, ...
As if that wasn't enough already, they also now have a dual core variant, which has two ARM920 cores next to the hardware crypto and pimped-up Ethernet controller!
While reading through the code, I made a slightly cleaned up diff against vanilla 2.6.15. It reveals a number of things that I'd like to point out:
- They have actually managed to implement a arch/arm/mach-sl2312 directory (instead of just editing some existing machine), though there seems no distinction between 2312/3516/3518/...
- They have GPL licensed drivers for their entire hardware functionality, not a single bit of proprietary stuff. It even comes with proper license headers and MODULE_LICENSE tags. This is really remarkable, especially for stuff coming from Taiwanese hardware companies. Congratulations!
- They integrate DMA capable RAID5 hardware generation, integrated with the Linux raid code
- They have two OTG capable EHCI USB controllers
- The ARM core they use is a FA526. It seems to originate from (another Taiwanese) ASIC/IP vendor called Faraday. Apparently an independent implementation of the ARMv4 instruction set, allegedly 100% compatible, even including a replica of the ARM ICE/JTAG. Could Faraday be to ARM what VIA is to Intel? In any case, definitely exciting.
- While the vendor-released GPL licensed sources contain support for this FA526 in a fairly decent way, it has not been merged into the mainline kernel. That's a pity. Does anyone know more about this? I think this should definitely be cleaned up and merged mainline.
- they re-use an entry from the mach-types registry for the sl2312. Not only do they use that machine type for all Stormlink SoC, but also the downstream hardware vendors use the same for all their products. not good. Did anyone tell them that registering new machine types is free?
- They're doing some obscure I/O pin sharing between IDE and the flash controller resulting in lots of ugly code. Probably a hardware workaround :)
- They have very invasive code all across the Linux crypto code, probably because they need async crypto support, which the crypto framework of 2.6.15 doesn't yet provide
- They seem to integrate their crypto with cryptoloop, but not dm-crypt
- They seem to be able to store their OS image in NOR, NAND or serial SPI(!) flash
- They have four hardware queues per Ethernet MAC
- They have done some serious hacks to the network stack in order to integrate their TCP offloading engines and hardware NAT. This code is obviously not the most beautiful you have seen. But what surprises me is that they actually have it working, and went all they way to get it developed. And all that for some obscure NAS chipset. I would be interested to learn how many man-years of engineering time they have in that code... Oh, and they do actually have code for TCP-over-IPv6 offloading
- Hardware-accelerated recvfile support
As a summary: Kudos to those who have designed the product, and actually implemented all its features, in purely GPL licensed code. It's just such a pity that none of the code, not even the most generic and clean bits have been merged mainline.