Framebuffer Operation Not Permitted Issue - 7.3.0+build18

Technical Support
, , ,
1

Hello,
We are trying to create a multi-container application using torizon-os and .NET. We have 3 parts to this application, and one of them is an Avalonia Framebuffer GUI container.
Up until recently we have had no issues with this set up, the framebuffer works perfectly through a HDMI cord. We use the iMX8MP and test on both the verdin dev board and a mallow board. Mallow boards for local testing and then the verdin board is running on an actual unit.
Recently the Verdin Dev Board device has stopped working with Avalonia framebuffer. The container crashes with code 133, and leaves this exception and stack trace in the logs:

[13:29:17 ERR] Framebuffer initialization failed: Operation is not supported on this platform.
[13:29:17 ERR] Stack trace: at Avalonia.Threading.Dispatcher.MainLoop(CancellationToken cancellationToken)
at Avalonia.Controls.DesktopApplicationExtensions.Run(Application app, CancellationToken token)
at LinuxFramebufferPlatformExtensions.StartLinuxDirect(AppBuilder builder, String args, IOutputBackend outputBackend, IInputBackend inputBackend)
at LinuxFramebufferPlatformExtensions.StartLinuxFbDev(AppBuilder builder, String args, String fbdev, Double scaling, IInputBackend inputBackend)
at smartui.Program.Main(String args) in /home/torizon/app/Program.cs:line 106
[13:29:17 ERR] Unhandled exception: System.PlatformNotSupportedException: Operation is not supported on this platform.
at Avalonia.Threading.Dispatcher.MainLoop(CancellationToken cancellationToken)
at Avalonia.Controls.DesktopApplicationExtensions.Run(Application app, CancellationToken token)
at LinuxFramebufferPlatformExtensions.StartLinuxDirect(AppBuilder builder, String args, IOutputBackend outputBackend, IInputBackend inputBackend)
at LinuxFramebufferPlatformExtensions.StartLinuxFbDev(AppBuilder builder, String args, String fbdev, Double scaling, IInputBackend inputBackend)
at smartui.Program.Main(String args) in /home/torizon/app/Program.cs:line 106
System.PlatformNotSupportedException: Operation is not supported on this platform.
at Avalonia.Threading.Dispatcher.MainLoop(CancellationToken cancellationToken)
at Avalonia.Controls.DesktopApplicationExtensions.Run(Application app, CancellationToken token)
at LinuxFramebufferPlatformExtensions.StartLinuxDirect(AppBuilder builder, String args, IOutputBackend outputBackend, IInputBackend inputBackend)
at LinuxFramebufferPlatformExtensions.StartLinuxFbDev(AppBuilder builder, String args, String fbdev, Double scaling, IInputBackend inputBackend)
at smartui.Program.Main(String args) in /home/torizon/app/Program.cs:line 106
[13:29:17 ERR] Stack Trace: at Avalonia.Threading.Dispatcher.MainLoop(CancellationToken cancellationToken)
at Avalonia.Controls.DesktopApplicationExtensions.Run(Application app, CancellationToken token)
at LinuxFramebufferPlatformExtensions.StartLinuxDirect(AppBuilder builder, String args, IOutputBackend outputBackend, IInputBackend inputBackend)
at LinuxFramebufferPlatformExtensions.StartLinuxFbDev(AppBuilder builder, String args, String fbdev, Double scaling, IInputBackend inputBackend)
at smartui.Program.Main(String args) in /home/torizon/app/Program.cs:line 106
Unhandled exception. System.PlatformNotSupportedException: Operation is not supported on this platform.
at Avalonia.Threading.Dispatcher.MainLoop(CancellationToken cancellationToken)
at Avalonia.Controls.DesktopApplicationExtensions.Run(Application app, CancellationToken token)
at LinuxFramebufferPlatformExtensions.StartLinuxDirect(AppBuilder builder, String args, IOutputBackend outputBackend, IInputBackend inputBackend)
at LinuxFramebufferPlatformExtensions.StartLinuxFbDev(AppBuilder builder, String args, String fbdev, Double scaling, IInputBackend inputBackend)
at smartui.Program.Main(String args) in /home/torizon/app/Program.cs:line 106

