[RFC PATCH 0/3] m68k goes DT

[RFC PATCH 0/3] m68k goes DT

[Daniel Palmer]

Short version:
I want to start converting m68k (including nommu) to use DT for booting
so I can add few cool boards I have (e.g. dual 040/060 VME board..).
I need ideas, help etc. Maybe if someone converted an m68k machine they
are using to DT alongside me this would have some hope of actually happening?

All of my WIP in-progress very messy code etc is here:
https://github.com/fifteenhex/m68kjunk

Longer version:

As of today I have:
- Modern (2024.07) u-boot fork that works on 000/030/040 real hardware/QEMU
  that supports booting a Linux ELF image. For nommu a FDT blob address
  is passed via a regiser, for mmu the normal bootinfo is created and
  the FDT is passed via a bootinfo tag. nommu never used bootinfo and doesn't
  need to.

- A Linux branch for nommu that removes most of the current DragonBall
  code, makes it into a devicetree based machine and adds a bunch of
  drivers etc. This works in a fork of QEMU I have and on the real hardware.
  The DragonBall even has a working 1bpp framebuffer. The nommu branch also
  works on 010 and better.

- A Linux branch for mmu that uses the crappy patches in this series and some
  other bits to start moving the MVME147 board over to using DT.

- A buildroot fork that can build a 000 nommu userland etc. A patch to add
  support for building for 030 is already in buildroot, I plan to send one
  for 060 later.

- A bunch of DragonBall machines, an MVME147 030 machine, an Eltec E27 dual
  socket VME board with one 040 at the moment but I have 060s to go in it once
  I work out the need jumper changes, some other 060 VME boards, Amigas...

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

Issues I have:

- The head.S code is real confusing, I'm not sure how I make this support
  a generic machine right now.
- The head.S code sometimes gets stuck setting up the mmu on my MVME147 when
  the kernel binary layout changes. I thought for a long time my new code was
  wrong but then discovered just making the kernel bigger by adding some printk()s
  also caused it.

Sorry for the wall of text.

Cheers,

Daniel

Daniel Palmer (3):
  m68k: bootinfo: Add tag for FDT address
  m68k: bootinfo: Add generic machine type
  m68k: Add dt support (proof of concept)

 arch/m68k/Kconfig                     |  2 +
 arch/m68k/include/uapi/asm/bootinfo.h |  4 ++
 arch/m68k/kernel/setup_mm.c           | 63 ++++++++++++++++++++++++++-
 3 files changed, 68 insertions(+), 1 deletion(-)

-- 
2.45.2

[RFC PATCH 1/3] m68k: bootinfo: Add tag for FDT address

[Daniel Palmer]

Allow bootinfo to carry a pointer to an FDT so that the
bootloader can pass us one.

This allows for devicetree support without changing the
boot protocol too much and breaking unmaintained bootloaders.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
---
 arch/m68k/include/uapi/asm/bootinfo.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/m68k/include/uapi/asm/bootinfo.h b/arch/m68k/include/uapi/asm/bootinfo.h
