Re: [PATCH 3/3] board: Add QEMU m68k virt board support

[Kuan-Wei Chiu <visitorckw@gmail.com>]

Hi Daniel,

On Sun, Dec 21, 2025 at 01:37:24PM +0900, Daniel Palmer wrote:
> Hi Kuan-Wei,
> 
> On Fri, 19 Dec 2025 at 04:06, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> >
> > Add support for the QEMU 'virt' machine on the m68k architecture. This
> > board emulates a generic machine based on the Motorola 68040 CPU
> > equipped with Goldfish virtual peripherals.
> 
> Since I already have this setup working and able to boot linux I will
> add some input:
> - The virt machine can use any supported CPU type, even 000 without
> mmu, you should really handle that.

You're right. Regarding the support for other 680x0 CPUs, would you
prefer to see them included in v2, or would you think that it is better
to integrate them incrementally after this baseline series is merged?

> - m68k linux for mmu machines uses "bootinfo" that is a structure
> after the kernel image that the bootloader prepares so linux can work
> out what CPU etc is present. QEMU does this as well but it will be
> after the u-boot image now, so to boot linux you must save it before
> it gets destroyed and when the kernel is loaded copy it to after the
> kernel. I use ELF images to boot linux. I have a hack in bootelf to
> put the bootinfo in place just before jumping to the entry point.
> - Since QEMU gives you the bootinfo and you need to parse it to work
> out how much to save either way you should use it to detect the
> selected CPU in u-boot. If the code is built for 000 it will run on
> anything and just needs to handle the differences in the caches. In my
> setup I fixup the cpu compatible string in u-boot's devicetree and
> then use that to work out what cache function to call for the current
> CPU.

Currently, I only parse the bootinfo to retrieve the RAM size and
haven't looked into the specific requirements for booting Linux yet.

If full Linux boot support isn't a blocker for this initial series,
could you advise on any specific structural adjustments I should make
now to facilitate that integration later?

> 
> Glad to see I'm not alone in messing around with this. :)

Same here! Glad to know I'm not the only one. :)

Regards,
Kuan-Wei