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/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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrdxeesQ_2CLF97CubLaeXCYVC%2BYM3u-P2dM8jZhqB3MA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
