Who's Online |
10 user(s) are online ( 7 user(s) are browsing Forums)
Members: 0
Guests: 10
more...
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/28 11:45
#41
|
Quite a regular 
|
@afxgroup
OK if this laptop has both integrated and discrete graphics then you can pass through just the radeon chip but there may be issues:
- How are these connected? Normally both of these GPUs would drive the internal screen but the firmware or OS would switch between them. So it could be that when the Radeon chip is not used the integrated GPU is connected so you won't see the output of the Radeon chip. Is there a way to configure it to drive the display connector while the integrated GPU drives the laptop screen? If not you may need to enable discrete GPU so it's connected to the screen but not use it from the host and pass it through to the guest. I don't know how to do all that but maybe there are some tools or Linux settings to control the discrete GPU in such machines. I think the doc I've found was using a laptop with integrated Radeon GPU that it passed through to the guest so this problem with which display it's connected to was not a question in that case.
- The AmigaOS driver may need the BIOS but a GPU in a laptop might not have it's own BIOS as it could be part of the system firmware. I don't know what to do in that case. You could pass a ROM image with romfile property but it can't be any random ROM but something that matches the settings for the internal GPU (otherwise you may break it if it tries to program with wrong values not suitable for the chip; I don't think it allows to overdrive and permanently break the chip but likely won't work with just any ROM from a similar graphics card but it has to match the memory and clock settings of the internal chip). If the internal card has it's own BIOS ROM then maybe it's enough to add rombar=1 and maybe run QEMU as root.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/28 11:35
#42
|
Quite a regular
|
@Hans
And Nikitas's benchmark results above say "RadeonRX.chip 2.12" so maybe an update is needed for it to work with pci.1. I don't know it that would help but at least we have an explanation for the error we get now and a possible fix to try. Which update includes v2.16 RX driver?
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/28 9:34
#43
|
Quite a regular
|
@nikitas OK, thanks for testing. It at least fixes the IRQ problem so you don't have to disable it. This helps but that's not all of the problems. Also now pci.0 should be the same as pci.1 because I've asked to test with pci.1 to check IRQ problems. (Unless the driver does something different for PCI and AGP in which case using pci.1 might still be better but the issue with the driver would need to be fixed for that. I can't do that so @Hans will need to check if your driver version is already fixed or this is another case that needs a fix.) Quote: Along with the latest patch you've published, should I also apply the previous two patches you posted on this thread and recompile? You can try that, these patches change different things. The first 3 patch series change AltiVec to use 128bit instead of 64bit so it may help with VRAM access with the default G4 but not with -cpu 750fx (or whatever is a good g3 CPU now). The other dcbz patch might help a bit with the same VRAM access but also with G3 cpu but I'll make a new version of that trying to improve it a bit but had no time for that yet. For now you can try these patches and see if they make a difference.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/28 9:25
#44
|
Quite a regular
|
@afxgroup
OK, just wanted to make sure there're no issues with the host. If you could cpmpile QEMU on it it should work. My second guess would have been memory as I've only seen that error when problem with memory happened but you've already found that too.
As for x-vga=on I don't know if it's needed or not, I think @nikitas got it working without it too but if it's needed maybe something is using that on the host. If you still see anything on screen from the host then the GPU is not isolated completely. The host should not use the GPU at all which might not be simple to do on a laptop. On a desktop machine you'd pass through a secondary card while the host is using either the embedded graphics or another card. Also you may need to check vfio groups and if the GPU can be passed on its own or there are other devices in the same group that may need to be passed through as well. I think you should check docs on vfio pass through and test with a Linux guest to see if it works before trying AmigaOS.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2024/6/28 9:17
#45
|
Quite a regular
|
@smarkusg Quote: You can also use qmiga.codeberg.page as a shorter way to access this page. Quote: -drive if=none,id=hd,file=amigahd.img,format=raw -device ide-hd,drive=hd,bus=ide.0 This also works but not necessary when using -drive media=disk as above. Older QEMU versions did not support that for sam460ex so you had to use this longer -drive if=none + -device ide-hd syntax but since QEMU 9.0 sam460ex can also use -cdrom and -drive media= forms so these can be shortened that way. Quote: I can't remember exactly, but I have this syntax (you can skip it if you don't need it)
-boot order=c,menu=on This wont work with any AmigaNG emulation and will be ignored. On other machines where this works it needs firmware support that none of the AmigaNG machines have so this option will do nothing. Boot order is set from firmware (but you can't save it lacking NVRAM) and the boot priority setting of the sys volumes found like on real machine.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2024/6/28 9:09
#46
|
Quite a regular
|
@Redlion
Hello and welcome. If you read the BBoot README it says it supports amigaone and pegasos2. BBoot does not work with sam460ex but QEMU includes the sam460ex firmware so you should be able to boot from that without needing bboot.
To boot from HD just remove the -cdrom option. This command should work:
qemu-system-ppc -machine sam460ex -rtc base=localtime -serial stdio -drive media=disk,format=raw,file=amigahd.img
(You don't even need the -vga none -device sm501 for sam460ex as it already has an sm501 on-board. Usually the simplest command that works is the best. Only add more options if you know they are needed.)
Then if you need the CD you can attach it from QEMU monitor as was discussed above using the change comnmand. If you want to boot from HD while a CD is attached then you may need to set the boot priority of the HD boot volume higher than the CD's boot priority. But I don't know what value the CD uses and what's a good value for the HD. This is just the same as on real machine.
Edited by balaton on 2024/6/28 11:30:01
Edited by balaton on 2024/6/28 11:30:31
|
|
|
|
|
|
Re: A1222Plus has a new home
|
Posted on: 2024/6/28 8:55
#47
|
Quite a regular
|
@eliyahu Quote: Actually I'm not authorized to distribute any firmware from A-EON, so I need to just remove the link. Have you checked the license? I think U-Boot is under GPL which means you can redistribute it as long as you pass on everything you got so if it's an unmodified package you can redistribute it. If you made modifications you also need to include the source for those changes. A-EON is bound by the same license using U-Boot and cannot change it to not allow redistribution. If they distribute modified U-Boot they also need to publish source and keep U-Boot free. (Free means free to redistribute and change it not that it must be free of charge.)
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/27 22:40
#48
|
Quite a regular
|
@nikitas Quote: What in the world could be happening with my machine... Every power management is disabled in UEFI. And I followed instructions to disable every PCIe power management on Ubuntu 24.04. I'll investigate further though. One thing is to disable power management on the host and then another to configure the guest to also not try to use it. I'm only guessing but maybe it is a problem trying to use PCI power management on a PCIe card. We're passing through the PCIe card as PCI so the guest may not be able to access all features. Or if the guest tries to use PM while it's disabled on the host that may cause issue. So either set the guest to also not use PM or allow it on host? Quote: In the worst case, I will keep the cards and I'll throw the PC into the sea. I might get one with a Ryzen CPU.
I would like to advise me if you know what mobos + CPUs combinations serve best QEMU/KVM, QEMU PPC, and virtualization in general. I don't know, I don't have much experience with vfio pass through. Generally for these AmigaNG virtual machines the faster a single core is the better and Intel CPUs used to be better in that while AMD may have more but slower cores but QEMU will only use 1-3 cores and only one to emulate guest CPU (it can do one thread per vcpu but AmigaOS only runs on a single CPU core and these machines are single CPU anyway, hence having one fast CPU core is better than having lots of slower ones). For vfio you'd have to read on the net. It can depend on a lot of things including motherboard and firmware so maybe some boards are better than the others but I don't know which might those be. It may depend more on firmware quality than Intel vs. AMD. Also may check if your host machine's firmware is the latest in case some bugs were fixed.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/27 22:24
#49
|
Quite a regular
|
@afxgroup Quote:
Invalid write at addr 0xFE000080, size 1, region '(null)', reason: rejected
Invalid write at addr 0x80, size 1, region '(null)', reason: rejected
These should not cause any issue. This port is either used for debugging or some drivers may use it for small delays so accessing it may be normal. As this was seen regardless of the graphics card it may not even be related to it. Quote:
invalid eieio using bit 6 at @fff063dc
Entering IKARUS low level console
This should not happen. It either means that your pegasos2.rom is somehow corrupted or is a version not supported or your host machine has some issues so maybe run memtest on the host and some stress test such as compiling a Linux kernel to make sure the machine works OK. Which version of pegasos2.rom do you have and if you have extracted it from an updater does it match if you get the updater again end extract it again to make sure it's not corrupted?
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/27 14:01
#50
|
Quite a regular
|
@nikitas
In any case si_dpm_init and radeon_pm_init in the Linux backtrace as well as the line before the Oops talking about fan control suggests it's some issue with power management of the card. Hans also suspeted the card may be running at lower clocks that could also be because of missing power management so maybe that's where we should look. Is there a way to disable power management in Linux and set the card to run at some fixed value? Also may meed some options to Linux guest to make it skip power management for this card but I don't know what are those options or if they exist.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/27 13:35
#51
|
Quite a regular
|
@nikitas Quote: I found this:
Quote:"A workaround is available in qemu, by adding the parameter "x-igd-gms=1" to the according IGD device line."
So it could be?
x-vga=on,x-idg-gms=1
I don't know what that is but IGD is Intel integrated graphics so this would do nothing for a Radeon device. With a laptop it might be difficult to configure pass through as the Radeon device should be removed from host and configured to load no host drivers only vfio so I don't know if that was done correctly. Getting some more logs or trying with a Linux guest that can give more diagnostics could help to debug it. Quote: You also use:
-display sdl,gl=on
I don't think you need this at all. It should not hurt either as this just sets the grapchics backend QEMU uses. But since you have no window to display (guest should use the passed through card) it also does not matter. Quote: For more debugging output you can add:
-d guest_errors,unimp
For getting logs from the guest, I think you can add:
-append "os4_commandline serial debuglevel=3"
You don't need os4_commandline in -append. That's the variable name when you set it from pegasos2.rom but for -append it only needs the values as the kernel command line is the only variable -append can set. So it's just -append 'serial debuglevel=7' You can experiment with different debug levels but too high won't boot so maybe up to 12-13 still works but less may be enough. Running with -d unimp,guest_errors is useful if it crashes otherwise it might not print an error. I don't know what your Linux kernel Oops means but at least it has some stack trace to some code that could show what operations it tried to do so could give some idea about the problem but have to check the kernel code to find out. This is why testing with Linux might help because with AmigaOS we don't know what it does and we can't get much info from the errors so those might only help if @Hans can find out what's wrong based on those. With Linux guest we have more insight what it does.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/27 13:23
#52
|
Quite a regular
|
@all Can you test this QEMU patch This should fix interrupts on pci.0 while it should make no difference for pci.1 so only could iprove things when using pci.0 and should not break things when using pci.1 (or no bus=pci.0 option as default for pegasos2 is pci.1). You should be able to apply to QEMU git master with git am command.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/26 12:32
#53
|
Quite a regular
|
@nikitas Quote: It starts getting very funny. I attached the Radeon R7 240:
- It doesn't work at all with bboot v.07. It works with pegasos.rom. That suggests that unlike the RX driver the HD driver does not init the card from AtomBIOS or this card does not have suitable BIOS so it needs its ROM to be run by the BIOS emulator in firmware. BBoot does not have a BIOS emulator so it won't run the card BIOS. AmigaOS has a BIOS emulator resource but only the Classic kernel invokes it so won't work even if added to pegasos2. So the only way is to use pegasos2.rom to get the card BIOS executed. However the pegasos2.rom and pegasos2 AmigaOS kernel don't properly init interrupts on pegasos2 so you also need to use BBoot from the firmware to fix that up. That is you need to use both pegasos2.rom and BBoot. To do that copy bboot, bboot.fth and Kickstart.zip to your boot volume where amigaboot.of is and from the pegasos2.rom ok prompt do 'boot hd:0 bboot.fth' (assuming hd:0 is your boot volume, otherwise change this in bboot.fth too). Then this should fix the interrupt settings after the firmware ran the card's BIOS. Quote: - The RadeonRX 550 refused to be attached to pci.1 and works only on pci.0. But in AOS4, Ranger reports that it is attached on bus 0x01. Don't care about those numbers. QEMU numbers them as the chip has it but on pegasos2 these are used in the opposite order (because on real chip pci.0 is 66MHz and used for the AGP port and pci.1 is 33MHz and used for PCI) and AmigaOS numbers them that way but this does not matter it's still the same bus just numbered differently. Quote: - Now, the Radeon 7 240 refuses to work on pci.0 slot and works only on pci.1. But in AOS4, Ranger reports that it is attached on bus 0x00(!) I don't know why unless you tell what does refuse to work mean. Any errors? Maybe it needs the missing interrupt. The firmware should init a GPU in the AGP port too so running the BIOS should not be a problem. Quote: Despite being inferior to RadeonRX 550, Radeon R7 240 performs much better(!) but still very slow. Any numbers on that so we can compare to the RX benchmark results?
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/26 10:21
#54
|
Quite a regular
|
@Hans Quote: The driver is getting into an infinite loop while going up the PCI bridge chain. It only does that, because some motherboard firmware doesn't set up the PCI bridges properly. Is this because you get a PCIe card on a PCI bus without a bridge? Or what is the proper setup of the bridge? BBoot does not do anything with the bridge and pegasos2.rom might not be able to do it as the bridge/host device 0 on the PCI bus is just a dummy device with most functions not implemented so if the driver looks for some setting it might not be stored. So what does the driver expect to avoid this loop and why this does not happen on real PegasosII? Maybe in this case we really don't have a bridge as the PCIe card is just connected as PCI and there is no PCI to PCIe bridge in the guest. The host has a CPU to PCIe bridge so that can't be passed through either. Do we need to emulate some dummy bridge device (but bridges did not work on real machine so I'm not sure that would work) or can the driver be changed to avoid this problem? Also why this does not happen with pci.0? Is that because AmigaOS thinks that's a PCIe bus or because there are no other devices on that bus?
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/26 10:14
#55
|
Quite a regular
|
@nikitas
I think I now understand the issues. With pci.1 it might work but there's the issue with the driver getting stuck trying to find a bridge. With pci.0 the interrupts from that bus are not corrected so it will not get interrupts and only works with interrupts disabled. I don't know if that causes it to be slow but could be. I'll need to find a way to connect the interrupts of pci.0 in QEMU. On real machine INTA and INTB are connected from the AGP port, C and D are ignored. In QEMU only the pci.1 bus is connected. With pci.1 are there any logs before the repeating lines? You can redirect it to a file like -serial stdio >output.txt 2>&1 then you see the beginning that scrolls out with the repeating lines. Maybe that has more info for @Hans to see why this happens.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2024/6/25 21:41
#56
|
Quite a regular
|
@white
You're connecting the HD to ide.1 so it replaces the CD drive. remove bus=ide.1 from the end of your command then it should work.
By the way you can replace:
-drive if=none,id=hd,file=C:\Users\lowlevel \Desktop\Pegasos2-VM\ONE-32gb.raw,format=raw -device ide-hd,drive=hd
with just
-drive media=disk,format=raw,file=C:\Users\lowlevel \Desktop\Pegasos2-VM\ONE-32gb.raw
with media=disk it will create the ide-hd so no need for a separate -device option (while -drive if=none only defines the drive that you then need to attach to a device).
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/25 20:28
#57
|
Quite a regular
|
@nikitas
Does the Invalid write at addr 0xFE000080 / 0x80 show up with bus=pci.0 as well or only with pci.1? It's probably not related if it shows in both case. If the GPU is busy then something is talking to it. Do you get any logs from the driver with debug kernel and -append 'serial debuglevel=<whatever is a good number here for RX driver>' or setting os4_commandline when using the pegasos2.rom. Where does romfile=vbios-ati.rom in your command come from? Is this a dump of the actual rom of the card or does it match the card? Why do you need it at all? If it can't find the rom without that isn't rombar=1 enough? Why do you need to specify PCI IDs on the command? Aren't they found from the card?
In any case it does not seem to be a problem with PCI window size, the BARs were mapped in the bboot output at 80000000/90000000 so there's enough room for pci.1 too. How did you get unmapped BARs in 'info pci' then? Did something unmap it later (e.g. the driver failing to init the card but then why we don't get logs of that with higher debuglevel)?
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2024/6/25 20:12
#58
|
Quite a regular
|
@white
What does 'info block' show?
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2024/6/25 19:08
#59
|
Quite a regular
|
@white
There are only two parameters for change command you could get wrong. The drive name which should be ide1-cd0 unless you added a -cdrom or -device ide-cd option. For ide-cd it would probably be the id you specified and don't know about -cdrom but you can check with 'info block'. I said remove all -cdrom and -device ide-cd (and correspoinding -drive if=none) options from QEMU command so you'd only have ide1-cd0 then connected as secondary master. (You can see 'info qtree' and see the drive property of the CD drive on the ide bus.) Then the next parameter is the iso file path which should be just the name of the file if it's in the dir where you started QEMU in (the directory in the window you issued the QEMU command from) or should have a correct path but don't know what path format Windows needs. On Linux it's just /home/user/dir/file.iso or similar on Windows it may need \ or drive letter or /c/ and / between dirs. I guess you could search 'qemu monitor change windows' or something like that to find some docs.
If you start QEMU from C:\Users\lowlevel\Desktop\Pegasos2-VM\ then it might be something like
change ide1-cd0 AmigaOneInstallCD-53.54.iso
make sure you have no -cdrom or -device ide-cd in the QEMU command line.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/25 18:58
#60
|
Quite a regular
|
@nikitas I got that it does not work with pci.1 but asked for logs to try to find out why. My guess is maybe this card has a lot of memory and there's not enough free space to map it in the pci.1 window while pci.0 may have more space and no other devices use that up. But it's just a guess without seeing the logs that show what happens. I think all devices generating interrupts on pci.1 should work but I'm not sure interrupts from both pci.1 and pci.0 can't conflict somehow so that's why I want to fix it on pci.1 to see if it may work better or with interrupts enabled that way. Yes, using input-linux,evdev should also work, then you can drop bochs-display. I didn't know about it (QEMU has a lot of features so I don't know much of it) but here is the doeumentation from the time it was added. Maybe it's also in the main docs and in some other guides. The difference is that usb-host passes through the USB device to the guest and the guest driver will drive it so the host should not access it while input-linux keeps the devices driven by the host drivers just can grab and redirect keyboard/mouse events to the guest. So then you don't need a window to do that hence no bochs-display is needed. It only works on Linux host though but so is vfio pass through where this may be needed.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
