Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
33 user(s) are online (14 user(s) are browsing Forums)

Members: 0
Guests: 33

more...

Support us!

Headlines

Forum Index


Board index » All Posts




Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


@Sailor
Are you aware if OF can boot from ext2fs ? Seems that not ? At least, by simple "ls hd:5" in OF it show nothing and when i tried to "boot hd:5 boot/vmlinuz root=/dev/sda6" as noted at the end of installation process i have "no such file/abort", while if i boot into morphos and mount this partition, i can see there are directory boot and vmlinuz in.

I then tried to copy manually under morphos whole "boot" directory from ext2fs to my "BOOT" (ffs) partition, and then: "boot hd:0 boot/vmlinuz root=/dev/sda6" and while kernel loads, i do have on serial words:

Quote:

Linux/PPC 3.16.0

arch: exit

Have fun!


It then simple stuck forever on the "returning from prom_init" when about to change screenmode and init video card or something (i am on radeon9250 for now).

So i think something still wrong with my installation, but i were under impression that ext2fs should be readable under OF ? Or maybe for OF issue is that i made my ext2df of 30 GB of size and it fails to init and should be small one ?

At moment didn't find any normal doc in google where will be explained how to install debian on peg2 together with os4/morphos on it , where to put kernels, and why installation procedure didn't handle all this .. Maybe you aware of some tips and tricks about ?

