I used the console image below. The ethernet USB gadget works. I’m not sure if lxqt and console use the same commit. Run the checksum on the kernel?
I can report similiar issues. I can’t believe the host system matters here.
Beaglebone kernel linux-image-4.1.12-ti-r29 works perfectly
Beaglebone kernel linux-image-4.1.15-ti-rt-r43 has flaw in USB0 as well as a flaw in another cape serial device…
The usb link is almost functional. The problem appears to be that the beaglebone doesn’t receive ethernet packets over the usb ethernet device. It can send packets out that are picked up by my desktop ubuntu 14.04 LTS system. It is consistent with an RX interrupt mismatch on the beaglebone. RX count is always 1. TX goes up as expected.
-Dave
SOLVED!!!
The issue is the default cmdline for linux has this: “cape_universal=enable” which activates pin setup, naming, functionality and whatnot according to structures built into the kernel. Those defaults are not necessarily correct. Example: In the case of /dev/ttyS0 linux reports finding the serial port ttyS1 at MMIO 0x48022000 but the IO pins associated with that uart are left as GPIO pins… so the serial port doesn’t work.
I have a viable setup where I used this source tree:
https://github.com/RobertCNelson/bb.org-overlays
Inside is a file src/arm/cape-universal-00A0.dts and I've been tinkering with that. I do make && make install and it
copies cape-universal-00A0.dtbo to /lib/firmware (in addition to overwriting whatever else might be there -- CAUTION!!!)
So things can be made to work this way, making changes to /boot/uEnv.txt:
1) Turn off cmd line switch "cape_universal=enable"
cmdline=coherent_pool=1M quiet
- Activate our own cape-universal file from bb.org-overlays with
cape_enable=bone_capemgr.enable_partno=cape-universal - Once linux boots I can fix /dev/ttyS1 with these commands:
config-pin p9_24 uart
config-pin p9_26 uart
The USB problem I was experiencing went away with this cape-universal overlay, so I assume it's another pinmux flaw,
and it wasn't an interrupt problem like I thought. NOTE that this is sort of a hack. I think the preferred way of doing
this thing is to explicitly load the overlays of the hardware one wants to use. So if I wanted to use uart1 I'd do
echo BB_UART1 > /sys/devices/platform/bone_capemgr/slots
but that conflicts with the cape-universal I'm loading at bootup, so it doesn't work for me...
Basically the underlying issue is the linux / bone_capemgr philosophy is to have all pins default to GPIO and you're
supposed to use overlays to activate the hardware you want to use, and the overlays configure the pins the way
they're supposed to be. I think understanding the bone_capemgr is a requirement. I found these links informative:
http://www.thing-printer.com/cape-manager-is-back-baby/
https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay
http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
https://github.com/beagleboard/linux/blob/4.1/Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr
-Dave
Some new info: It doesn’t seem like the cape_universal=enable makes any difference whatsoever, meaning by taking it out nothing changes.
Regarding fixing the USB problem, I’m not sure if it did fix it after all. I’m running the beaglebone with a separate 5V power supply plugged in, so it isn’t being powered by USB. When I first boot the USB exhibits the same problem, the beaglebone side doesn’t receive any ethernet packets. But if I unplug the usb and plug it back in, the USB works fine, without making any bone_capemgr changes at all.
This isn’t an option when the beaglebone is being powered by USB, unplugging it will shut it down and when it is plugged in again everything starts over…
-Dave