Linux 7.1 expands Arm, RISC-V, and MIPS support

Linux 7.1 adds embedded architecture updates for Arm, RISC-V, and MIPS boards.

This guide is for kernel developers, board support engineers, and embedded Linux users who want a practical readout of the Linux 7.1 release. After following the steps, you will know what changed in the release, where Arm, RISC-V, and MIPS gained support, and how to verify those changes on a target board or kernel tree.

It focuses on the release highlights that matter for hardware bring-up and downstream kernel work, with a special note on the new Microchip PIC64GX support on RISC-V using SiFive U54 CPU cores.

Before you start

• Linux kernel source access: a local checkout of the Linux 7.1 tree or the relevant release branch.
• Git 2.40+ for inspecting release commits and architecture changes.
• A build host running Linux, macOS, or WSL2 with 16 GB RAM or more.
• Cross-compilers for your target: aarch64-linux-gnu-gcc, riscv64-linux-gnu-gcc, and mips-linux-gnu-gcc.
• One test board or emulator for each architecture you care about, such as an Arm64 SBC, a RISC-V dev kit, or a MIPS target.
• Optional: LKML access and kernel docs for deeper release context.

Step 1: Review the release highlights

Goal: build a release-level map of what Linux 7.1 changed so you can decide what matters for your hardware and software stack.

Start with the major themes in the release: filesystem work around NTFS, security additions such as Landlock updates, high-resolution timer improvements, swap subsystem cleanup, and removal of obsolete 486 subarchitectures. For embedded work, the important part is that the release also carries broad architecture updates across Arm, RISC-V, and MIPS.

Verification: you should be able to summarize Linux 7.1 in one sentence and point to at least three areas that affect kernel maintenance or board support.

Step 2: Inspect Arm architecture updates

Goal: identify the Arm-side changes that could affect boot flow, device trees, power management, or interrupt handling on your boards.

Look for the Arm 9.6 LSUI feature, which helps the kernel access user-space memory without disabling privileged access never first, and note that futex operations use the new instructions. Also review the improved Memory Partitioning and Monitoring support, plus device-tree updates for Allwinner, Rockchip, Amlogic, Samsung, and Qualcomm platforms. The release also adds or fixes board definitions, clock drivers, PCIe tracepoints, and timer support for a wide range of SoCs.

Verification: you should see new Arm64 device-tree entries, clock-controller additions, and platform-specific fixes when you inspect the release shortlog or architecture patches.

Step 3: Check RISC-V board support

Goal: confirm the RISC-V changes that matter for embedded bring-up, especially new SoC enablement.

The standout item is support for the Microchip PIC64GX embedded RISC-V chip using SiFive U54 CPU cores. That means the kernel now includes the platform hooks needed to start bringing the chip up in a standard upstream flow. If you maintain a RISC-V board, this is the kind of change that usually touches device tree, interrupt routing, timer setup, and early console support.

git show --stat v7.1 -- arch/riscv

Verification: you should see RISC-V patch entries that mention PIC64GX, SiFive U54, or related platform enablement in the architecture diff.

Step 4: Audit MIPS and legacy cleanup

Goal: understand what changed for MIPS and what cleanup may affect older targets.

Linux 7.1 does not focus on flashy MIPS feature growth, but it does participate in the broader kernel cleanup trend by removing support for some old and unused 486 subarchitectures elsewhere in the tree and by continuing the general maintenance pattern across embedded architectures. For MIPS users, the practical task is to check whether your downstream tree depends on any removed legacy code paths or outdated board files.

Verification: you should be able to confirm whether your MIPS platform is still aligned with upstream expectations and whether any stale board support needs rebasing.

Step 5: Validate your target kernel tree

Goal: make sure the new release can be tracked, built, and tested against your hardware baseline.

Pull the release branch, configure the target architecture, and run a build for each platform you support. Then boot on real hardware or an emulator and compare dmesg output against the previous kernel. For Arm and RISC-V, pay attention to early boot messages, device-tree parsing, timer initialization, and any new driver probes. For MIPS, focus on regressions in legacy peripherals and board-specific initialization.

Verification: you should get a successful build and a boot log that reaches userspace without new architecture-related warnings or missing-device errors.

Common mistakes

• Assuming the release is only about generic kernel changes. Fix: scan the architecture sections first, because embedded board support often ships there.
• Testing only on one board. Fix: validate at least one target per architecture family you use, since Arm, RISC-V, and MIPS changes can affect different subsystems.
• Ignoring device-tree updates. Fix: rebase DTS files carefully, because many release issues come from clock, timer, or interrupt mismatches rather than core kernel code.

What’s next

Use the Linux 7.1 shortlog and architecture patch series to decide whether to forward-port board support, update device trees, or prepare regression tests for Arm, RISC-V, and MIPS targets.