@MartinW
Both RedHat and Debian have ppc cross compiler so any distro based on those would also likely have it. Arch only seems to have binutils for ppc, installing that is one prerequisite but gcc has some others then it takes a while to compile. There are some scripts to build a cross compiler that you could seearch for.

Maybe even the compiler included in the AmigaOS SDK should work so if you have that (even on AmigaOS) you could try. Only other tool used is make so that should be available anywhere.

@kas1e
I wanted to ask you to send .properties of that bridge to check its ranges property but you did that above already. What if you cd to /pci/pci and do ls? Does a display device node appear there? Then you can also get .properties of that to see how the firmware sees this. You could get all info from SmartFirmware with dump-all but that's too long to post here, maybe send it to me or upload somewhere. There's also a dump-pciconfig word in SmartFirmware but I don't know what that does but sounds like it can get some info from a card.

BBoot currently only lists devices attached to the internal PCI buses of Pegasos2, it won't go down in bridges. I'll need to change that but don't know yet how to access devices behind the bridge on pegasos2 so I'll also have to read some docs on these bridges. At least now I have the device node for the bridge so I can see if there's some info on this there.

@Maijestro
Quote:

What to check though? If we can't reproduce it and also don't know what's different between the cases when it's fast vs. when it's slow then what should we look for? We would need something to be able to find anything. So you would try to find out what's different between the two cases, if it can be also reproduced with other guest OSes (Linux, MorphOS) or something similar to be able to get an idea what could cause it. Otherwise we can only guess and have to be very lucky to find a problem that way.

AS this seems to be dependent on some changes between boots maybe it's related to memory layout but I still can't find out what could be different. Try at least gather some info from QEMU monitor about the two cases such as info jit info irq and see if there are some differences there or if you can get a memory map or other statisctics from AmigaOS that can be compared then maybe some difference can be identified from those. I can't help with debugging these but I also can't find and fix anyhing in QEMU until the issue is identified a bit more exaclty.

BBoot would change an interrupt which is 0 or ff to 9 but only does that if it also assigned the addresses and won'f fix this for the case when running under pegasos2 firmware. I can change it to do that in that case too. But apart from that it seems we may also have a problem that if the pegaos2 firmware does not set up devices behind a bridge and AmigaOS only looks at devices that are set up by the firmware then it won't see the graphics card connected to the bridge unless BBoot would also do that. Is that the case or does AmigaOS try to drive the bridge and find devices behind it? I think @Hans said something about cards that have such bridge on them and the driver may work with it but maybe it's not the driver version indcluded in AmigaOS so I'm not sure what BBoot would have to do with these bridges. We need more data on what it looks like with current version with BBoot output, AmigaOS debug log and what can be seen in Ranger after boot and also if there's any info what the Driver needs the firmware (or in this case BBoot) to set up for it to be able to use tha card.

@Maijestro
Maybe some updates solved it, I saw this with 4.1FE without updates juat booted from the CD but could be I had some wrong Kickstart module versions mixed in somewhere. At least this isn't a problem for others then.

@m3x
OK makes sense, so we just used something in a config it did not expect to run in which the next version should support now. Then nothing to fix in QEMU (at least for this issue, there are probably more to fix for other problems in QEMU).

@white
Don't know what are you talking about. These are options to the Xorg driver for Linux and have nothing to do with QEMU or AmigaOS nor they would likely have any effect on QEMU even if you enable it in a Linux guest running on an emulated machine. So I don't think these are useful at all.

@Maijestro
Yes, until you find a way to reproduce it it's hard to debug and find anything. Also I'm not sure it's not something in AmigaOS as QEMU should not behave differently between runs so it must be some difference in the guest. Maybe it's related to the order things start which I think is parallel and can be different in each boot but maybe there's some dependency which is not handled.

I've noticed that if I boot AmigaOS and start a new shell before the Dock, SFS showed up and the startup sound finished playing then programs started from the shell will crash (even if I start a new shell) but if I wait for it to fully boot I never had that problem so not sure this isn't something in AmigaOS rather than in QEMU.

@white
Maijestro is on macOS where there's no tap so the commands for Linux don't work. The equivalent on macOS is vmnet-host but that does not work on Linux so won't help you. smarkusg can probably set it up without problem but again how does that help you?
Additionally, if you use tap netowrking then port forward options don't make sense as you can just use the IP of the tap network interface to access the machine. When using tap, instead of port forwarding you have to set up IP addresses and routing propertly to access the guest.

@geennaam
You definitely should not blindly apply patches then report that it does not work without any detail. That does not help to find a problem. So first try with latest BBoot (currently 0.4) describe how you ran it and what's the problem you got and if relevant debug output where there are errors or showing what problem you got.

The freeze might be related to interrupts that aren't yet understood nor fixed any patch yet but @MartinW found that just using the single patch here

[PATCH v5 5/7] hw/isa/vt82c686: Work around missing level sensitive irq in i8259 model

works the best. The rest of that series is already applied on QEMU master so you should not be able to apply those without errors, if you could then you're maybe using wrong QEMU version to begin with but you did not include that info either so can't tell. To apply this one patch get it from the Download mbox link on above page then use "git am" to apply to the QEMU master git tree.

But first maybe try without any patches with QEMU master and give some more details about what you did and what result you got.

@kas1e
The change in firewire memory BAR address is because the PCI bridge memory BAR was mapped before it as you can see from the numbwers. This is OK, it just means the firmware found the bridge first and allocated space for it then went on with the other devices which then moved further up.

