What the fastest possible x64 emulation way of OS4 today ?

@Maijestro, @joerg

There may be some issues with parsing but BBoot is case sensitive and don't plan to make it insensitive (no strcasecmp in minimal libc) so you should match file case. I did a diff of the names in Kicklayout and zip listing above and it found this:

-Kickstart/SmartFilesystem
+Kickstart/SmartFileSystem

This is what I said in first reply: "check that 1. it's there, 2. its name matches what's in Kicklayout"

Leading spaces should not cause problem and ; lines should also be ignored even with spaces before them. I'll check white space at end that may cause trouble and may need to be handled.

@balatonQuote:

There are no unimplemented messages when the programs crash. If I use the pegasos firmware then nvgetvar produces output instead of crashing.


The peg2ide commands are found in the kickstart file nvram.config

*edit*

noticed that AmigaOS has an extra error in the debug log for bboot, but not pegasos2.rom

@balatonQuote:

Ok I found the error in the kicklayout it says "SmartFileSystem" but in the kickstart folder the module is called "SmartFilesystem" this caused BBoot not to find the file.

@joerg

I use the SmartFileSystem from Enhancer Software 2.2 apparently it is written differently "SmartFilesystem" like the original one on the AmigaOs4.1 Pegasos 2 install CD. Maybe this should be fixed in the Enhancer Software package. ?

Balaton I am thrilled with the boot speed this takes Qemu to the next level finally the boot command is no longer needed and AmigaOs.4.1 boots completely. Due to the new bootloader, we can now use 2048 MB of RAM, a great additional side effect

Thank you for this alternative boot option I am so happy wow this is even more fun now. I hope you got your donation account in order in the meantime

@all

Thank you very much for trying to help. It is impressive what we can achieve together as an Amiga community.



Edit: @Balaton It seems like Qemu 8.1 RC has been optimized a bit...this is what some benchmarks I did conclude. With 8.1 RC I get for the first time without "hard float" patch with Quake Timedemo over 30 FPS that is impressive.

@balaton

this is the qemu 8.0.3 command line:

qemu-system-ppc -M pegasos2 -cpu apollo7 -accel tcg -kernel /home/white/Download/bboot-0.1/bboot -initrd /home/white/Download/Kickstart.zip -m 1024 -serial stdio -device sm501 -drive if=none,id=hd,file=/home/white/Download/32gb.raw,format=raw -de vice ide-hd,drive=hd,bus=ide.1 -netdev user,id=mynet0 -device rtl8139,netdev=mynet0 -vga none -drive if=none,id=hd1,file=/home/white/Downloads/coffin.raw,format=raw -device ide-hd,drive=hd1,bus=ide.1

