BBAI-64 Yocto BSP support

Hello - does AI-64 Yocto BSP support exist. Which is the correct BSP repo for AI-64 ?

TI publishes an embedded Linux distro called ā€œAragoā€ that is built via the Yocto Project. I donā€™t have the BBAI-64, but I have experimented with Arago on the BBB and it worked ok. TI has built and posted an SD card image as part of the processor SDK. Hereā€™s a link to the corresponding processor on the BBAI-64:

Personally I would verify it runs on the BBB-AI64 first. Then, assuming it does, I would trace through the documents of the TI Processor SDK to start rolling my own Yocto image using the recipes from the base image of Arago.

Any way you cut it using the Yocto project requires an R&D time investment before you end up with an image that fits your needs. TI created Arago to help give their customers a jump-off point for the effort - check it out! And please post back with your findings - someday I might be doing the same exercise!

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/08_04_00_11/exports/docs/linux/Overview_Building_the_SDK.html#overview-building-the-sdk

After some digging and research here are my findings:

TLDR:
I am able to build Yocto Kirkstone tisdk-thinlinux-image based on linux beaglebone 5.10.153. I plan to flash and test drive the image sometime this week to validate the image actually boots. By the way, the sdk image linked in the previous post does not boot the bbai-64.

# This file takes repo entries in the format
# repo name,repo uri,repo branch,repo commit[,layers=layer1:layer2...:layern]

bitbake,git://git.openembedded.org/bitbake,2.0,HEAD
meta-arago,git://git.yoctoproject.org/meta-arago,kirkstone,HEAD,layers=meta-arago-distro:meta-arago-extras
#meta-browser,https://github.com/OSSystems/meta-browser.git,master,5f365ef0f842ba4651efe88787cf9c63bc8b6cb3,layers=
meta-qt5,https://github.com/meta-qt5/meta-qt5.git,kirkstone,HEAD,layers=
meta-virtualization,git://git.yoctoproject.org/meta-virtualization,kirkstone,HEAD,layers=
meta-openembedded,git://git.openembedded.org/meta-openembedded,kirkstone,HEAD,layers=meta-networking:meta-python:meta-oe:meta-gnome:meta-filesystems
meta-ti,git://git.yoctoproject.org/meta-ti,kirkstone,HEAD,layers=meta-ti-extras:meta-ti-bsp
meta-arm,git://git.yoctoproject.org/meta-arm,kirkstone,HEAD,layers=meta-arm:meta-arm-toolchain
oe-core,git://git.openembedded.org/openembedded-core,kirkstone,HEAD,layers=meta
OECORELAYERCONF=./sample-files/bblayers.conf.sample
OECORELOCALCONF=./sample-files/local-arago64-v2.conf.sample
BITBAKE_INCLUSIVE_VARS=yes
  • I use googleā€™s repo tool to pull in all the required layer dependencies into my yocto source folder prior to building. It is required to point the repo tool to a mannifest file (living in a repository of its own) that lists all the repository links. The manifest file I created is here GitHub - saizen408/bbai64-repo-manifest: Yocto Layer Repo Manifest for Beaglebone AI-64

  • For some reason in the ti-sdk the /yocto-build/sample-files/bblayers.conf.sample is not populated with the required layers to build the image. So I had to make my own. I plan to create a custom layer that has a bblayer.conf.sample file but for now, below is what I used for the bblayers.conf in the yocto build folder:

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /yocto/sources/poky/meta \
  /yocto/sources/poky/meta-poky \
  /yocto/sources/poky/meta-yocto-bsp \
  /yocto/sources/meta-arago/meta-arago-distro \
  /yocto/sources/meta-arago/meta-arago-extras \
  /yocto/sources/meta-openembedded/meta-networking \
  /yocto/sources/meta-openembedded/meta-python \
  /yocto/sources/meta-openembedded/meta-oe \
  /yocto/sources/meta-openembedded/meta-gnome \
  /yocto/sources/meta-openembedded/meta-filesystems \
  /yocto/sources/meta-qt5 \
  /yocto/sources/meta-ti/meta-ti-bsp \
  /yocto/sources/meta-ti/meta-ti-extras \
  /yocto/sources/meta-arm/meta-arm \
  /yocto/sources/meta-arm/meta-arm-toolchain \
  /yocto/sources/meta-virtualization \ 
