Latest image with uboot overlays.

[William Hermans]

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 . . .

[William Hermans]

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 <yyr...@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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b5d0918b-b0e6-4ed6-9c8d-716f2a23186a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

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.

[William Hermans]

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 !

[William Hermans]

By the way, the remoteproc modules went away on their own. I'm not sure why, but good ;)

[William Hermans]

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