edgeAI flasher images not working on AI-64

General Discussion
1

Dear all,

I just spend a couple of hours realizing that none of the EdgeAI images are working ‘out of the box’. There are alltogether 4 images of this type for the AI-64. They show the heartbeat but the board is not reachable via COM or SSH.
Am I really the first one who is noticing that or do I miss something during installation.
In general I’m aware of how to handle a Flasher image. So I successfully flashed the 6.12. image (that doesn’t help me much due to my needs for the edgeAI lib).

Best Regards
Markus

2

Which of the 4 images are you trying?

I see the following available:

  • 11.6 (REVB1 production)
  • 11.8 (2023-10-07)
  • 11.7 (2023-09-02)
  • 11.5 (2022-11-01) not listed as a flasher image

My colleague got one of them working recently, I’ll verify which one they used.

3

My current status (always flashed with BeagleBoard Image utility, press boot button, power on (DC-connector), release boot button - balenaEtcher always fails with validation, even if I unpack the images first). Most of the items in the list below I tested on Ubuntu 24 and Win11 host. My procedure works with this image without any problems. To make sure eMMC content doesn’t have an impact on the test. I used the 13.3. image runing from eMMC and made it ‘unbootable’ by: sudo dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=16 conv=fsync (verified and can confirm that only the power LED is on, no heartbeat). I don’t have a serial cable available to show boot messages.

  • 11.8 is saying its a flasher image it has the following entry in extlinux.conf:
    menu title BeagleBone AI-64 microSD (extlinux.conf) Options

    menu title BeagleBone AI-64 microSD (extlinux.conf) Options

    timeout 50

    default BeagleBone AI-64 microSD (default)

    label BeagleBone AI-64 microSD Recovery
    kernel /Image
    append root=/dev/mmcblk1p2 ro rootfstype=ext4 rootwait net.ifnames=0
    fdtdir /
    initrd /initrd.img

    label BeagleBone AI-64 copy microSD to eMMC
    kernel /Image
    append root=/dev/mmcblk1p2 ro rootfstype=ext4 rootwait net.ifnames=0 init=/usr/sbin/init-beagle-flasher
    fdtdir /
    initrd /initrd.img

    label BeagleBone AI-64 microSD (default)
    kernel /Image
    append root=/dev/mmcblk1p2 ro rootfstype=ext4 rootwait net.ifnames=0 quiet init=/usr/sbin/init-beagle-flasher
    fdtdir /
    #fdtoverlays /overlays/.dtbo
    initrd /initrd.img

    Nevertheless it shows after a short period (shorter then expected) a heartbeat but the board is not reachable on COM or SSH. No ‘knight-rider’ running LEDs either.

  • 11.7 more less the same as for 11.8 described above.

  • 11.6 more less the same as for 11.8 described above. The description on the website says it is used in a webinar (I havn’t checked that yet)
    This image has only one entry in the extlinux.conf:
    label Linux microSD
    kernel /Image
    append root=/dev/mmcblk1p2 ro rootfstype=ext4 rootwait net.ifnames=0 init=/usr/sbin/init-beagle-flasher quiet
    fdtdir /
    #fdtoverlays /overlays/.dtbo
    initrd /initrd.img

  • 11.5 more less the same as for 11.8 described above. This image has only one entry in the extlinux.conf:
    label Linux microSD
    kernel /Image
    append console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 root=/dev/mmcblk1p2 ro rootfstype=ext4 rootwait net.ifnames=0 quiet
    fdtdir /
    initrd /initrd.img

After testing these four images (in the order from top to bottom) I did a successful back-to-back test with the working 6.12 image. I’m using the same SD-card for all the tests (64Gbyte). One more observation. None of the edgeAI images has a sysconf.txt file in \boot.
So for a final test I add to the 11.8 version a sysconf.txt file (the default one) but don’t notice any difference (no surprise because all the listed images don’t even start the flash process).

With the assumption that no-one is putting broken images on the web and also couldn’t find anything about it in this forum I assume I missed anything that applies especially to EdegAI images. If someone can please point me to that.

Best Regards
Markus

4

I started with a board with the 13.3 image loaded (kernel 6.12).

With a 64GB micro-sd, used BeagleBoard Imager (Linux Flatpak version) to write the Debian 11.8 flasher image. The written card contains an extlinux.conf that looks like what you posted.

Installed the card, hold BOOT, power on. Continue to hold BOOT, I got to the flashing lights roughly 20 seconds in. I do have a console cable, so I was able to monitor the progress, and it does indeed flash the board.

Thoughts:

  • After you power on, how long are you continuing to hold the BOOT button? Try holding it for > 10 sec or more?
  • Have you tried a different power supply? I’m using USB-C, 5.1V / 3A max (one of the newer RPI branded supplies).

So the 11.8 image works, at least.

