It always just worked for me. g_ether that is. Of course, I do not use systemd . . . no idea if systemd requires any special voodoo to get g_ether working, or not.
One thing to note though Fabian. You can use ./build_deb next time you build a new kernel, copy the deb over, and just *sudo dpkg -i linux-image*.deb*. I only mention that in case you were unaware of that. . . but this way has the added benefit of being easier, and installing everything you need. Once you get a base rootfs running. It'll work on all the base images too, of course. On Mon, Dec 7, 2015 at 8:22 AM, Fabian Dalbert <[email protected]> wrote: > journal as in journalctl? doesn't seem to be included. but here's what I > found in dmesg that seemed relevant: > > > [ 2.976012] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk >> combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftCo) >> [ 2.976031] musb-hdrc: MHDRC RTL version 2.0 >> [ 2.976039] musb-hdrc: setup fifo_mode 4 >> [ 2.976056] musb-hdrc: 28/31 max ep, 16384/16384 memory >> [ 2.977348] 47401b00.usb-phy supply vcc not found, using dummy >> regulator >> [ 3.005848] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk >> combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftCo) >> [ 3.005863] musb-hdrc: MHDRC RTL version 2.0 >> [ 3.005871] musb-hdrc: setup fifo_mode 4 >> [ 3.005885] musb-hdrc: 28/31 max ep, 16384/16384 memory >> [ 3.006170] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver >> [ 3.006461] musb-hdrc musb-hdrc.1.auto: new USB bus registered, >> assigned bus number 1 >> [ 3.006690] usb usb1: New USB device found, idVendor=1d6b, >> idProduct=0002 >> [ 3.006703] usb usb1: New USB device strings: Mfr=3, Product=2, >> SerialNumber=1 >> [ 3.006712] usb usb1: Product: MUSB HDRC host driver >> [ 3.006721] usb usb1: Manufacturer: Linux 4.1.13-bone-rt-r17 musb-hcd >> [ 3.006730] usb usb1: SerialNumber: musb-hdrc.1.auto >> [ 3.007420] hub 1-0:1.0: USB hub found >> [ 3.007470] hub 1-0:1.0: 1 port detected >> > > >> [ 21.101221] using random self ethernet address >> [ 21.101247] using random host ethernet address >> [ 21.101265] using host ethernet address: 84:EB:18:AE:CB:AA >> [ 21.160643] Mass Storage Function, version: 2009/09/11 >> [ 21.160672] LUN: removable file: (no medium) >> [ 21.160867] LUN: removable file: /dev/mmcblk0p1 >> [ 21.160878] Number of LUNs=1 >> [ 21.162626] usb0: HOST MAC 84:eb:18:ae:cb:aa >> [ 21.162973] usb0: MAC a2:29:c5:ee:bf:e6 >> [ 21.163029] Number of LUNs=1 >> [ 21.166695] g_multi gadget: Multifunction Composite Gadget >> [ 21.166721] g_multi gadget: g_multi ready >> [ 21.767642] g_multi gadget: high-speed config #1: Multifunction with >> RNDIS >> [ 33.184926] net eth0: initializing cpsw version 1.12 (0) >> [ 33.187423] net eth0: phy found : id is : 0x7c0f1 >> [ 33.187492] libphy: PHY 4a101000.mdio:01 not found >> [ 33.192436] net eth0: phy 4a101000.mdio:01 not found on slave 1 >> [ 33.218457] net eth0: BQL enabled >> [ 33.228304] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready >> [ 132.378851] device usb0 entered promiscuous mode >> [ 153.177973] device usb0 left promiscuous mode >> [ 1555.067418] device usb0 entered promiscuous mode >> [ 1570.862790] device usb0 left promiscuous mode >> > > On Monday, December 7, 2015 at 4:05:37 PM UTC+1, RobertCNelson wrote: >> >> Sorry missed the "bone" >> >> r17 has that fix too: >> >> >> https://github.com/RobertCNelson/bb-kernel/blob/am33x-rt-v4.1/patches/defconfig#L4305 >> >> Now i'm not sure.. >> >> What shows up on the beagle's journal? >> >> On Mon, Dec 7, 2015 at 9:03 AM, Fabian Dalbert <[email protected]> wrote: >> >>> I actually thought, it were a problem with g_ether and spent hours >>> trying to fix that. However as I used Robert Nelsons patches, everything >>> was fine there. I'll try the updated kernel. >>> >>> On Monday, December 7, 2015 at 3:36:23 PM UTC+1, William Hermans wrote: >>>> >>>> Have you loaded the g_ether kernel module on the beaglebone ? When >>>> building your own kernel, this is something you have to take care of >>>> yourself . >>>> >>>> On Mon, Dec 7, 2015 at 7:21 AM, Fabian Dalbert <[email protected]> >>>> wrote: >>>> >>>>> Hi >>>>> >>>>> I'm trying to write a module for a real-time kernel. Following the >>>>> instructions on https://eewiki.net/display/linuxonarm/BeagleBone+Black, >>>>> I compiled and deployed a 4.1.13-bone-rt-r17 kernel to an sd card with a >>>>> Debian GNU/Linux 7 BeagleBoard.org Debian Image 2015-03-01. >>>>> >>>>> Before, with kernel 3.8.13-bone70, everything was working perfectly >>>>> fine. However after upgrading the kernel, my desktop (running Linux Mint) >>>>> no longer receives an ip address. >>>>> >>>>> ifconfig beaglebone: >>>>> >>>>> usb0 Link encap:Ethernet HWaddr a2:29:c5:ee:bf:e6 >>>>>> inet addr:192.168.7.2 Bcast:192.168.7.3 >>>>>> Mask:255.255.255.252 >>>>>> inet6 addr: fe80::a029:c5ff:feee:bfe6/64 Scope:Link >>>>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>>>> RX packets:1 errors:0 dropped:0 overruns:0 frame:0 >>>>>> TX packets:37 errors:0 dropped:0 overruns:0 carrier:0 >>>>>> collisions:0 txqueuelen:1000 >>>>>> RX bytes:76 (76.0 B) TX bytes:9408 (9.1 KiB) >>>>>> >>>>> >>>>> ifconfig desktop: >>>>> >>>>> eth1 Link encap:Ethernet HWaddr 84:eb:18:ae:cb:aa >>>>>> inet6 addr: fe80::86eb:18ff:feae:cbaa/64 Scope:Link >>>>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>>>> RX packets:37 errors:0 dropped:0 overruns:0 frame:0 >>>>>> TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 >>>>>> collisions:0 txqueuelen:1000 >>>>>> RX bytes:7262 (7.2 KB) TX bytes:268 (268.0 B) >>>>>> >>>>> >>>>> manually assigning an ip does not do the trick. When pinging the >>>>> desktop from the beaglebone (with or without manually assigning an ip), i >>>>> can catch the requests using tcpdump. The beaglebone does however not >>>>> receive anything, no answers to pings, nothing showing up in tcpdump. >>>>> >>>>> fdalbert@edge ~ $ sudo tcpdump -i eth1 >>>>>> tcpdump: WARNING: eth1: no IPv4 address assigned >>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol >>>>>> decode >>>>>> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 >>>>>> bytes >>>>>> 15:01:10.597986 ARP, Request who-has 192.168.7.1 tell 192.168.7.2, >>>>>> length 28 >>>>>> 15:01:11.588800 ARP, Request who-has 192.168.7.1 tell 192.168.7.2, >>>>>> length 28 >>>>>> 15:01:12.588895 ARP, Request who-has 192.168.7.1 tell 192.168.7.2, >>>>>> length 28 >>>>>> 15:01:13.597976 ARP, Request who-has 192.168.7.1 tell 192.168.7.2, >>>>>> length 28 >>>>>> 15:01:14.588800 ARP, Request who-has 192.168.7.1 tell 192.168.7.2, >>>>>> length 28 >>>>>> 15:01:15.588772 ARP, Request who-has 192.168.7.1 tell 192.168.7.2, >>>>>> length 28 >>>>>> 15:01:16.597983 ARP, Request who-has 192.168.7.1 tell 192.168.7.2, >>>>>> length 28 >>>>>> 15:01:17.588936 ARP, Request who-has 192.168.7.1 tell 192.168.7.2, >>>>>> length 28 >>>>>> 15:01:18.588919 ARP, Request who-has 192.168.7.1 tell 192.168.7.2, >>>>>> length 28 >>>>>> ^C >>>>>> 9 packets captured >>>>>> 9 packets received by filter >>>>>> 0 packets dropped by kernel >>>>>> >>>>> >>>>> root@beaglebone:~# ping 192.168.7.1 >>>>>> PING 192.168.7.1 (192.168.7.1) 56(84) bytes of data. >>>>>> From 192.168.7.2 icmp_seq=1 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=2 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=3 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=4 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=5 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=6 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=7 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=8 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=9 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=10 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=11 Destination Host Unreachable >>>>>> From 192.168.7.2 icmp_seq=12 Destination Host Unreachable >>>>>> ^C >>>>>> --- 192.168.7.1 ping statistics --- >>>>>> 14 packets transmitted, 0 received, +12 errors, 100% packet loss, >>>>>> time 13001ms >>>>>> pipe 3 >>>>>> root@beaglebone:~# tcpdump -i usb0 >>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol >>>>>> decode >>>>>> listening on usb0, link-type EN10MB (Ethernet), capture size 65535 >>>>>> bytes >>>>>> ^C >>>>>> 0 packets captured >>>>>> 0 packets received by filter >>>>>> 0 packets dropped by kernel >>>>>> >>>>> >>>>> I already spent hours trying to figure out the problem here, any help >>>>> is greatly appreciated! >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Robert Nelson >> https://rcn-ee.com/ >> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
