| Hi there,
Introduction I am attempting to port the fully open source IXP_NPE driver to the NSLU2-Linux build system. In this email I will summarise the advantages this driver can bring to SlugOS and the work that will need to be done to integrate it.
Background The NSLU2 is based on the IXP425 development platform released by Intel. Intel also releases software, known as an Access Library which allows both Linux and Vxworks (a proprietary OS) to use the hardware of IXP425 boards. However, the Access Library is very bulky, and until recently was released under a highly restrictive License. It can only be downloaded from Intel after registering with the site, and in addition is a remarkable example of poor coding practice.
The mainline Linux kernel, as of 2.6.18-rc6 integrated drivers for very many of the IXP425 hardware features without using the Intel-supplied Access Library. This includes the I2C bus, the integrated UARTs, and the hardware random number generator. However, this does not include the Network Processing Engines (NPE) present.
The NPE is a somewhat strange device, by conventional (x86) hardware standards. It is a coprocessor which is meant to accelerate networking applications. The NPE requires 'microcode' to be loaded into it in order to function. Different Microcode means different functionality. The IXP425 and thus the NSLU2 has 3 NPEs, known as A, B and C.
NPE A is used for ATM and is irrelevant to the NSLU2. In the NSLU2, NPE B is connected to an ethernet PHY (id=1), which allows this NPE to act as an ethernet interface (when appropriate microcode is loaded). NPE-C is not connected to an ethernet PHY, but could be used as a hardware cryptography engine (again with appropriate microcode) in future.
The Microcode is only available from Intel under a highly restrictive License, known as the 'Intel Public License'. However, it is fundamentally 'firmware' and is NOT loaded into the kernel. Thus, the status of the IXP_NPE driver is similar to that of the Speedtouch 330 (ADSL modem) kernel driver, where the driver is available freely under the GPL despite the restrictive license of the firmware.
Further information:
Advantages The new IXP_NPE driver does not require the Intel Access Library to function. In the long term, inclusion of this driver will free the NSLU2-Linux developers from having to support this code which traditionally fails to support little-endian processor operation, which is in turn required for Debian ARM support.
In addition it will free up a substantial amount of kernel RAM (important on a RAM-starved device) as the Intel Access Library is very large and must be loaded directly into the kernel. The Intel Access Library also manages to use a remarkable amount of CPU time to do very little.
The new driver is modular and is only ~40KB in size, down from over 500KB. There is also a strong chance that, if it receives sufficient testing, it can be pushed upstream so that all of the commonly used features of the NSLU2 are directly supported by the stock kernel. Therefore, I feel it is important to get involved at this early stage.
Integration Strategy Proposal Stage 1 Integrate the patch provided into a separate branch on the NSLU2-Linux kernel SVN repository. Build the kernel and modules and test the driver's functionality. Benchmarks and Stress Test.
Stage 2 Due to the requirement for microcode loading, userspace will need to be load the new driver, with the firmware loaded via hotplug. My understanding of this is that it will require changes to the init scripts, udev, or more likely both. My strategy would be to maintain this as a patchset against Openembedded HEAD, contained in the NSLU2-Linux SlugOS/branches/ SVN repository.
Stage 3 Remove support for IXP Access Library for SlugOS 4.x in OpenEmbedded HEAD. Use IXP_NPE for SlugOS 4.x release.
Potential Difficulties See previous email to this list: 'NPE Location in NSLU2 Flash' It would be useful to store the NPE Microcode in a specific separate partition. If this is co-ordinated by the 3 main projects targetting the NSLU2: nslu2-linux (slugos), debian and the apex bootloader, then all of these projects can distribute only GPL code and load the non-free microcode at run-time.
Alternative Strategy for Microcode Loading Apex can be used as a second stage bootloader by SlugOS, which initialises the NPEs. Then if the NPEs are not reset, there is a possibility that SlugOS (and Debian?) will not need to load the microcode again.
Conclusion If you are interested in this proposal, please read this carefully and correct and mistakes I may have made. I am currently part way through Stage 1 - I have successfully built a 2.6.18-rc6 kernel with the IXP_NPE modules.
Thanks for reading,
Michael-Luke Jones | 
