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 . . .
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
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.
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.
It appears everything loaded fine.
uEnv.txt
By the way, the remoteproc modules went away on their own. I’m not sure why, but good 
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