index 024e87d7095f..326f20e82769 100644
--- a/arch/m68k/include/uapi/asm/bootinfo.h
+++ b/arch/m68k/include/uapi/asm/bootinfo.h
@@ -73,6 +73,9 @@ struct mem_info {
 #define BI_RNG_SEED		0x0008
 
 
+/* Pointer to FDT if there is one */
+#define BI_FDT			0x0009
+
     /*
      *  Linux/m68k Architectures (BI_MACHTYPE)
      */
-- 
2.45.2

[RFC PATCH 2/3] m68k: bootinfo: Add generic machine type

[Daniel Palmer]

Add a generic machine type that will use an FDT instead
of board setup code.

This will allow the bootloader to just pass the generic
machine type, some memory info for the head.S code and
a pointer to a FDT blob instead of a specific machine
type and make adding new machines simpler.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
---
 arch/m68k/include/uapi/asm/bootinfo.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/m68k/include/uapi/asm/bootinfo.h b/arch/m68k/include/uapi/asm/bootinfo.h
index 326f20e82769..e885bbc462d3 100644
--- a/arch/m68k/include/uapi/asm/bootinfo.h
+++ b/arch/m68k/include/uapi/asm/bootinfo.h
@@ -94,6 +94,7 @@ struct mem_info {
 #define MACH_M54XX		12
 #define MACH_M5441X		13
 #define MACH_VIRT		14
+#define MACH_GENERIC		15
 
 
     /*
-- 
2.45.2

[RFC PATCH 3/3] m68k: Add dt support (proof of concept)

[Daniel Palmer]

This is not ready for merge. This just adds enough, probably incorrect,
code to get the FDT blob from the bootinfo and parse it.

This is enough to get drivers to probe using devicetree nodes instead
of manually registering them but looking up interrupts etc in the DT
will not work.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
---
 arch/m68k/Kconfig           |  2 ++
 arch/m68k/kernel/setup_mm.c | 63 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 7c4f7bcc89d7..e348e6822943 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -39,6 +39,8 @@ config M68K
 	select OLD_SIGSUSPEND3
 	select UACCESS_MEMCPY if !MMU
 	select ZONE_DMA
+	select OF
+	select OF_EARLY_FLATTREE
 
 config CPU_BIG_ENDIAN
 	def_bool y
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 15c1a595a1de..6d358124259e 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -50,6 +50,10 @@
 #include <asm/natfeat.h>
 #include <asm/config.h>
 
+#include <linux/libfdt.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+
 #if !FPSTATESIZE || !NR_IRQS
 #warning No CPU/platform type selected, your kernel will not work!
 #warning Are you building an allnoconfig kernel?
@@ -107,11 +111,57 @@ EXPORT_SYMBOL(isa_sex);
 
 #define MASK_256K 0xfffc0000
 
+static phys_addr_t fdt_blob;
+static void __init m68k_setup_fdt(void)
+{
+	pr_info("m68k generic DT machine support, FDT blob at 0x%08x\n", fdt_blob);
+	if (!early_init_dt_verify(__va(fdt_blob), fdt_blob)) {
+		pr_err("FDT blob is bad?!\n");
+		return;
+	}
+
+	early_init_dt_scan_nodes();
+}
+
+static const struct bi_record __init *m68k_find_bootinfo_record(const struct bi_record *record, u16 bi_type)
+{
+	uint16_t tag;
+
+	while ((tag = be16_to_cpu(record->tag)) != BI_LAST) {
+		uint16_t size = be16_to_cpu(record->size);
+
+		if (tag == bi_type)
+			return record;
+		record = (struct bi_record *)((unsigned long)record + size);
+	}
+
+	return NULL;
+}
+
 static void __init m68k_parse_bootinfo(const struct bi_record *record)
 {
 	const struct bi_record *first_record = record;
+	const struct bi_record *machine_record;
 	uint16_t tag;
 
+	fdt_blob = 0;
+
+	/*
+	 * First attempt to work out if we are a generic DT machine,
+	 * must have an FDT record.
+	 */
+	machine_record = m68k_find_bootinfo_record(record, BI_MACHTYPE);
+	if (machine_record->data[0] == MACH_GENERIC) {
+		const struct bi_record *fdt_record;
+
+		fdt_record = m68k_find_bootinfo_record(record, BI_FDT);
+
+		BUG_ON(!fdt_record);
+		fdt_blob = (phys_addr_t) fdt_record->data[0];
+	}
+
+	/* Revert to the pure bootinfo method */
+	record = first_record;
 	while ((tag = be16_to_cpu(record->tag)) != BI_LAST) {
 		int unknown = 0;
 		const void *data = record->data;
@@ -124,7 +174,6 @@ static void __init m68k_parse_bootinfo(const struct bi_record *record)
 		case BI_MMUTYPE:
 			/* Already set up by head.S */
 			break;
-
 		case BI_MEMCHUNK:
 			if (m68k_num_memory < NUM_MEMINFO) {
 				const struct mem_info *m = data;
@@ -162,6 +211,10 @@ static void __init m68k_parse_bootinfo(const struct bi_record *record)
 			break;
 		}
 
+		case BI_FDT:
+			fdt_blob = (phys_addr_t) record->data[0];
+			break;
+
 		default:
 			if (MACH_IS_AMIGA)
 				unknown = amiga_parse_bootinfo(record);
@@ -240,6 +293,9 @@ void __init setup_arch(char **cmdline_p)
 		}
 	}
 
+	if (fdt_blob)
+		m68k_setup_fdt();
+
 	setup_initial_init_mm((void *)PAGE_OFFSET, _etext, _edata, _end);
 
 #if defined(CONFIG_BOOTPARAM)
@@ -329,6 +385,11 @@ void __init setup_arch(char **cmdline_p)
 		panic("No configuration setup");
 	}
 