I’m not sure what else to suggest other than to verify with a console cable. For reference (as I had to do some digging to come up with this info), I found the following parts to construct a cable, since I didn’t find a ready-made assembly:

  • JST P/N ZHR-3 (DigiKey: 455-1160-ND) need 1 per cable, order at least 10
  • JST P/N ASZHSZH28K305 (DigiKey: 455-3080-ND) need 3 per cable, these are the 12” leads with pre-crimped connectors. I cut them in half, install them into the housing, and then solder to 0.1” headers for use with a 3.3v USB-TTL cable. (I’m sure there’s other ways to make the cable, if you can find pre-made 3-pin assemblies that’s great, this is just what worked for me.)
5

Hi,
thanks for all the hints.

I ordered the parts for an UART cable and will receive it by mid of next week. I will come back as soon I have it ready to work.

One more question about the ‘hold’ time of the the boot button. I thought the boot botton will force the board to boot from SDcard if the low level software reads button pressed at powerup. Then it looks into extlinux.conf and displays the menu. After the timeout it will choose the option that is marked as ‘default’. So the duration of the hold time doesn’t really matter. I assume I don’t have the full picture here. Please let me know the different effects of the hold time of the boot button.

Best Regards
Markus

6

Dear all,

I continue with my observations - still havn’t received my UART adapter.

I accidentially find out that having success (in terms of a working board) after the flashing depends also on the kernel version and the SD-card. I have two Samsung (Pro, UHS-I U3) SD cards that don’t work with 5.10 Kernels. The same cards run with 6.12 and 6.18 Kernel. I have another SD card (that I cannot read the manufacturer anymore) that is working on 5.x and 6.x Kernels. Certainly I checked all my SDcards with typical tools to make sure they are 100% OK.

There are already a couple of comments in this forum about suitable SD cards. For me it seems to be not only a question of the SD card but also a question of the Kernel version - maybe that rings a bell to someone who is involved with driver topics inside the Kernel.

Till now I still havn’t reached the point to use EdgeAI on one of the latest kernels. I will continue to try.

Best Regards
Markus

7

To use the newer EdgeAI and kernels you’ll need to build your own Yocto based image.

Unfortunately, there is no working EdgeAI Yocto image build for the BeagleboneAI64. I did mange to get a TISDK 11.00 EdgeAI image build working for the TDA4VM-SK/J721E-SK dev board.

Here is my meta layer with a fix to get the EdgeAI demo working for the J721E-SK dev board meta-j721e-sk-edgeai-sdk-11-00-fix

I have been meaning to also make a Yocto meta layer to fix the TISDK 11.01 EDGE AI build for the BeagleboneAI64. After some time, I got burned out and have not gotten back to it yet.

Some links to help you get started:

Figuring out a Yocto EdgeAI build for the BeagleboneAI64

There are two paths I see to attempt to get a working EdgeAI image build for the BeagleboneAI64.

  • One direction is to start from the working SDK 11.00 setup I have for the J721E-SK build. And then to make your own Yocto meta-layer with modifications for the BeagleBoneAI64. You’ll need to change the device tree config, bootloader config, and whatever else you run into. I once with success did this method for a similar TI SOC based board.

  • The other direction is to start from either SDK 11.01.07.05 or SDK 11.02.00. IIRC these two SDKs have working tisdk-default-image Yocto builds for the BeagleboardAI64. They will boot up and make it to a bare Weston desktop. This is the direction I am attempting to take.

    For your Yocto local config, in conf/local.conf, make sure to set MACHINE = "beaglebone-ai64" to use beaglebone-ai64.conf.

Yocto build instructions for BBAI64

Start with the normal TI Scarthgap-based Yocto setup described here Setup dev container and so on

Inside your TI build container, do the following steps.

git clone https://git.ti.com/git/arago-project/oe-layersetup.git tisdk
cd tisdk
./oe-layertool-setup.sh -f configs/processor-sdk-analytics/processor-sdk-analytics-11.##.##-config.txt

cd build
. conf/setenv

echo 'ARAGO_BRAND = "edgeai"' >> conf/local.conf
echo 'MACHINE = "beaglebone-ai64"' >> conf/local.conf

Build the default tisdk image:

bitbake -k tisdk-default-image # NO TI EdgeAI!

Build the Edge AI image:

bitbake -k tisdk-edgeai-image #currently broken for BBAI64
8

Building a current EdgeAI image for the BeagleBone AI-64 — progress + one remaining blocker

Following up on the “EdgeAI flasher images not working on AI-64” topic. I went the build-it-yourself route and got a current tisdk-edgeai-image to build, boot, and bring up a display on the BeagleBone AI-64. The accelerated TIOVX path still fails at runtime, and I think I’ve pinned down exactly why — would appreciate input from anyone who’s gone further.

