What the fastest possible x64 emulation way of OS4 today ?

@balaton
Quote:

Yeah, all tests can be done once bridge arrived. But just for sake of filling gap, for Radeon9250 on real pegasos it's /pci@C0000000 , the /pci@8000000 is for general stuff like fireware, isa, ide, usb, sound and co:

80000000:




C0000000:



Dunno why there 2 displays, but that what each of them show:

That for display@8:



And that for display@8,1:



But anyway all will be inetersting once i get bridge..

@Maijestro
You can get more info from QEMU on what the driver tries to do with -trace enable="ne2000*" then find some docs of RTL8029 and try to make sense of the communication and see if some error can be spotted there. This could be easier if the AmigaOS driver source was available but it could be similar to other open source drivers for this card like that found in some BSD unices. QEMU emulates a generic NE2000 which the the RTL8029 should be compatible with but maybe the Realtek device has some peculiarity that the driver expects but QEMU does not emulate. If we find what is that it might be added to QEMU.

@balaton
Except for onboard ethernet controllers the RTL8139 is the most used PCI ethernet controller on AmigaOS systems, therefore I doubt the problems are something in the AmigaOS driver.
The main difference in the RTL 8029 and 8139 drivers is that AFAIK the 8139 one uses DMA, while the 8029 is PIO-only, which should be much easier to emulate.

@geennaam
To debug the DMA issue further maybe we would need at least this info:
- command line you used to start qemu
- the output you got
- info mtree and info pci output after booting AmigaOS where the errors happen.
I know you've posted these before but never all of them from one run so I have some command lines but don't know which one used when saw the errors (in particular did you have VGA or not x-vga or not, if you still using VGA and x-vga=off then I believe that's an invalid config that can't work because the card ROM can't talk to the VGA part of the card that way). And bacause of the previous ambiguities I don't know if for example vga parts shown in an info mtree output comes from where.

Since x-vga does not work with older Radeons you can't use that so you should try without x-vga but also not adding VGA and see if the driver can init the card. If that does not work then try fixing x-vga so the card's VGA regs show up in the guest. I don't think other way might work. What I think might be happening is that unlike the RadeonHD/RX driver the Radeon driver can't init the card because these cards predate AtomBIOS so there's no other way to do the init than running the card ROM. The card ROM can't run because it may need the VGA regs that x-vga would solve but that needs to be fixed. You were able to get past the ROM by adding VGA device but that results writes to VGA regs go to the emulated VGA card and writes to PCI regs go to the passed through card and if writes to VGA regs are also needed to propetly init the card then this won't work until x-vga is fixed. Fixing that may not be that hard if all it needs to do is to use BAR1 for the io BAR instead of BAR4 so you may try that for testing even if it breaks HD cards then if that works come up with a patch that works with both. Hope this makes sense and I could explain what I think.

@joerg
Also QEMU emulates a lot of systems and all of them can use rtl8139. While it may not be the default and because of that less tested it should work with all other guest OS drivers in Windows, linux and I know people used it with MacOS on qemu-system-ppc too so then it's more likely to either something with AmigaOS driver or with the pegasos2 emulation than the rtl8139 emulation.

@balaton
If the RTL8139 emulation works on all other guest OSes it's probably related to the Pegasos2 emulation, especially DMA related parts since there were some "Failed to initialise Radeon DMA" errors as well. AmigaOS Radeon drivers need DMA (and CCE, and and least some executing the BIOS with a x86 emulator by the firmware), and the RTL8139 driver needs DMA as well.
Like with the gfx drivers the MorphOS RTL8139 driver might have some PIO fallback code if DMA doesn't work, just like the MorphOS gfx drivers do, but the AmigaOS drivers don't.

@balaton

X-vga is always needed when you want to show the bootloader output on the display output of the gfx card. Somehow only DVI works for me on all cards except the voodoo3 which only has vga.

The effect can be seen seen on the uboot output. It shows something like
VGA: 1
VESA: ok

X-vga causes a crash on the Radeon 9250 and Sam460. But the quick and dirty in the qemu source code fixes this. But maybe I have to see what this quirk is meant to fix anyways.

I am nowhere near my computers this weekend so I cannot paste the commandlines and outputs.

@joergQuote:

I think they might be right, since this driver is used extensively under AmigaOs4.1 and has also been tested.

@balaton

The rtl8139 driver under Qemu works fine so far, but I can also confirm that my network crashes from time to time for no apparent reason. The only solution then is not to restart AmigaOs4.1. I have to quit Qemu completely and restart. Which suggests that Qemu or the Pegasos emulation have a problem with the rtl8139 somewhere.

We should investigate this in parallel to the PCI passthrough story probably there is also a connection that the passthrough cards break in connection with the network or AmigaOs4.1 freezes.

I have asked before that we should investigate the problem with rtl8139 driver under Qemu, unfortunately I don't know exactly how we could do that.

@joerg

Iirc at least the RadeonRX depends on the vbios to reset and initialize the card. Atombios is not enough. This was the reason why soft resets don't work.

@MartinW

Your "fixup script" is a static script with hard-coded values that you have stored next to Amigaboot.of?

Or is it something that you enter line by line on the of command prompt?

It’s the first. So I get to the of prompt. Type boot hd:0 5450.of and that executes the script. The last line of the script boots amigaboot.of as you normally would.

Before we all dwell too much on network issues I need to do some more work on it. I noticed I’ve missed off a memory range so I imagine that could mean there’s a clash somewhere. I realised it when the values for RX card were posted earlier and confirmed it on my machine.

Food time right now. I’ll look at it some more after.

@MartinW

Yes there are 4 bars. The fifth memory range is something called "extended ROM" iirc

By no means an observation based on any kind of proof but my feeling is that the freezes are not related specifically to the network card. I just added a working sound configuration to my command line and I couldn't even get past the startup sound before the OS froze. The degbug output on serial didn't give any clue, it just stopped.

I did just make the mistake of moving the order of my command line so that I could easier comment out bits and of course that completely changed all of the memory addresses. Well, I assume "of course" anyway because the display is no longer device 2 it's now device 3 and the memory ranges changed as well.

So I've just reworked all my figures and it's working again. I'm actually typing this from OS4. Which thinking about it, is stupid given it might crash when I click submit!

[edit] It didn't. Obyssey is very slow at updating the screen by the way.

@MartinW

Yeh, JavaScript is slow on Amiga, we need our own JS JIT for PowerPC, I think someone worked on it, its was not as simple, because other part of browser, or something like that.

@MartinW
If you want to make sure a device always have the same address you can add addr property to the -device command line such as -device vfio-pci,addr=2 to make sure it won't change when adding more devices. If you don't specify any address QEMU will pick a free one.

I can't help with debugging the hangs, it's more a problem of how to debug AmigaOS and not much different from debugging a hang on real hardware except that with QEMU you can inspect the machine state from QEMU monitor such as info registers info irq and some other things or even attach a debugger for more detailed analysis but if you don't know what to look for then that's not much help and to know what to look for knowledge about AmigaOS is needed not knowledge about QEMU.

A hang might be related to interrupts not delivered as expected so maybe that's where we need to check it, I hope you're using the latest QEMU version for this, at least 8.0 or even better QEMU master just to make sure we're not debugging a problem that was already fixed. It might also be possible that the network card driver has a bug that does not happen on real hardware because for example there are delays there but the emulated card is much faster so events may happen that trigger a bug not otherwise seen on real machine. Or some registers behave a bit different than the driver expects or whatever, it's impossible to guess without being able to find out what's happening which should point in the direction what could cause the issue. So some help from somebody who can debug such issues on real hardware could help to debug the same on emulated hardware as the debuggging itself is no different.

@derfs

Sorry, didn't realise what the time was!

Try this:



You will still need to enter blind to get to the open firmware input. From there you can copy and paste that all in one go. It should work. If the screen output isn't all in a nice neat display at the end then probably something didn't work.

Obviously adjust (or comment out) the final boot command to suit what you would normally type.

NB: Do note that if you change the order of devices in your qemu command or add / remove any then it's highly likely these numbers WILL change. I got caught out with that earlier when I just thought "I'll move these to the bottom so make them quicker to comment out" and I had to redo all my numbers. I'm starting to get used to the pattern of bits now though so it didn't take long.

Hopefully that goes well. If so, enjoy!

If it works then you can save it to the same place your amigaboot.of is and provided your qemu config doesn't change you can just call that script instead of amigaboot and have it chain the boot for you.

Right, I'm not going to be about much over the weekend. 2 children and 1 adult all with birthdays, but at some point I hope to start to dig into why this thing is unstable because I'm pretty sure either something is still not configured correctly (less face it, quite possible), or there is a resource conflict. What I do know is that it's not limited in any way to the network card.

@MartinW
Or alternatively to using addr you could connect the gfx card to the AGP port/other PCI bus with -device vfio-pci,bus=pci.0 where it is alone as other devices are on bus=pci.1 so it won't change when addding devices to other bus. The memory windows for pci.0 are different so you have to cahnge the numbers once but then they should be stable. Using pci.0 for the gfx card also matches real machine better and may fit larger BARs as you won't share the memory window with other cards.

Could that potentially help with interrupts as well? Looking in Ranger i just noticed that both the GFX and the RTL8139 share the same interrupt details (line, pin and whatever the 3rd one was - the VM has now crashed)

You did mention this a number of replies back. I'm only just getting to trying to look at it.

[EDIT] I'll look more when I can. That doesn't appear to work. OS4 freezes before it's had a chance to draw the dock loading image in the middle of the screen. It's possible I've rushed and got a number wrong. This is where doing it by hand isn't so wise!

@MartinW
I don't know if it would help with interrupts and it's possible something is wrong with interrupts still after trying to fix this in QEMU 8.0. Before that PCI interrupts did not work at all for pegasos2. The firmware configures all PCI devices to use IRQ 9 but don't know what it does for the AGP port or if that's wired up correctly at all. Somebody needs to test this and maybe getting lspci -v and /proc/interrupts contents from a real pegasos2 under Linux and comparing that to emulated machine might help to see if there are any differences.

@kas1e
Can you boot Linux on real pegasos2 and get lspci -v and /proc/interrupts from it?