Please enable CONFIG_ENC28J60=m

[RadekHvizdos]

With 3.18 we have moved to device tree based configuration, so we no longer need to put SPI connection specific information into a board file. Could we now enable ENC28J60 as a module so that both armv6 and amrv7 distribution kernels support this ethernet controller?

http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=18397

Thanks!

[RadekHvizdos]

Hi all,

I guess the SPI clock issue will take a bit longer to address. Let's keep the existing default for now.

@pelwell, could you please update the binary firmware with latest DT overlay?

Thanks

[popcornmix]

A firmware build is in progress, so whatever has been checked in will appear in next rpi-update.

[RadekHvizdos]

Works like a charm!

[AMelbye]

Hi, I've been trying for days now to make this device work, this thread has gotten me a lot closer, but I'm still not quite there.

I've done the following:

1. created enc28j60-overlay.dts, entered the text posted by Pelwell and copied it to the /boot/overlays directory
2. connected the module
3. entered the following in /boot/config.txt: dtdebug=1 dtparam=spi=on dtoverlay=enc28j60,int_pin=25

I get the following error message: "failed to load overlay 'enc28j60'". I've tried changing the filename of the overlay to things like enc28j60.dts, changing the extention to .dtb etc. but it didn't help

What am I doing wrong? I'm on kernel 3.18.7+

I've probably missed something pretty basic, I'm learning as I go. Could you please point me in the right direction?

[gajdipajti]

Update your kernel with sudo rpi-update, and you will get the latest kernel with the fixed overlay. OR you can download just the overlay from here: https://github.com/Hexxeh/rpi-firmware/tree/master/overlays

[pelwell]

You need to find a suitable version of dtc - the Device Tree compiler - to convert the .dts into a .dtb. You should really read the documentation here - it will save you a lot of time.

You can also download from here: https://github.com/raspberrypi/firmware/blob/master/boot/overlays/enc28j60-overlay.dtb

[madarax64]

Hey all, Sorry about posting this when the issue is closed, but I can't seem to figure out how to set a fixed MAC address for this module. Every time I reboot I get a new MAC. I'm on the latest Jessie-Lite image, which has dhcpcd in it. Normally, adding hwaddr ether xx:xx:xx:xx:xx:xx to /etc/network/interfaces would fix this, but that file has relinquished control of the interfaces to dhcpcd which is giving me serious trouble. Any help would be highly appreciated. Thanks!

[gajdipajti]

Hello, i wrote a shell script as a workaround, and added it to /etc/init.d/mac.sh:

#!/bin/sh
ifconfig eth0 down hw ether 00:11:22:33:44:66
ifconfig eth0 up 

Then sudo chmod +x /etc/init.d/mac.sh && sudo update-rc.d mac.sh defaults

But it would be a nice feature to use the Serial from /proc/cpuinfo

[msperl]

you could probably also create a udev rule to handle that for you, but do not ask about details how it works, but this maybe as a hint: https://wiki.archlinux.org/index.php/MAC_address_spoofing#Method_2:_systemd-udevd

[madarax64]

Thanks, @gajdipajti , this workaround works (no pun intended). Incidentally I followed the steps from your blog https://gajdicookbook.wordpress.com to get the whole thing up and running :-) However, I was hoping for another solution, say some hidden device-tree binding for getting this done, so I could just specify the MAC address right in the .dts file or even in the dtoverlay=... directive in config.txt

Thanks @msperl , I'd seen this but it seems to assume that the device has a MAC address of xx:xx:xx:xx:xx:xx which you're trying to spoof into yy:yy:yy:yy:yy:yy. The issue here is that its impossible (at least to me) to determine what the MAC address the module got at boot-time (since its different on every boot), so I can't write a udev rule that essentially depends on knowledge I won't have :-) However, you've given me an idea. It just might be possible to use the driver as the matching attribute rather than the permanent MAC address xx:xx:xx:xx:xx:xx. Since in theory there will be only one device for which the enc28j60 kernel module is loaded, then maybe the rule can be adjusted to target that...I'll give that a shot and let you know how it goes. Thanks!

[DougieLawson]

Hi Phil,

I did much the same as Tamas. I've got a script that picks up the RPi serial number, prefixes that with B8:27:EB and issues a ifconfig eth0 ether B8:27:EB:xx:xx:xx

That makes it look like a real Raspberry Pi to anything that scans my network. When I can get connected to my home VPN (can't do that from here due to the corporate firewall) I'll post a copy of my scruffy script.

Regards, Dougie

[msperl]

You probably could filter on the driver or on the first few bits of the mac - the driver uses some defaults pattern - you still need to figure out what it is... - or you filter on the driver type or similar (which - I believe is possible)

[msperl]

I guess the filter: DRIVERS=="enc28j60" instead of ATTR{address}=="XX:XX:XX:XX:XX:XX"should do the trick... You could also check on the spi chip-select you have used with KERNELS=="spi*.0"

[DougieLawson]

#!/bin/bash
exit 0
raspberry="B8:27:EB:"
cpuid=$(cat /proc/cpuinfo | grep Serial | cut -c 21-26 | sed
's/\(..\)/\1:/g')
ifconfig eth0 hw ether $raspberry$cpuid

On 12 Jan 2016 4:48 pm, "msperl" notifications@github.com wrote:

I guess the filter: DRIVERS=="enc28j60" instead of ATTR{address}=="XX:XX:XX:XX:XX:XX"should do the trick... You could also check on the spi chip-select you have used with KERNELS=="spi*.0"

— Reply to this email directly or view it on GitHub https://github.com/raspberrypi/linux/issues/795#issuecomment-170971184.

[DougieLawson]

I run that in /etc/network/if-pre-up.d on a system that doesn't have raspberry-net-mods so that network-manager still works. On 12 Jan 2016 5:24 pm, "Dougie Lawson" dl1ims@gmail.com wrote:

#!/bin/bash
exit 0
raspberry="B8:27:EB:"
cpuid=$(cat /proc/cpuinfo | grep Serial | cut -c 21-26 | sed
's/\(..\)/\1:/g')
ifconfig eth0 hw ether $raspberry$cpuid

On 12 Jan 2016 4:48 pm, "msperl" notifications@github.com wrote:

I guess the filter: DRIVERS=="enc28j60" instead of ATTR{address}=="XX:XX:XX:XX:XX:XX"should do the trick... You could also check on the spi chip-select you have used with KERNELS=="spi*.0"

— Reply to this email directly or view it on GitHub https://github.com/raspberrypi/linux/issues/795#issuecomment-170971184.

[nickdesaulniers]

Maybe a noob question, but can these be daisy chained, or do I need to make changes to my DTS?

Also, does the DTS tell you how the enc28j60 should be wired?

[pelwell]

Please don't re-open closed issues for questions like this - use the Forums.

[matiaspl]

I've just hit the very same bug as @DougieLawson "transmit queue 0" after 250-300 seconds after bootup. The interface looses it's DHCP-acquired IP (seems to drop to the private 169.254 class for whatever reason) and stops responding.

This is observed on the original RPi B (256M), newest kernel and overlays via rpi-update, stable Raspbian, module connected with int line on the default GPIO25, 15 cm cables. Has anyone found a reason for this to happen or even better - a solution?

[matiaspl]

There was a question on the forum about a very similar looking issue but unfortunately it didn't get any response (https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=187567)