"
  • There are also example local.conf.sample files in the /yocto-build/sample-files directory. The one I used for my build was /local-arago64-v2.conf.sample. Be sure to update the MACHINE value to MACHINE = "beaglebone-ai64"

  • Finally after sourcing the bitbake env variables I ran bitbake tisdk-thinlinux-image

  • I noticed some issues with trying to fetch the linux-bb kernel, but after a couple rebuilds it worked. I think something was up with the server that hosts the kernel source

  • Please note that Iā€™ve yet to actually flash this image to my bbai-64 so Iā€™ve not yet confirmed it actually boots. Will report back shortly! Hope this write up helps :smile:

1 Like

Weā€™ve pinged the meta-ti team, this should be patched at somepoint to use github (GitHub - beagleboard/linux: The official Read Only BeagleBoard and BeagleBone kernel repository https://git.beagleboard.org/beagleboard/linux) vs our single gitlab machine on awsā€¦

Regards,

1 Like

Ok time for an update.

  1. First off, I instead attempted to build the tisdk-default-image since I wanted all the necessary to experiment with the AI demos.

  2. The build requires about 250+ GB of space. Also, I had to increase the RAM of my virtual machine to 20+ GB in order for the yocto build to not crash during the linking stage of the nodejs package.

  3. Compared to the official Debian release Beaglebone provides, this image loads via uboot (v2021.1) but then you are greeted to the famous GNU GRUB version 2.06 OS select prompt. I found this odd. Also, ā€˜bootā€™ is the only option available, I just press enter and the Kernel (Linux version 5.10.162 (oe-user@oe-host) (aarch64-oe-linux-gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.38.20220708) begins to boot.

  4. As to why I chose 5.10.162, I originally wanted to build Linux 5.10.153 (GitHub - beagleboard/linux at 5.10.153-ti-arm64-r86), however, when I this specific tagā€™s commit hash in SRCREV option in meta-ti/meta-ti-bsp/recipes-kernel/linux/linux-bb.org_git.bb I get a ā€œfailed to fetchā€ error from Bitbake after it seemingly cloned in 100% of the sources successfully. I think it might have something to do with the message displayed by Github (see previous web link), This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository..

  5. Currently I boot to the point of systemd going through its initialization but then get the following, not-syncing: Asynchronous SError Interrupt kernel panic. Iā€™m completely in the dark about what might be causing this. However, looking at the cpu register dump I see RGXBvncInitialiseConfiguration in the pc and lr registers. Could this be some issue with SGX driver, VNC? Any advice or ideas would be super appreciated;

Below is a snippet from partway through the systemd initialization to the kernel panic:

[  OK  ] Started Journal Service.
[  OK  ] Finished Load Kernel Modules.
[  OK  ] Finished Generate network units from Kernel command line.
         Mounting FUSE Control File System...
         Mounting Kernel Configuration File System...
         Starting Apply Kernel Variables...
[  OK  ] Mounted FUSE Control File System.
[  OK  ] Mounted Kernel Configuration File System.
[  OK  ] Finished Apply Kernel Variables.
[  OK  ] Finished File System Check on Root Device.
         Starting Remount Root and Kernel File Systems...
[    8.039477] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  OK  ] Finished Remount Root and Kernel File Systems.
         Starting Flush Journal to Persistent Storage...
[    8.080858] systemd-journald[251]: Received client request to flush runtime journal.
         Starting Create System Users...
[  OK  ] Finished Flush Journal to Persistent Storage.
[  OK  ] Finished Create System Users.
         Starting Create Static Device Nodes in /dev...
[  OK  ] Finished Create Static Device Nodes in /dev.
[  OK  ] Reached target Preparation for Local File Systems.
         Mounting /media/ram...
         Mounting /var/volatile...
[    8.278099] audit: type=1334 audit(1651167747.024:2): prog-id=5 op=LOAD
         Starting Rule-based Manageā€¦for Device Events[    8.286416] audit: type=1334 audit(1651167747.032:3): prog-id=6 op=LOAD
 and Files...
[  OK  ] Finished Coldplug All udev Devices.
[  OK  ] Mounted /media/ram.
[  OK  ] Mounted /var/volatile.
         Starting Wait for udev To ā€¦plete Device Initialization...
         Starting Load/Save Random Seed...
[  OK  ] Started Rule-based Manager for Device Events and Files.
[  OK  ] Reached target Hardware activated USB gadget.
[    8.911694] k3-dsp-rproc 4d80800000.dsp: assigned reserved memory node vision-apps-c66-dma-memory@a9000000
[    8.921885] k3-dsp-rproc 4d80800000.dsp: configured DSP for remoteproc mode
[    8.930096] k3-dsp-rproc 4d80800000.dsp: local reset is deasserted for device
[    8.938112] remoteproc remoteproc0: 4d80800000.dsp is available
[    8.945350] k3-dsp-rproc 4d81800000.dsp: assigned reserved memory node vision-apps-c66-dma-memory@a8000000
[    8.956284] k3-dsp-rproc 4d81800000.dsp: configured DSP for remoteproc mode
[    8.963458] remoteproc remoteproc0: Direct firmware load for vision_apps_eaik/vx_app_rtos_linux_c6x_1.out failed with error -2
[    8.974907] remoteproc remoteproc0: powering up 4d80800000.dsp
[    8.980772] remoteproc remoteproc0: Direct firmware load for vision_apps_eaik/vx_app_rtos_linux_c6x_1.out failed with error -2
[    8.992196] remoteproc remoteproc0: request_firmware failed: -2
[    8.996093] k3-dsp-rproc 4d81800000.dsp: local reset is deasserted for device
[    9.197259] img_dec 4300000.video-decoder: Direct firmware load for pvdec_full_bin.fw failed with error -2
[    9.207023] img_dec 4300000.video-decoder: Firmware binary is not present
[    9.214705] PVR_K:  288: Device: 4e20000000.gpu
[    9.219500] SError Interrupt on CPU0, code 0xbf000000 -- SError
[    9.219502] CPU: 0 PID: 288 Comm: systemd-udevd Tainted: G           O      5.10.162 #1
[    9.219503] Hardware name:  /, BIOS 2021.01-g09210092 06/01/2022
[    9.219505] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[    9.219506] pc : RGXBvncInitialiseConfiguration+0x1ec/0x8e0 [pvrsrvkm]
[    9.219507] lr : RGXBvncInitialiseConfiguration+0x850/0x8e0 [pvrsrvkm]
[    9.219508] sp : ffff80001257b740
[    9.219509] x29: ffff80001257b740 x28: ffff800011a97000 
[    9.219512] x27: ffff800009358bb0 x26: ffff000816a48148 
[    9.219514] x25: 0000000000000000 x24: ffff800009358158 
[    9.219516] x23: ffff8000093b1000 x22: 0000000000000001 
[    9.219518] x21: 0000000000000000 x20: ffff000816a48000 
[    9.219520] x19: ffff000814d4b800 x18: 0000000000000000 
[    9.219522] x17: 00000000e18d0391 x16: 00000000d14da548 
[    9.219525] x15: 0000000000000002 x14: 0000000000000001 
[    9.219527] x13: 00000000000638d5 x12: 0000000000000000 
[    9.219529] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f 
[    9.219531] x9 : 64716d741f397224 x8 : 7f7f7f7f7f7f7f7f 
[    9.219533] x7 : fefefefefefefeff x6 : ffff80001257b617 
[    9.219535] x5 : 8080808080808080 x4 : 0000000000000000 
[    9.219538] x3 : ffff80000939f1b8 x2 : ffff000814d4b990 
[    9.219540] x1 : 0000000000000000 x0 : ffff800014a80000 
[    9.219542] Kernel panic - not syncing: Asynchronous SError Interrupt
[    9.219559] SMP: stopping secondary CPUs
[    9.219560] Kernel Offset: 0xd0000 from 0xffff800010000000
[    9.219560] PHYS_OFFSET: 0x80000000
[    9.219561] CPU features: 0x28240022,20806008
[    9.219562] Memory Limit: none

Time for an update. I got it to finally boot into a terminal with some changes:

  • For some reason I couldnā€™t get bitbake to accept the 5.10.153 version of beaglebone-linux hosted on github (same fetch issues fromm before). So I had to clone it locally myself and point bitbake to it with the following amendment to the /meta-ti/meta-ti-bsp/recipes-kernel/linux/linux-bb.org_git.bb recipe. The SRC_URI field is where I made my changes to point to the local directory the linux-bb kernel resides.
  • Note that the proper way to make this change is by creating a linux-bb.org_git.bbappend file and overriding SRC_URI with the local path to the kernel. NOT by changing the original .bb file
SECTION = "kernel"
SUMMARY = "BeagleBoard.org Linux kernel"
LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"

COMPATIBLE_MACHINE = "beagle.*"

inherit kernel

require recipes-kernel/linux/ti-kernel.inc

DEPENDS += "gmp-native libmpc-native"

KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT} ${EXTRA_DTC_ARGS}"

