Re: FDT for armv5

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

On 27/09/2025 21:13, Yuri Honegger wrote:
> Hello,
> Over the last few weeks, I've been working on adding device tree support for armv5 boards. It is now working well enough that I can boot into a ramdisk, so I'd like to talk about if NetBSD is interested in merging something like this.

Cool! and I'm happy to help get this into NetBSD.


> There are two parts to it:
> - the general changes required to boot an armv5 CPU using device trees. This adds a GENERIC_V5 configuration, the MMU initialization code and some ifdefs around platform-specific stuff.
> - device tree based drivers for the NXP i.MX23 SOC on the olinuxino board. I've used this board for development because it is an armv5 board already supported by NetBSD. For now, I've only converted the absolute minimum to boot NetBSD (interrupt and timer drivers).
>
> I do have a few questions:
>
> - Is it possible to change device trees under sys/external/gpl2/dts/... or will this cause issues the next time these files are synchronized with the linux kernel?

It's possible, but as you guessed it might cause problems with merging 
of upstream. Personally, I don't see a problem change 
sys/external/gpl2/dts/ for simple cases, but others (Hi Jared) prefer to 
have all updates in sys/arch/arm/dts/.

If you ever bring something in from upstream then I'd say apply them 
straight into sys/external/gpl2/dts/.


> - All files seem to contain a revision comment at the start. Is this something that has to be manually edited or is this done by CVS? What is expected from new contributions
> Same questions for __RCSID I see in some files.

I typically change these to "$NetBSD$" and let cvs do its thing when 
committing.

> - Most SOC-specific drivers are prefixed with the manufacturer/soc name, e.g. sunxitimer for the timer for sunxi SOCs. The existing imx23 code doesn't do this. Is it worth changing this for imx23 drivers? (e.g. icoll => imx23icoll or timrot => imx23timrot)
> If we change it, change all or just the ones where I've added device tree support?

yes, please do this as it avoids conflicts with other drivers (for other 
SoCs) when they're added to GENERIC*.

> - What is the preferred way to submit code? I've seen patches on mailing lists, but the website (https://www.netbsd.org/contrib/#submit-fixes) suggests opening a PR. Looking through PRs, they seem to be more bug-focussed than on new contributions.
> For reference, my changes are slightly more than 1000 lines.

Raise a bug with a URL to the patches (I don't think github will 
disappear anytime soon) or the patches?

> In the meantime, my code can be seen here: https://github.com/NetBSD/src/compare/trunk...recursivetree:netbsd-src:armv5-fdt-upstreamable

Would you mind fixing up so its all KNF (see 
https://nxr.netbsd.org/xref/src/share/misc/style). I'll send other 
comments separately.

> If someone wants to test it on the i-mx23-olinuxino-mini (There are some more steps required to get the ramdisk going,
> I'll skip them to keep it short. This "guide" will panic because I can't find the init process late in the boot process. If someone with the hardware wants them, I'm happy to type them out):
> 1. Build the u-boot bootloader using
> make mx23_olinuxino_defconfig
> make boot.sb
> 2. Format a microSD-card using a MBR with at least two partitions. The first partition must be of type 0x53, the second a FAT partition.
> 3. burn the u-boot boot.sb to the first partition (dd if=u-boot.sb of=/path/to/first/partition)
(I dont'> 4. Build the NetBSD kernel
> ./build.sh -u -U -m evbearmv5-el kernel=GENERIC_V5
> 5. Build the device trees
> ./build.sh -U -m evbearmv5-el dtb
> 6. Copy the device tree (src/sys/dtb/arm/obj/imx23-olinuxino.dtb) to the FAT partition
> 7. Copy the kernel uImage (src/sys/arch/evbarm/compile/obj/GENERIC_V5/netbsd.ub) to the FAT partition
> 8. Insert the SD card, apply power, and observe the debug UART header at 115200 baud

Fancy creating a pkgsrc package for u-boot?

Thanks
Nick