BeagleV-Ahead - Toolchain on Yocto?

I’m running the Yocto image on my BeagleV-Ahead. I’m looking at a nice clean, responsive Weston screen (so different from the one in the Ubuntu image) and imagining all the adventures I could have in this environment – if only I could compile C and C++ code!

So I followed the Yocto build instructions (ignoring the stuff about /mnt/yocto-cache, who has that?) and after some tribulations (eg. adding INHERIT = "rm_work" so it doesn’t eat my entire hard disk), I… still can’t build a new image. Several of the packages don’t build. But it did build a whole lot of .deb’s. After installing enough of those on by BeagleV-Ahead, I can now run gcc. But I still can’t build programs – it fails at the link step because it can’t find libgcc. And I can’t find any of those .deb’s that would supply it – there’s libgcc_s (which was already in the Yocto image), but not libgcc.

Has anyone got a toolchain going in the Yocto image, or have any hints about how to do that?

1 Like

The version of yocto we got was really hacked together, use docker or a vm with the matching distros…

feel free to take this runner example and docker… .gitlab-ci.yml · Linux_SDK_V1.1.2-light-beagle · BeagleV-Ahead / xuantie-yocto · GitLab

Ps, here is the docker file i hacked together for the builds:

ARG FRM='debian:bullseye-slim'
ARG TAG='latest'


ENV DEBIAN_FRONTEND noninteractive

RUN apt update && apt -y upgrade

# Required Packages for the Host Development System
RUN apt install -y gawk wget git-core diffstat unzip texinfo gcc-multilib \
        build-essential chrpath socat cpio python3 python3-pip python3-pexpect python-is-python3 \
        xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
        pylint3 xterm

# Additional host packages required by poky/scripts/wic
RUN apt install -y curl dosfstools mtools parted syslinux tree zip

# Additional host packages required by ssh-agent
RUN apt install -y openssh-client git rsync

# Additional host packages required by our fork
RUN apt install -y lz4 zstd bison flex autoconf cmake software-properties-common 

# More missing
RUN apt install -y file

RUN apt-add-repository contrib

RUN apt update && apt install -y repo

# Create a non-root user that will perform the actual build
RUN id build 2>/dev/null || useradd --uid 30000 --create-home build
RUN apt install -y sudo
RUN echo "build ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers

# Fix error "Please use a locale setting which supports utf-8."
# See
RUN apt install -y locales
RUN sed -i -e 's/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen && \
        echo 'LANG="en_US.UTF-8"'>/etc/default/locale && \
        dpkg-reconfigure --frontend=noninteractive locales && \
        update-locale LANG=en_US.UTF-8


USER build
WORKDIR /home/build
CMD "/bin/bash"



FYI, I had the same problem with the yocto build.
here’s the link for the issues I had,
compile C code on BeagleV
my BVA has been on the back burner for a few months, may need to look at RCN’s comments

$gcc --version

If that is does not show the version post your local.conf
What is your machine=

$bitbake-layers show-layers

Thanks for the suggestions, everyone.

My errors from GCC are just like the ones amf99 posted – I guess I should’ve looked back farther in the forum. gcc --version gives gcc (GCC) 12.2.0. Here’s my bitbake-layers show-layers:

layer                 path                                      priority
meta                  /home/steve/xuantie-yocto/openembedded-core/meta  5
meta-oe               /home/steve/xuantie-yocto/meta-openembedded/meta-oe  5
meta-python           /home/steve/xuantie-yocto/meta-openembedded/meta-python  5
meta-multimedia       /home/steve/xuantie-yocto/meta-openembedded/meta-multimedia  5
meta-networking       /home/steve/xuantie-yocto/meta-openembedded/meta-networking  5
meta-external-toolchain  /home/steve/xuantie-yocto/meta-external-toolchain  1
meta-riscv            /home/steve/xuantie-yocto/meta-riscv      6
meta-thead            /home/steve/xuantie-yocto/meta-thead      6
meta-light            /home/steve/xuantie-yocto/meta-light      6
meta-gnome            /home/steve/xuantie-yocto/meta-openembedded/meta-gnome  5
meta-filesystems      /home/steve/xuantie-yocto/meta-openembedded/meta-filesystems  5
meta-webserver        /home/steve/xuantie-yocto/meta-openembedded/meta-webserver  5
meta-qt5              /home/steve/xuantie-yocto/meta-openembedded/meta-qt5  7

