Hello friends. I need some help with my file also forgive me I’m new to this. I have a file with a lot of custom stuff on it including a custom DTB. The file was originally written for rev C and now it does not play audio on rev D. I’m flashing it to the Emmc and letting it boot up from that. I’ve already disabled all the hdmi stuff to see if that was an issue. From what I gathered I have a mcasp node 48038000 that says status okay on the old rev C but when it’s on the rev d in live practice it says disabled. Something native to the rev D is causing it to not work and then it can’t build out everything including the sound card. Does anyone know anything that would cause the rev D to not work like this.
Hard to say, based on the evidence shown, but a first cautious estimate would be
that you may be loading two or more overlays, one which enables and one who
disables the mcasp node. Last past the post wins…
Please provide the output from sudo beagle-version
and please enclose it in tripple-backslash notation:
Like this
makes log output much easier to read
debian@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Buster IoT Image 2020-04-06
This is the best I can do I think. sudo beagle-version did not work sorry
Also I thought there might be a different overlay turning it back off but the image worked on Rev C and it looked like all the same overlays loaded
Sounds odd that you’re unable to run the diagnostic,
but looking at the age of that image; the D wasn’t even around when that was built,
so I highly doubt you’re going to make that work.
Please use beagle-imager-rs and fetch an image that has a chance to work properly…
Do you use HDMI in your old rev c build?
No I don’t. I tried disabling it too and no dice.
Sounds like I’d have to rebuild it from scratch then in a way. A lot of the custom stuff on it wasn’t done by me so I’m not sure if I’m skilled enough to transfer.
Post your current audio overlay
Could cape universal be the problem? I disabled hdmi audio and everything but I don’t think I disabled that so I’m wondering if it is being ignored.
Cape universal isn’t used passed 5.10
Post your overlay
I’m using a 4.19 buster file on rev D though. I’m having a hard time figuring out what overlay is being used since I didn’t build the file myself and there’s a lot of old junk it that doesn’t do anything. I did notice that when it’s loaded on rev c nothing is assigned to P9_25 but on Rev D it’s assigning that pin I assumed it was because of the hdmi but when I disabled video and audio for the hdmi in the uEnv file it didn’t fix anything. Like I said though it still had cape universal on and wasn’t sure if that could affect it. I also don’t know what will happen if I disable it and then try to use it on the cape board.
Plug in a USB to serial adapter into j6 header and we will see what u-boot is doing for the overlay
I do not have an adapter is there another way to check? Sorry for being so difficult and limiting this was a project suddenly handed to me.
Grab one of these, https://www.digikey.com/en/products/detail/raspberry-pi/SC0889/17877576 located world wide thru many vendors..
Regards,
Adding to @lranders and @RobertCNelson — you can pull almost everything Robert
needs from the overlay side without the serial adapter, straight from Linux on
the booted board. That’ll also show why P9_25 gets grabbed on the D but not the C.
First, why sudo beagle-version didn’t run: that wrapper isn’t on the 2020-04-06
Buster image. Use the script it wraps:
sudo /opt/scripts/tools/version.sh
Paste that whole output (in triple-backticks). It shows your U-Boot version, the
full /boot/uEnv.txt, and — the important part — the uboot_overlay lines U-Boot
actually applied.
Then these:
# what U-Boot decided at boot (base dtb + applied/rejected overlays)
dmesg | grep -i -e overlay -e "not applied" -e "OF:"
# is McASP0 live or dead in the running tree?
cat /proc/device-tree/ocp/mcasp@48038000/status; echo
# (if that path errors: ls /proc/device-tree/ocp/ | grep -i mcasp)
# the board-ID string U-Boot keys off of — this is the crux
cat /proc/device-tree/model; echo
hexdump -C /sys/bus/i2c/devices/0-0050/eeprom | head
# and what audio overlays even exist on the image
ls -la /lib/firmware/*.dtbo
My guess at the cause: that image is from April 2020 and predates the Rev D, so
U-Boot doesn’t recognize the D’s EEPROM revision. On the C it IDs the board and
leaves your audio path alone; on the D it falls back to auto-loading
cape-universal (still active on 4.19 — the “not past 5.10” is the newer kernels).
cape-universal muxes nearly every P8/P9 pin, including P9_25 = mcasp0_ahclkx, your
McASP master clock — the exact pin you saw getting assigned on the D. Once it
claims those pins, the last write to the node’s status wins and McASP0
(48038000) ends up disabled, so the card never comes up. That’s also why killing
HDMI did nothing — HDMI wasn’t grabbing the pin, cape-universal was.
To test that, edit /boot/uEnv.txt on the eMMC and force the overlay set:
enable_uboot_overlays=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
enable_uboot_cape_universal=0
uboot_overlay_addr0=/lib/firmware/<your-audio-cape>.dtbo
Two catches: (1) U-Boot has a long-standing quirk where it ignores
enable_uboot_cape_universal=0 UNLESS a real cape overlay is actually loaded — so
the uboot_overlay_addr0= line pointing at your audio .dtbo is what actually makes
it skip cape-universal. (2) You need that overlay’s filename — the ls /lib/firmware/*.dtbo and the version.sh output will show what’s there / what’s
already being pointed at.
If you can’t tell which .dtbo is the audio one (since the file was handed to you
prebuilt), post the version.sh output + that ls and we’ll give you the exact line.
Longer term I’m with the others — cleanest fix is to flash a current image that
actually supports the Rev D and carry just that audio overlay onto it, instead of
forcing a 2020 image onto hardware it was never built for. But the uEnv.txt route
should get you sound today so you can keep moving.
1 Like