Setup

  • oe-layersetup with processor-sdk-analytics-11.02.00-config.txt

  • MACHINE = "beaglebone-ai64", ARAGO_BRAND = "edgeai"

  • Building tisdk-default-image (works) and tisdk-edgeai-image

  • All fixes kept in a separate machine/brand-scoped meta layer so the TI layers stay untouched

Build fixes that got tisdk-edgeai-image to compile

1. ti-vision-apps was pinned to a stale manifest for the edgeai brand. The recipe has a brand override:

SRC_URI:edgeai = "...REL.PSDK.ANALYTICS.NONSAFETY.11.01.00.03...;manifest=vision_apps_yocto_nonsafety.xml"

With ARAGO_BRAND = "edgeai" that override wins, so vision_apps was built from the 11.01 release, while ti-tidl (its arm-tidl is at SRCREV 4366d488…) is at 11.02. Result: ti-tidl failed to link with

libvx_tidl_rt.so: undefined reference to `tivxCreateObjectArrayFromList'
libvx_tidl_rt.so: undefined reference to `tivxTIDLNodeV2'

i.e. the 11.01 libtivision_apps.so doesn’t export the newer TIOVX/TIDL symbols. There is no 11.02 NONSAFETY analytics tag (only REL.PSDK.ANALYTICS.11.02.00.01..10), which is presumably why the override was never bumped. I overrode SRC_URI:edgeai to the 11.02 manifest the recipe’s own default uses:

SRC_URI:edgeai = "...REL.PSDK.ANALYTICS.11.02.00.10...;manifest=vision_apps_yocto.xml"

2. The full 11.02 manifest pulls in the SRV GPU 3D demo, which needs two third-party headers. After the manifest fix, ti-vision-apps failed in kernels/srv/gpu/3dsrv/graphics:

fatal error: stb_image.h: No such file or directory
fatal error: nlohmann/json.hpp: No such file or directory

Both recipes already exist in the layer set, so adding

DEPENDS:append:edgeai = " nlohmann-json stb"

to ti-vision-apps resolved it, and the full image then built cleanly (all tasks succeeded).

Runtime status

  • Image boots from microSD, kernel 6.12.43 (from linux-bb.org).

  • edgeai-init.service autostarts the OOB demo (edgeai-gui-app -platform linuxfb).

  • Display: at the monitor’s native 4K I got TIDSS Plane1 underflow / CRTC0 SYNC LOST. There is no extlinux.conf and no devicetree line in the SD’s GRUB config; the SD boots via GRUB/EFI (EFI/BOOT/grub.cfg), and the name_overlays= line in uEnv.txt is not honored on this boot path. Forcing the mode in the GRUB linux line fixed it:

video=DP-1:1920x1080@60

The blocker: TIOVX can’t initialize its shared memory

The OOB GUI starts, then bails:

MEM: ERROR: Failed to initialize DMA HEAP [/dev/dma_heap/carveout_vision_apps_shared-memories] !!!
APP: ERROR: Memory init failed !!!
Bail out! ERROR: .../gsttiovxcontext.c:146:gst_tiovx_context_init: assertion failed: (0 == ret)

So the vision_apps_shared-memories carveout / DMA heap is missing from the device tree.

Root cause (as far as I can tell): MACHINE = beaglebone-ai64 uses the BeagleBoard.org kernel (linux-bb.org, here 6.12.43+git), and its device trees do not define the TI EdgeAI memory map. A grep -rl "vision_apps" across that kernel’s arch/arm64/boot/dts/ti returns nothing — not for the BBAI64 DT, and not even for the k3-j721e-sk.dtb it builds. The k3-j721e-edgeai-apps.dtbo overlay referenced in uEnv.txt is not built/present anywhere in the image. The TI vision_apps reserved-memory carveouts, DMA heaps and the related remoteproc/IPC nodes appear to live only in the TI kernel (ti-linux-kernel), not in the bb.org kernel this machine config selects.

Open questions

  1. Has anyone gotten the TIOVX vision_apps memory carveouts (the carveout_vision_apps_shared-memories DMA heap + the C7x/R5 reserved-memory and remoteproc nodes) onto the BBAI64 while using the linux-bb.org kernel?

  2. Is the realistic path to switch beaglebone-ai64 to ti-linux-kernel + a TI-style J721E device tree, or to port TI’s J721E rtos memory-map / vision_apps reserved-memory into the bb.org BBAI64 DT as an overlay/patch?

  3. Does a working k3-j721e-edgeai-apps.dtbo (or an equivalent carveout overlay) exist anywhere for the bb.org kernel — and if so, how is it applied on the GRUB/EFI boot path (which ignores uEnv.txt name_overlays)?

Happy to share the full fix layer if it’s useful. The build side seems solved; the device-tree memory map for EdgeAI on the bb.org kernel is the piece I’m stuck on.