And some relevant lines from my local.conf:

EXTRA_IMAGE_FEATURES ?= "debug-tweaks tools-sdk dev-pkgs"
EXTRA_IMAGE_FEATURES:append = " tools-sdk dev-pkgs"
EXTRA_IMAGE_FEATURES:remove = " dbg-pkgs staticdev-pkgs tools-debug"
IMAGE_FEATURES:remove = " dbg-pkgs staticdev-pkgs tools-debug"

Perhaps you can tell that I don’t actually know Yocto, I was just hacking around… I was running it in an Ubuntu 23.10 VM. The built packages I installed were libmpfr6, libmpc3, cpp, gcc, gcc-symlinks, libc6-dev, gcc-dev, libgcc-s-dev. And I installed the built binutils for good measure, but it didn’t make any difference compared to the one already in the image.

I’m hoping to give that Docker image a try tomorrow.

Thanks again!

gcc automatically links to the proper files. Might be missing a flag for RSICV or that version is just too new for RV. Have you tried using an older version, must be a version that works or that board would not be up.

Also, dev-pkgs will bring in the -dev files if they are available so typically you would not have to use a line item to add -dev.

when i compile with the gcc from xuantie-ubuntu build, no flags were required. going from memory, i thing gcc version was like 14 something from xuantie-ubuntu build.

That might be the issue, 14 might have the proper files for that RV. On a simple test program it should work out of the box without any -l, I did look at GCC docs and they have some flags for some RV stuff. Only looked at 12 and they had specific mentions of the other RiscV not the aliexpress version.