+	if (fdt_blob) {
+		memblock_reserve(fdt_blob, fdt_totalsize(__va(fdt_blob)));
+		unflatten_device_tree();
+	}
+
 	if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && m68k_ramdisk.size)
 		memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
 
-- 
2.45.2

Re: [RFC PATCH 0/3] m68k goes DT

[Finn Thain]

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... but it may be easier to add your FDT suppor to the 
already-available bootloaders on those platforms (?)

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

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.

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.

Then you could get to work on the drivers, and I'm guessing that may be 
where most of the work lies. (I may be wrong, though -- I've never brought 
up a new board.) I don't have much experience with FDT but I am curious 
about the kind of driver changes this would involve.

Re: [RFC PATCH 0/3] m68k goes DT

[Daniel Palmer]

Hi Finn,

On Sun, 5 Jan 2025 at 18:40, Finn Thain <fthain@linux-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

Re: [RFC PATCH 0/3] m68k goes DT

[Finn Thain]

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.

Re: [RFC PATCH 0/3] m68k goes DT

[Josh Juran]

On Jan 5, 2025, at 10:28 PM, Finn Thain <fthain@linux-m68k.org> wrote:

> In the case of Penguin, you also need to know MacOS internals.
> 
> But these bootloaders have bugs, like any other program, and someone has 
> to maintain them…

If Penguin needs maintenance, I’m still here and I still develop for classic Mac OS.  I’ve ditched CodeWarrior’s proprietary project files, though I still use the non-free Metrowerks compiler and linker (but now in MPW’s ToolServer, driven by my own build tool running in MacRelix).  Lately I’ve been using custom post-linkers to improve startup code compatibility with older OS versions.

I’m not in a position to do testing on hardware or development relating to Linux bootup, but as before, I can maintain and build Mac OS programs.

Cheers,
Josh

Bootloaders, was Re: [RFC PATCH 0/3] m68k goes DT

[Finn Thain]

On Mon, 6 Jan 2025, Josh Juran wrote:

> 
> I'm not in a position to do testing on hardware or development relating 
> to Linux bootup, but as before, I can maintain and build Mac OS 
> programs.
> 

I've entered the Penguin-19 bugs that I know of into the mac68k bug 
tracker on sourceforge. I didn't add feature requests, like support for 
the Mac LC II 12 MB RAM configuration, or support for zstd-format 
compressed vmlinux. (Nevermind netbsd support, or device tree support...)

Some of those bugs and missing features apply to EMILE as well. IMHO, what 
EMILE really needs is a MacOS GUI like Penguin. So my advice to 
prospective mac bootloader developers is, add a GUI to EMILE rather than 
try to maintain both packages.

That's easier said than done -- Penguin is a hard act to follow. But, in 
theory, thanks to Retro68, it could be done without resorting to 
proprietary tooling. Both the Linux executables and the MacOS application 
could be built with a modern GCC.

Consider that, without a modern GCC, it will be difficult to re-use the 
available code e.g. for kernel image decompression. Hence, it will be more 
difficult to fix the long standing Penguin bug relating to gzip 
decompression (which does not affect EMILE).

Re: Bootloaders, was Re: [RFC PATCH 0/3] m68k goes DT

[Daniel Palmer]

Hi Finn,

On Tue, 7 Jan 2025 at 09:57, Finn Thain <fthain@linux-m68k.org> wrote:
> Some of those bugs and missing features apply to EMILE as well. IMHO, what
> EMILE really needs is a MacOS GUI like Penguin. So my advice to
> prospective mac bootloader developers is, add a GUI to EMILE rather than
> try to maintain both packages.

