Summary, mostly working with some gotchas; this posting is just help others doing a change to 4.1.x, if not, please just ignore.
1) I2C works but it appears the addresses have changed: sudo i2cdetect -y -r 2 shows I2C at address 2 2) Adafruit_BBIO.ADC: needs fixes from https://gist.github.com/grizmio/bc752dd070652f21266b#file-gistfile1-txt just due to $SLOTS location changing. Copy this to the source file of git://github.com/adafruite/adafruit-beaglebone-io-python.git and do a git apply "patch-file" and then go to main directory and do a sudo make install. There are some warnings at patch application, but they don't seem to cause problems (I checked the code - the warning have something to do with line end spaces; I also checked the ADC functionality with gdb) I think I had to copy the ADC.so file in manually to /usr/local/lib/python2.7/dist-packages/Adafruit_BBIO; not sure why. 3) Adafruit_BBIO.SPI not working but not needed as spidev has been fixed for the RPi (by gadgetoid?) and seems to work fine fine for the BBB 4.1.x. It is found at https://github.com/doceme/py-spidev (just download and sudo make install). 4) uio_pruss: recompiled to increase memory size (I may have used a 4.1.13bone17 source due to laziness - no problems so far): > cat /sys/class/uio/uio0/maps/map1/size 0x00800000 and copied uio_pruss.so to /lib/modules/4.1.15-bone17/kernel/drivers/uio/ As far as I can tell the uio_pruss all works fine. I recompiled my logic analyzer and it seems to run as before (this seems like almost the only thing that worked without changes) 5) Networking, and wireless, had real problems but now working fairly well with a custom network manager (yech!); I still get intermittent problems for unknown reasons, but it generally comes up now irrespective of device and network subnet; I'm primarily using python with subprocess.Popen to call "ip" and a bit of pinging to find subnetwork address; networking has never been well done (and maybe will never be well done) in linux. Total lines of python: 628 to date If the usb0 gadget connection had not worked, I wouldn't of had a chance (thanks Robert). Loading overlays: I had and have problems here; could be due to my mis-understanding. 1) in /boot/uEnv.txt using: cape_enable=bone_capemgr.enable_partno=BB-BONE-PRU,BB-ADC,BB-SPIDEV1 doesn't work as the BB-SPIDEV1 seems to be from the main device tree, not from /lib/firmware. I added a systemd service to add overlays at boot from /lib/firmware. When adding at boot, my self.spi.max_speed_hz was wrong; it was 24MHz; if I loaded it later manually, it had its correct value of 100kHz (I'm running it slow to make using the logic analyzer easier). Note, the default in the main device tree is 16MHz. Suggestion: specify self.spi.max_speed_hz in your code to be safe Note also, the main device tree has spi-cpha; specified for channel 0. This has D1 changing on positive going clock edges; most SPI slaves sample on positive going edges, so one wants D1 changing on negative going edges; this default should be commented out Suggestion, specify self.spi.mode in your code to be safe (normally as 0, not the current 1) 2) I'm seeing unexpected (to me) behaviour when loading and removing SPI tree overlays. The first one comes at /dev/spidev1.0 and /dev/spidev1.1 irrespective if whether it is bus 0 or bus 1 (i.e. BB-SPIDEV0-00A0.dtbo or BB-SPIDEV1-00A0.dtbo), the next one comes in at /dev/spidev2.0 and /dev/spidev2.1 again irrespective of which bus it really is. The spi overlays can be removed and the re-installed, but each time, they come in at one higher file number location. One's code needs to know the location to open the device (one could check for it, but this seems overly complicated). I would have expected spi0 to come in at spi0 and spi1 to be at spi1. I lost at least a full week here. With these caveats, and the fixed code from gadgetoid, the spi1 seems to be now working fine for me; for me the I2C's and SPI's are the most critical drivers. Summary, some issues with the tree overlays, that need to be simplified/modified, but overall everything is mostly now working (somewhere around 7-8 weeks full-time from first flashing), Pyside, scite, and gtkwave all work with no problems. I may not be the best at BBB's, but this will be the last time I reflash. The uio_pruss seemed to have no problems (after recompiling) which was real nice (the PRUs are the only reason - well maybe lack of an eMMC as well - besides invested time, that I am not switching to RPis). I suggest just doing updates -with the correct flags- unless your full-time job is embedded linux. I also suggest some simple shell scripts to automate backup (such as nc -l -p 19000|bzip2 -d|dd bs=16M of=$filNm on host and sudo dd bs=16M if=/dev/mmcblk0|bzip2 -c|nc $1 19000 to back up often (also be careful not to get rid of eMMC in /boot/uEvt.txt if not running for sD card - as I accidentally did - this is dangerous). There were many many errors during the process as the documentation is primarily scattered one-liners in many forum postings; it's just nice to be past it now. Hoping this saves others some time. -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
