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: <291d1541-e026-cc50-6a55-42c11c64b6eb@linux-m68k.org>
Date: Sun, 5 Jan 2025 20:40:51 +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:

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