Who's Online |
74 user(s) are online ( 36 user(s) are browsing Forums)
Members: 0
Guests: 74
more...
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
|
Quite a regular 
|
@flash
What needs improving on the MV64361 emulation in QEMU? I think it works well enough now. This chip has tons of features but if nothing uses them it does not worth emulating all details that will be unused. I think I already have a few unused things that weren't needed but implemented it anyway.
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Quite a regular
|
@Maijestro
I think somebody tested that before with real machine and ATI card with 16 bit mode (it's probably somewhere in the long QEMU pegasos2 thread, I think it was when we tested it with a Mario like game) and it did not reproduce the problem. I think somebody said back then that ATI cards support big endian 16bit mode but SM502 doesn't or something like that and it seems that some function used by graphics library does not take that into account on pegasos2. With the test from Capehill it's now also proven that it's not related to SDL code but it's something in AmigaOS. So we likely won't get more info from trying with real graphics card (unless somebody can try on real pegasos2 with a real SM501/502 card but those are probably rare so likely nobody has such card). The ATI cards were working even in 16 bit in previous tests so it should be the same result with a passed through card.
|
|
|
|
|
|
Re: MPlayer 1.5 released!
|
|
Quite a regular
|
@white Use the official QEMU sources from gitlab (see qemu.org Download menu item), I don't have a separate repo to use now. I think you can set optimization level from configure without editing meson.build by adding -Doptimization=3 to configure. That would be better than modifying meson.build because then you can easily update from git. I don't know how much difference it makes but if you use opt 3 and see problems also check with the default optimization level just to make sure it's not some compile error. The results of opt 3 on Linux with gcc might be different than on macOS with clang. For your QEMU command line -cpu 7457 -accel tcg are the default so you can drop these, only need to add -cpu if you want to use other than the default 7457 CPU. You can use -display gtk,zoom-to-fit=on,full-screen=on instead if separate -full-screen option that may be removed at some point and specifying it as a -display option is now preferred. Instead of separate -drive if=none and corresponding -device ide-hd option there's a shortcut to define a drive with one option:
-drive media=disk,index=0,file=/home/white0/Scaricati/32gb.raw,format=raw
-drive media=disk,index=1,file=/home/white0/Scaricati/coffin.raw,format=raw
which does not need a separate -device ide-hd option so it's shorter and more readable. (Since QEMU 9.0 this also works with sam460ex now which previously did not support these short options.)
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 4/27 11:31
#24
|
Quite a regular
|
@Hans
I said I don't mind if others don't support or believe in free software and have other views. I just wanted to make clear my point of view and explain why I won't do much with this problem. I think it's better to be clear about that than just saying nothing so you don't have to wait if I reply or not and can go ahead with this task. What I said is not against you personally so don't take it as that.
I think keeping things closed especially in such small community just hinders progress and leads to unnecessary fights over who owns what and who gets the crumbs. It may be better to do like other communities who are keeping their beloved platform alive together like Haiku for example. AmigaOS is already obsolete and not fit for daily use (e.g. lacking support for modern hardware, memory protection, security and SMP just to name a few) so there's not much commercial value there and there isn't much hope that the handful of people who can be payed to work on it will ever make it reach the level of modern systems (or if their work will be published at all as others are still fighting over who can publish it in the first place). Making AmigaOS modern and a viable alternative OS would only be possible by allowing contribution from passionate developers but if they are discouraged seeing this state there won't be much progress. It reminds me of the book title from David "From Vultures to Vampires", looks like for AmigaOS4 we're still watching the vultures tearing apart the remains of it. I'd like to see a modern AmigaOS but I don't think the current closed source way will lead to that in our lifetime. So those who in charge may consider if there's some better way. That's why I don't want to help to keep the status quo and rather advocate free software. Sorry if this offends some people, I don't want to attack anybody just discuss views and get people consider alternative ways.
Some people are payed to work on free software so closed source is not the only way to earn a living. Even if kas1e could pay me I could not do much as I don't have the AmigaOS kernel source. If you get payed and fix it that still won't help me as I likely won't get a fixed version so there isn't much motivation for me to do much with this.
|
|
|
|
|
|
Re: Running my OS4 games on QEmu
|
Posted on: 4/27 10:45
#25
|
Quite a regular
|
@Capehill
That changelog says "Compositing requires PatchCompositeTags on WinUAE, for example." I don't know what that does or means but if it's patching some kernel routines to work without hardware compositing then maybe that would be a solution here as well? It's still strange why the amigaone kernel works while pegasos2 has problems but despiite the two machines being similar in hardware the pegasos2 kernel also lacks some IRQ init that the amigaone one does so there might be some differences between these kernels.
|
|
|
|
|
|
Re: Running my OS4 games on QEmu
|
Posted on: 4/26 18:43
#26
|
Quite a regular
|
@Capehill
Not sure what would be the correct output but I've tried it on QEMU amigaone,pegasos2,sam460ex machines just booting the 4.1FE install CD. The 8 bit and 32 bit looks the same on all 3 machines but 8 bit has text in different colors and gray background and 32 bit has all black text on gray background. The 16 bit one has blue-green background with black text and on pegasos2 also the text is broken (endianness issue?) whereas on amigaone (with same 7457 default cpu as pegasos2) and sam460ex the text is OK even in 16 bit mode. Using -M pegasos2 -cpu 750cxe fixes text in 16 bit mode. (This was tested before with SDL that endianness issues only happen on pegasos2 and with G4 CPU.)
To me this looks like some problem with pegasos2 kernel again assuming other components are the same on all three machines.
Maybe it would also be interesting to see how it displays on real sam460ex with the on-board SM502. Anybody could try that for comparison?
|
|
|
|
|
|
Re: Amiga X5000 and Sound Blaster Audigy FX problem
|
Posted on: 4/26 16:18
#27
|
Quite a regular
|
Software is licensed and you can only use it according to its license. The author has the right to decide what license the sofware is published under. It does not matter what you think, you only have two choices: accept the licence or not use the software. (This is also true for free software under GPL. You can use, distribute, modify it freely, even can ask for money to support it, but you can't make it non-free and have to give the same rights you got to others.) Those who produce commercial products and expect people to follow their licenses should also follow the license of the components they use themselves and should check and comply to those licenses.
In this case the HDA driver's license says it's only for non-commercial personal use and cannot be distributed as part of a commercial product or ask money for it. (I don't think this can be revoked once it's published so this driver version is still available under those terms and it allows to be distributed for personal use.) But the author can ask it to be removed from commercial products (or try to ask for some money for past "damage" but maybe there's not much profit made on any of this and we don't need more court cases so getting some agreement may be a more sensible approach).
The authors also have the right to decide if they want to support it further. license further versions under different license or stop making further versions. You can't force them to do something they don't want to.
Maybe people are too passionate about all these Amiga stuff and still hold on to their pieces which just hinders development so it would be better if there could be more cooperation instead of competition and forget commercial thinking where there's no real market but this seems to be the state of things now. I can only hope it will change in the future.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 4/26 15:39
#28
|
Quite a regular
|
@Hans Quote: AFAICT, with RTAS you need to pass the full PCI card address: PCI domain, bus, device, function. And, of course, the register you want to access. I've tried that, and it works for all cards except the one behind the PCI-to-PCI bridge. Then this may be a limitation in RTAS as it only has provision to pass a single address but not PCI domain or host. So if RTAS on pegasos2 interprets bus 1 as the AGP port (which is really another PCI domain) then maybe there's no way to access devices on bus 1 on the default PCI domain. You can test this theory if you get data from the AGP port with bus 1 and device for the card on that bus. Then reading bus 1 for device behind the bridge would try to access the wrong PCI domain and so won't find a device there because you can't have bus mean both bus and PCI domain so you could either access all devices on one domain or bus 0 of all domains depending on what RTAS uses the bus part of the PCI address for. If my theory is true then you probably can't use RTAS and you'd need to write a proper PCI driver in AmigaOS to be able to access all devices on all domains. I could help with that but I only work for free on open source projects that I can then also use myself. But if I won't get the result and you're payed to do that and not me I'll let you figure that out (or you can hire me for consulting if needed). It's not difficult though, accessing PCI is not much different from other platforms which is well documented and I've already given you the docs where it's explained for pegasos2 as well. Also my code is free to study (not for copying into commercial projects though, so you should not copy&paste it but write your own from what you've learned from it). Sorry for that but I believe in free software. I don't mind if others don't but then the rules of commercial software should be applied for those projects which means you get what you pay for.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 4/26 15:13
#29
|
Quite a regular
|
@kas1e
I've read somewhere: "If all else fails read documentation." Ever thought about that? If you want to learn Forth try forth.com. Have you even seen old reverse Polish notation calculators that are stack based? Those where you had to type 5 3 + Enter or something like that to add two numbers and display the result? Forth works like that, so you have to push arguments to stack then call operation word and then you can find results on the stack that you need to print to get the result.
But this probably does not matter as it seems even if you can get the needed values from the SmartFirmware prompt they may not be accessible via RTAS.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 4/24 16:34
#30
|
Quite a regular
|
@Hans
You probably don't have to be concerned about the PCI domain. I think a domain corresponds to a /pci node in the device tree but since the bridge and the devices behind it appear in the first domain where are all the other PCI devices it should be accessed the same way and don't need to consider the other domain where is only the AGP port. I don't know how this works with RTAS, but in OF you can cd into the right /pci node to call the corresponding config words for that domain or may need to open the device node first. The config words should take address in the same format as it appears in the device tree and I think the same should be true for RTAS or these mostly follow the same address encoding that the PCI spec describes and also shown in the OF PCI doc.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 4/24 14:09
#31
|
Quite a regular
|
@kas1e
I would also have to read the OpenFiware PCI docs to check how the config-* words work, I don't remember that now. So you could have a look at that doc then try to read config space vars like vendor/device ID and BARs of your gfx card behind the bridge from the OpenFirmware prompt just to verify it works on the OF level at least and to find the right address that should work with RTAS too. Maybe access the SmartFirmware prompt via serial from another machine so you can cut&paste and don't have to type that much.
I don't know what Debian did, you have not posted enough details to understand what happened there. Maybe posting full Debian logs from boot and BBoot output with the card may help to see more (BBoot won't handle bridges but if the card appears in the device tree it should at least list basic info on it).
But I don't have PegasosII hardware, don't have these gfx cards and even if I had a card and it works with QEMU with pass through I don't have AmigaOS drivers for it so I'm not much interested in this.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 4/24 10:40
#32
|
Quite a regular
|
@Hans Quote: Where did you get this from (bboot/brd_pegasos2): I wrote it after reading the OpenFirmware PCI doc I've linked to above. Maybe also check the Marvell Discovery II docs as that provides the PCI bus on pegasos2. Quote: These are from libpayload as can be seen in the comment at the top of the file. Did you try if you can access the card behind the bridge with config-l@ config-w@ and so on from the SmartFirmware prompt? Maybe you're just passing the wrong address to the RTAS function that's why it does not read the right bus.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 4/22 23:32
#33
|
Quite a regular
|
@Hans I don't know of any docs on pegasos2 specifically but there are some docs on OpenFirmware here: https://openfirmware.info/Bindings and on PCI there are many on the net. You may also look at some BSD sources but not GPL code if you want to use it in non-GPL closed source project.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 4/20 12:46
#34
|
Quite a regular
|
@kas1e I think PegasosII SmartFirmware may have a limit on how many blocks it can read so the boot partition should be at the beginning of the disk (maybe below some cylinder/block limit). Maybe it does not need to be hd:0 but if it's at the end of a large disk that's outside the limit. Try to put it fully within the first 2GB or so. It probably tries hd:0 by default that's why it says it should be first otherwise you'd need to type boot hd:1 ... or set some env var. Also pegasos2 kernels contain an initrd so you may either need such kernel or some boot loader to load both kernel and initrd. So maybe you need to boot cuimage or boot img which have embedded initrd instead of vmlinuz that may be just the kernel. I have some docs on what Linux distros I could boot on emulated machines here: https://www.qemu.org/docs/master/system/ppc/amigang.html I think for pegasos2 Debian 8.11 was the latest that supported it but maybe there some unofficial later versions.
Edited by balaton on 2024/4/20 13:12:48
Edited by balaton on 2024/4/20 13:18:54
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/19 21:50
#35
|
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.
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/19 21:46
#36
|
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.
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/19 20:40
#37
|
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.
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/19 20:35
#38
|
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.
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/19 20:30
#39
|
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.
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
Posted on: 4/19 18:11
#40
|
Quite a regular
|
@geennaam Quote: 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. I can't imagine how a USB drive could affect GPU especially when not used. The only thing these might have in common are IRQs so maybe try 'info irq' command in QEMU monitor with and without the USB drive to see if there are a lot of interrupts for the USB. Or maybe there's something with the interrupt handler chain checking the USB before the GPU and it causes some slow down? I have no idea how all this works so just guessing, maybe Hans knows more about what could this be or how to debug/resolve it. Quote: The gfxbench2d score is much better than on real PegasosII (which seems to reach about 3100) and about half of the best real machine so I'd say it's not bad for a start. It seems the large rectangle scores are comparable to real hardware but the small rectagle values are lower. Also the RAM access is much slower so maybe that's where the problem is. Again this is something that Hans could have some more info on. Maybe the copy routines aren't the best for QEMU. If you compare RageMem results with real machine then some methods that work well on real machine are slower on QEMU. If AmigaOS happens to use that it may not work the best. Also you may try -cpu 750cxe (or whatever matches real machine). In theory having AltiVec should help but maybe it's not emulated that well yet. At least testing if it has any effect may help finding where the limitation is coming from. 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.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
