@kas1e
Could you please try this new version on real PegasosII?
http://zero.eik.bme.hu/~balaton/amiga/bboot/bboot-test1.xz
It should fix access to AGP card which was showing with all ff values before which also means that this is probably broken in QEMU now so maybe that's why @MartinW could not get a card work with bus=pci.0 so use the default bus for pci pass through for now.

(This is now a pre-release testing version, nothing new for using on QEMU in it and I plan to add more to this for an actual release so everybody else can ignore this, for them it's identical to last released version but will get all ff on QEMU for pci.0 devices, opposite of what's in real hardware I think but that's what should be tested.)

@Maijestro, @smarkusg
Don't understand what you want to convince @kas1e about. He's been helping a lot so far and I think he uses both emulation and real hadware so no need to take sides or fight about anything or try to convince anybody that one way is better than any other. There's enough space for everybody here I hope so just be cool.

My primary goal for writing BBoot was to avoid the need for the non-free firmware for booting AmigaOS on QEMU but I realised that this could be useful for other things as well, such as allowing using so far unsupported gfx cards either via pass-through with QEMU or via bridges on real hardware or also to just boot faster even on real PegasosII so those are also usages I'm happy to support and glad to see if BBoot is useful beyond its original goal to boot AmigaOS without pegasos2.rom. I still want to keep it simple and small so maybe don't want to put in too many features but its usage is certainly not limited to QEMU and I've considered real hardware usage as well when writing it.

@kas1e, @MartinW

Looking at the log from real PegasosII it looks like board firmware also leaves card at least on AGP bus with all ff values not only for interrupt but also for BARs. I'm not sure how that happens but if this works on real machine then BBoot should also not set these and leave them when they are set to all ff values. Currently in 0.2 these will be set and due to having wrong BAR values it results in 32 bit BARs set to 64 bit which maybe does not cause a problem if AmigaOS driver only needs the assigned-addresses property values and later reprograms the card based on that but I should probably need to fix this in a next version to get closer to real hardware.

To check if other values are the same with pegasos2.rom and bboot+VOF you could try booting with bboot both through bboot.fth with -bios pegasos2.rom (and maybe also running your script first) and without ROM just using -kernel bboot and post both logs and compare the values in those. BBoot prints the assigned-addresses property and other PCI values as it finds them and all chnages it made to them so this should help to find what's different when it works vs. when it doesn't. I think you got this just did not have time to test it but just saying it again to make sure I've explained it clearly enough.

@Maijestro
I plan to update my pegasos2 guide with BBoot instructions, I just haven't got to it yet.

As for QEMU the faster single core performace is the better which may be hard to find in a laptop where energy efficiency is usually more valued than performance. And to have all that not expensive may be difficult. You know the saying: good, cheap, fast - pick two. But maybe some gaming laptop could have good performance but then not cheap or practical as a laptop so maybe you have to live with lower performance but otherwise convenient usage.

@geennaam
Quote:
Nobody knows until somebody tries. Try with qemu 8.1-rc0 or git master without any patches first then if it still has problems we can try patching IRQs. BBoot does not handle IRQs it will just set IRQ 9 for any devices not having an IRQ yet which is what pegasos2.rom seems to do as well but we never understood what exavtly causes the freeze so that's the next thing to debug. BBoot at least provides infos on how the PCI devices are configured at boot and we can compare those with different settings.

@MartinW and @all
Maybe it's easier to test if you don't have to compile it so I've just made a release 0.2 with the changes from today. Apart from now should work with zip created from macOS Finder it will change 0xff interrupts but keep the 64 bit type in the register value so it should replicate what your Forth script did. Let me know if this works better.

@MartinW
No problem, it's not urgent so just let us know when you've found out something. Apart from IRQ I've meant these numbers:

where there are two changes for each bar:
the phys.hi ss field is changed from 3 to 2 (43001810 -> 42001810)
and the reg value is changed accordingly: 9000000c -> 90000008 clearing bit for 64 bit BAR type (see https://wiki.osdev.org/PCI#Base_Address_Registers) and I'm not sure bout this second change is correct. Can somebody tell what should we do here? Changing the first value is needed for the BAR to show up and not get the cannot handle SS == 3 or similar message in AmigaOS but what should the card be programmed for in this case? Should we still program it as 64 bit BAR?

@MartinW
Regarding network, that's not 64bit BAR but ROM BAR fix which is only needed because VOF gets that wrong so it would not happen with pegasos2.rom and therefore not likely to have any effect, also because I don't think AmigaOS uses the ROM (unless the pegasos2.rom runs that ROM which breaks something but you could disable with -device rtl8139,romfile="" and test that). If anything then maybe different IRQ mappings could have an effect but don't think there are differences in that but have to check the numbers to find out.

@MartinW
Maybe your distro has a powerpc compiler and that could work. i only needed to install gcc-powerpc64-linux-gnu and binutils-powerpc64-linux-gnu packages.

To make it change ff to 9 as well that change should be enough howeveer there's also a difference in BAR values written for 64 bit BARs the bit meaning 64bit is cleared and the BAR is programmed as 32bit BAR. I'm not sure if that's correct or we should keep the 64bit value in the PCI register and only clear the bit in the phys.hi number for AmigaOS to see the BAR. You can test this by booting with bboot using the pegasos2.rom (you need to put the zip on the guest disk and edit bboot.fth with the zip size then boot hd:0 bboot.fth. As seen from the log bboot will reprogram the 64 bit BARs as 32bit (what you did from the script before but besides changing the assigned-addresses property also changes the value in the PCI reg). If this now broke it then we likely only have to edit the assigned addresses value and do the same when not using pegasos2.rom. I can make these changes but don't know which one is correct so that's what you should test and tell me which one works. (Or if somebody like Hans has some insight could chime in, I don't know much about graphics cards.)

@white
Don't overwrite anything with anything, that would just mix up these. Either download tar and compile from that or clone git and build from that. You can do those in separate directories but mixing them is a really bad idea.

@smarkusg
It's unlikely to affect network but anything is possible and I can't tell. That's why BBoot prints these verbose numbers so such differences can be debugged. Compare what you get when doing boot hd:0 bboot with pegasos2.rom with what you get when using bboot without pegasos2.rom, and see if there are differences. If the network issue is thought to be related to interrupts then compare how interrupts are configured, this is in the /pci/device line after the | between the device id and command reg value so for example:


the value for interrupt is 0409 above in the first line, that's line 9 pin 4, the 7 is the command register value: bus master, io, mem enabled the values before the | come from the deivce tree so they are less interesting for this. The Added assigned-addresses means that BBoot created the value below, this won't be shown on pegasos2.rom in which case the values shown were made by the firmware. This device only has BAR4 at offset 0x20, last byte of phys.hi that's the first value, these numbers are encoded as per the OF standard for PCI binding. On the right from | is the actual value from config reg 0x20 that was 00000001 before and changed to 00001041 to match the assigned address of fe001040. This is an io bar so last bit is 1 and mapped from 0 in the PCI io space which is visible on host in io win at fe000000.
These numbers convey a lot of info but may take some time for somebody not familiar with these to get all of them but I hope these would help debugging issues with BAR and IRQ assignment now that these could be get with BBoot on QEMU with and without pegasos2.rom and on real hardware as well.

@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.

@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.

@joerg
No you can connect any emulated card to any netdev so just replace virtio-net with rtl8139 just nobody uses anything else than virtio-net when the guest has a driver for that so that's the normal example. What these options do are just send all data to a socket created by the socket_vmnet daemon which will forward it to the macOS virtualisation framework. QEMU can also use that with -netdev vmnet something but then whole QEMU has to run as root and this way only socket_vmnet will need to be root and QEMU can run as normal user.

@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.

@Maijestro
I can't help with Windows but on macOS you could use vmnet instead of tap. I've just found this: https://github.com/lima-vm/socket_vmnet that should also avoid having to run QEMU as root. Don't know how that works, since QEMU only connects to a socket with this you'd have to select vmbet settings within socket_vmnet instead of with QEMU options but it should have a similar setting like vmnet-host that allows the guest to see the host and vice versa.

@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.

@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.

@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.

@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.