[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sources.list for NSLU2. fetchmail problem



On 3/28/07, Rod Whitby <rod@whitby.id.au> wrote:
Peter Naulls wrote:
> On 3/28/07, Rod Whitby <rod@whitby.id.au> wrote:
>> Rod Whitby wrote:
>> > Peter Naulls wrote:
>> >> While we're on the subject, I've managed to make the very latest
>> >> drivers from Intel (2.3 access library + 1.6 driver) work with a
>> Debian
>> >> EABI system (little endian of course) with kernel 2.6.20-rc4.
>> > ...
>> >> If anyone wants to put it together sensibly, then get in touch.  Or
>> >> better yet,
>> >> chide Intel over such a stupid setup (license + code assumptions), for
>> >> no good reason at all.
>> >
>> > Why not just ignore them by simply using the Open Source ixp ethernet
>> > driver which is already in both OpenEmbedded (part of SlugOS, working
>> > for all kernel versions up to and including 2.6.21-rc4-git6) and Debian
>> > (part of Debian Etch for NSLU2) ?
>>
>> BTW, the open source driver works fine compiled for EABI in OpenEmbedded
>> (Angstrom) and Debian (armel) too.
>
> It's not at all obvious that such a thing exists.  I spent a long time
> scouring the web, including the NLSU2 pages and others.  What files
> should I be looking at precisely, either in the kernel sources or OE?

For ixp4xx kernel patches (including the open source driver) that have
not been accepted upstream yet, look in:

http://svn.nslu2-linux.org/svnroot/kernel/trunk/patches/

In OpenEmbedded, packages/linux/ixp4xx-kernel* is what you want to build
a kernel which includes the open source driver, and ixp4xx-npe packages
the microcode (you need to download the source package for that yourself
from Intel, so you can personally accept the license).

The canonical upstream for the open source driver is:

http://www.hohnstaedt.de/ixp_npe/0.3.1/

Just an update.  I have all this working, although my board has some
peculiarities - it has 4 ports connected to one controller.  The
driver author agreed with me that it needed a modification to force
the status of the ports to always be up, otherwise it would only
monitor the status of one of the ports, and detect it as down even
though it had a valid connection on one of the other three.

Thanks for pointing me at this.



Reply to: