What the fastest possible x64 emulation way of OS4 today ?

Voodoo 1 and 2 were 3D add-on cards only and need another VGA card, but Voodoo 3/4/5 are complete gfx cards incl. VGA: https://bochs.sourceforge.io/doc/docbook/user/voodoo-notes.html

I've asked what errors you get if you only have ATI 9250 with x-vga=on and no other VGA in the system, I know that does not work but I'd need the errors to find out why as I think that's how it sohuld work and not how you managed to get past it as then it did not work so that may not be a viable work around if the problem is elsewhere.

For RadeonHD/RX cards I was suspecting it's a problem with 64 bit BARs and in that case I'm not sure it can be fixed because the pegasos2 is a 32 bit system so there may not be enough space in the memory map to map these even if the PCI controller may support these (which probably it doesn't as I did not expect it to be needed so maybe the Marvell emulation may also need to be checked for this). The X5000 and sam460 may use newer CPUs that at least have larger virtual address spaces which may be needed.

I doubt that this is the issue. I am able to use a Radeon R9 270x in a an old SAM440ep with just a PCI to PCIe bridge.

A Radeon 9250 works on a real pegasos. So there must be something in the qemu emulation going wrong.

balaton found something already, IO and MMIO using the same code which of course can't work because the AmigaOS driver switches MMIO to big-endian but IO always stays little-endian. The segfault is something unrelated, though.

I'm still looking at sam460 PCIe emulation

@geennaam
For RadeonHD/RX cards I was suspecting it's a problem with 64 bit BARs and in that case I'm not sure it can be fixed because the pegasos2 is a 32 bit system so there may not be enough space in the memory map to map these even if the PCI controller may support these (which probably it doesn't as I did not expect it to be needed so maybe the Marvell emulation may also need to be checked for this). The X5000 and sam460 may use newer CPUs that at least have larger virtual address spaces which may be needed.

But @kas1e said this somehow works on microA1 which is similar to pegasos2 so maybe it's possible but I've found no info on that so I don't know how that's done. Maybe Hans can fix this in his Radeon drivers and already works on it. If it turns out there's some issue in the pegasos2 emulation I can look at that if somebody finds out what's needed.

Yes I think I meant ub2lb/parthenope when I said AROS bootloader. But doesn't that just load amigaboot file and launches it? Does it replicate what amigaboot does and loads the kernel modules itself? I've looked at the source but it's not very clear.

The Open Firmware part is clear to me. I tested amigaboot.of with the minimal open firmware in QEMU and know what it misses to run and what OF client interface functions it uses but I don't know what it does with the data it retrieves from OF. That is what kind of structure should it build from the OF device tree and how should it pass to the kernel. So I'd need more info on that part, all the others I don't care about.

The different versions are probably just to talk to the different firmwares in these machines. There are at least 3 kinds of firmware interfaces so there are that many boot loader versions but these likely only differ in the firmware side which I know for OF, I only need info on the kernel facing side that makes the module list in memory and prepares the info about the machine and starts the kernel. I'd look for info, docs or hints on that, the rest I can handle.

OK then maybe there are only two versions, one for OF and one for U-Boot wuth the U-Boot part already open source but that's not too interesting.

I'd need the interface between amigaboot.of and loader.of and to know what structures in memory loader.of needs and where to pass them. The rest is just firmware dependent or trivial.

Yes this is the part that would be interesting if it was documented in a bit more detail.

quiesce is the OF client interface word for closing down and stop using firmware services after boot so it's not just how Linux calls it. The OF client interface is well documented in its standard.

I'm not sure about that part, I think I'm still missing the structs and calling convention of loader.of to be able to reimplement amigaboot.of.

Since yaboot probably can't load AmigaOS I don't think it would help much.

geennaam wrote:@balaton
Quote:

I'm still looking at sam460 PCIe emulation

Yes, I agree. This is the only way forward.

64-bit PCI cards are backward compatible. I first started using them in an A1-XE, which is of the same era as the Pegasos-II. All the firmware has to do is treat it as a 32-bit card (ignore the 64-bit addressing bit, and set the upper 32-bits to 0).

The A1-XE clearly did this, because the resource ranges are present. What's uncertain here, is whether it's the Pegasos II firmware that's at fault, or the vfio passthrough. We'd need to somehow check how those BARs behave when they're read & written.

Fixing this from the drivers isn't realistic. The OS reports that BAR0 & BAR2 don't exist. I could directly read the BARs from their PCI configuration registers, but then I'd have to somehow find and claim an empty space within the 32-bit address space to put it in.

The firmware is supposed to allocate address space. If it doesn't, then the bootloader would be the next appropriate place to do so.

Maybe this could be debugged by checking what the firmware has about the card in the device tree. I've asked for .properties output before in post #417 but I haven't seen a result posted.

reg                   2:0
                      xp2,0,10,0:10000000
                      xp2,0,18,0:200000
                      i2,0,20,0:100
                      m2,0,24,0:40000
                      m2,0,30,0:20000
assigned-addresses    xp2,0,10,90000000:10000000
                      xp2,0,18,80200000:200000
                      i2,0,20,FE001200:100
                      m2,0,24,80080000:40000
                      m2,0,30,80020000:20000

Will this kind of information of any help, if i will buy some agp-pcie bridge and put real radeonhd into real pegasos2 ?

otherwise I'd expect to get the same results as with QEMU above

Just guessing here. But I think that this would be the os4 kernel itself.