On Tue, 26 Oct 2021, Mark Cave-Ayland wrote:
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.
My aim is to let the most guests boot and adding the /pci node btoke two NetBSD versions while not adding any node breaks MorphOS. This patch allows all three to boot and it's the most unlikely to break anything else. I was trying to fix the /pci node but I could not find out what NetBSD needs so I went for solving the actual problem instead which is to let all three of these boot and for that this is the simplest solution.
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.
That's the theory but mac99 does not emulate the real machine 100% so there could be other differences why an identical device tree may not work. For one we don't emulate the pci-bridge (QEMU could do it but OpenBIOS cannot deal with that so it's disabled. This makes the current /pci node already different). We also don't really emulate the AGP port and just have a PCI instead so maybe this /pci node I'm trying to add can't be the same either. It would take fixing QEMU to emulate everything faithfully and make OpenBIOS do everything what OpenFirmware does to arrive to an identical state which is unreasonable. Not only in the week left until the freeze but all these years I'm trying to fix this MorphOS problem so that won't happen.
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.
I don't know. Are you subscribed to that list or know their IRC channel you could ask them faster? Please cc me the answer. I've tried my best to find this out but I don't have more time to spend with this now.
Regards, BALATON Zoltan