S = "${WORKDIR}/git"

# 5.10.145 version
SRCREV = "9b11aaf2cdb1861ca74dc69d032a0f94cdd32bd6"
PV = "5.10.145+git${SRCPV}"
BRANCH = "5.10"

# 5.10.153 version
SRCREV:k3 = "11ebcc09f32669fac8254dff56d500f86c4c2caf"
PV:k3 = "5.10.153+git${SRCPV}"
BRANCH:k3 = "5.10-arm64"


SRC_URI = "git:///yocto/linux;protocol=file;nobranch=1"


DEFCONFIG_NAME = "bb.org_defconfig"
KERNEL_CONFIG_COMMAND = "oe_runmake -C ${S} O=${B} ${DEFCONFIG_NAME}"

kernel_do_compile:append() {
	oe_runmake dtbs CC="${KERNEL_CC} $cc_extra " LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}
}

I never cared for TI arago approach, too bloated. When we did the 7 inches and 12 inches displays for the Yamaha boats we used a DRA726 which was a cheaper part of the DRA74x parts. I first customized arago and had so many issues that for the next project I switched to poky and brought in recipes from arago that I wanted to use. I got a much better working environment.
This is a similar approach that Automotive Grade Linux uses.

I plan to do something similar with the Beaglebone ai-64
If there are any interest I can share my recipes when I have that work done.