and I get this:
BBoot 0.1 (20.7.2023)
/pci@80000000: me fe000000/10000 mem 80000000/40000000
/pci@80000000/host: 0:0.0 11ab:6460 60000 | 646011ab 0000 7
Added assigned-addresses
/pci@80000000/pci126f,501: 0:1.0 126f:0501 38000 | 0501126f 0000 0
Added assigned-addresses, set interrupt 0009
2000810 0 80000000 0 4000000 | 00000000 ! 80000000
2000814 0 84000000 0 200000 | 00000000 ! 84000000
/pci@80000000/pci10ec,8139:0:2.0 10ec:8139 20000 | 813910ec 0100 0
Fixed ROM BAR
Added assigned-addresses, set interrupt 0109
1001010 0 fe001200 0 100 | 00000001 ! 00001201
2001014 0 84200000 0 100 | 00000000 ! 84200000
2001030 0 84240000 0 40000 | 00000000 ! 84240000
/pci@80000000/isa:0:c.0 1106:8231 60100 | 82311106 0000 8
Added assigned-addresses
/pci@80000000/ide: 0:c.1 1106:0571 1018f | 05711106 010e 87
Added assigned-addresses
1006110 0 fe001000 0 8 | 00000001 ! 00001001
1006114 0 fe001008 0 4 | 00000001 ! 00001009
1006118 0 fe001010 0 8 | 00000001 ! 00001011
100611c 0 fe001018 0 4 | 00000001 ! 00001019
1006120 0 fe001020 0 10 | 00000001 ! 00001021
/pci@80000000/usb:0:c.2 1106:3038 c0300 | 30381106 0409 7
Added assigned-addresses
1006220 0 fe001040 0 20 | 00000001 ! 00001041
/pci@80000000/usb:0:c.3 1106:3038 c0300 | 30381106 0409 7
Added assigned-addresses
1006320 0 fe001060 0 20 | 00000001 ! 00001061
/pci@80000000/other: 0:c.4 1106:8235 68000 | 82351106 0009 0
Added assigned-addresses
/pci@80000000/sound: 0:c.5 1106:3058 40100 | 30581106 0309 4
Added assigned-addresses
1006510 0 fe001100 0 100 | 00000001 ! 00001101
1006514 0 fe001030 0 4 | 00000001 ! 00001031
1006518 0 fe001034 0 4 | 00000001 ! 00001035
/pci@80000000/pci1106,3068:0:c.6 1106:3068 78000 | 30681106 0309 30
Added assigned-addresses
/pci@c0000000: i f8000000/10000 mem c0000000/20000000
/pci@c0000000/host: 0:0.0 11ab:6460 60000 | 646011ab 0000 7
Added assigned-addresses
Checking initrd at 0x600000-0x94a2d5 (3449557 bytes)
Found zip with 66 entries
Parsing Kicklayout at 0x94a2d5 (3287 bytes)
Booting config 1: AmigaOS_4.1_Final_Edition
Loading loader.of
Loading kernels
Loading FastFileSystem
Loading SmartFilesystem
Could not find files
Could not load module
Booting failed, exiting.
qemu: Stopped as the VM requested "exit"

the kickstart to copy is zipping
SYS:kickstart ?

Thank you.

@white

Check the contents of your zip for "SmartFilesystem" vs "SmartFileSystem" it looks like you have the exact same error as Maijestro just one reply above yours.

@MartinW

Perfect now it works (2gb ram)
Thank you


