On 24/10/2021 21:02, BALATON Zoltan wrote:
On Sun, 24 Oct 2021, BALATON Zoltan wrote:
On Sun, 24 Oct 2021, BALATON Zoltan wrote:
On Sun, 24 Oct 2021, Mark Cave-Ayland wrote:
On 23/10/2021 21:08, BALATON Zoltan wrote:
On Sat, 23 Oct 2021, Mark Cave-Ayland wrote:
I've run through the CDROM boot tests and unfortunately this version causes the NetBSD kernel to be unable to locate its boot disk on my NetBSD 8.0 test ISO:
$ ./qemu-system-ppc -m 512 -bios openbios-qemu.elf.nostrip -M mac99,via=pmu -cdrom NetBSD-8.0-macppc.iso -boot d -prom-env 'boot-device=cd:,\ofwboot.xcf' -nographic
... ... atapibus0 at atabus1: 2 targets cd0 at atapibus0 drive 0: <QEMU DVD-ROM, QM00003, 2.5+> cdrom removable uhidev1 at uhub0 port 2 configuration 1 interface 0 uhidev1: QEMU (0x627) QEMU USB Mouse (0x01), rev 2.00/0.00, addr 3, iclass 3/1 uhid at uhidev1 not configured WARNING: 2 errors while detecting hardware; check system log. boot device: <unknown> root on md0a dumps on md0b root file system type: ffs kern.module.path=/stand/macppc/8.0/modules /: bad dir ino 10 at offset 0: null entry exec /sbin/init: error 2 init: trying /sbin/oinit /: bad dir ino 10 at offset 0: null entry exec /sbin/oinit: error 2 init: trying /sbin/init.bak /: bad dir ino 10 at offset 0: null entry exec /sbin/init.bak: error 2 init: trying /rescue/init exec /rescue/init: error 2 init path (default /sbin/init):
Removing -bios allows the CDROM to boot to the terminal prompt as normal:
... ... atapibus0 at atabus1: 2 targets cd0 at atapibus0 drive 0: <QEMU DVD-ROM, QM00003, 2.5+> cdrom removable uhidev1 at uhub0 port 2 configuration 1 interface 0 uhidev1: QEMU (0x627) QEMU USB Mouse (0x01), rev 2.00/0.00, addr 3, iclass 3/1 uhid at uhidev1 not configured WARNING: 2 errors while detecting hardware; check system log. boot device: <unknown> root on md0a dumps on md0b root file system type: ffs kern.module.path=/stand/macppc/8.0/modules erase ^H, werase ^W, kill ^U, intr ^C, status ^T Terminal type? [vt100]
I could reproduce this but have no idea what is happening. Looks like it cannot read from CD so I suspected some problem with DMA but I could not find any traces that show a difference. I've tried pci, unin, macio, ide but these don't seem to show any change. I'm not sure where to look for further clues, I could not find in NetBSD sources where it reads OF device tree and how it uses it. Do you have any idea what to look for and where?
Unfortunately I'm not too familiar with NetBSD sources but clearly the change is affecting something in the way it configures the hardware. Perhaps try asking over on one of the NetBSD mailing lists such as port-macppc?
I've found in NetBSD man pages (https://man.netbsd.org/boot.8) that additional debug messages can be enabled with boot -x kernel which I think is what I need to get more info on what's happening but I couldn't yet figure out how to pass options to kernel or how to get an interactive boot prompt from the boot loader to add this -x option.
There are some more man pages: https://man.netbsd.org/macppc/boot.8 https://man.netbsd.org/macppc/ofwboot.8
I try to get some mode detailed logs.
I could not get more verbose messages and ultimately could not figure out why this fails but this is what I've found. The current NetBSD 9.2 version is not affected and boots with or without the patch so that's good news. Previous versions mostly don't boot even before the patch (I wonder if these were tested on real hardware and they boot there at all). The two versions that booted before this patch (8.0 and 9.0) fail with different problems, 9.0 fails to find openpic and 8.0 I have no idea at all. I still don't understand what these NetBSD versions might need in the added pci node but I've found that MorphOS does not actually care what's in the node for the first bus or even what it's called. It just seems to look for a device-type pci node before the actual pci bus with the devices and probably just discards the first node it finds. So adding just a dummy node with pci device-type _before_ the /pci node makes MorphOS boot and I hope this won't break any other guests now so this would be an acceptable work around until proper support for multiple PCI buses would be implemented. I've sent a new patch with this, please test and let me know if there are any guests in your test images that still don't like this.
This means we've gone full circle, no? When you pinged this thread recently, I said I didn't mind merging a patch that added the correct /pci node from a real machine. The latest version of your patch goes back to adding a /dummy-pci node which is moving us away from where we want to be: the aim should be to move towards a real device tree, rather than adding synthetic nodes to work around bugs in various OSs.
The advantage of this approach is that once you get the new /pci node correct then everything will just work, since the device tree is the same both on real hardware and in QEMU.
What was the response from the NetBSD port-macppc mailing list? The NetBSD guys use QEMU a lot as part of their CI/release engineering process and are generally very responsive and knowledgeable: at the very minimum they will be able to point you directly towards the code in question.
ATB,
Mark.