All this was done by the pegasos2 firmware, the only change bboot did was the "Truncated 64 bit BAR" and it also printes that it changed 43003010 that the firmware put there to 42003010 but now we don't change the register value which is 8000000c and still has the 64 bit type. This chnage was found to be needed at least for graphics cards to avoid the error about SS==3 because it looks like pegasos2 AmigaOS kernel can't handle 64bit bars but presenting them as 32 bit may work. Otherwise these did not show up in Ranger. You can test that by booting with amigaboot.of instead of bboot and see if the bridge is seen by AmigaOS then.

Now BBoot does not scan devices on PCI bus, only looks at what the firmware found so the firmware found the bridge but did not try to do anything with that. I think AmigaOS can handle some bridges but then you should enable debug logs and check what it says about this bridge. Maybe @Hans can tell more about what bridges should work or if it could work if we add a driver for the bridge in BBoot and enumerate devices from that. So far at least the first step seems to be sone that the brisge shows up in AmigaOS.

So check if booting with amigaboot.of is the same to see if BBoot is needed at all other than getting info from the devices and check in AmigaOS logs (maybe even using kernel.debug) to see if there are any more errors there.

By the way BBoot will skip this PCI part if p is missing from Acrions so if you use Ab instead of the default Apb then it's about the same as booting with amigaboot.of and nothing will change in PCI configs where the only change now is the 64 bit BAR identifier in device tree to avoid the kernel error and make the BAR apprear for AmigaOS.

@Maijestro
I did see that line from @Walkero forwarding what @m3x said somewhere else but it does not give me a clue why such long delay may exist. udelay is not a function of the processor or pegasos2 that QEMU emulates, this is a function that's implemented using some lower level functionality like time base or some clock on pegasos2 and there may be a problem emulating that but I don't know what the udelay the sm502 driver ueses is based on so I can't check if that's emulated correctly. That's why I've asked @m3x above if he knows about any problem in QEMU that I should check.

@joerg
Also pegasos2 follows CHRP which reserves addresses above 2GB for system IO and pegasos2 firmware puts PCI memory at 0x80000000 and I'm not sure nothing has this hard coded so even if we would change that it could break something.

Additinally a different thread here or on other forums talked about that using more than 1GB memory on real machine may not work and that limit comes from either hardware problem or the firmware not configuring memory controller correctly. This would not be fixed even by using BBoot which solves the problem on QEMU where the problem is that only a single memory slot is emulated and the firmware cannot recognise more than 1GB per slot but on real hardware the problem is different.

@kas1e
Try with 0.4, also check README for answers to your question.

@m3x
This is great news. Regarding delay in emulation is there something that can be corrected in QEMU to emulate the machine closer to real hardware? While you probably don't need a delay on QEMU if this issue pointed to a problem with something then it may worth fixing in case it can cause problem for other sofrware. So if you found something out please let me know.

@Hans
Using the original sm502 driver from 4.1 Update 3 as is recommended in the setup guides would also work until a newer driver is avaialeble so why don't you use that?

@kas1e
I've made another bboot release 0.3 which is most interesting for using on real hadware as it fixes the forth script to not require editing (took almost the whole day to figure it out although it should be simple) and adds configurability to make it faster on real hadware and output to screen instead of serial. See README for details under Configueation section.
For use with QEMU there's not much change, It will just less likely to try to program a PCI device if it cannot talk to it to avoid breaking anything otherwise it's pretty much as before, the other new features are not useful on QEMU where it's already configured by default for best usage so no reason to change anything (and there's no way either as QEMU does not support setting options yet).

@hans
There are also some Windows build here:
https://www.emaculation.com/forum/viewtopic.php?t=9028
which are currently older but will likely be updated for QEMU 8.1 when it's released. Unlike the "official" wilnetz builds these are actually from QEMU upstream whereas Weil's build are from a fork so maybe a bit different. Maybe worth trying different builds to see which one runs better on your host. The best is building your own and maybe also rinning it on Linux instead of Windows.

@Maijestro
Are you using own QEMU builds? Is there any options that you use such as extra cflags or lto or something when building that may help @MartinW on the M1 laptop? Although maybe that's just a slower CPU.

@smarkusg
That initial post by @kas1e was written more than a year ago when AmigaOS did not run on QEMU pegaos2 yet (at least not in a usable way) and it does run slower on sam460ex due to some issues in PPC440 emulation. I've found the issues earlier this year when did profiling to try optimising it a bit but did not have time to try to fix it yet. But since then we've made aome progress with pegasos2 which is still not fully there but should be more usable now so it's more the background or view point changing than opinions.

Yes communicating in English with it not being native languege for most people can be difficult so just wanted to clear any misunderstandings.

And for Open Firmware fans "may the Forth be with you".

@kas1e
Hmm, then I'm puzzled how to actually access the AGP port on pegasos2. I think Linux just uses rtas for that, not sure if AmigaOS does the same. The openfirmware.resource in kernel mentions rtas but did not see calls from it so don't know what it actually does. At least one change now that BBoot will not try to write the wrong device (no ! value after ffffffff values) so it should be safer against breaking somehting but I'd still like to find out how this works as that may be the reason why pci.0 did not work with pass through. Any ideas anyone?

@Hans
I think designing a common virtio.library to support the communication method basics that can be shared could be rally helpful. The virtio headers are BSD licensed so such library could also be inder a BSD license and thu free to be used in commercial projects as well but keeping the virtio.library open could help different driver writers to share and improve it together. I've considered writing such library before but did not get very far so I can't help much with it but coming up with a standard shared way for this in a shared library would be useful in my opinion.