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: <CAMuHMdVa932fBaJ-sc-38g5n95TepLt+a2RhxucVrfBD0xDF2w@mail.gmail.com>
Date: Thu, 9 Jan 2025 11:06:13 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Daniel Palmer <daniel@...f.com>, linux-m68k@...ts.linux-m68k.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] m68k goes DT

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