We have not had this error before, the UI was working perfectly fine. What caused the change is updating to a new version of our program via an Over the Air update through torizon cloud. The version we pushed was not correct so we pushed another new version and since then it started failing with this error.

Some important info:
The screen appears to be working, our splashscreen image included in Torizon Core Builder shows up properly on startup and shutdown.
The latest Torizon OS + Container bundle USB we have works on our mallow boards, it is only the verdin dev board that is failing. A fresh OS install from the same USB with 0 changes between works on the mallow but not the verdin board.
The error is “operation is not supported on this platform.” The fb0 file is present in the boards host file system as well as inside the docker container.

Steps we have taken to debug:
We installed a new fresh iMX8MP into the verdin dev board, and fresh installed our OS onto it. It still fails to work with framebuffer.
We tried using Avalonia DRM instead of FB and got it working on our test mallow boards. We pushed that working version to the broken verdin board and Avalonia still failed to initialize using DRM.
We tried rolling back the OS we installed on it to the version we had previously that was working, it also had the same framebuffer error.
We saw that the device tree used in our TCB project was:
imx8mp-verdin-wifi-mallow.dts
so we switched it to:
imx8mp-verdin-wifi-dev.dts
This didnt change anything, and it still works after this on the mallow and still is broken on the verdin.

At this point we can’t think of any other things we could look into to fix. We don’t believe its our code because it works on the mallows, and it used to work on the verdin. We don’t think its a hardware issue with the SOM because we replaced it. It seems it could only be a hardware issue with the board unless we are missing something.

Here is the tdx-info output:
Software summary

Bootloader: U-Boot

Kernel version: 6.6.94-7.3.0-g5a62539de8f9 #1-Torizon SMP PREEMPT Wed Jun 25 09:14:55 UTC 2025
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/d8c21aa760fd7985364658bad9cbc0c9a0d8ac56fbe068f0688ba6f42d512f1a/0 video=HDMI-A-1:1024x600
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.3.0-build.18
Distro variant: VARIANT=“Docker”
Hostname: smartcontroller-15677728

Hardware info

HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board

Toradex version: 0058 V1.1B
Serial number: 15677728
Processor arch: aarch64

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

.NET Avalonia Framebuffer Issue on Verdin iMX8M Plus

Based on your description, you’re experiencing a platform support error with .NET Avalonia framebuffer on the Verdin iMX8M Plus development board after an OTA update. Let me help you troubleshoot this issue.

Framework Context

According to Toradex documentation, .NET Avalonia is a supported GUI framework option (1). The documentation indicates that .NET Avalonia supports legacy framebuffer and X11 backends (1). However, there are some important considerations for GPU acceleration and platform compatibility (1).

Potential Root Causes

1. Hardware Acceleration Configuration

The documentation notes that for .NET Avalonia, “GPU-accelerated; however, many details and versions of libraries must be in sync for it to work on Linux” and “Currently, it is not possible to leverage GPU acceleration on Toradex hardware because X11 is not supported” (1).

2. Device Tree Configuration Issues

Since you mentioned switching device trees between imx8mp-verdin-wifi-mallow.dts and imx8mp-verdin-wifi-dev.dts, this could be related to hardware-specific configurations. Device trees describe the hardware components and their configurations (2), and mismatches between the actual hardware and device tree can cause platform support issues.

Troubleshooting Steps

1. Verify Container Permissions

Ensure your Avalonia container has proper access to framebuffer devices:

docker run --device=/dev/fb0 --privileged your-container

2. Check Framebuffer Device Status

Verify the framebuffer device is accessible:

ls -la /dev/fb*
cat /sys/class/graphics/fb0/modes

3. Device Tree Verification