Probably the way i copy manually "boot" directory from ext2ds to my BOOT(ffs) partition is the way to go, but maybe some bits need to be changed somewhere in fstab or so to make it all works after manual changes.. Installation process is surely ends succefully (as i have all those words "done, you can remove CD and reboot, etc). Just they by some reassons says that i should boot vmlinuz from hd:5 , but this one surely didn't visibly from OF.

Thanks!

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@balaton

There is no offset cpu load from within qemu. Everything was just slower.
I have captured the result of the slowdown as gfxbench2d result before I removed that emulated Usb drive earlier today.
https://ftp.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2772

Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@geennaam
Quote:
It did not affect the speed of the GPU directly. It affected the speed of the cpu. And therefore the speed of resizing windows and scrolling. So the speed of the system in general. Once deactivated the system came alive.

But this is no different on a real system. The GPU performance is also there limited by the performance of the cpu.

Is there a way to measure that? If adding a USB drive slows down the CPU even if it's idle then there's some problem somewhere. Unless you use that device why should it take CPU cycles just to have it mounted? If there's some way to show or measure this CPU slow down with the usb-storage then maybe we could find out what causes the slow down by profiling that to show where it slows down.

Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@geennaam
Quote:
I need a "second screen" as access to the passtrough card. So when I click on the uninitialized vga window, I can take control of the mouse pointer in Amigaos4. So when I move my Linux mouse over that vga window then I can move the mouse in amigaos. As a consequence or needs to be full screen as well.

I remember something about that now (it's somewhere in the other thread this was discussed before but I forgot most of that by now). Also back then I said take something other than VGA because VGA has some legacy registers so only one VGA card can be in a machine without clashing and adding a -device VGA shadows the VGA registers of the passed through card. This may cause problems initialising it and getting picture on it from firmware so just to make sure to avoid that add some other card that does not have VGA such as bochs-display or sm501 or I think that's what secondary-vga in QEMU is for. Or just pass through a USB card too with a keyboard and mouse connected or those USB devices themselves with usb-host (but that then needs a separate keyboard and mouse for the guest).
Quote:
I also need it to enter the " /failsafe" io.

If you get picture withot -device VGA on the passed through card then at least for output not but for keyboard and mouse maybe still needed.
Quote:
I vaguely remember that PCI bus 1 did cause issues. Therefore I use 0. But maybe you can skip that now with all improvements due to bboot.

Maybe we tried that to avoid interrupts from other devices to clash but that should be resolved now but I'm not sure interrupts from different PCI buses won't interfere. Devices on the default pci.1 bus were now debugged and should be handled but I don't know what happens if two PCI buses drive the same interrupt inputs. So maybe better to just use the default bus unless there are problems with that.

Go to top


Re: Qemu Pegasos II interrupts issue
Just can't stay away
Just can't stay away


@geennaam

Quote:
geennaam wrote:Anyways, it works. So if someone is really dedicated to qemu then he could buy a mobo with two x16 slots and a Ryzen 7800X3D and enjoy a fast system.


I would have loved to see it in action, but as I mentioned it is absolutely stunning and could be an alternative to real hardware which is unfortunately a bit expensive and not very available.

This is not to say that the x5000 is a bad machine, on the contrary it is a really good NG hardware for AmigaOs4.1 probably the best at the moment.

Setting it up is probably the biggest problem at the moment and is really only for power users. But you have shown that with the right components Qemu is able to use this hardware natively.

So I still hope for Hans' solution to use AmigaOs4.1 accelerated under Qemu with the help of Vitio 3d.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


Anyways, it works. So if someone is really dedicated to qemu then he could buy a mobo with two x16 slots and a Ryzen 7800X3D and enjoy a fast system.

Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@balaton

It did not affect the speed of the GPU directly. It affected the speed of the cpu. And therefore the speed of resizing windows and scrolling. So the speed of the system in general. Once deactivated the system came alive.

But this is no different on a real system. The GPU performance is also there limited by the performance of the cpu.

Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@balaton

I need a "second screen" as access to the passtrough card. So when I click on the uninitialized vga window, I can take control of the mouse pointer in Amigaos4. So when I move my Linux mouse over that vga window then I can move the mouse in amigaos. As a consequence or needs to be full screen as well.

I also need it to enter the " /failsafe" io.

Otherwise I don't know how to return to the of prompt and switch from Linux to the pass-through environment once amigaos is booted

I vaguely remember that PCI bus 1 did cause issues. Therefore I use 0. But maybe you can skip that now with all improvements due to bboot.

Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@Maijestro
First of all you'd need to run Linux on your Mac because vfio is only supported on Linux. (All the search results about macOS and vfio talk about running macOS as a VM on Linux and passing through a GPU to it so I don't know if macOS supports PCI pass through and QEMU can use that.) Then it may or may not work depending on how the bridge is handled through Thunderbolt if Linux recognises that at all, although if anything then Linux has the highest chance to work with such things but on Mac hardware it may be different. This is probably more for people who run Linux on a desktop machine and run QEMU on that. For people running QEMU on some other OS the virtio-gpu driver may be an easier way.

Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@geennaam
Quote:
It was just an observation that the system became sluggish with the emulated USB drive as described here in the FAQ: http://zero.eik.bme.hu/~balaton/qemu/amiga/index.html

This can be caused by the fact that the shared drawer and ubuntu itself are installed on an old mechanical HDD.

But if you don't copy anything to or from that disk then it should not affect the general speed of a GPU unless there's something happening in the background that accesses that disk or the USB somehow interferes with the gfx card. So I still don't see how this USB drive can have an effect on gfx card speed and finding that out could uncover some problem.

Also even if it's the same as with real machine, understanding what causes the 100% CPU might help avoding or improving that which might also help real machines with slow CPU but fast GPU. So debugging those things might bring some improvement.

Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@geennaam
Thanks for the details, that should help those who want to further experiment with it. No need to write a tutorial, somebody else could do that, now they should at least have the info needed for starting with it.

Quote:
When I connect my RX560 instead then QEMU fails to start with that error message described above. Apparently this has something to do with a bad reset of the RX card. Or at least that is what you said a year ago.

I don't remember that any more but this reminds me there are some quirks in Linux kernel for some cards that don't like to be reset where the card may need to be added and the Linux kernel recompiled but I don't remember more than that. Maybe it's an issue with the BIOS emulator in SmartFirmware not able to fully run the card's ROM or something so either avoid resetting the card after the host booted to keep it in the state the host's firmware put it (which may need tweaks in the host's kernel) or try using different emulated machine like amigaone which might have different BIOS emulator version. (I mean those who are interested can try, not specifically you if you don't want to experiment with it any more.)

Quote:
qemu-system-ppc -machine pegasos2 -rtc base=localtime -serial stdio -vga none -device VGA,romfile="" -drive media=disk,format=raw,file=hd.img -m 1024M -bios pegasos2.rom -device es1370,addr=0x08 -device rtl8139,addr=0x09,netdev=nic -netdev user,id=nic,hostname=pegasos-os4 -device vfio-pci,host=02:00.0,bus=pci.0,x-vga=on -device vfio-pci,host=02:00.1,bus=pci.0 -accel tcg


If you have x-vga=on you might not need -device VGA as that would result in two VGA cards mapped to the VGA registers so maybe that's why you don't get picture in SmartFirmware? Just -vga none should be enough but I'm not sure. You also may not need es1378 as the on-board via-ac97 should work and probably the addr properties are unneeded as well.
Quote:
Using bus=pci.0 makes sure that the card gets connected on the virtual AGP bus for the pegasos2.

I'm not sure that helps as that PCI bus wasn't tested too much so maybe it works better without specifying bus and have everything on the default PCI bus. I'm not sure that IRQs from two buses won't collide somehow, those on the single default bus should work now. Unless AmigaOS needs the GPU to be on the other bus for some reason.

Go to top


Re: Qemu Pegasos II interrupts issue
Just can't stay away
Just can't stay away


@geennaam

Quote:

It also depends on if you can isolate the adapter in your iommu tree. You have to pass through everything in a group otherwise it will not work.
And I don't expect that a PCIe port behind some thunderbolt controller will work


Thanks for the information, I probably wouldn't be able to set up such an elaborate setup.

Still, it's impressive that you've managed it. Thanks a lot

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: Qemu Pegasos II interrupts issue
Just popping in
Just popping in


@joergQuote:
joerg wrote:@balaton

One of the best tools for checking CPU usage on AmigaOS4 should be Tequila (source), because a few parts of it are based on my 20 years old "top" tool


Btw, how much overhead does the tool itself cause if it relies on quite big number of (soft) interrupts per second (default: docs say 5000, source says 999). How expensive are (soft) interrupts in AOS4? Maybe not quite as much as task switches (in case they don't need to save fpu state) - you were talking about how much speed up there is in filesystems if one avoids AOS3 style app task <-> filesystem task switches.

Also the version history in the readme says "Use Forbid() instead of Disable() when reading task lists" which is wrong/bug.

Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@Maijestro

It also depends on if you can isolate the adapter in your iommu tree. You have to pass through everything in a group otherwise it will not work.
And I don't expect that a PCIe port behind some thunderbolt controller will work


Here's my iommu tree. you can clearly see that the R9 270x is in it's own iommu group ( group 9)
IOMMU Group 0:
    
00:00.0 Host bridge [0600]: Intel Corporation Comet Lake-S 6c Host Bridge/DRAM Controller [8086:9b53] (rev 05)
IOMMU Group 1:
    
00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 05)
    
01:00.0 VGA compatible controller [0300]: Advanced Micro DevicesInc. [AMD/ATIEllesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev ef)
    
01:00.1 Audio device [0403]: Advanced Micro DevicesInc. [AMD/ATIEllesmere HDMI Audio [Radeon RX 470/480 570/580/590] [1002:aaf0]
IOMMU Group 2:
    
00:12.0 Signal processing controller [1180]: Intel Corporation Comet Lake PCH Thermal Controller [8086:06f9]
IOMMU Group 3:
    
00:14.0 USB controller [0c03]: Intel Corporation Comet Lake USB 3.1 xHCI Host Controller [8086:06ed]
    
00:14.2 RAM memory [0500]: Intel Corporation Comet Lake PCH Shared SRAM [8086:06ef]
IOMMU Group 4:
    
00:16.0 Communication controller [0780]: Intel Corporation Comet Lake HECI Controller [8086:06e0]
IOMMU Group 5:
    
00:17.0 SATA controller [0106]: Intel Corporation Comet Lake SATA AHCI Controller [8086:06d2]
IOMMU Group 6:
    
00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:06b2] (rev f0)
IOMMU Group 7:
    
00:1d.3 PCI bridge [0604]: Intel Corporation Device [8086:06b3] (rev f0)
IOMMU Group 8:
    
00:1f.0 ISA bridge [0601]: Intel Corporation H470 Chipset LPC/eSPI Controller [8086:0684]
    
00:1f.3 Audio device [0403]: Intel Corporation Comet Lake PCH cAVS [8086:06c8]
    
00:1f.4 SMBus [0c05]: Intel Corporation Comet Lake PCH SMBus Controller [8086:06a3]
    
00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake PCH SPI Controller [8086:06a4]
IOMMU Group 9:
    
02:00.0 VGA compatible controller [0300]: Advanced Micro DevicesInc. [AMD/ATICuracao XT Trinidad XT [Radeon R7 370 R9 270X/370X] [1002:6810]
    
02:00.1 Audio device [0403]: Advanced Micro DevicesInc. [AMD/ATIOland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000 Series] [1002:aab0]
IOMMU Group 10:
    
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., LtdRTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)


Grouping doesn't always make logical sense. My previous mainboard didn't create a separate group for the gfx card.
If the ethernet adapter in group 10 was also in group 9 then I would have had to detached it from the host system as well.

Go to top


Re: Qemu Pegasos II interrupts issue
Just can't stay away
Just can't stay away


@geennaam

Quote:
geennaam wrote:OK, weird, but I used a drawer mounted as USB drive to transfer data between QEMU and Linux.
Now what that disabled it is definitely a lot faster.

Window resizing is a lot smoother. (compositing enabled) Running at 2560x1440@32bit now

Cow3D W3DNova manages 251 fps. That is a bit faster my SAM440-FLEX 800 MHz with the same R9 270x

https://ftp.hdrlab.org.nz/benchmark/gf ... 2d/OS/AmigaOS/Result/2773

- Night of the zombies 24fps menu / 10fps game /CPU 100%


Really great that you have tested this again. As far as I've been following this thread, the R9 270/x is best for passing through to Qemu.

It may sound a little crazy but I was looking at a setup today that might work with my MacStudio via Thunderbold and external eGPU adapter with R9 270/x.

The MacStudio, as well as MacOs recognize this adapter and probably also the graphics card, but MacOs itself cannot use it directly. Of course you could try to forward the whole thing to Qemu.

But I'm really not sure if it can work....

The setup would use this adapter:

Th3p4g3 Thunderbolt-compatible GPU dock

An external power supply unit including R9 270/x would also be required.

The R9 270 is a PCIe graphics card?
The direct use of PCIe is currently not possible and everything must be made accessible via a PCI bridge? I still haven't understood it exactly.

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@joerg @Batalon

Just to be clear.

The emulated system with HD R9 270X reacts just like a real machine The only difference is that the speed of emulated PowerPC is slow on my PC. Therefore the workload jumps to 100% faster then on my X5020. But when the emulated system is idling. The CPU load is also 0%-1% just like on real systems.

It was just an observation that the system became sluggish with the emulated USB drive as described here in the FAQ: http://zero.eik.bme.hu/~balaton/qemu/amiga/index.html

This can be caused by the fact that the shared drawer and ubuntu itself are installed on an old mechanical HDD.

Go to top


Re: Qemu Pegasos II interrupts issue
Just can't stay away
Just can't stay away


@balaton
Quote:
When you see 100% CPU in guest is it possible to find out what code is keeping the CPU busy? That's where we should look to find what's limiting performance.
One of the best tools for checking CPU usage on AmigaOS4 should be Tequila (source), because a few parts of it are based on my 20 years old "top" tool

Go to top


Re: Qemu Pegasos II interrupts issue
Quite a regular
Quite a regular


@balaton

First of all, I am working with the Pegasos2 target. Not AmigaOne XE or SAM460 because that would need me to do new installs. I had the pegasos2 target still on my disk.

I'm also working with the latest QEMU 9.0.0RC4 which i've compiled myself

There isn't much to post. And tbh, the Radeon9250 and HD4850 are not interesting anyways. So let's ignore those.

The HD7000 works fine in pass-through thanks to bboot.fth boot V0.7 and Kickstart.zip.
- "Fast" Workbench at 2560x1440@32. Experience is limited by the speed of PowerPC emulation on my old Core i5. Take a Ryzen 7700x and you'll definitely leave the X5020 in the dust.
- Warp3D Nova works
- Warp3D works
- Compositing works
- Internet is stable with old RTL8139 driver
- Audio works
- 500MB FAT USB disk emulation will greatly slowdown the machine so better share files with a network drive

So currently I have a QEMU which is usable with a real HD7000 card in pass-through and feels like sam460 speed.

When I connect my RX560 instead then QEMU fails to start with that error message described above. Apparently this has something to do with a bad reset of the RX card. Or at least that is what you said a year ago.

The info how to pass through and bind the VFIO kernel driver to the GFX card is well described on various sites. You can even use some helper scripts on Ubuntu to ease the pain https://github.com/pavolelsig/passthrough_helper_ubuntu_20

pegasos2.rom isn't capable of fully configuring a HD 7000 card so the " /failsafe" io trick is still needed to get the of prompt back.

My qemu commandline is as follows:
qemu-system-ppc -machine pegasos2 -rtc base=localtime -serial stdio -vga none -device VGA,romfile="" -drive media=disk,format=raw,file=hd.img -m 1024M -bios pegasos2.rom -device es1370,addr=0x08 -device rtl8139,addr=0x09,netdev=nic -netdev user,id=nic,hostname=pegasos-os4 -device vfio-pci,host=02:00.0,bus=pci.0,x-vga=on -device vfio-pci,host=02:00.1,bus=pci.0 -accel tcg


The pass-through parameters depend on where the card is located in your iommu tree of course.

Using bus=pci.0 makes sure that the card gets connected on the virtual AGP bus for the pegasos2.

For me is was just (my technical) curiosity if I could finally make it to work. I have no intention to run QEMU or write a tutorial.

Going to rebuild my machine back to original state so that my kids can play Fortnite on Windows again


Edited by geennaam on 2024/4/19 18:53:31
Go to top


Re: X5000 switches itself off
Just popping in
Just popping in


@Gregor

My X5000/20 has had this problem over the years, and it just started getting worse and worse.

I have the MCU connected to serial so I can monitor the error and see the output. I used the 1 second output option and watched the vdd_3v3_xorro drop from 3.21 to 2.95 over the period of about 15 minutes.

Here is a measure meant about halfway through:
- vcc_cpld: 3.32
- vdd_3v3_xorro: 3.04
- vdd_1v0_idt: 1.00
- vdd_1v0_xorro: 1.00
- vdd_3v3: 3.32
- vdd_2v5: 2.46
- vdd_1v2_eth: 1.19
- vdd_pl: 1.03
- vdd_ca: 1.09
- vdd_cb: 1.09
- vdd_ddr3_io: 1.49
- vdd_xvdd_fl: 1.80



Here is the output when the problem happened:
- vcc_cpld: 3.32
- vdd_3v3_xorro: 2.98
- vdd_1v0_idt: 1.00
- vdd_1v0_xorro: 0.99
- vdd_3v3: 3.32
- vdd_2v5: 2.46
- vdd_1v2_eth: 1.19
- vdd_pl: 1.03
- vdd_ca: 1.09
- vdd_cb: 1.08
- vdd_ddr3_io: 1.49
- vdd_xvdd_fl: 1.80


- pcb_temp: 40 deg C
- cpu_temp: 56 deg C
- pex_temp: 66 deg C


- FAN RPM: 0

ERROR: vdd_3v3_xorro out of range. Expected 3.30, got 2.95
WARNING: Supplies Turned off. Shutting down.
ATX supply turned off.

My case differed from Sinans in that only one voltage line was impacted.

I would hook up the MCU to serial so you can get a better view of the issue. I use this part to access the MCU:
https://www.amazon.com/gp/product/B07R ... _asin_title?ie=UTF8&psc=1

The manual has the pins. Let me know if you need those as well.

Cheers,
Bill "tekmage" Borsari

Go to top


Re: X5000 switches itself off
Just popping in
Just popping in


@Gregor

My X5000/20 has had this problem over the years, and it just started getting worse and worse.

I have the MCU connected to serial so I can monitor the error and see the output. I used the 1 second output option and watched the vdd_3v3_xorro drop from 3.21 to 2.95 over the period of about 15 minutes.

Here is a measure meant about halfway through:
- vcc_cpld: 3.32
- vdd_3v3_xorro: 3.04
- vdd_1v0_idt: 1.00
- vdd_1v0_xorro: 1.00
- vdd_3v3: 3.32
- vdd_2v5: 2.46
- vdd_1v2_eth: 1.19
- vdd_pl: 1.03
- vdd_ca: 1.09
- vdd_cb: 1.09
- vdd_ddr3_io: 1.49
- vdd_xvdd_fl: 1.80



Here is the output when the problem happened:
- vcc_cpld: 3.32
- vdd_3v3_xorro: 2.98
- vdd_1v0_idt: 1.00
- vdd_1v0_xorro: 0.99
- vdd_3v3: 3.32
- vdd_2v5: 2.46
- vdd_1v2_eth: 1.19
- vdd_pl: 1.03
- vdd_ca: 1.09
- vdd_cb: 1.08
- vdd_ddr3_io: 1.49
- vdd_xvdd_fl: 1.80


- pcb_temp: 40 deg C
- cpu_temp: 56 deg C
- pex_temp: 66 deg C


- FAN RPM: 0

ERROR: vdd_3v3_xorro out of range. Expected 3.30, got 2.95
WARNING: Supplies Turned off. Shutting down.
ATX supply turned off.

My case differed from Sinans in that only one voltage line was impacted.

I would hook up the MCU to serial so you can get a better view of the issue. I use this part to access the MCU:
https://www.amazon.com/gp/product/B07R ... _asin_title?ie=UTF8&psc=1

The manual has the pins. Let me know if you need those as well.

Cheers,
Bill "tekmage" Borsari

Go to top



TopTop
« 1 ... 168 169 170 (171) 172 173 174 ... 7368 »




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project