Ok, I'm 99.9% sure the GPIO's are all being configured correctly and functional. As I know there are exactly 6 GPI's and the rest are GPO's.
root@wgd:~# cat /sys/class/gpio/gpio*/direction out out out out out out out out out in in in in in in out out out out On Wed, Apr 5, 2017 at 8:51 PM, William Hermans <[email protected]> wrote: > By the way, the remoteproc modules went away on their own. I'm not sure > why, but good ;) > > On Wed, Apr 5, 2017 at 8:49 PM, William Hermans <[email protected]> wrote: > >> It appears everything loaded fine. >> >> *uEnv.txt* >> ### >> ###Additional custom capes >> uboot_overlay_addr4=/lib/firmware/custom-00A0.dtbo */* 6 channels PWM, >> and ~19 pins GPIO */* >> uboot_overlay_addr5=/lib/firmware/BB-ADC-00A0.dtbo >> uboot_overlay_addr6=/lib/firmware/BB-W1-P8.26-00A0.dtbo */* Modified >> 1-wire overlay */* >> #uboot_overlay_addr7=/lib/firmware/<file7>.dtbo >> >> >> root@wgd:~# *lsmod* >> Module Size Used by >> ti_am335x_adc 6300 0 >> kfifo_buf 3732 1 ti_am335x_adc >> industrialio 62863 2 ti_am335x_adc,kfifo_buf >> w1_therm 4886 0 >> w1_gpio 3764 0 >> wire 35436 2 w1_gpio,w1_therm >> omap_aes_driver 23912 0 >> omap_sham 26513 0 >> omap_rng 5544 0 >> pwm_tiehrpwm 5883 0 >> rng_core 9066 1 omap_rng >> evdev 13511 1 >> ti_am335x_tsc 6268 0 >> ti_am335x_tscadc 6563 2 ti_am335x_adc,ti_am335x_tsc >> uio_pdrv_genirq 3923 0 >> uio 10524 1 uio_pdrv_genirq >> >> OK so . . . >> >> root@wgd:~# *cat /sys/bus/w1/devices/28-*/w1_slave* >> c0 01 4b 46 7f ff 10 10 8f : crc=8f YES >> c0 01 4b 46 7f ff 10 10 8f t=28000 >> >> 1-wire definitely working. >> >> root@wgd:~# *ls /sys/class/pwm/* >> pwmchip0 pwmchip2 pwmchip4 >> >> PWM seems to be there, I'd have to test further to be 100% sure. e.g. >> echo 'x' > export etc. >> >> root@wgd:~# *ls /sys/class/gpio/* >> export gpio111 gpio115 gpio2 gpio23 gpio44 gpio46 gpio48 >> gpio50 gpio60 gpiochip0 gpiochip64 unexport >> gpio110 gpio112 gpio117 gpio22 gpio3 gpio45 gpio47 gpio49 >> gpio51 gpio86 gpiochip32 gpiochip96 >> >> GPIO's all look right. Not tested yet of course. >> >> root@wgd:~# *cat /sys/bus/iio/devices/iio:device0/in_voltage*_raw* >> 2160 >> 3053 >> 3255 >> 1428 >> 1553 >> 2281 >> 2312 >> >> And of course the ADC's all seem to be working. channel 0 is the only one >> connected to a voltage externally, so I'd have to write a quick script or >> something, check the schematic, and see what the voltage range is to be >> sure it's working properly. But that's outside the scope of uboot overlays. >> . . >> >> Anyway, the "custom" overlay is not something I need for this specific >> cape, but is something I would test right away. For GPIO's, and PWM. That >> slot will actually be for enabling I2C-1. Plus I do believe there is an I2C >> RTC on one of the other buses, but those buses are most likely working, >> otherwise the beaglebone would not function correctly, or at all. >> >> Well done Robert ! This is pretty awesome stuff. You too Panto ! >> >> >> On Wed, Apr 5, 2017 at 8:19 PM, William Hermans <[email protected]> >> wrote: >> >>> Ok so an observation. >>> >>> I've got one custom overlay to load. Well technically two, but only one >>> at a time so far. I've only experimented with one at a time so far. >>> However, the image I downloaded was an sdcard only image, and no flasher >>> image on the testing image page. So what ends up happening is that the eMMC >>> second stage bootloader interferes with the changes we're trying to make >>> from sdcard, The problem here, is that I have a custom cape on the >>> beaglebone( green ), and I can not put a serial debug cable on the >>> beaglebone, let alone depress the boot button . . . >>> >>> The bootloader on the eMMC was. . . >>> >>> root@wgd:/opt/scripts/tools# *sudo ./version.sh | grep bootloader* >>> bootloader:[microSD-(push-button-default)]:[/dev/mmcblk0]:[U-Boot >>> 2017.03-00002-gbfe60d6057] >>> bootloader:[eMMC-(bootrom-default)]:[/dev/mmcblk1]:[U-Boot >>> *2016.03-00001-gd12d09f*] >>> >>> Big problem there for those who would be unaware, but I was able to >>> "fix" this problem of mine by flashing the eMMC via changing the cmdline= >>> to the flasher image variety. So now, both my custom overlays have loaded, >>> one at a time. The only other overlay I need to test for now is the stock >>> BB-ADC overlay, which I'm sure will work. >>> >>> @Robert >>> >>> So short of the serial output, how do we know an overlay has loaded ? >>> I'll have to get with my buddy to change the cape he's designed so it'll >>> have a serial "header pass through" so that the serial debug pins will be >>> on top of the cape. I was able to determine the capes loaded by issuing the >>> command lsmod, and seeing what's loaded, but running cat on */slots did not >>> really yield much information. >>> >>> On Wed, Apr 5, 2017 at 6:36 PM, William Hermans <[email protected]> >>> wrote: >>> >>>> So after: >>>> >>>> root@wgd:~# *systemctl disable generic-board-startup.service* >>>> Removed /etc/systemd/system/multi-user.target.wants/generic-board-st >>>> artup.service. >>>> >>>> root@wgd:~# *nano /boot/uEnv.txt* >>>> Change: cmdline=coherent_pool=1M net.ifnames=0 quiet >>>> cape_universal=enable >>>> To: cmdline=coherent_pool=1M net.ifnames=0 quiet >>>> >>>> This has cut down the running driver modules pretty good. To: >>>> root@wgd:~# *lsmod* >>>> Module Size Used by >>>> omap_aes_driver 23912 0 >>>> omap_sham 26513 0 >>>> omap_rng 5544 0 >>>> rng_core 9066 1 omap_rng >>>> evdev 13511 1 >>>> uio_pdrv_genirq 3923 0 >>>> uio 10524 1 uio_pdrv_genirq >>>> pru_rproc 15431 0 >>>> pruss_intc 8603 1 pru_rproc >>>> pruss 12026 1 pru_rproc >>>> >>>> Which as far as I'm concerned is about as minimal as I'd want. >>>> Blacklisting the remoteproc PRU driver modules will do the rest. Awesome. >>>> But for those unaware keep in mind this is for a production system. For >>>> testing, you may want or need cape universal, and if you're tethered via >>>> USB networking, you do not want to disable >>>> *generic-board-startup.service* either. >>>> >>>> Anyway, I have several custom overlays I have to test, and it's dinner >>>> time, so will add all that info afterwards. >>>> >>>> >>>> On Wed, Apr 5, 2017 at 5:58 PM, William Hermans <[email protected]> >>>> wrote: >>>> >>>>> So, I've not actually gotten to testing the overlays loaded through >>>>> uboot yet. But I must say Robert, good job. Running lsmod after removing >>>>> cape universal from uEnv.txt (cmdline ) works awesomely. The only thing >>>>> left is the RNDIS related stuff, which can be disabled through your >>>>> generic-board service, and then black listing the PRU modules for those >>>>> who >>>>> don't need them should work great. >>>>> >>>>> Anyway, I'll keep updating this post as I explore the new image + >>>>> uboot features. Sorry it took so long to get aroudn to it, but now I'm >>>>> here, testing . . . >>>>> >>>>> -- >>>>> 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]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/beagleboard/b5d0918b-b0e6- >>>>> 4ed6-9c8d-716f2a23186a%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/beagleboard/b5d0918b-b0e6-4ed6-9c8d-716f2a23186a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpUk2cbNwJ-%2BRxN7EYV1NYtVXYSFBiHnVm6bsis0NDq_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