FWIW I have started to move EMILE over to using meson to build (so
it's easier to build on modern systems) and fixing up some of the
issues it has with building with recent GCC.
I have it working enough to boot HEAD on a LC475 and on QEMUs Q800
machine. While the penguin ui is nice EMILE seems to work well enough
and it can be used to generate bootable CDs.
I have a setup now that can generate a bootable CD with the kernel and
a buildroot based userland that I can drop on the SD card for my
bluescsi and boot into Linux without any macos intervention.

So basically, for 68k mac I think EMILE is the way to go.

Cheers,

Daniel

Re: Bootloaders, was Re: [RFC PATCH 0/3] m68k goes DT

[Finn Thain]

On Tue, 4 Mar 2025, Daniel Palmer wrote:

> FWIW I have started to move EMILE over to using meson to build (so
> it's easier to build on modern systems) and fixing up some of the
> issues it has with building with recent GCC.

Thanks for doing that.

> I have it working enough to boot HEAD on a LC475 and on QEMUs Q800
> machine. While the penguin ui is nice EMILE seems to work well enough
> and it can be used to generate bootable CDs.

That's good news -- I've long wondered whether QEMU's emulated q800 had 
reached a point where it could run EMILE. That will make development 
easier.

> I have a setup now that can generate a bootable CD with the kernel and a 
> buildroot based userland that I can drop on the SD card for my bluescsi 
> and boot into Linux without any macos intervention.
> 

I guess it's only a matter of time before someone puts EMILE into EEPROM. 
(Many of these systems have a ROM SIMM slot.)

> So basically, for 68k mac I think EMILE is the way to go.
> 

And there is a way to go...

Penguin 19 works on every 68k Mac model. That's hard to achieve and 
running under MacOS helps a lot. EMILE doesn't have that advantage so it 
isn't expected to enjoy the same level of hardware compatibility without 
further work.

For systems that have the standard ROM, booting MacOS is an easy first 
step for system recovery purposes or just experimentation. So I think 
EMILE needs a MacOS UI which, though it might not boot Linux, could do the 
bootloader installation and config (a bit like what XPostFacto did for Mac 
OS X) so the ROM could then boot into EMILE (and Linux).

Re: [RFC PATCH 0/3] m68k goes DT

[Geert Uytterhoeven]

On Mon, Jan 6, 2025 at 4:28 AM Finn Thain <fthain@linux-m68k.org> wrote:
> 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.

That was indeed my first thought, too: do not store a pointer to the
FDT in a bootinfo record.  Else you end up with a situation similar
to ARM(32), which supports the can of worms of mixing FDT and ATAGS.

Instead, replace bootinfo by FDT, and differentiate by checking for
the FDT magic value. That way you can have a kernel that supports both
bootinfo and FDT.

Passing FDT using a register is also an option, but might be harder to
auto-detect: when using bootinfo, there may be garbage in the register,
when booting FDT, there may be garbage in memory where bootinfo is
usually stored.

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

Yes, this complicates things.

> > That's why I think embedded FDTs might be needed in some places and
> > leaving the bootinfo part as-is.

For "simple" (fixed hardware) machines, that is indeed an option,
and already supported on various other architectures.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC PATCH 0/3] m68k goes DT

[Greg Ungerer]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

Hi Daniel,

On 5/1/25 17:14, Daniel Palmer wrote:
> Short version:
> I want to start converting m68k (including nommu) to use DT for booting
> so I can add few cool boards I have (e.g. dual 040/060 VME board..).
> I need ideas, help etc. Maybe if someone converted an m68k machine they
> are using to DT alongside me this would have some hope of actually happening?

I have been thinking about this for a while for the ColdFire targets.
In a few cases the drivers its uses are already devicetree enabled,
since they are used on some of the NXP/Freescale ARM SoC devices.
So this is interesting work to me.


> All of my WIP in-progress very messy code etc is here:
> https://github.com/fifteenhex/m68kjunk
> 
> Longer version:
> 
> As of today I have:
> - Modern (2024.07) u-boot fork that works on 000/030/040 real hardware/QEMU
>    that supports booting a Linux ELF image. For nommu a FDT blob address
>    is passed via a regiser, for mmu the normal bootinfo is created and
>    the FDT is passed via a bootinfo tag. nommu never used bootinfo and doesn't
>    need to.
> 
> - A Linux branch for nommu that removes most of the current DragonBall
>    code, makes it into a devicetree based machine and adds a bunch of
>    drivers etc. This works in a fork of QEMU I have and on the real hardware.
>    The DragonBall even has a working 1bpp framebuffer. The nommu branch also
>    works on 010 and better.
> 
> - A Linux branch for mmu that uses the crappy patches in this series and some
>    other bits to start moving the MVME147 board over to using DT.
> 
> - A buildroot fork that can build a 000 nommu userland etc. A patch to add
>    support for building for 030 is already in buildroot, I plan to send one
>    for 060 later.
> 
> - A bunch of DragonBall machines, an MVME147 030 machine, an Eltec E27 dual
>    socket VME board with one 040 at the moment but I have 060s to go in it once
>    I work out the need jumper changes, some other 060 VME boards, Amigas...
> 
> 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. :)
> - 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.

To that end that is what I have been playing with. Doing it in a similar
way to what MIPS does. Example patch attached of what I did for non-MMU
ColdFire. So no boot loader support required.

Regards
Greg



