Re: FDT for armv5

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

> Am 28.09.2025 um 17:26 schrieb 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/.

Thank you for pointing out sys/arch/arm/dts. I’ve missed that directory when studying the DTB build process and is exactly what I've been searching for. I’ve moved the changes there.

> 
> 
>> - 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?

Sure
github link: https://github.com/NetBSD/src/compare/trunk...recursivetree:netbsd-src:armv5-fdt-upstreamable-v2
patch: https://github.com/NetBSD/src/compare/trunk...recursivetree:netbsd-src:armv5-fdt-upstreamable-v2.patch


> 
>> 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.

I’ve tried to change it to KNF as much as possible. If I missed something, I’m happy to fix it.

> 
>> 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?

I’m really not an expert on how pkgsrc works. It seems to be more about building user-space application for the host, while u-boot is closer to a kernel. You will be mostly cross-compiling. Also, you have to use a different configuration for basically every board, so you will never be able to just install it from a package manager. It might be possible, but I don’t quite see how. Building from source worked just fine for me.
My next plan was rather to port the lego mindstorms EV3 to NetBSD.

> 
> Thanks
> Nick