New Hardware: An RP2350 Drives 1080p, RISC-V Meets AMD ROCm, and Xen Runs on Real Silicon

Some of the most interesting recent hardware news is about what developers can make existing chips do.

An RP2350 microcontroller is producing a 1080p video signal without a full framebuffer. SiFive and AMD have demonstrated ROCm 10.0 on a RISC-V server paired with Radeon graphics. And Xen developers have booted a guest on physical RISC-V hardware after working in emulation.

These are software milestones with hardware implications. Together, they show how much a platform’s capabilities depend on the software around it.

The RP2350 inside the Raspberry Pi Pico 2 family is a capable microcontroller, yet few people would have listed 1080p video output among its likely tricks.

Developer Aaron Gayle has made it happen anyway.

Gayle’s TV-Top Kiosk firmware outputs 1920 × 1080 at approximately 30 Hz with 24-bit color from an RP2350. The project uses a Raspberry Pi Pico 2 W, with the chip generating a DVI video signal through an HDMI connector. TV-Top firmware repository

The obstacle is memory. An uncompressed 1920 × 1080 framebuffer at 24-bit color requires 6,220,800 bytes—about 6.22 MB, or 5.93 MiB. The RP2350 has just 520 KB of SRAM.

So the project skips the full framebuffer.

Rather than holding a complete image in memory, the firmware prepares scanlines shortly before they are transmitted.

It builds compact, run-length command streams from vector geometry cached in flash, working six lines ahead of the display output. The RP2350’s high-speed transmit peripheral, HSTX, handles the video serialization and encoding. Rendering and hardware details

The approach recalls older systems that generated video as the display scanned across the screen. It sidesteps the need to store millions of pixels at once, although scanline data still consumes memory.

The workload is heavy. The documented 1080p30 configuration runs at around 372 MHz with the core regulator set to 1.30 V. This is an experimental overclock, and the video link also exceeds HSTX’s rated throughput. The firmware supports other modes, including 720p60 and 640 × 480 at 60 Hz. Display compatibility, wiring, and cable quality matter. Video modes and overclocking notes

The video code belongs to TV-Top, a board-game platform where a television displays the board and players use their phones as controllers.

The project offers onboard Wi-Fi or an ESP32 that handles Wi-Fi, the IP stack, and TLS. The developer says the 1080p work was developed using the ESP32 configuration; the onboard Wi-Fi build with 1080p and TLS is documented as building successfully but not yet tested on hardware. Build configurations

The firmware is available under the MIT license, with bundled components retaining their own licenses. The TV-Top server and protocol specification are not open source. Project licensing

Nobody should expect a Pico 2 to stand in for a Raspberry Pi 5. This is a specialized renderer for board-game graphics, and its clock speeds are well outside normal operating conditions.

Still, that is part of the appeal. It demonstrates how much inexpensive microcontrollers can deliver when developers build around their limits.

AI is moving fast and most people are falling behind. 

The Rundown AI keeps you ahead of the curve. 

It's a free AI newsletter that keeps you up-to-date on the latest AI news, and teaches you how to apply it in just 5 minutes a day.

Plus, complete the quiz after signing up and they’ll recommend the best AI tools, guides, and courses — tailored to your needs.

Sign up to start learning.

RISC-V has come a long way in embedded systems, development boards, and increasingly capable Linux machines.

But a CPU is only part of a usable computing platform.

Modern systems rely on large software ecosystems, especially where GPUs and AI accelerators are involved. That makes a recent SiFive and AMD demonstration notable.

On September 15, the companies announced a demonstration of ROCm 10.0 on SiFive’s BigSky datacenter development platform. SiFive P870-D processors acted as the host, while AMD Radeon AI PRO R9700 GPUs handled inference for the Gemma4-E2B language model. SiFive’s announcement

This hardware is far beyond the RISC-V boards most enthusiasts know.

SiFive lists the BigSky SF-2U870 with 32 P870-D cores at 2.0 GHz, 256 GB of DDR5-5600 memory, four PCIe Gen5 x16 connections totaling 64 lanes, an additional PCIe Gen3 x4 connection, two 7.68 TB U.2 NVMe SSDs, and a 10/25 Gb OCP 3.0 network adapter. The platform targets software porting, workload tuning, and validation. BigSky specifications

Those PCIe connections provide room for accelerator hardware. Making useful applications run on it requires the software stack as well.

What matters here goes beyond a RISC-V processor communicating with a Radeon GPU over PCIe.

A usable platform needs drivers, libraries, tools, frameworks, and applications that developers can rely on. Each working workload is a step toward that broader ecosystem.

SiFive and AMD say they will continue evaluating and optimizing ROCm on RISC-V servers, including work toward larger models and additional acceleration use cases. They explicitly describe the system as a demonstration and the effort as an early step. It does not establish general production support for every ROCm feature on RISC-V. Collaboration details

That distinction matters. A successful demonstration shows that a particular combination can work. Turning it into a dependable platform requires repeatable builds, supported configurations, testing, documentation, and ongoing maintenance.

RISC-V already runs Linux. The harder challenge is making the surrounding software and accelerator ecosystem dependable enough for demanding workloads.

Another piece of that ecosystem has reached a milestone.

In a September 3 report, Vates engineers Baptiste Le Duc and Oleksii Kurochko described booting Xen and launching a guest domain on a SiFive HiFive Premier P550. Their test reached the expected guest message, “Hello RISC-V World!” Vates’ development report

The RISC-V port had previously been running under QEMU.

Emulation is invaluable when bringing up a new architecture. It lets developers test software before suitable hardware is widely available and makes debugging easier.

But an emulator and a physical processor do not always behave the same way. Running on a board exposes implementation details and missing features that software must handle.

The HiFive Premier P550 uses an ESWIN EIC7700X SoC with SiFive P550 cores.

According to the engineers, the chip implements a draft of the RISC-V Hypervisor extension predating ratification; its manual identifies Hypervisor-Level ISA v0.6. Xen targets the ratified extension, so the team had to accommodate missing control registers and extensions. The board also uses a PLIC interrupt controller. Hardware compatibility details

The work includes an automated board test that checks for the guest’s boot message. At the time of the report, the board-support patch series had not been submitted to the Xen mailing list because other prerequisite work needed to go upstream first. Testing and patch status

This is an early boot milestone, not evidence of a complete production virtualization platform.

Nevertheless, testing Xen on physical RISC-V hardware gives developers a firmer foundation for the next stage.

Virtualization may have little relevance to a microcontroller blinking LEDs. It becomes much more useful in systems that need to run isolated workloads side by side.

For servers and other consolidated systems, a hypervisor can provide the separation needed to run multiple operating environments on shared hardware.

A standardized architecture helps, but mature virtualization also requires software that handles the processors and platform components actually available.

Booting a guest on one board does not finish that job. It provides a concrete configuration that developers can test, debug, and improve.

That work is less visible than a new processor announcement, but it is essential to making a computing platform useful.