r/embeddedlinux

Hello,

I’m currently working on a Yocto + meta-xilinx workflow for Zynq UltraScale+ and I’m wondering if my workflow is completely wrong… or if everyone suffers the same way

My current workflow

1. Vivado

- make PL changes

- integrate Verilog into a custom IP

- add it to the Block Design

- validate BD

- run synthesis

- run implementation

-generate .xsa

2. Yocto / meta-xilinx

generate the SDT (`sdtgen`)

generate machine conf (`gen-machine-conf`)

run bitbake

flash SD card with dd

Total time: easily 30+ minutes for every small hardware change.

And very often I only discover stupid mistakes at runtime…

Example from today:

I forgot to reconnect an AXI slave.

No Vivado errors.

Yocto build succeeds.

Linux boots fine.

Then my app starts and obviously cannot find the AXI slave address...

So I have to redo everything just because of one missing AXI slave connection.

Questions :

How do you guys iterate faster with Yocto + meta-xilinx?

Some ideas I’ve been thinking about:

avoid rebuilding the full OS for every .xsa ? Is it possible ?

load only a new bitstream?

device tree overlays? I know that exists but don't know if it is usefull here

What the purpose of the fpga-manager ?

Thanks

Hey folks,

I'm working on the OS architecture for an ultra-remote, autonomous gateway device. Once it is deployed, physical access is no more possible and communication bandwidth is quite low.

We use Yocto to build our BSP. I'd love to get a sanity check from the community on our storage and filesystem architecture before we lock it in.

Here is the rundown of our approach:

1. Hardware & Boot Hierarchy We have an external hardware MCU that controls the boot pins to provide a 3-tier failsafe:

• Tier 1 (Golden Rescue): QSPI Flash. Strictly read-only monolithic image (bootloader, minimal kernel, initramfs). Only booted if block devices completely fail.
• Tier 2 (Primary Prod): eMMC.
• Tier 3 (Dev/Secondary Fallback): SD Card.

2. Partition Layout Both the eMMC and SD card use an identical 4-partition block layout:

1. BOOT (FAT32)
2. RootFS-A (EXT4)
3. RootFS-B (EXT4)
4. Data (EXT4 - persistent storage for logs/payload data)

3. Filesystem Permissions & State Management

• Production: RootFS-A and RootFS-B are strictly Read-Only by default. (The inactive RootFS slot and the BOOT partition only become temporarily writable during an OTA update).
• Development: To keep engineering velocity high, we tweak the kernel bootargs via the U-Boot console to mount the active RootFS as Read-Write for local testing and application/library deployment.
• Volatile Data: /var and /tmp are mounted to RAM (tmpfs) to save flash wear. Critical post-mortem crash logs are explicitly written to the Data partition before a watchdog reboot.
• Persistent State: We use OverlayFS for paths like /etc and /home. The upperdir lives on the Data partition of the currently active boot medium.

4. Mitigating A/B Update Configuration Drift Because we rely on Delta OTAs (due to the narrow bandwidth), we ran into the classic OverlayFS trap: if Slot B boots a newly updated app, it might read an outdated configuration schema left behind in the /etc overlay by Slot A.

• Our Fix: We enforce schema versioning in the directory structure itself. Apps read their configs from paths like /etc/myorg/app/v2.1.0/config.yaml. This allows old and new schemas to safely coexist in the persistent overlay.

My questions for the community:

1. Are there any hidden traps with the OverlayFS upperdir living on an ext4 partition that is susceptible to sudden power loss, assuming we mount it with aggressive fsck auto-repair flags?
2. Is bypassing the RO RootFS via U-Boot for development a common practice, or are we asking for Dev/Prod parity trouble down the line?
3. Does anyone see a glaring flaw in how we are handling the A/B configuration drift using versioned directory paths?

Appreciate any ruthless critiques or advice you can offer!

Developer provisioning plus JetPack installation is nowhere near reproducible.

It takes weeks to get to a stable JetPack environment, and the only path I’ve seen toward reproducibility is handing integrators a golden image and hoping nothing drifts. That’s extremely brittle in production and should scare the shit out of any OEM shipping at real volume.

Has anyone seen this work well in practice for Jetson deployments? Production-grade, multi-site, auditable across rebuilds. Not “it worked on my desk.”

We’re sinking crazy hours into solving this (leveraging EO4T/meta-tegra) and I want to make sure we’re not on a fool’s errand before we commit any harder.

Can someone suggest a best resource for kernel development for raspberry pi 5 to be used in yocto.

Hello,

I am wondering if anyone has any experience with tiling Wayland compositors (window managers) on embedded Linux systems with touchscreens, i.e. something like https://swaywm.org/.

I know that Wayland generally works on those, especially on devices like a Raspberry Pi 5. I've recently found a demo on YouTube showing Weston instead of Sway in the same scenario - https://www.youtube.com/watch?v=Cv1Ox3N9MIw. I've also heard that people were building custom compositors for embedded systems on top of wlroots, i.e. in https://fosdem.org/2026/schedule/event/BTMDHW-wayland-is-fun/.

Has anyone perhaps tried to use a tilling compositor on an embedded system with a touchscreen? Have you tried opening multiple different applications and managed to get touch (drag) based resizing and window repositioning work in a way that isn't clunky (unusable)?

I suppose that window positioning and resizing could also be handled by a purpose-built application in case that it'd be impossible to implement with things like gestures.

Any kind of input will be appreciated.

Thanks!

Hi everyone,

I am working on continuous UART communication between an STM32H563 and a Linux-based application processor such as RK3568, Raspberry Pi, or similar embedded processors.

Current setup:

• MCU: STM32H563
• Peer device: Linux-based processor (RK3568 / Raspberry Pi / similar)
• Communication: UART
• UART mode: Interrupt mode
• Hardware flow control: Disabled (RTS/CTS not used)

Issue:

During continuous high-frequency communication, I am frequently getting UART ORE (Overrun Error) on the STM32 side. Once ORE occurs, incoming data gets lost and communication becomes unstable.

I would like to understand the best industry approach for handling this kind of communication reliably without hardware flow control.

Questions:

1. What is the best workaround to avoid ORE errors without enabling RTS/CTS?
2. Is continuous UART communication considered reliable without hardware flow control in production systems?
3. What UART settings or software architecture are recommended for STM32H5 series?
4. Is DMA reception mandatory for stable high-throughput UART communication on STM32H563?
5. What is the proper ORE recovery sequence on STM32H563?
6. Are there recommended buffering or packet-handling strategies when communicating with Linux processors over UART?

Additional details:

• Using HAL UART interrupt APIs currently
• Bidirectional communication is frequent
• Packet sizes are variable
• Looking for a production-grade reliable solution

Would appreciate suggestions, best practices, or reference implementations from anyone who has handled STM32 ↔ Linux processor UART communication in real products.

Thank you.

Evaluating adding Qualcomm to the supported silicon list on our embedded Linux platform.

Currently shipping production on Jetson, imx, pi 4/5, and others.

Previous round of Qualcomm work was choppy. Rough areas were around:

- BSP source fragmentation (Linaro QCOMLT, Qualcomm direct, board vendors)

- Kernel and Yocto release alignment

- Blob and licensing handling

- General integration overhead

For reference, Jetson BSP refresh runs us 3-4 engineer-weeks at minimum.

Curious whether things have improved, especially on robotics-class parts (QRB5165, QCS6490, IQ-9, Dragonwing).

How much engineering overhead per BSP refresh are folks seeing today vs Jetson or i.MX? Worth supporting at production grade?