Re: Device trees and armv5

[Yuri Honegger <yuri.honegger%icloud.com@localhost>]

> Am 04.09.2025 um 17:13 schrieb Jason Thorpe <thorpej%me.com@localhost>:
> 
> 
>> On Sep 4, 2025, at 7:29 AM, Warner Losh <imp%bsdimp.com@localhost> wrote:
>> 
>> I'd think it would be that the loader would get heartburn from mixing armv5 and armv6/7 features into the same binary. We ran into that in FreeBSD, plus some early cache or MMU differences (I can't recall which now, but the early boot code looked at the MMU to find the PA we were loaded at, and cache flushing was always an issue at the loader / kernel handoff) that made it hard to have a unified kernel. But that was a very different world, with vastly less arm competence at the time for sorting the issues out.
> 
> All the ARMv5 boards I worked on back-in-the-day were systems with RedBoot.  All of the early boot code I wrote for these boards ensured the MMU was disabled and worked with physical addresses.  (Typical scenario to the best of my recollection: my “gzboot” boot loader was concatenated with a compressed kernel image and written into the NOR flash on the device, in a managed-by-RedBoot partition.  To boot the kernel, you jumped to the beginning of said NOR flash region, which uncompressed the kernel into RAM and jumped to it.  RedBoot had a simple scripting facility that automated this.)
> 
> If I were to do this with device trees today, the way it would play out is that gzboot, which had to be built for the specific board in any case, would contain a copy of the device tree blob.  It would decompress the kernel into RAM as before, then copy the DTB immediately after the kernel, and then load the kernel symbol table after the DTB.  This way, I could have a stable known location of the DTB (ALIGN(&_end)), and then use the DTB to find everything else (including stashing the start and size of the kernel symbol table in /chosen properties).
> 
> Of course, there might be an existing convention for passing the location of the DTB to the kernel for armv5, which should take precedence over any harebrained scheme I come up with :-)
At least the ev3 can use u-boot, so I guess the process doesn’t differ that much from more modern SOCs that get their device tree from u-boot.
> 
> -- thorpej
>