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 <yyrk...@gmail.com> 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 <yyrk...@gmail.com> wrote: > >> So after: >> >> root@wgd:~# *systemctl disable generic-board-startup.service* >> Removed /etc/systemd/system/multi-user.target.wants/generic-board- >> startup.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 <yyrk...@gmail.com> >> 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 beagleboard+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqTVHC%2B1OxRUAkYtsLFb3%2BSNN03aPny5XTdsLWx-r%3DNDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