Michel

4 Likes

Hey, very cool work! Any further progress?

1 Like

Hey thanks! Iā€™ve been planning to make a stripped down version of the arago distro but havenā€™t gotten around to it just yet. Also, what gets stripped can be quite dependent on the project. Thereā€™s just so much "stuffā€™ in it to weed through lol.

I have completed one beagleplay-kirkstone as a test case. It compiled without issues.
I have the yocto source almost completed for the AI-64.

My sonā€™s wedding an family visiting from QuĆ©bec will keep me busy on other things for the next couple of weeks.
It should be completed in the second week of July.

Hi
I was trying to build the tisdk-default-image for BBAI-64 too and managed to boot one when using older commits of meta-ti with 5.10.153 kernel version. However, it looks like there are some problems with the bootloader. When booting from mmc1 (external SD card), the bootloader canā€™t find the root partition and just hangs. So I am flashing the image into the internal mmc0, but still, it looks like the system does not work with peripherals well. Like, it does not detect a display in the DisplayPort, SD card or any device connected to USB (dmesg is completely silent when connecting/disconnecting something too).

Did it behave the same way for you? And does anyone have ideas why this is happening?

Checkout kirkstone for poky and all the meta layers.

also source the build and post this:

$bitbake-layers show-layers

I am actually at the same point when booting from the external SD card, up to date meta-ti, all layers in kirkstoneā€¦ plus some extra issues with the bootloader. I have not gone the arago way though.

What image are you building and what machine are you using.
Its been a few months ago, I do recall that core-image-base and core-image-weston will boot.

Iā€™m building core-image-minimal for the bbai64. On another related thread RobertCNelson contacted me and the problem seems to be related to the bootloder (currently u-boot-ti-staging), which is currently WIP.

A few months ago the bootloader was u-boot-bb if I remember correctly.

Oh itā€™s lots of fun. :wink: Commits Ā· v2023.04-ti-09.00.00.007 Ā· BeagleBoard.org / u-boot Ā· GitLab

Iā€™ve got 3 boards iā€™m trying to get working on u-boot-ti-staging

Had the Play working pretty good, started working on the BBAI64, then noticed something wrong on my AM69-SK. :wink:

Regards,

I built core-image-weston for the bbai64 but didnā€™t get any life on my monitor - what am I missing? Also tried core-image-sato, no joy. All works ok with default debian image

Not sure what is going on with the TI stuff. It did work a while back, they have massive confusion going on. We went with another vendor so I doubt that we will spend any time trying to puzzle out what has gone wrong.

If you donā€™t need a yocto build the RCN debian console image is very stable, we are running that on a production server and the ai64 with NVMe runs along side the big box dells without any problems.

You can run weston using that image, if memory is correct all you need is to build the ini file. And kill lightdm service.

$ sudo apt-cache search weston

That will show what is available with apt.

1 Like