Re: Device trees and armv5

["Jonathan A. Kollasch" <jakllsch%kollasch.net@localhost>]

On Thu, Sep 04, 2025 at 07:25:30AM -0700, Jason Thorpe wrote:
> 
> > On Sep 4, 2025, at 5:41 AM, Jonathan A. Kollasch <jakllsch%kollasch.net@localhost> wrote:
> > 
> > No technical reason; we just haven't hand any ARMv5 SoCs added since we
> > started using device trees.
> 
> Indeed, I’ve been interested in converting existing legacy evbarm to device trees, as well (I sure wish I still had the boards, sigh).  So, I 100% support the idea of using the device tree mechanism for this.
> 
> >> Also, what is the preferred way to add support for a new system: Fixing device trees so GENERIC also works with armv5, 
> >> or adding a new set of kernel configuration files specific to the EV3 to arch/evbarm/conf?
> >> 
> > 
> > Ideally it should be part of GENERIC.
> 
> While I agree, I think it comes with a caveat — I am not 100% certain that you’ll be able to boot a built-for-armv6 GENERIC on an armv5 system.  Maybe it’ll be OK if the early bootstrap code can diverge early enough to avoid armv6-isms.  But you’ll also want to double-check that GCC doesn’t emit code for the armv6 configuration that won’t run on armv5.
> 
> (Sorry for being vague about this… it’s been an awfully long time since I thought about any of this.)

Well, yes.  The general idea is that when you build evbarm for a ARMv5
MACHINE_CPU that there's a GENERIC kernel (perhaps not the same GENERIC
as ARMv6 and ARMv7 use as it might be difficult to share kernel start
code).  It might also make sense to have a GENERIC_V5 just because a lot
of drivers for newer SoCs won't be relevant, and ARMv5 machines
generally have limited RAM.

Marvell Orion and Kirkwood are also potential SoCs to support via FDT
ARMv5.  (Although we already support those with machine-specific
kernels.)