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?
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
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:
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.
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.
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.
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
$weston-flower
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)
[core]
gbm-format=argb8888
idle-time=0
#use-g2d=1
xwayland=true
repaint-window=16
#enable-overlay-view=1
[shell]
cursor-theme=Adwaita
cursor-size=22
size=1920x1080
#[output]
#name=HDMI-A-1
#mode=1920x1080@60
#transform=90
#[output]
#name=HDMI-A-2
#mode=off
# WIDTHxHEIGHT Resolution size width and height in pixels
# off Disables the output
# preferred Uses the preferred mode
# current Uses the current crt controller mode
#transform=90
[screen-share]
command=/usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize
[launcher]
icon=/usr/share/icons/Adwaita/24x24/legacy/utilities-terminal.png
path=/usr/bin/weston-terminal
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/insmod.sh. 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.
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/vs-drm_dri.so: 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
├───Connectors
│ └───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.
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/vs-drm_dri.so” 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.
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.
You mean backend=drm-backend.so. 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:
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.
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 systemd-notify.so.
[Unit]
Description=Weston, a Wayland compositor, as a system service
Documentation=man:weston(1) man:weston.ini(5)
Documentation=http://wayland.freedesktop.org/
# Make sure we are started after logins are permitted.
Requires=systemd-user-sessions.service
After=systemd-user-sessions.service
# If Plymouth is used, we want to start when it is on its way out.
After=plymouth-quit-wait.service
# D-Bus is necessary for contacting logind. Logind is required.
Wants=dbus.socket
After=dbus.socket
# Ensure the socket is present
Requires=weston.socket
# Since we are part of the graphical session, make sure we are started before
# it is complete.
Before=graphical.target
# Prevent starting on systems without virtual consoles, Weston requires one
# for now.
ConditionPathExists=/dev/tty0
[Service]
# Requires systemd-notify.so Weston plugin.
Type=notify
EnvironmentFile=/etc/default/weston
ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so
# Optional watchdog setup
#TimeoutStartSec=60
#WatchdogSec=40
# The user to run Weston as.
User=root
Group=root
# Make sure the working directory is the users home directory
WorkingDirectory=/home/weston
# Set up a full user session for the user, required by Weston.
PAMName=weston-autologin
# A virtual terminal is needed.
TTYPath=/dev/tty7
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
# Fail to start if not controlling the tty.
StandardInput=tty-fail
StandardOutput=journal
StandardError=journal
# Log this user with utmp, letting it show up with commands 'w' and 'who'.
UtmpIdentifier=tty7
UtmpMode=user
[Install]
# Note: If you only want weston to start on-demand, remove this line with a
# service drop file
WantedBy=graphical.target