yocto build
cat /proc/version
Linux version 5.10.113-yocto-standard (oe-user@oe-host) (riscv64-linux-gcc (Xuantie-900 linux-5.10.4 glibc gcc Toolchain V2.2.8 B-20221201) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP PREEMPT Fri Jul 28 20:31:29 UTC 2023

ubuntu build
cat /proc/version
Linux version 5.10.113-20231002+ (amf@debian) (riscv64-linux-gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.41) #1 SMP PREEMPT Mon Oct 2 12:07:06 CDT 2023

from my notes:


riscv64-linux-gcc (GCC) 13.2.0
GNU ld (GNU Binutils) 2.41

does not work

riscv64-linux-gcc 10.2.0
GNU ld (GNU Binutils) 2.35

1 Like

I’ve finally had a chance to play with this some more, so here’s a little update.

First, thanks to RobertCNelson for that Dockerfile, it worked great. It was able to build all the way to the final image (although I didn’t try flashing it). However, the GCC .deb that it made had the same problem.

I had the idea of trying to get the .debs for GCC from the Ubuntu build, and seeing if I could install them in Yocto. Getting the .debs was as easy as apt download <package-name>, with dpkg -I <deb-file> to see the dependencies. But Yocto didn’t like them – it looks like the Ubuntu .debs use zstd compression, which Yocto’s dpkg doesn’t support.

But I discovered a few things while I was booted into Ubuntu…

I should point out that part of the reason I didn’t want to use the XFCE in Ubuntu was that mine had become unusably slow after a while. I think that phenomenon has been mentioned elsewhere on this forum. After some experimentation, I found that I could get into that state by simply booting after a fresh flash of Ubuntu, logging out of XFCE, and logging back in again. Then it’s bad forever.

It turns out Ubuntu actually has Weston installed. Lightdm will even let you try to select it, but it doesn’t work. That’s not so surprising, given that lightdm is X11-only. I tried installing GDM3, but that just showed a pretty but serious-looking error screen.

i3 works great in Ubuntu.

I’d had the foresight to grab “weston@.service” from Yocto, but so far I haven’t been able to get Weston to run on Ubuntu. “weston-launch” is missing for some reason. I may need to flash Yocto again to see what other pieces I might be missing.

So for now my plan is to keep using i3 on Ubuntu (where GCC works just fine), and to keep trying to get Weston working there.

1 Like
$ env | grep DISPLAY

You need to have your weston.ini configured properly.
Also need to set environment variable DISPLAY_WAYLAND = /run/user=0
With x DISPLAY=:0 I just set both and don’t have to mess with it later on.

I don’t have the V board so this might not be of any value.

On your desktop install

$sudo apt install weston

after install


Point with this is when it works you now have a working example to reference when you set up your board.

To find your weston.ini

$cd /
/$ find -name weston.ini

Here is a .ini (this is not for a BB)




#	WIDTHxHEIGHT    Resolution size width and height in pixels
#	off             Disables the output
#	preferred       Uses the preferred mode
#	current         Uses the current crt controller mode

command=/usr/bin/weston --no-clients-resize


Thanks, that gbm-format line may well be what I need, given this:

Mar 19 22:42:45 BeagleV weston[2854]: [22:42:45.814] format 0x34325258 not supported by output HDMI-A-1
Mar 19 22:42:45 BeagleV weston[2854]: [22:42:45.814] failed to create gbm surface
Mar 19 22:42:45 BeagleV weston[2854]: [22:42:45.814] Failed to init output gl state
Mar 19 22:42:45 BeagleV weston[2854]: [22:42:45.814] Enabling output "HDMI-A-1" failed.
Mar 19 22:42:45 BeagleV weston[2854]: [22:42:45.815] Error: cannot enable output 'HDMI-A-1' without heads.

Unfortunately, I have to be away from my BeagleV-Ahead for a few days, so I won’t be able to try that right away.

Here are some of my discoveries since the last time I posted:

  • Empirically, Weston doesn’t seem to work without hardware graphics support.
  • Sway works fine, using a software renderer. It needs “WLR_NO_HARDWARE_CURSORS=1” in the environment.
  • The Ubuntu build doesn’t support the graphics hardware. And it doesn’t intend to, unless and until the drivers are mainlined.
  • RevyOS doesn’t seem to support the GPU either, at least I haven’t seen it do that. The pvrsrvkm.service shows as “failed”, even after I corrected the path in /usr/share/gpu/ But the pvrsrvkm module is already loaded, which seems to be the cause of the “failure”.
  • TCC works great! I built it from Git – the available tarballs are old and they don’t include RISC-V support. I haven’t tried copying the binary to Yocto to see if it works there.

How are you launching it ? and the .ini file?

Usually using the weston@.service from the Yocto build.

Sometimes just this:



But I probably tried different things. At the very least, I know I’ve tried “xrgb8888”.

The most relevant log line seems to be:

Mar 24 20:16:07 BeagleV weston[2537]: MESA-LOADER: failed to open vs-drm: /usr/lib/dri/ cannot open shared object file: No such file or directory (search paths /usr/lib/riscv64-linux-gnu/dri:\$${ORIGIN}/dri:/us/lib/dri, suffix _dri)

…but it doesn’t actually fail until a little later:

Mar 24 20:16:08 BeagleV weston[2537]: [20:16:08.333] Output 'HDMI-A-1' using color profile: built-in default sRGB SDR profile
Mar 24 20:16:08 BeagleV weston[2537]: [20:16:08.333] format 0x34325241 not supported by output HDMI-A-1
Mar 24 20:16:08 BeagleV weston[2537]: [20:16:08.333] failed to create gbm surface
Mar 24 20:16:08 BeagleV weston[2537]: [20:16:08.333] Failed to init output gl state
Mar 24 20:16:08 BeagleV weston[2537]: [20:16:08.334] Enabling output "HDMI-A-1" failed.
Mar 24 20:16:08 BeagleV weston[2537]: [20:16:08.334] Error: cannot enable output 'HDMI-A-1' without heads.

Some relevant bits from “drm_info”:

drmModeGetResources: Operation not supported
Failed to retrieve information from /dev/dri/card1
Node: /dev/dri/card2
├───Driver: pvr (Imagination Technologies PVR DRM) version 1.16.6099580 (20170530)
├───Device: platform img,gpu
│   └───Available nodes: primary, render
Node: /dev/dri/card0
├───Driver: vs-drm (VeriSilicon DRM driver) version 1.0.0 (20191101)
├───Device: platform verisilicon,display-subsystem
│   └───Available nodes: primary
│   └───Connector 0
│       ├───Object ID: 116
│       ├───Type: HDMI-A

That’s the same on both Ubuntu and RevyOS. Unfortunately, Yocto doesn’t have drm_info, so I can’t see what it should look like. I have to wonder what VeriSilicon has to do with this chip, and why the HDMI is hooked to that instead of the PVR device.

under core try and add this line


And try to comment out gbm

Not sure what the format 0x34325241 not supported references.


first get the session and seat

$loginctl show-session <session ID> -p Type

This will expose what is being used, x or wayland.

It looks like I may not have actually tried Weston using weston@.service on RevyOS. Interestingly, that doesn’t have the “failed to open vs-drm: /usr/lib/dri/” line. But it’s the same otherwise:

Apr 02 11:44:30 ahead weston[1300]: [11:44:30.783] using /dev/dri/card0
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.161] DRM: head 'HDMI-A-1' updated, connector 116 is connected, EDID make 'HWP', model 'HP 22cwa', serial '6CM6031XZ0'
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.162] DRM: head 'HDMI-A-1' found, connector 116 is connected, EDID make 'HWP', model 'HP 22cwa', serial '6CM6031XZ0'
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.164] Registered plugin API 'weston_drm_output_api_v1' of size 24
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.164] Registered plugin API 'weston_drm_virtual_output_api_v1' of size 48
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.164] Color manager: no-op
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.165] Output 'HDMI-A-1' using color profile: built-in default sRGB SDR profile
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.165] format 0x34325258 not supported by output HDMI-A-1
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.165] failed to create gbm surface
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.166] Failed to init output gl state
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.166] Enabling output "HDMI-A-1" failed.
Apr 02 11:44:31 ahead weston[1300]: [11:44:31.166] Error: cannot enable output 'HDMI-A-1' without heads.

