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.
