Fatal Error when trying to compile DTS on stock BBAI

General Discussion
,
1

Disclaimer: this has frustrated me for a week now. I thought device tree overlays were supposed to be easier? I would really appreciate some explicit help here to get this running, or at least to get further along and be able to compile a device tree and/or overlay and apply it for a custom cape. Perhaps we can make a trade such that I write up a clear, non-embedded firmware engineer oriented step-by-step tutorial that others could use to avoid this frustration? Otherwise what’s the point of flexible, reconfigurable, open-source hardware if you can’t set it up to do what you want? /rant

I’m trying to make a device tree or device tree overlay that turns off the LCD/HDMI on P8 so I can use those pins as GPIO (plus anything else, I2C, SPI, etc). I am keeping the default eMMC pins. As a test, I tried to edit the default BBAI dts (am5729-beagleboneai.dts) to just change the model name to something custom in the hopes of getting that to load so I know the process works, but I’m stuck at even getting the default dts to compile (modified or not). I’m in the /opt/source/dtb-4.14-ti/src/arm directory, and I immediately get the error:

Error: am5729-beagleboneai.dts:10.1-9 syntax error
FATAL ERROR: Unable to parse input tree

I’ve seen the dtc -O dtb -o command referenced in many places, but trying to use that on even the original file doesn’t work. The hope was I could use the default dts, change the "okay"s to “disabled” on the things I didn’t want, and get the BBAI to use that re-configured dts file. Seemed easy enough…

I can however compile an overlay from an example, but how can I apply that without rebuilding the kernel, which frankly seems more complicated than even the device tree overlay?

Or is there a way to manually deactivate devices / drivers after the system is booted up, regardless of the device tree / overlay?

Queue Chappelle show crack meme: Y’all got any more of them details?

Background:

  • Used a BBB for a couple mechatronics projects in grad school
  • BBAI rev A1, flashed with the latest IoT image from BeagleBoard.org - latest-images (AM5729 Debian 10.3 2020-04-06 16GB eMMC IoT TIDL Flasher) (and is this really the latest?)
  • Kernel is the image’s stock 4.14.108-ti-r131
  • dtc is 1.4.7
  • Cape is a custom daughter PCB to break out signals and GPIO lines needed
  • I’ve gone through the Bootlin / Beagleboard device tree overlay “example”, but it completely skips over important pieces like:
    • where in the file structure should the dtc -O dtb -o... command be run from?
    • why does the kernel need to be rebuilt? (for a non-Linux user this feels like needing to rebuild Windows because I want to plug in a different mouse)
    • why are they referencing an Ubuntu thing if all of the BBorg’s images are Debian?
    • if commercial capes are supposed to have an EEPROM that tells the BBB which overlay to load based on what is plugged in, why is anything kernel or SD card necessary? Shouldn’t it just be able to be built, plugged in, and turned on? And would this need to be repeated every time the board is booted up with said cape?
  • I have searched and searched for a more detailed tutorial and just can’t find something that works. I could do what I’m trying to do with a BBB, but I was excited to try a BBAI because it has more horsepower, only to find that the (very helpful) boot manager from the BBB’s uEnv.txt doesn’t exist. And why on Earth wasn’t the usefulness of this for non-embedded firmware engineers more obvious and implemented in a similar fashion for the BBAI out of the box?
2 
cd /opt/source/dtb-4.14-ti/
make

Regards,

3

Copied the modified am5729-beagleboneai.dtb from /opt/source/dtb-4.14-ti/src/arm to the logically named /boot/dtbs and rebooted … and now it won’t connect over USB via SSH. So now I’m reflashing the board again.

4

Ok, 1 problem down! I ran make from /opt/source/dtb-4.14-ti and even deleted the original am5729-beagleboneai.dtb file (yes, I made a back up), and it rebuilt the am5729-beagleboneai.dtb file, hopefully with my changed name.

But, how do I get it to boot with my rebuilt am5729-beagleboneai.dtb file? After a reboot, the model name in /sys/firmware/devicetree/base still lists the default “BeagleBoard.org BeagleBone AI”.

5

That’s also in the makefile…

cd /opt/source/dtb-4.14-ti/
sudo make install
sudo reboot

Regards,

6

Hey Robert, just wanted to say thank you much for the help. I’ve been able to directly edit the dts file, turn things off, and set up the pinmux directly.

I did however find that even just changing only the model name would cause the dts file not to load at all, so that was a surprise.

7

That’s odd, there’s nothing really tied to that…

Regards,

8

Well I’ve got some fun weirdness to report back with in response to my initial issues with just changing the model name. And just for specificity, for initial tests I was only changing line 16 in the original 4.14.x-ti dts here, which only changed the “BeagleBoard dot org” inside the quotes to something custom. So no messing with the actual dts or pinmux at that point.

It appears the dtb file was loading, but something is happening to the USB connection. It’s not clear if it’s on the BBAI side or Windows, however I would not get the tell-tale bing-bong when I plug it in, nor do I even get an unknown USB device listed in Device Manager.

At the time I was only connecting to the BBAI with a USB-C and SSH via Putty and anytime I changed the model text it would no longer connect over USB-C (the BBAI is powered externally btw). So I stopped trying to change the model name, set up my pinmux and disabled devices, and have been going from that.

Now that I have the pinmux set up and tested and unnecessary things disabled, I’ve since switched to the BBAI being connected to my router via ethernet, the BBAI’s wireless and tethering disabled, and I connect over WiFi through my router. However, if I change the model name now it apparently does load the default dtb (or a custom dtb via uEnv.txt) with the changed model name, and I can see it in the /sys/firmware/devicetree/base, but only if I connect via its IP address. I still get nothing if I plug in the USB-C.

And that’s certainly part of my previous confusion/frustration, because I could see the heartbeat LED but not connect with USB-C. And using a micro-HDMI cable didn’t work either, though admittedly I likely didn’t have something set up correctly there. So my guess is that it was loading the dtb regardless, I just didn’t know it because of whatever is happening with the USB-C with the changed model name. And I did previously try different file names and specifying them in uEnv.txt and got the same lack of USB connectivity issue. However just testing it quickly now, I can change the model name or specify a custom dtb file in uEnv.txt and see that it it did it, but only if I connect via its IP address.

9

Digging more deeply, USB_C gadget devices with v4.14.x (Debian Stretch or Buster?)

Used this old script:

	BeagleBoard.org_BeagleBone_AI)
		script="bbai.sh"
		;;

So you just disabled USB gadget devices in Stretch/Buster…

For Bullseye i rewrote it like this…

Which doesn’t care what hardware you have, it just runs:

Regards,

10

Well, good to know at least what was happening. I am using the Buster 10.3 IoT image listed on the latest images page on the BeagleBoard website. I’m guessing that’s not actually the latest image that should be used for the BBAI?

And obviously it begs the question: what should be used as the latest, and is it drastically different to set up the pinmux again?