Re: IXP_NPE Driver Inclusion proposal

Michael-Luke Jones wrote:
> 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.

Michael,

I don't have the free time right now to read your proposal (will do so
tonight), but I want to assure you that what you are doing is one of the
highest priorities for the nslu2-linux core team at the moment, so you
will get all the assistance you need to do it.

I'm currently on a business trip in Toulouse (and offline as far as IRC
goes), but will be back on line this weekend and going forward.  Let's
touch base directly then on #nslu2-linux and discuss the various options
in real time.

-- Rod

(original message included below, because debian-arm has not seen it)

Michael-Luke Jones wrote:
> 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.
> 
> http://www.hohnstaedt.de/ixp_npe/
> 
> 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:
> http://www.intel.com/design/network/prodbrf/27905104.pdf
> 
> 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



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nslu2-developers/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nslu2-developers/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:nslu2-developers-digest-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx 
    mailto:nslu2-developers-fullfeatured-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx

<*> To unsubscribe from this group, send an email to:
    nslu2-developers-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/