Note that card0 is the VeriSilicon, and card2 is the PVR.

I tried following (minus the boot prompt bit, I’m using 1920x1080), but it didn’t help.

I’ve also tried BGRA8888 and BGRX8888.

Well, that’s the crux of the problem, I think.

0x34325258 == ‘42RX’ == DRM_FORMAT_XRGB8888
0x34325241 == ‘42RA’ == DRM_FORMAT_ARGB8888

That took a bit of Googling to find. It ultimately comes from “linux/include/uapi/drm/drm_fourcc.h”.

As expected, this shows “tty” when in a VT and “wayland” when in Sway.

As expected, adding “xwayland=true” didn’t make a difference – Weston doesn’t make it far enough for that to matter.

Might have to check all the rules and systemd start up and see where that format number is coming from. If stuff is commented out or not listed in weston.ini it must be way upstream.

Looks like you are very close to getting it running.

Maybe try forcing it in


Found these formats:

You mean But it was already using that backend automatically (I didn’t show that part of the log). It’s still using the GL renderer as before:

Apr 02 11:44:30 ahead weston[1300]: [11:44:30.783] Loading module '/usr/li/riscv64-linux-gnu/libweston-10/'

I wish I shared your optimism. Even in XFCE, I haven’t seen much evidence of GPU support – the glx* programs all crash, and glmark-es2 uses software rendering. (XFCE itself is decently responsive, however, unlike in the Ubuntu image; dunno if that’s due to the GPU or something else.)

Like I said, those all come from that file in the Linux kernel sources.

Here is a working weston.service

It might have a few clues, if not, the issue might be much deeper.

:/lib# cat ./systemd/system/weston.service
# This is a system unit for launching Weston with auto-login as the
# user configured here.
# Weston must be built with systemd support, and your weston.ini must load
# the plugin
Description=Weston, a Wayland compositor, as a system service
Documentation=man:weston(1) man:weston.ini(5)

# Make sure we are started after logins are permitted.

# If Plymouth is used, we want to start when it is on its way out.

# D-Bus is necessary for contacting logind. Logind is required.

# Ensure the socket is present

# Since we are part of the graphical session, make sure we are started before
# it is complete.

# Prevent starting on systems without virtual consoles, Weston requires one
# for now.

# Requires Weston plugin.
ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log

# Optional watchdog setup

# The user to run Weston as.

# Make sure the working directory is the users home directory

# Set up a full user session for the user, required by Weston.

# A virtual terminal is needed.

# Fail to start if not controlling the tty.

# Log this user with utmp, letting it show up with commands 'w' and 'who'.

# Note: If you only want weston to start on-demand, remove this line with a
# service drop file