Message-ID: <CAFr9PXm4kTWF27GPMNDb5=W8vZRQia418xOQDF_X1yo0vwn6hA@mail.gmail.com>
Date: Sun, 5 Jan 2025 20:00:57 +0900
From: Daniel Palmer <daniel@...f.com>
To: Finn Thain <fthain@...ux-m68k.org>
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

Hi Finn,

On Sun, 5 Jan 2025 at 18:40, Finn Thain <fthain@...ux-m68k.org> wrote:
>
>
> On Sun, 5 Jan 2025, Daniel Palmer wrote:
>
> >
> > What I'm thinking:
> >
> > - We initially add passing of an FDT via bootinfo for mmu
> > - Add support for a generic machine that can boot almost anything so I
> >   can bring up my new (to Linux) machines.
> > - I will migrate MVME147 to device tree.
> > - Some like minded person migrates a machine they have to device tree.
> >   :)
>
> Interesting ideas. I gather that you've already done a uboot port for
> MVME147, and I guess uboot could be made to work on other m68k
> platforms...

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

>but it may be easier to add your FDT suppor to the
> already-available bootloaders on those platforms (?)

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.

> > - Maybe embed a FDT for machines that'll never get a bootloader that
> >   supports this and use the machine type to select the embedded FDT and
> >   move all of that stuff over without needing to mess with bootloaders.
> >
>
> I like this idea. A few weeks back I was recapping a Mac Classic II and
> thinking about how I could boot Linux on it.
>
> Pengiun (the bootloader I've been using) can be expected to fail with
> "68020 has no MMU. Aborting boot...". However, the source code for EMILE
> appears to have ample support for booting a nommu Mac.

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.

> Most of the drivers for this logic board are present in Linux. Some are
> platform drivers, most rely on bootinfo to some extent (particularly
> macfb.c and misc.c). And head.S also relies on bootinfo.

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.

> Maybe the easiest approach for head.S is to neglect support for both
> bootinfo and FDT in the same binary, so it becomes a build-time choice.
> That way, a first cut could be a new head.S that supports your "generic"
> platform, lacks bootinfo support, but has an embedded FDT.

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

Cheers,

Daniel

Powered by blists - more mailing lists