The person involved with the HW and SW change, that also happened to make this post might know more than a person(myself) that would have to dig through inventory and go board by board inspecting the HDMI chip to find one that’s the new Rev… Assuming we even have one with the changes…
I’ve recently also refreshed the driver for kernel 6.6, I’ve been meaning to send it to you but forgot:
this is pushed to 6.6.x … 6.12.x has a fun new build error might look at it tomorrow..
drivers/uio/uio_pruss.c:298:19: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Werror=incompatible-pointer-types]
298 | .remove = pruss_remove,
| ^~~~~~~~~~~~
drivers/uio/uio_pruss.c:298:19: note: (near initialization for 'pruss_driver.<anonymous>.remove')
cc1: some warnings being treated as errors
make[7]: *** [scripts/Makefile.build:229: drivers/uio/uio_pruss.o] Error 1
make[7]: *** Waiting for unfinished jobs....
CC [M] drivers/target/target_core_configfs.o
CC [M] drivers/target/iscsi/iscsi_target_erl2.o
CC [M] drivers/media/dvb-frontends/stv6111.o
CC [M] drivers/hid/hid-magicmouse.o
make[6]: *** [scripts/Makefile.build:478: drivers/uio] Error 2
make[6]: *** Waiting for unfinished jobs....
too late tonight to think…
Regards,
yes, the return type of remove changed from int to void, so that’s a pretty easy fix: just change the return type to void and remove the return 0;
These just hit us. We don’t (knowingly) use HDMI, (parallel RGB and frame buffer) and are using a Yocto build with kernel 5.15.54. During testing/programming, we boot off a microSD card into one version of Linux to program a second version of Linux onto the eMMC. The bootloader via the debug port complains about not being able to find ‘am335x-boneblack-revd.dtb’, says it’s starting the kernel…and then nothing.
Are there any updates since October on the side effects of Rev D, or any hints as to how I should approach this? Has the Yocto support gotten any better ? (My sense is that it started out great, then became something of a forgotten stepchild)
JPA
I got v5.15.x-lts ITE hdmi support to the same level as 6.x.x series…
So if you ‘need’ the HDMI working, otherwise just boot up as “am335x-bonegreen.dtb” (copy as am335x-boneblack-revd.dtb).. and the hdmi boot up issues won’t show up..
Regards,
there’s really no 'Beagle" maintainer for yocto, it’s more of a free for all.. if someone wants to start doing this for BeagleBoard for fun, we have ci on github/gitlab/etc…
dear RobertCNelson thank you for contributing to the community . can you please share the new schematic based on ITE IT66122 .
@jkridner is this in your queue?
Hi, Robert
I don’t need the HDMI function, so I can use my old image in Rev D without change?
just set in /boot/uEnv.txt
disable_uboot_overlay_video=1
Then hdmi should not be loaded..
or force it to use the green device-tree which also disables hdmi..
Thanks,
By the way, my old image is using kernel v4.19 with Debian10 in Rev C, so I don’t need to do any other thing it can work fine in new board?
If your not using HDMI, you can use the image as is.. at worst case, your just force the green device tree..
Thanks,
I‘ll try
Hi, Robert
Rev D works fine in our old image. But we have some old board which don’t know their actual version(Rec C or Rev D). We want to distinguish them by software like reading the eeprom. Is bbblack eeprom can read this information?
Yes, the eeprom has the Rev encoded in the ASCII text..
hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -n 28 | cut -b 5-28
For reference, here is every known id… image-builder/readme.md at master · beagleboard/image-builder · GitHub
in RevD, it’s A335BNLT00D0
and in RevC, it’s A335BNLT000C or A335BNLT00C0
right?
Thanks
Hello,
I also just noticed the BBB Rev D issue.
We’re using the 4.19 kernel and debian 11.9.
Is there an update to the 4.19 kernel that has the new HDMI driver?
Thanks,
Franco
Nope, I’ve gotten things working ish back to v5.15.x..
For something as old as 4.19.x whats stopping you from 5.15 or later?
Regards,
Hi,
I went through this 2 years ago, so I’m depending on my notes here as I can’t remember it all.
There were 3 things that stopped us from using a kernel newer than 4.19.
One of them was gpio devices being handled differently: we have legacy code and scripts that modify gpio by using the /sys/class/gpio/gpioNN interfaces, and in any kernel 5.10 or newer the gpio devices get re-ordered, gpiochips are discovered in a different order, etc.
2nd one was ethernet. We had at the time lots of Rev B BBB’s, and ran into the problem where the on board ethernet would occasionally just not work with 5.4 or newer kernel. We did get the Ethernet on Rev B6 boards to work a little better with 5.10, but it had other problems: if the Ethernet was unplugged and plugged back in, it would fail to be found just like it used to during boot.
We got some Rev C BBB’s and tried the newer kernels that were supposed to work with ethernet and Rev C, but never were able to get the BBB’s ethernet to work reliably with anything newer than 4.19.
Third thing my notes say was the ability to get the PRU to work in UIO mode, but I don’t have enough details in my notes to remember the problem. Maybe with the right overlay the PRU works as expected in the newer kernels.
Franco