BBoot 0.1 (20.7.2023)
/pci@80000000: io fe000000/10000 mem 80000000/40000000
/pci@80000000/host: 0:0.0 11ab:6460 60000 | 646011ab 0000 7
Added assigned-addresses
/pci@80000000/pci126f,501: 0:1.0 126f:0501 38000 | 0501126f 0000 0
Added assigned-addresses, set interrupt 0009
2000810 0 80000000 0 4000000 | 00000000 ! 80000000
2000814 0 84000000 0 200000 | 00000000 ! 84000000
/pci@80000000/pci10ec,8139: 0:2.0 10ec:8139 20000 | 813910ec 0100 0
Fixed ROM BAR
Added assigned-addresses, set interrupt 0109
1001010 0 fe001200 0 100 | 00000001 ! 00001201
2001014 0 84200000 0 100 | 00000000 ! 84200000
2001030 0 84240000 0 40000 | 00000000 ! 84240000
/pci@80000000/isa: 0:c.0 1106:8231 60100 | 82311106 0000 8
Added assigned-addresses
/pci@80000000/ide: 0:c.1 1106:0571 1018f | 05711106 010e 87
Added assigned-addresses
1006110 0 fe001000 0 8 | 00000001 ! 00001001
1006114 0 fe001008 0 4 | 00000001 ! 00001009
1006118 0 fe001010 0 8 | 00000001 ! 00001011
100611c 0 fe001018 0 4 | 00000001 ! 00001019
1006120 0 fe001020 0 10 | 00000001 ! 00001021
/pci@80000000/usb: 0:c.2 1106:3038 c0300 | 30381106 0409 7
Added assigned-addresses
1006220 0 fe001040 0 20 | 00000001 ! 00001041
/pci@80000000/usb: 0:c.3 1106:3038 c0300 | 30381106 0409 7
Added assigned-addresses
1006320 0 fe001060 0 20 | 00000001 ! 00001061
/pci@80000000/other: 0:c.4 1106:8235 68000 | 82351106 0009 0
Added assigned-addresses
/pci@80000000/sound: 0:c.5 1106:3058 40100 | 30581106 0309 4
Added assigned-addresses
1006510 0 fe001100 0 100 | 00000001 ! 00001101
1006514 0 fe001030 0 4 | 00000001 ! 00001031
1006518 0 fe001034 0 4 | 00000001 ! 00001035
/pci@80000000/pci1106,3068: 0:c.6 1106:3068 78000 | 30681106 0309 30
Added assigned-addresses
/pci@c0000000: io f8000000/10000 mem c0000000/20000000
/pci@c0000000/host: 0:0.0 11ab:6460 60000 | 646011ab 0000 7
Added assigned-addresses
Checking initrd at 0x600000-0x94a2d5 (3449557 bytes)
Found zip with 66 entries
Parsing Kicklayout at 0x94a2d5 (3287 bytes)
Booting config 1: AmigaOS_4.1_Final_Edition
Loading loader.of
Loading kernel
Loading FastFileSystem
Loading SmartFilesystem
Loading JXFileSystem
Loading peg2ide.device.kmod
Loading battclock.resource.kmod
Loading bootmenu.kmod
Loading bootimage
Loading CDFileSystem
Loading con-handler.kmod
Loading console.device.kmod
Loading diskboot.kmod
Loading diskboot.config
Loading diskcache.library.kmod
Loading dos.library.kmod
Loading elf.library.kmod
Loading env-handler.kmod
Loading FileSystem.resource.kmod
Loading gadtools.library.kmod
Loading gameport.device.kmod
Loading graphics.library.kmod
Loading hunk.library.kmod
Loading input.device.kmod
Loading intuition.library.kmod
Loading it8212ide.device.kmod
Loading keyboard.device.kmod
Loading keymap.library.kmod
Loading lsi53c8xx.device.kmod
Loading newlib.library.kmod
Loading nonvolatile.library.kmod
Loading nvram.config
Loading ps2.resource.kmod
Loading ram-handler.kmod
Loading ramdrive.device.kmod
Loading ramlib.kmod
Loading shell.kmod
Loading sii0680ide.device.kmod
Loading sii3112ide.device.kmod
Loading sii3114ide.device.kmod
Loading sii3512ide.device.kmod
Loading strap.kmod
Loading timer.device.kmod
Loading PCIGraphics.card
Loading ATIRadeon.chip
Loading 3dfxVoodoo.chip
Loading siliconmotion502.chip
Loading petunia.library.kmod
Loading usbresource.library
Loading usbsys.device
Loading hub.usbfd
Loading bootmouse.usbfd
Loading bootkeyboard.usbfd
Loading massstorage.usbfd
Loading uhci.usbhcd
Loading ohci.usbhcd
Loading ehci.usbhcd
Loading mounter.library
Starting exec

Thanks for that, @balaton

@Maijestro
Quote:I can change it in the next SFS update, but until now that never was a problem since all other bootloaders (classic Amiga, SLB_V2, amigaboot.(ub|of)) are case insensitive.
The only problem might have been using a case-sensitive formatted SFS partition for the kickstart files, but I'm not sure any of the boot-loaders supports that at all.

@joergQuote:

It doesn't really matter either, since it works on real hardware. I just wanted to point it out to you

@joerg
Quote:

More exactly Amiga file systems are usually case insensitive so the bootloader passing a name with a different case would still read the file. There's nothing in the bootloaders to handle this, it's because of the file systems. BBoot cannot read from disk so it reads from a zip instead which is case sensitive but I don't want to add special handling as it may later also read from disk and then reading from a case sensitive file system will be the same.

If you correct this in SFS consider that all other file system modules seem to be using capital S as FileSystem only SFS uses lower case so maybe it was supposed to be corrected by renaming the module but the Kicklayout entry was missed as it still loads that way on case insensitive file systems. It seems the upper case version comes with Enhancer Software so perhaps that should also change Kicklayout when installing the new module.

I've made some changes to Kicklayout parsing to be more tolerant in next version but I don't plan to handle case sensitivity there.

@white
Quote:
Are you sure it's QEMU 8.0.3? That version didn't have -initrd yet I think unless that patch made it in stable without me noticing but it's more likely a typo. All should be testing 8.1 rc release now so we can fix any bugs for the release.

