On 04/09/2025 17:12, Yuri Honegger wrote:
Am 04.09.2025 um 17:15 schrieb 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.
yes, please.Using FDT definitely doesn't mean it has be via GENERIC. See RPI for example.
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.
The last time I looked at this I seem to remember coming to the conclusion that there should be a GENERIC_V[456] (the existing GENERIC is really for armv7)
I’m not too familiar with the NetBSD kernel, but my current attempts at doing this suggest a GENERIC_V5 might be easier. I’m not sure if it is supposed to behave like that, but when changing CPU_CORTEX to CPU_ARM9E in GENERIC, I still have CPU_ARMV7 and CPU_ARMV5TE defined at the same time. I’m not sure if that should be. Regardless, I’d assume a kernel that supports both will need to have both enabled. Still, it leads to quite some issues. For one, the MMU code more or less expects only one of these variants to be present at the time. It also caused issues where it tried to pull in armv7 aes code that can’t build on armv5.
Right, the start code and pmap and bus_dma and probably more are compile time CPU architecture specific.
Nick