[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFr9PXnFi5FSsjMmuDPe6CtuyEa2bkDSiRZtVUPmYyXcmEuFkQ@mail.gmail.com>
Date: Mon, 6 Jan 2025 11:10:34 +0900
From: Daniel Palmer <daniel@...f.com>
To: Greg Ungerer <gerg@...nel.org>
Cc: geert@...ux-m68k.org, fthain@...ux-m68k.org,
linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] m68k goes DT
Hi Greg,
On Sun, 5 Jan 2025 at 23:59, Greg Ungerer <gerg@...nel.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
View attachment "0001-m68k-dt-embedding.patch" of type "text/x-patch" (2298 bytes)
Powered by blists - more mailing lists