linux-kernel - [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-next>] [day] [month] [year] [list]

Message-ID: <20250105071433.3943289-1-daniel@0x0f.com>
Date: Sun,  5 Jan 2025 16:14:30 +0900
From: Daniel Palmer <daniel@...f.com>
To: geert@...ux-m68k.org,
	fthain@...ux-m68k.org,
	linux-m68k@...ts.linux-m68k.org
Cc: linux-kernel@...r.kernel.org,
	Daniel Palmer <daniel@...f.com>
Subject: [RFC PATCH 0/3] m68k goes DT

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