@derfs
If you see no Unknown RTAS token message then it's not using rtas to access nvram but reads it directly. I think I know what might be missing then but does this cause any issue other than the crash log? If not I probably won't fix until QEMU 8.2. The output you get with pegasos2 firmware does not seem meaningful anyway.

@balaton

I'm still double-checking to make sure I've not got something mixed up here. I'm on my linux box now (the one with passthrough). With SM501 everything boots OK using the new bboot. With my 5450 passed through on pci.1,addr3 & addr4 (hdmi sound) I can't boot and I think it's because there's an incorrect address.

BBOOT:


Note the 0x100 byte mapping of 0xfe001300

If i boot the old way and query the properties:



Note: 0xfe001200 (not 0xfe001300) but I'm scratching my head a bit at the moment how this could be coming out wrong for this one instance and correct for everyone else.

I am using latest master Qemu with the original patch MBOX applied on top.

[edit] Actually that's completely different addresses. Let me make sure I'm not getting something mixed up!

Nope, only difference is in the use of bboot:

New (bboot)


Old (bios rom)


I did also try with 2048 memory in case that changed anything but it didn't.

@MartinW
If you use BBoot with -kernel then it will assign addresses instead of the firmware because VOF does not do that so you get similar but not identical results as BBoot's algorithm for allocating addresses is not the same as what the pegasos2 firmware does. The results are similar but there can be differences. I'm not sure what BBoot does is correct but as long as it does not allocate overlapping areas and everything is mapped that should be OK. There's not much info in the partial log you've posted but what looks strange is the 0xff value set for interrupt line. BBoot would set it to 9 if it was 0 but does not touch it if it has another value but I'm not sure how 0xff ended up there.

To check the mapping you can run BBoot with the pegasos2.rom firmware, just loading boot hd:0 bboot without the forth script to load initrd won't boot but still get the numbers about PCI BARs so you can check and debug that way what are the differences when the firmware assigns BARs and when BBoot does it. So you'd need to get two logs:
1. with -bios pegasos2.rom and loading bboot from guest disk and
2. the full log when using -kernel bboot without -bios which is when BBoot is assigning addresses and compare the two to see there are anything that could cause trouble.

Different guest RAM sizes won't change anything as these BARs are mapped in the windows over 2GB, it does not matter what's below that only how the windows are set but QEMU follows what the firmware does in setting the windows for the PCI buses.

@balaton

OK, yes - info pci shows interrupt 0.

I'll investigate.

@balaton

--version gives me this:
qemu-system-ppc --version
QEMU emulator version 8.0.50 (v8.0.0-2725-g887cba855b-dirty)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

@white

Have you done a

And then rebuilt Qemu?

You should be seeing something along these lines:


Note: I have two different directories with two different qemu source clones (one patched, one not) because I'm being lazy with git!

@white
That's some version compiled from some git repository with additional patches, definitely not 8.0.3. You should be on qemu git master or wait for 8.1-rc0 that's already tagged and should be available shortly on QEMU download page too.

@whiteQuote:

You should compile from the Qemu git master source, there have been many changes within Qemu. You can read it above post #983 there were also some optimizations.

This is the source I used:

https://gitlab.com/qemu-project/qemu/-/tree/master

@MartinW

I usually do this:
https://www.qemu.org/download/

git clone https://gitlab.com/qemu-project/qemu.git
cd qemu
git submodule init
git submodule update --recursive
./configure (parameters)
sudo make install -j16

@MartinW
That's probably bcause BBoot should also set interrupt if it's 0xff but don't know why that happens as all other cases I've seen it was 0 but maybe it's related to pass through? If you get the numbers with bboot under pegasos2.rom we can compare what the firmware does vs. what BBoot does. If BBoot changes anything it will log it so you'd see Added assigned-addresses if the property was modified or ! new value on the right if the PCI config reg was written or set interrupt x if the interrupt was changed. I hope you've read the comment in brd_pegasos2.c referred in the README about how to read these numbers but it's possible I could not explain that clearly.