[-- Attachment #2: coldfire-dtb.patch --]
[-- Type: text/x-patch, Size: 3419 bytes --]

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 7c4f7bcc89d7..a4949b69e1dc 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -39,6 +39,8 @@ config M68K
 	select OLD_SIGSUSPEND3
 	select UACCESS_MEMCPY if !MMU
 	select ZONE_DMA
+	select OF if COLDFIRE
+	select OF_EARLY_FLATTREE if COLDFIRE
 
 config CPU_BIG_ENDIAN
 	def_bool y
diff --git a/arch/m68k/Kconfig.devices b/arch/m68k/Kconfig.devices
index e6e3efac1840..ea0bce4db639 100644
--- a/arch/m68k/Kconfig.devices
+++ b/arch/m68k/Kconfig.devices
@@ -144,3 +144,14 @@ config SERIAL_CONSOLE
 endmenu
 
 endif
+
+config EMBEDDED_DTB
+	bool "Embedded devicetree ELF section"
+	help
+	  If there is no capability for the boot loader to specify a
+	  devicetree (DTB) then this option allows for it to be embedded
+	  within the linux binary itself. Typically you can do this with
+	  something like this:
+
+		objcopy --update-section .embedded_dtb=<filename>.dtb vmlinux
+
diff --git a/arch/m68k/coldfire/head.S b/arch/m68k/coldfire/head.S
index c6d7fd28c602..88fd8b5b3bda 100644
--- a/arch/m68k/coldfire/head.S
+++ b/arch/m68k/coldfire/head.S
@@ -133,6 +133,15 @@ _init_sp:
 .long	0
 #endif
 
+#ifdef CONFIG_EMBEDDED_DTB
+/*
+ * If embedding a DTB in the kernel ELF binary then create a place holder
+ * for that section. It will be inserted after the final kernel build/link.
+ */
+.section ".embedded_dtb","aw"
+.long 0
+#endif
+
 /*****************************************************************************/
 
 __HEAD
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index c926da9d5ec2..d1d79c41c6f0 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -33,6 +33,8 @@
 #include <linux/initrd.h>
 #include <linux/root_dev.h>
 #include <linux/rtc.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
 
 #include <asm/setup.h>
 #include <asm/bootinfo.h>
@@ -70,6 +72,31 @@ void (*mach_halt)(void);
 #define	CPU_NAME	"UNKNOWN"
 #endif
 
+#ifdef CONFIG_EMBEDDED_DTB
+static void __init m68k_setup_fdt(void)
+{
+	extern void *embedded_dtb;
+	phys_addr_t fdt = (phys_addr_t) &embedded_dtb;
+
+	pr_info("m68k generic DT machine support, FDT blob at 0x%08x\n", fdt);
+	if (!early_init_dt_verify(__va(fdt), fdt)) {
+		pr_err("FDT blob is bad?!\n");
+		return;
+	}
+	early_init_dt_scan_nodes();
+}
+
+static void __init m68k_dtb_model(void)
+{
+	const char *model;
+	model = of_flat_dt_get_machine_name();
+	if (model)
+		pr_info("DTB reports model = %s\n", model);
+	else
+		pr_warn("DTB has no model type?\n");
+}
+#endif /* CONFIG_EMBEDDED_DTB */
+
 /*
  * Different cores have different instruction execution timings.
  * The old/traditional 68000 cores are basically all the same, at 16.
@@ -166,6 +193,11 @@ void __init setup_arch(char **cmdline_p)
 	 * Get kmalloc into gear.
 	 */
 	paging_init();
+
+#ifdef CONFIG_EMBEDDED_DTB
+	m68k_setup_fdt();
+	m68k_dtb_model();
+#endif
 }
 
 /*
diff --git a/arch/m68k/kernel/vmlinux-nommu.lds b/arch/m68k/kernel/vmlinux-nommu.lds
index 2624fc18c131..1be3bfe31ba4 100644
--- a/arch/m68k/kernel/vmlinux-nommu.lds
+++ b/arch/m68k/kernel/vmlinux-nommu.lds
@@ -70,6 +70,15 @@ SECTIONS {
 	INIT_TEXT_SECTION(PAGE_SIZE)
 	INIT_DATA_SECTION(16)
 	PERCPU_SECTION(16)
+
+#ifdef CONFIG_EMBEDDED_DTB
+	STRUCT_ALIGN();
+	.embedded_dtb : {
+		embedded_dtb = .;
+		*(.embedded_dtb)
+		KEEP(*(.embedded_dtb))
+	}
+#endif
 	.m68k_fixup : {
 		__start_fixup = .;
 		*(.m68k_fixup)

Re: [RFC PATCH 0/3] m68k goes DT

[Daniel Palmer]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

Hi Greg,

On Sun, 5 Jan 2025 at 23:59, Greg Ungerer <gerg@kernel.org> wrote:
> > - 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. :)
> > - 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.
>
> To that end that is what I have been playing with. Doing it in a similar
> way to what MIPS does. Example patch attached of what I did for non-MMU
> ColdFire. So no boot loader support required.

Based on that I've attached what I think would work for normal 68k MMU.
Instead of manually embedding the DTB we embed all of them and if
there is no FDT in the bootinfo we use the builtin blob.
This allows booting without bootloader support and I can still pass a
custom FDT from u-boot to enable hardware connected to the VME
backplane.

Does this plan seem ok? If so I'll start the process of creating and
sending the dt bindings etc. I hate doing that stuff so I don't want
to do it if this is a no go. :)

Cheers,

Daniel

[-- Attachment #2: 0001-m68k-dt-embedding.patch --]
[-- Type: text/x-patch, Size: 2298 bytes --]

From d957da5c1a71ca91743f6b962a9adf0c7f093645 Mon Sep 17 00:00:00 2001
From: Daniel Palmer <daniel@0x0f.com>
Date: Mon, 6 Jan 2025 10:35:08 +0900
Subject: [PATCH] m68k: dt embedding

---
 arch/m68k/dts/Makefile           |  2 ++
 arch/m68k/dts/embedded_dtbs.S    | 12 ++++++++++++
 arch/m68k/kernel/setup_mm.c      | 11 +++++++++++
 arch/m68k/kernel/vmlinux-std.lds |  6 ++++++
 4 files changed, 31 insertions(+)
 create mode 100644 arch/m68k/dts/embedded_dtbs.S

diff --git a/arch/m68k/dts/Makefile b/arch/m68k/dts/Makefile
index ca4d64a73f49..e2cb53e6d2db 100644
--- a/arch/m68k/dts/Makefile
+++ b/arch/m68k/dts/Makefile
@@ -1,3 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-y += \
 	mvme147.dtb
+
+obj-y += embedded_dtbs.o
diff --git a/arch/m68k/dts/embedded_dtbs.S b/arch/m68k/dts/embedded_dtbs.S
new file mode 100644
index 000000000000..139851e77b39
--- /dev/null
+++ b/arch/m68k/dts/embedded_dtbs.S
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include <linux/linkage.h>
+#include <asm/page.h>
+
+        .section ".embedded_dtbs","aw"
+
+        .balign PAGE_SIZE
+
+SYM_DATA_START(mvme147_dtb)
+        .incbin "arch/m68k/dts/mvme147.dtb"
+SYM_DATA_END_LABEL(mvme147_dtb, SYM_L_GLOBAL, mvme147_dtb_end)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 6d358124259e..a5feb561064d 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -293,6 +293,17 @@ void __init setup_arch(char **cmdline_p)
 		}
 	}
 
+	// TODO: This is wrong, the blob is in the init section so it needs to be copied
+	// but PoC
+	if (!fdt_blob)
+	{
+		extern void *mvme147_dtb;
+
+		pr_info("FDT blob was not provided, will use embedded one if available\n");
+		if (MACH_IS_MVME147)
+			fdt_blob = mvme147_dtb;
+	}
+
 	if (fdt_blob)
 		m68k_setup_fdt();
 
diff --git a/arch/m68k/kernel/vmlinux-std.lds b/arch/m68k/kernel/vmlinux-std.lds
index 1ccdd04ae462..3e40b6cf36a4 100644
--- a/arch/m68k/kernel/vmlinux-std.lds
+++ b/arch/m68k/kernel/vmlinux-std.lds
@@ -43,6 +43,12 @@ SECTIONS
   __init_begin = .;
   INIT_TEXT_SECTION(PAGE_SIZE) :data
   INIT_DATA_SECTION(16)
+  STRUCT_ALIGN();
+  .embedded_dtbs : {
+	embedded_dtbs = .;
+	*(.embedded_dtbs)
+	KEEP(*(.embedded_dtbs))
+  }
   .m68k_fixup : {
 	__start_fixup = .;
 	*(.m68k_fixup)
-- 
2.45.2

Re: [RFC PATCH 0/3] m68k goes DT

[Brad Boyer]

On Mon, Jan 06, 2025 at 12:59:04AM +1000, Greg Ungerer wrote:
> On 5/1/25 17:14, Daniel Palmer wrote:
> >Short version:
> >I want to start converting m68k (including nommu) to use DT for booting
> >so I can add few cool boards I have (e.g. dual 040/060 VME board..).
> >I need ideas, help etc. Maybe if someone converted an m68k machine they
> >are using to DT alongside me this would have some hope of actually happening?
> 
> I have been thinking about this for a while for the ColdFire targets.
> In a few cases the drivers its uses are already devicetree enabled,
> since they are used on some of the NXP/Freescale ARM SoC devices.
> So this is interesting work to me.

The m68k mac platform is similar in this due to sharing some drivers
with ppc macs using Open Firmware. There are a few drivers where we
could eliminate complexity and #ifdef trickery if it was all
device tree based. For example, pmac_zilog.c relies on the data from
OF on a powermac but is getting platform data from the tables in
config.c on m68k. The code in via-cuda.c similarly looks up the
hardware info from OF on a powermac but has hard-coded data on m68k.

	Brad Boyer
	flar@allandria.com

Re: [RFC PATCH 0/3] m68k goes DT

[Finn Thain]

On Mon, 6 Jan 2025, Brad Boyer wrote:

> There are a few drivers where we could eliminate complexity and #ifdef 
> trickery if it was all device tree based.

Ideally, yes. But how would we get there from here?

Should the kernel synthesize a device tree from the bootinfo data, so that 
an ideal no-ifdef pmac_zilog could work? (This seems like a maximum bloat 
solution.)

Or should the mac platform abandon bootinfo, and require a new bootloader 
for all kernel releases after device tree adoption? (This seems maximally 
difficult, since it requires simultaneously merging many patches to many 
subsystems, even if the bootloader changes could be done in advance...)

I wonder whether any other architectures have attempted to retrofit device 
tree support (?)

Re: [RFC PATCH 0/3] m68k goes DT

[Geert Uytterhoeven]

Hi Finn,

On Mon, Jan 6, 2025 at 11:14 PM Finn Thain <fthain@linux-m68k.org> wrote:
> On Mon, 6 Jan 2025, Brad Boyer wrote:
> > There are a few drivers where we could eliminate complexity and #ifdef
> > trickery if it was all device tree based.
>
> Ideally, yes. But how would we get there from here?
>
> Should the kernel synthesize a device tree from the bootinfo data, so that
> an ideal no-ifdef pmac_zilog could work? (This seems like a maximum bloat
> solution.)

We can add a wrapper that starts from a basic Amiga/Atari/Mac/... FDT
and extends/modifies that, based on the bootinfo.
Modification can be done using libfdt, even from assembler.
See e.g. arch/arm/boot/compressed/*fdt*.

> Or should the mac platform abandon bootinfo, and require a new bootloader
> for all kernel releases after device tree adoption? (This seems maximally
> difficult, since it requires simultaneously merging many patches to many
> subsystems, even if the bootloader changes could be done in advance...)

Drivers can easily support both DT and non-DT, assuming they use proper
platform devices.  That means no more MACH_IS_* and *HW_PRESENT()
checks in the drivers themselves, but proper platform data setup
in arch/m68k/<mach>/*.

> I wonder whether any other architectures have attempted to retrofit device
> tree support (?)

ARM is the classical example.
Until recently, there was code under drivers/staging/board/ to support
mixed DT/non-DT systems, but I don't suggest going that way.
Conversion of SH to DT is still WIP (except for J-Core, which is
DT-only).

The largest initial step is usually irqchip, clocksource, and clock
drivers and DT bindings.  Existing drivers "just" need DT bindings
and DT support.

For e.g. Amiga, the clock driver would be rather simple.
Clocksource is much more complicated, as the timers are provided by
the CIAs, which are really multi-function-devices (MFD), providing
timer, gpio,spi, and irqchip functionalities.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC PATCH 0/3] m68k goes DT

[Finn Thain]

On Thu, 9 Jan 2025, Geert Uytterhoeven wrote:

> On Mon, Jan 6, 2025,Finn Thain wrote:
> > On Mon, 6 Jan 2025, Brad Boyer wrote:
> > > There are a few drivers where we could eliminate complexity and 
> > > #ifdef trickery if it was all device tree based.
> >
> > Ideally, yes. But how would we get there from here?
> >
> > Should the kernel synthesize a device tree from the bootinfo data, so 
> > that an ideal no-ifdef pmac_zilog could work? (This seems like a 
> > maximum bloat solution.)
> 
> We can add a wrapper that starts from a basic Amiga/Atari/Mac/... FDT
> and extends/modifies that, based on the bootinfo.
> Modification can be done using libfdt, even from assembler.
> See e.g. arch/arm/boot/compressed/*fdt*.
> 
> > Or should the mac platform abandon bootinfo, and require a new 
> > bootloader for all kernel releases after device tree adoption? (This 
> > seems maximally difficult, since it requires simultaneously merging 
> > many patches to many subsystems, even if the bootloader changes could 
> > be done in advance...)
> 
> Drivers can easily support both DT and non-DT, assuming they use proper 
> platform devices.  That means no more MACH_IS_* and *HW_PRESENT() checks 
> in the drivers themselves, but proper platform data setup in 
> arch/m68k/<mach>/*.
> 

In the case of pmac_zilog, we still have to avoid pmac_call_feature() and 
the macio_dev stuff, so many ifdefs would remain.

If DT compatibility was needed in pmac_zilog in order to port Linux/m68k 
to new hardware (e.g. Mac Classic II) then I'd be in favour of such a 
driver patch. I don't have time to write it though.

> > I wonder whether any other architectures have attempted to retrofit 
> > device tree support (?)
> 
> ARM is the classical example.
> Until recently, there was code under drivers/staging/board/ to support
> mixed DT/non-DT systems, but I don't suggest going that way.
> Conversion of SH to DT is still WIP (except for J-Core, which is
> DT-only).
> 
> The largest initial step is usually irqchip, clocksource, and clock
> drivers and DT bindings.  Existing drivers "just" need DT bindings
> and DT support.
> 
> For e.g. Amiga, the clock driver would be rather simple.
> Clocksource is much more complicated, as the timers are provided by
> the CIAs, which are really multi-function-devices (MFD), providing
> timer, gpio,spi, and irqchip functionalities.
> 

That's a lot of work. The old drivers would end up being more portable 
when converted to DT, but is there a need for those drivers on new 
platforms?

MVME147 is different in that Daniel is proposing new drivers to support 
boards that are presently unsupported. (Not unlike the hypothetical Mac 
Classic II example I gave.)

Supporting new hardware is good, but any benefit from retro-fitting DT 
onto existing drivers is dubious, if those drivers will only end up being 
used on systems on which they are already being used...

Re: [RFC PATCH 0/3] m68k goes DT

[Geert Uytterhoeven]

Hi Daniel,

On Sun, Jan 5, 2025 at 8:15 AM Daniel Palmer <daniel@0x0f.com> wrote:
> - The head.S code sometimes gets stuck setting up the mmu on my MVME147 when
>   the kernel binary layout changes. I thought for a long time my new code was
>   wrong but then discovered just making the kernel bigger by adding some printk()s
>   also caused it.

What is your kernel size?  Perhaps the code to map 8 or 16 MiB of
the first memory chunk doesn't work on 68030?

There could also be some alignment issues.  IIRC, there is code that
expects the FDT to be 8-byte aligned.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC PATCH 0/3] m68k goes DT

[Daniel Palmer]

Hi Geert,

On Thu, 9 Jan 2025 at 19:31, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Daniel,
>
> On Sun, Jan 5, 2025 at 8:15 AM Daniel Palmer <daniel@0x0f.com> wrote:
> > - The head.S code sometimes gets stuck setting up the mmu on my MVME147 when
> >   the kernel binary layout changes. I thought for a long time my new code was
> >   wrong but then discovered just making the kernel bigger by adding some printk()s
> >   also caused it.
>
> What is your kernel size?  Perhaps the code to map 8 or 16 MiB of
> the first memory chunk doesn't work on 68030?

Kernel is 3.something MiB

> There could also be some alignment issues.  IIRC, there is code that
> expects the FDT to be 8-byte aligned.

I thought that too but it seems to be something else. I worked out
that for some reason head.S writes values to memory but reads back the
old value in some cases. The MMU code was not working correctly
because it was constantly clearing the page where it was putting the
data.

I then realised I wasn't disabling the I/D caches in u-boot so I added
that and it started working more reliably but it only boots every time
if I disable the caches before doing the stuff to load the ELF into
memory. So there is something funky going on in my u-boot I think and
head.S might be fine.

Anyhow,.. I have everything including the timer and interrupts setup
via DT on the MVME147 now.

Cheers,

Daniel