Message-ID: <4eb796cc-b178-8394-0149-03600f1caaed@linux-m68k.org>
Date: Mon, 6 Jan 2025 14:28:26 +1100 (AEDT)
From: Finn Thain <fthain@...ux-m68k.org>
To: Daniel Palmer <daniel@...f.com>
cc: geert@...ux-m68k.org, linux-m68k@...ts.linux-m68k.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] m68k goes DT


On Sun, 5 Jan 2025, Daniel Palmer wrote:

> 
> I have u-boot working on DragonBall (68000), my MVME147, QEMU Virt etc.
> So the u-boot could be made to work for almost anything as long as
> there is a serial port and a timer driver.
> On virt I take the bootinfo QEMU creates, turn that into a devicetree
> in u-boot and then pass the bootinfo and FDT into the kernel. :)
> 

I suppose the benefit of integrating FDT into bootinfo is that you can 
have a new bootloader that's backwards compatible with existing binaries.

I think the embedded FDT option brings a similar result for old 
bootloaders, but can't support a multi-platform vmlinux.

So I see some benefit to keeping bootinfo support and device tree support 
independent. A minimal kernel build is going to omit bootinfo support. In 
the long run, I'm not sure you'd want the FDT stored in a bootinfo record.

> 
> I think adding FDT support to some old crusty bootloader for the Amiga
> or something might be a lot of hassle.
> Like I'm not sure if I'd even be able to setup a system that could
> build it if it needs some old Amiga C compiler.
> That's why I think embedded FDTs might be needed in some places and
> leaving the bootinfo part as-is.
> 

Right. Bootloaders for old platforms are difficult code bases to 
contribute to. You need a lot of old hardware to test with, and a variety 
of operating system releases.

In the case of Penguin, you also need to know MacOS internals. In the case 
of EMILE, you need to deal with the early execution environment, which is 
not well documented AFAIK.

But these bootloaders have bugs, like any other program, and someone has 
to maintain them...

> 
> If you can write some code that loads the u-boot binary into memory
> and jumps to it, getting u-boot working on the mac shouldn't be too
> difficult.
> I might even have serial, ethernet, scsi drivers you can use. I'd
> rather port u-boot than fix up a bootloader unless the bootloader has
> some special hardware setup magic that can't be reproduced.
> 

Those hardware quirks are a given, I think, being that Penguin and EMILE 
need to support dozens of different Mac models. Porting u-boot is not a 
very attractive option.

> 
> The platform drivers should be easy to make work. I need to look at
> macfb.c but if it's anything like the DragonBall one it'll have 
> hardcoded addresses and stuff in there that need to be cleaned up but 
> it's not impossible.
> And if we do this the headers with the MMIO addresses can go away and
> a lot of junk can be removed from arch/m68k.
> 

At that point, bootinfo support can also be omitted. Maybe it's doable for 
a platform like MVME (?)

It seems that a multi-platform vmlinux binary would have to handle the 
case where some plaforms will use bootinfo and others will use the device 
tree.

I wonder whether there are implications for kexec support...

> 
> mmm so have a different head.S for a generic FDT machine and just pass 
> the FDT via a register like I'm doing on nommu. I don't mind either way 
> so if a maintainer decides which they'd be willing to merge I'll get 
> that going..
> 

Yes, I think we've touched on several questions for senior maintainers to 
ponder.

Powered by blists - more mailing lists