This will be easier than I anticipated then :)
However, there is one further obstacle as, currently, the changes
I've made only support the NSLU2.
The IXP_NPE driver requires the MAC to be explicitly set up in the
[insertboardname]-setup.c file in mach-ixp4xx
Adoption to your custom board:
------------------------------
use "arch/arm/mach-ixp4xx/ixdp425-setup.c" as template:
in "static struct mac_plat_info" adopt the entry "phy_id" to your
needs
(Ask your hardware designer about the PHY id)
The order of "&mac0" and "&mac1" in the "struct platform_device"
determines which of them becomes eth0 and eth1
From:
http://www.hohnstaedt.de/ixp_npe/readme
I've managed this (with assistance from the author) for nslu2-
setup.c, though the changes are currently untested. Similar changes
will need to be made in nas100d-setup.c and the DSM-600G patchset. To
do this, we will need details about which PHY is connected to which
NPE on these boards.
FYI, I think that the Intel Access Library autodetects this information.
Michael-Luke Jones
On 11 Sep 2006, at 13:32, Rod Whitby wrote:
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.
You're preaching to the converted :-)
One of the main goals of SlugOS 4 (and integration of the NSLU2
into the
mainline kernel and also the Debian kernel) is to do exactly what you
are proposing. We're glad that there is someone with the time and
where-with-all to do it :-)
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.
We would use alpha testing of SlugOS 4.x to give it this sufficient
testing.
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.
Instead of a separate branch, we will implement it directly into the
2.6.18 kernel branch. We want to get this thing into the hands of
testers as quickly as possible.
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.
Again, this will be part of the mainline SlugOS Openembedded head,
rather than a separate branch.
Stage 3
Remove support for IXP Access Library for SlugOS 4.x in OpenEmbedded
HEAD. Use IXP_NPE for SlugOS 4.x release.
We will do this as soon as we have a working replacement which can at
least connect and do ssh. Then we fix the bugs from there during the
SlugOS alpha testing.
*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.
We can put this in the payload area in the last erase block. We will
update slugimage to include the NPE microcode in the 8MB flashable
image, and distribute that on www.slug-firmware.net
*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.
This is also something we want to look into for SlugOS. It is a
definite decision that this (using apex for second stage bootloader)
will be done for the Debian release.
I am currently part way through Stage 1 - I have successfully built a
2.6.18-rc6 kernel with the IXP_NPE modules.
Let's get you SVN and monotone access and get that into the nslu2-
linux
kernel SVN asap. Then we will update the ixp4xx kernel in OE to
use the
2.6.18 kernel including your patches. Then we'll have the nslu2
developers start testing that OE head, which will become SlugOS 4.x
In parallel, I expect Martin and others will work on getting the
Debian
kernel to build with these patches too (perhaps using the nslu2-linux
SVN kernel repo as the source of the 2.6.18 patchset) ...
-- Rod
smime.p7s
Description: S/MIME cryptographic signature
