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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c0428d69-2f18-45d3-8024-a9fe4170b23e@kernel.org>
Date: Mon, 6 Jan 2025 00:59:04 +1000
From: Greg Ungerer <gerg@...nel.org>
To: Daniel Palmer <daniel@...f.com>, geert@...ux-m68k.org,
 fthain@...ux-m68k.org, linux-m68k@...ts.linux-m68k.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] m68k goes DT

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



View attachment "coldfire-dtb.patch" of type "text/x-patch" (3419 bytes)