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 2) Activate our own cape-universal file from bb.org-overlays with cape_enable=bone_capemgr.enable_partno=cape-universal 3) 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 On Thursday, February 4, 2016 at 4:49:12 PM UTC-6, [email protected] wrote: > > 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 > > On Wednesday, January 27, 2016 at 9:44:09 PM UTC-6, [email protected] > wrote: >> >> I experienced the same issue: >> BBB runs in 4.1.15-ti-rt-r43 >> Host runs in 4.2.5-300.fc23.x86_64. >> >> I thought I had network setup issue in host PC. So I checked the route, >> IP, net mask and gateway in host PC under 3.8 kernel, where host PC get >> connected to USB gadget ethernet correctly. >> >> But even I manually applied this setting for 4.1.15-ti-rt-r43. The >> connection is still broken. I wonder if/what DHCP server runs in 3.8? Is it >> possible that kernel USB gadget driver is broken in 4.1? >> >> thanks, >> Ricky >> >> >> On Wednesday, December 9, 2015 at 12:11:10 PM UTC-5, Fabian Dalbert wrote: >>> >>> seems to have been a driver compatibility problem on the host side >>> (linux mint 17.2, kernel 3.16). an update to linux mint 17.3 with kernel >>> 3.19 solved the problem. >>> >>> On Wednesday, December 9, 2015 at 9:13:47 AM UTC+1, Fabian Dalbert wrote: >>>> >>>> any ideas? >>>> >>> -- 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.
