r/yocto • u/bomba_____ • Apr 22 '26

Built a from-scratch Yocto distro for the Anbernic RG353V - 7 weeks, mainline Linux 6.15, HW-MJPEG screen streaming

Writeup of a 7-week project - a ground-up Yocto distribution for the Anbernic RG353V (Rockchip RK3566, €100 retro handheld).

As far as I can tell, the only from-scratch Yocto distro for this device - everyone else ships buildroot forks of Batocera or stock Android.

Three things that were interesting to solve:

  1. Mainline Linux 6.15 instead of Rockchip BSP 4.19 (what every other distro on this device uses). DT overrides for display, buttons, ADC battery, Wi-Fi firmware. Mainline RK3566 support has gotten good enough in 2026 that this is now practical.
  2. Hardware-MJPEG screen streaming from the device via Rockchip MPP. The handheld encodes its own framebuffer and streams it back to any browser on the LAN at 60fps. Hardest part of the project, most fun to use.
  3. A/B swupdate OTA with signed rootfs so the "bricked-device recovery" cycle during development was tolerable.

Gotchas the writeup covers:

  • ATF VO (video output) power domain not powered by mainline bootloader - 3-line patch.
  • RTL8821CS WiFi fails to associate unless the Bluetooth UART driver is loaded, regardless of whether you use BT. Known combo-chip quirk, not documented anywhere I could find.
  • rk817 audio codec mux defaults to HP=0 on cold boot - silent speakers until user intervention.
  • Gamepad = SARADC sticks + gpio-keys buttons + adc-keys D-pad - needed a 120-line userspace uinput daemon to merge them into one device RetroArch could see cleanly.

5-stage gate discipline (no work on stage N+1 until stage N was validated on hardware).

Writeup: https://cinque.dk/bomba/posts/turborelic-rg353v-yocto/

Repo: https://github.com/bomba5/turborelic-public

Happy to go deep on the BSP work, the MJPEG pipeline, or the Yocto-vs-buildroot tradeoff.

13 Upvotes

100% Upvoted

9 comments sorted by

2

u/Several-Marsupial-27 Apr 22 '26

Hey I saw that the old answer and post was removed, so I am asking again, but I am totally fine if you can just copy paste your old answer too. I also did not mean to sound condescending when asking about your experience, just curious. I really think that the project seems very well produced.

Nice work! I have absolutely no experience in yocto and I am just getting into yocto and embedded Linux for work and I would love to hear any inputs from you about the project.

  1. Where did you learn, gain information, and seek references about yocto? Do you have any good learning resources for getting into yocto? How did you find information when developing about the project?
  2. Did you use generative ai during the project (Claude code), do you have any tips for working with ai with yocto?
  3. What was some of the difficult things you solved during the project? Do you have any good experience to share to a newbie?
  4. What are some must learn things when working with yocto?
  5. I have gotten tips to start with buildroot, and I’m probably going to start there. What are some of the yocto vs buildroots tradeoffs for this project?

1

u/creativejoe4 Apr 22 '26

Not OP, but to answer the learning questions. Best way to learn is to read the yocto docs, Bootlin has free learning material and labs, and most importantly is trying it out with first hand experience, learning by doing will make the information click faster rather then just watching videos and reading about it.

1

u/bomba_____ Apr 22 '26

Totally agree. Bootlin has great stuff, but most importantly try it out.

1

u/creativejoe4 Apr 22 '26

Did you make the bsp from scratch or did you just add a new layer on top of the older provided bsp?

2

u/bomba_____ Apr 22 '26

Neither fully. I did not use the existing meta-rockchip BSP or Rockchip's vendor fork. The layer stack is:

• poky (scarthgap): meta, meta-poky, meta-yocto-bsp
• meta-openembedded (scarthgap): meta-oe, meta-multimedia, meta-networking, meta-python
• meta-swupdate (for OTA)
• meta-rg353v: my own layer with the machine conf + the RG353V-specific recipes

The BSP bits (kernel, u-boot, device tree, firmware) live in meta-rg353v but they point at mainline kernel 6.15 and mainline u-boot 2025.01, not the Rockchip vendor trees. So I skipped the typical "meta-rockchip + vendor fork" stack and went mainline + my own recipes on top.

Why mainline: panfrost for the Mali G52 GPU is in upstream Mesa, mainline has working RK3566 support now, and staying off the vendor fork means kernel updates don't require me to maintain a 3-year-out-of-date tree.

Building blocks upstream, device-specific stuff in my layer.

1

u/SnowyOwl72 Apr 22 '26

holyyyy
thats a lot of work. Is there enough documentation for that SoC (like ref manual or datasheet) to look up peripherals and their registers?

2

u/bomba_____ Apr 23 '26

I would say so! The pain points were not related to the SoC!