Since you’re using TorizonCore Builder, ensure the correct device tree is applied. The documentation shows how to apply custom device trees (3):

torizoncore-builder dt apply custom-device-tree.dts

4. Consider Alternative Backend

Given the platform support issues with framebuffer, you might want to consider using X11 backend instead of framebuffer for .NET Avalonia, as mentioned in the framework comparison (1).

Hardware-Specific Considerations

The fact that this works on Mallow boards but not on the Verdin Development Board suggests a hardware-specific configuration issue. The Verdin Development Board may have different display routing or initialization requirements compared to Mallow boards.

Next Steps

  1. Verify device tree compatibility - Ensure you’re using the correct device tree for your specific hardware configuration
  2. Check container runtime configuration - Verify all necessary devices and permissions are properly mapped
  3. Consider switching to X11 backend - This might provide better compatibility for your use case
  4. Review OTA update changes - Check if any system-level changes were introduced during the OTA update that might affect framebuffer access

The issue appears to be related to platform-specific framebuffer access rather than your application code, especially since it works on different hardware configurations.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Another piece of information to note is that when we say we are installing an OS we are talking about a fresh install using Tezi, and Tezi does show up on the screen when we use it.

4

Hey @TWatson,

On the setup that is with the verdin development board, can you give the output from sudo tdx-info

If I understand you correctly, you had a software configuration that once worked with the verdin development board, but this is no longer true?

-Eric

5

I included it in the orignal post but here it is again:
Software summary

Bootloader: U-Boot

Kernel version: 6.6.94-7.3.0-g5a62539de8f9 #1-Torizon SMP PREEMPT Wed Jun 25 09:14:55 UTC 2025
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/d8c21aa760fd7985364658bad9cbc0c9a0d8ac56fbe068f0688ba6f42d512f1a/0 video=HDMI-A-1:1024x600
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.3.0-build.18
Distro variant: VARIANT=“Docker”
Hostname: smartcontroller-15677728

Hardware info

HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board

Toradex version: 0058 V1.1B
Serial number: 15677728
Processor arch: aarch64

Yes at one point it was working but after installing an update, rolling back the version, and many other steps it still isnt working. Both on the latest version of our program (which runs fine on our mallow boards) and the original version that was originally working.

6

Hey @TWatson,

It doesn’t quite make sense that the rollback OS wouldn’t work if it previously did. The rolledback state is a unique commit hash, so its the exact same software that was previously working, can you confirm via the unique hash OStree hash IDs are the same between the ‘working version’ and ‘non working version’.

Is it possible that you have mixed software packages between your verdin and mallow boards?

-Eric

7

@eric.tx Yes that is what we are thinking, it doesn’t make sense at all. The problem is the “working version” no longer works. We save all of our OS builds (the folder outputted by torizon core builder) locally on our computers. The software installed onto the mallow and the verdin was moved from the TCB output folder, loaded onto a USB and installed via Tezi to both boards, using the same USB. From my understanding there isnt a way to have a difference between the two if using the same USB. In the same fashion, when we “rolled back” we used the OS build that successfully installed and booted right up on the verdin board prior to our issue. This is 100% the same build we installed before and it no longer boots up. I can get the OStree hash IDs if necessary but I know for a fact that the OS build that worked previously, no longer works.

8

Hey @TWatson,

Any luck finding out what happened?

-Eric

9

Hi @eric.tx ,

We’ve held off on doing any more work here for now since the development board is not something that will make its way into production and we recently had sample hardware arrive. When the sample hardware is up and running on our equipment in place of the dev board we intend to try to dive a little deeper into it to make sure its not something we did wrong, but based on everything we can see there is nothing on our end that makes sense that would cause this. Its a very strange situation and we will circle back here if we end up making any headway.

Another piece of information that I don’t think has been mentioned is that we took the IMX8MP SOM out of the Verdin dev board, put it into a Mallow, without any changes, and it boots up just fine on the Mallow.