I would like to use some of the pins on P8 listed as for the LCD as GPIOs with the ARM and PRU sides of the SOC. I have not been successful getting this to work. What’s the secret? Is it even possible? I’ve tried P8_27, P8_28 and P8_45 and one of these work.
In the buster era, you just disable the hdmi option in /boot/uEnv.txt
Or your force the board to use BeagleBone Green Device tree (which doesn’t have hdmi)
Regards,
Here’s my uEnv.txt. I thought disabling video disabled HDMI. Am I missing something here?
FYI - I rolled that disable-tilcdc.dtbo and have tried it with it enabled and disabled and it makes no difference.
I appreciate your help. This isn’t an area that I work in a lot.
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
uname_r=4.19.94-ti-r68
#uuid=
#dtb=
###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/boot/dtbs/$(uname -r)/overlays/disable-tilcdc.dtbo
#uboot_overlay_addr1=<file1>.dtbo
#uboot_overlay_addr2=<file2>.dtbo
#uboot_overlay_addr3=<file3>.dtbo
###
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-W1-P9.24-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo
#uboot_overlay_addr6=<file6>.dtbo
#uboot_overlay_addr7=<file7>.dtbo
###
###Custom Cape
#dtb_overlay=<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###
cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet
#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet video=HDMI-A-1:1024x768@60e
#Use an overlayfs on top of a read-only root filesystem:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet overlayroot=tmpfs
##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
Nothing seems to work.
I have edited /boot/uEnv.txt to disable video and added an explicit
disable_hdmi=1
to uEnv.txt
debian@beaglebone:/var/lib/cloud9/EDENDev/Misc$ dmesg | grep -i hdmi
debian@beaglebone:/var/lib/cloud9/EDENDev/Misc$ dmesg | grep -i lcd
debian@beaglebone:/var/lib/cloud9/EDENDev/Misc$ dmesg | grep -i FB
debian@beaglebone:/var/lib/cloud9/EDENDev/Misc$ ls /dev/fb0
ls: cannot access '/dev/fb0': No such file or directory
I don’t think its enabled at all based on the above checks.
Yet, the few pins that are ‘allocated’ to the LCD still don’t turn on an external LED.
I have confirmed the wiring of the test LED is correct by directly connecting the lead to it fo P9_3 and the LED comes on.
Any ideas?
The Green is not an option. In my experience, I lose other GPIOs if I do that.
Many of the lines allocated to the LCD are technically available as GPIO’s the PRUs can use and I need a couple of those desperately. Otherwise I’m headed to a multi-BeagleBone architecture on this machine.
that disabled hdmi… so the pins are free…
idk… run…
sudo beagle-version
Which might not exist on Buster…
Regards,
@WalterCEden
It’s possible to use that pins, since it’s straight forward when using libpruio. All you’ve to consider is the additional load from the wired chip. But since you never tried that:
You didn’t tell us: how do you do pinmuxing without libpruio? I cannot find anything in your uEnv.txt.
Regards
sudo beagle-version
[sudo] password for debian:
eeprom:[A335BNLT00C02411SBB02285]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2021-02-15]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2019.04-00002-gc9b3922522 (Aug 24 2020 - 16:42:18 -0500)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gc9b3922522]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0.kernel]
UBOOT: Loaded Overlay:[BB-ADC-00A0.kernel]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0.kernel]
UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
kernel:[4.19.94-ti-r68]
nodejs:[v10.23.1]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.24-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20210809.0-0~buster+20210816]
pkg:[bb-customizations]:[1.20210810.1-0~buster+20210810]
pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal input bluetooth netdev i2c gpio admin spi iio docker tisdk weston-launch xenomai cloud9ide pwm eqep remoteproc]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 73.895571] remoteproc remoteproc0: wkup_m3 is available
[ 74.051090] remoteproc remoteproc0: powering up wkup_m3
[ 74.051119] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148
[ 74.057275] remoteproc remoteproc0: remote processor wkup_m3 is now up
[ 76.074214] remoteproc remoteproc1: 4a334000.pru is available
[ 76.091929] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[ 76.074214] remoteproc remoteproc1: 4a334000.pru is available
[ 76.074405] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully
[ 76.091929] remoteproc remoteproc2: 4a338000.pru is available
[ 76.092114] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully
dmesg | grep pinctrl-single
[ 1.027512] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[ 1.040948] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 002: ID 0846:9030 NetGear, Inc. WNA1100 Wireless-N 150 [Atheros AR9271]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END
@DTJF we do not use libpruio. Our C code does system calls to run config-pin. We don’t need to make any real-time pinmux changes and this has always worked sufficiently for our system. Maybe I should learn about libpruio but that’s one more thing I don’t have time to do! But maybe it would save me time in the long run!
Yeap you have full control thru config-pin in that build…
Regards,
@RobertCNelson I thought so but it isn’t working. None of the pins P8_27-P8_46 are working. I could really use them. I’ve tried another unit running the same image but no luck.
Anyhow, I see no reason why I should ever use config-pin again. But in the beginning (3.x kernels), I found out that some of my universal overlays silently don’t work, since they’re too big for the dts compiler. After dividing them into peaces, they run.
I used example analyse to prove the pinmuxing (but it needs libpruio installed). If there’s any other method to read/check the pinmux registers in the CM module, you should tell @WalterCEden how to use it.
Regards