Who's Online |
69 user(s) are online ( 51 user(s) are browsing Forums)
Members: 0
Guests: 69
more...
|
|
Headlines |
-
amiarcadia.lha - emulation/gamesystem
Dec 12, 2025
-
ticklish.lha - utility/misc
Dec 11, 2025
-
catacombgl.lha - game/fps
Dec 10, 2025
-
ubek.lha - game/fps
Dec 10, 2025
-
allkeys.lha - utility/misc
Dec 9, 2025
-
opengw.lha - game/shmup
Dec 8, 2025
-
amigagpt.lha - network/chat
Dec 7, 2025
-
serial_door.lha - utility/communication
Dec 7, 2025
-
yt.lha - video/misc
Dec 7, 2025
-
imp3.lha - audio/play
Dec 5, 2025
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/3 15:54
#901
|
Quite a regular 
|
@geennaam Quote: Pegasos2 has hit a brick wall at the moment for passthrough. Likely an issue that can only be solved in the kernel.
I'm not sure about that. If the problem is that AmigaOS cannot handle 64bit bars but would work with reporting them as 32bit bars since they are mapped in 32bit address space anyway then this should be possible to be fixed in a Forth script running on SmartFirmware that replaces the reg and assigned addresses properties of the card with same but changing 64 bit bars to 32 bit. This should be the place where AmigaOS gets the info about the card so fixing that up could avoid this problem. So anybody wants to learn Forth to find out how to write such a script or you'll just keep waiting for me to do that too?
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/3 15:50
#902
|
Quite a regular 
|
@geennaam Quote: 2. Radeon 9250 has the same result as Pegasos2. Boot logo ok. But workbench backdrop and windows messed up. Except for icons. And a crash shortly after.
Do you see any errors when running the card ROM by the firmware? Are you adding an emulated VGA to circumvent missing x-vga=on option? I think that may be a problem because then the firmware talks to the emulated VGA card and may not init the passed through card properly and looks like AmigaOS driver can't fix that up but needs the BIOS ROM running. To solve this we likely need to fix x-vga option for older Radeon cards as noted in the comments in QEMU source. All that somebody would need to do is read qemu/hw/vfio/pci-quirks.c and understand what it does then modify it to work with older cards insted of the HD Radeons. It's not that long and half of it is for Nvidia cards that can be ignored so it's doable if somebody wants to. Just waiting for it to happen won't make any progress. I may eventually get there and fix it if nobody does by then but it may be a long time as I have no use for that myself so not high on my list. Quote: 3. Radeon HD4850 fails with VFIO DMA map errors
4. Radeon RX 560 fails with VFIO DMA map errors
qemu: VFIO_MAP_DMA failed: Invalid argument
qemu: vfio_dma_map(0x5561a1a38000, 0x1030ffe00000, 0x200000, 0x7fab111ff000) = -22 (Invalid argument)
qemu: VFIO_MAP_DMA failed: Invalid argument
qemu: vfio_dma_map(0x5561a1a38000, 0x1030ffe00000, 0x200000, 0x7fab111ff000) = -22 (Invalid argument)
qemu: VFIO_MAP_DMA failed: Invalid argument
qemu: vfio_dma_map(0x5561a1a38000, 0xf0000000, 0x10000000, 0x7faaf0000000) = -22 (Invalid argument)
When do you see these messages? At start, during firmware or after AmigaOS driver touches the card? What are the numbers in the arguments of vfio_dma_map correspond to? I think it should be the BARs of the card but if those are missing in AmigaOS then that may be a bigger problem at the moment because without a frame buffer BAR we won't get any output. Quote: Unlike the Pegasos2, the commandline doesn't need the sam460 uboot image. Is it embedded in the target?
Since sam460ex firmware is GPL licensed it can be included in QEMU. It's in pc-bios/u-boot-sam460-20100605.bin and compiled from the sources that I had to add some fixies, source is at https://gitlab.com/qemu-project/u-boot-sam460ex.gitQuote: Overall description of sam460 emulation in QEMU8.02 with one word: Unstable
What do you mean by unstable compared to pegasos2? It's slower but did you get any other problems with it?
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/3 15:27
#903
|
Quite a regular 
|
@MartinW GPU pass through for AmigaOS currently does not seem to work so not usable at the moment. We're trying to find out here why and how to fix it. If you have a motherboard that has PCIe and PCI slots then it probably has a bridge on the board so it's still the same as using an external bridge. (Maybe there were older motherboards that had both PCI and PCIe in their chipset but recent systems are PCIe native and only have PCI slot through a bridge chip.) I think @geennaam used a Pericom bridge which are said to be good and generally work but this can depend on a lot of things. The older CPU with VT-x may not be enough for pass through, I think that's needed for using KVM but pass through needs VT-d that's IOMMU virtualisation.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 18:59
#904
|
Quite a regular 
|
@derfs Quote: I also have this showing in the os4 debug output, not sure what it means.
There is a large 15-20 second delay after 'MISC_TIMING 00000000' shows, and then once the table shows the OS boots as normal.
I think that's when the driver (maybe the SM502 driver) reads the EDID from the monitor and the table shown is the EDID info retrieved. As this shows QEMU monitor this isn't the external display but the emulated one. Reading the EDID bit by bit may be slow but I think this is not related to pass thorugh. I think there are two siliconmotion502.chip drivers and one of them has the delay while the other (maybe the older one) doesn't so you may try downgrading the driver if this is an issue.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 18:54
#905
|
Quite a regular 
|
@geennaam Quote: Of course it's a means to sell more copies. But it is just cynical that you lecture me on a breach of the EULA when the whole QEMU effort is a breach of the EULA. QEMU is neither an amiga-branded nor amiga-licensed computer. If you want to abide to the rules then either stop cherry picking or don't try to lecture others. At this moment it's just for educational purposed for me. Actually the only reason why I am doing this is to help you in your effort. I own several real AmigaOnes so I'm not in need of qemu.
Sorry if you took it as cynical and lecturing, I just wanted to make sure people know what they are doing when they modify an AmigaOS CD. As said above QEMU does not break the EULA, it emulates hardware and can run other OSes so it has nothing to do with AmigaOS or its license. Just as the real hardware can run this OS so can the emulated one too. If thid is not allowed by the license that's not QEMU's or my problem but should be considered by those who want to run AmigaOS on it. So I just wanted to make it clear that I don't encourage anybody ro do anything that's against the license but what they do at the end is their decision. If you want to modify your sam440 cd then you can do that but maybe you should not advertise it.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 18:23
#906
|
Quite a regular 
|
@geennaam I also know about that but other OSes like macOS and Windows also have similar clauses in their license yet people still run those for a while. QEMU does not violate that license, it just emulates some hardware. People who run AmigaOS with QEMU may do something the license does not permit but that's not my problem. If the AmigaOS owners want to sell more copies of these CDs that otherwise nobody would buy as the machines they are made for not produced any more then maybe it's not a wise move to try to enforce that clause though.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 18:07
#907
|
Quite a regular 
|
@geennaam You may be violating the license by modifying the CD that way so you should not do that. (I know that adding the sm502 driver to pegasos2 cd is also similar but at least that's not running a completely different version on a machine it wasn't intended for). So if you want to keep to the rules set by the owners of this software you sould buy the version you need. Otherwise they could have published a single version for all machines but that's not how they license it. If you don't care about the rules and get in trouble because of that that's your problem.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 17:59
#908
|
Quite a regular 
|
@geennaam See info qtree to find out. Just adding devices without any bus will go to PCI that is called pci.0. The 1x PCIe is pcie.0 and the 4x PCIe is pcie.1 but these don't work yet. Also you can't use the 1x bus because it's set to SATA as we don't have NVRAM to change settings. So unleds you had bus=pcie.1 in the vfio-pci when you got the errors then the card was passed as PCI. Maybe we could check similar infos from U-Boot but I don't know how to get those. U-Boot shold have some help or docs. Also there's an info pci command in the QEMU montitor that only lists the PCI devices but info qtree is more detailed and shows the relation to buses.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 17:55
#909
|
Quite a regular 
|
@geennaam Quote: Running my Sam440 install CD in the Sam460ex target results in a kernel panic.
Yes, that's for a different machine than what QEMU emulates. You need the corresponding AOS version. Just updateing the kernel is not enough as other drivers for the Sam640 may also be needed.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 17:53
#910
|
Quite a regular 
|
@joerg Quote: Only on machines with U-Boot. Does A1 XE use U-Boot? I only know pegasos2 and sam460ex so don't know what other machines have but Hans said it's from the pegasos2 era when U-Boot may not have been that popuiar. Quote: I doubt it's hardware (or hardware emulation) related, but the Firmware configuring 64 bit BARs as 64 bit "x" instead of 32 bit "m" BARs, which the AmigaOS Pegasos2 kernel may not support. If that's the case it would require changes in the Pegasos2 kernel, the slb (slb_v2, amigaboot.(ub|of), Parthenope (which isn't usable anyway because it doesn't support any AmigaOS file system but only Linux (ext2fs) and AROS (SFS 1.84) ones)) can't fix it, nor can the AmigaOS gfx drivers. Well, if the only problem is that pegasos2 firmware reports the BARs as 64 bit instead of 32 bit then this may be patched from Forth by replacing the assigned addresses and reg properties with the same values but showing 32bit for AmigaOS. As this happens at the OK prompt after the fiemware has init the card and mapped its resources the firmware does not care any more and then nothing else needs to be modified in AmigaOS either. Somebody would just need to find out the forth code to do that. It would need to read and parse the reg and assigned-addresses properties of the card then create equivalent properties with the BAR type changed to 32 bit. Even though this may not be trivial in Forth there should be some example code for this on-line. For general Forth introduction see https://www.forth.com/starting-forth/ and for the properties format the PCI binding doc I've quoted before. Is there anybody who wants to give this a try? Update: If this works then the same could be done from amigaboot.of, loader.of or from the replacement amigaboot if we need it to work with QEMU VOF so this may still be slovable withot modifying everyhing else.
Edited by balaton on 2023/7/2 18:15:10
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 17:43
#911
|
Quite a regular 
|
@geennaam Quote: Ah, thanks for the hint. Maybe I can upgrade my Sam440 iso with the 460 kernel from Update2.
Why would you do that? Maybe check first if there's any difference then tha Kickstart files between the two CDs. Probably they are the same just have different kernel and drivers so you can already run the Sam460 version.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 17:41
#912
|
Quite a regular 
|
@geennaam Quote: geennaam wrote:VFIO for the Sam460ex target results in qemu DMA errors. So for now that doesn't work Do you mean passing through PCIe card as PCIe or PCI? It's expected that it won't work as PCIe card as the PCIe controller needs to be emulated better for the firmware to be able to find devices and make them usabble. I'm not sure about passing through as PCI card but maybe that wasn't tested on real hardware either as it's not needed when one has PCIe slot.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 17:00
#913
|
Quite a regular 
|
@joerg The CPU core in PPC440EP and PPC46EX are PPC 440 but other peripherals in the SoC are differnent. Only the EX versions have PCIe but there exist 405EX with a 405 core as well so these may be mix and match in different configs.
If you look at AmigaOS 4.1FE Update 2 there are different kernels for Sam440 and Sam460 in it so maybe these need to handle some differences in the SoC. You could check the datasheets to see what are these differences may be.
But what's the point of all this? It's proven that at least on some machines with only PCI AmigaOS is able to handle PCIe cards so then this should be fixable on pegasos2 unless there's something in the hardware that would prevent this but that's not likely as the firmware seems to be OK with the card. So this just need to be looked at by AEon/Hans and find out what's going on as they own the kernel and drivers. We've checked the firmware side and that seems to be working.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 12:47
#914
|
Quite a regular 
|
@white Quote: it is possible according to your experience that somehow it is possible to use "NPCAP" inside "qemu"
I don't know what is NPCAP in relation to WinUAE and I have absolutely no experience with Windows or Wine, sorry. But I think you're overcompicating things and trying to apply concepts to QEMU where it's not applicable. Instead you should find out why communication through -netdev hostfwd or -netdev tap is not working for you. You may just be configuring it incorrectly. Just forget about VMWare and WinUAE and think QEMU, we don't have vmnet8 and NPCAP here, we have slirp or tap which probably do the same but differently.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 11:44
#915
|
Quite a regular 
|
@kas1e Quote: otherwise I'd expect to get the same results as with QEMU above Thinking about it some more maybe it's not the same on real hardware because there something should handle the bridge as well and @Hans told before this might be a problem with pegasos2 firmware. Maybe this could be tested on QEMU too by using similar config, so on an older machine with PCI passing through a bridge but finding a machine with PCI and VT-d may not be that simple. One could try with a PCIe to PCI then PCI to PCIe bridge and pass through the latter but this seems to be quite doubdtful config that can be hard to tell why it broke if not working. So maybe this won't work on real pegasos2 unless something can handle the bridge there. If SmartFirmware does not have code for that then it may not see the card. @geennaam Quote: Just guessing here. But I think that this would be the os4 kernel itself. Since it works on A1 XE the kernel and OS itself should be able to handle it but it seems to be somewhere in AOS4 code not outside of it so they should have a look and see if it's fixable there.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/2 11:00
#916
|
Quite a regular 
|
@geennaam Quote:
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
Thanks. Looks like the firmware part may be OK. In the above it shows it recognised the 64 bit BARs and also mapped them according to assigned addresses. The docs https://www.openbios.org/data/docs/bus.pci.pdf on page 7 say what these mean and x denotes 64 bit BAR. So likely it's whatever reads this info from the firmware and creates the AOS info from it that later the OS uses needs to be checked if that handles 64bit BARs correctly. Is that loader.of? Does the A1 XE where this supposedly works use different version of that loader or gets device info differently? If the firmware already handles it correcly then it's likely not fixable from the boot loader above AOS because it seems the firmware already passes this info down. (Unless you consider loader.of part of the boot loader but I only mean the first exe loaded by the firmware under as boot loader which is amigaboot.of here.) @kas1e Quote: Will this kind of information of any help, if i will buy some agp-pcie bridge and put real radeonhd into real pegasos2 ?
Only for cross checking the above and maybe testing a fix later if one will be available, otherwise I'd expect to get the same results as with QEMU above.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/1 22:45
#917
|
Quite a regular 
|
@Hypex Yes, thanks, I've also found that function later in parthenope and saw it loads modules and calls the exec binary so maybe I can start from that. I'm not familiar with the source just found a bug when trying to boot AROS on the sam460ex emulation which I did to check it so I had to fix the bug first to get it load. I think the OF ABI on what a binary run by the firmware gets is documented either in some OF standard or in CHRP but for me the easiest is to look at QEMU VOF: https://gitlab.com/qemu-project/qemu/- ... master/pc-bios/vof/main.chttps://gitlab.com/qemu-project/qemu/- ... ter/pc-bios/vof/bootmem.cso according to that it would be (*kernel_addr)(initrd_addr, initrd_size, CI_entry); in r3, r4, r5 so I can start from that and see if I can get ti boot or do something at least.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/1 22:34
#918
|
Quite a regular 
|
@Hans Quote: 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.
I think vgio pass through should be working as it's used for passing through stuff with other machines and it worked for a while to run Windows VMs with GPUs so I don't think it could be a problem with that. It's either someting in pegasos2 emulation or in the pegasos2 firmware. We're also passint through a PCIe card to a PCI bus without a bridge so I'm not sure how that should work but it could be that the pegsos2 firmware can't handle 64 bit bars. 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. Quote: 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.
The firmware allocates space for PCI as can be seen in the ourput in post #436 and after that. The pci1-mem is the PCI memory space for PCI slots, pci0-mem is AGP memory BARS and in the system view these are mapped from 0x80000000 and 0xc0000000 where tha BARs show would show up. So you could check what else on the same bus is mapped and find a free space in the window for that and program the BAR accordingly. The IO space bars work similarly and you can see where they are mapped in the info mtree output. But once we have a replacement amigaboot.of that we can modify it may be possible to patch things from there so no modification to the drivers are needed. So maybe I should look at the bootloader next as that seems to be useful to resolve several problems at the same time.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/7/1 22:09
#919
|
Quite a regular 
|
@geennaam Quote: geennaam wrote:@balaton Quote: I'm still looking at sam460 PCIe emulation Yes, I agree. This is the only way forward. It's not the only way forward and fixing the x-vga problem would be needed for older PCIe Radeon cards as well even on sam460ex. But since it's a config that works with real hardware if I can emulate that then it could at least provide some way to cross check other attempts. But I could not find any documentation on how PCIe works on 460EX, the only info I have is the u-boot sources that's not very useful as a lot of detail is missing and it handles different variants so it's hard to follow. I could make some progress with u-boot now able to see an ati-vga on pcie on sam460ex but it can't fully detect or use the card yet. Since we have only a bit more than a week left until QEMU freeze ( https://wiki.qemu.org/Planning/8.1) I won't be able to make this work, clean up to submit then get reviewed and merged in the remaining tine so this would miss 8.1 anyway so I'll have time to find this out later. So I'll keep trying on and off but this could take a while and it won't be in a release before December. This may not even be needed if HD cards can be made working with pegasos2 which would be better anyway because pegasos2 is faster. So I think getting PCIe with sam460ex working is interesting but maybe not the highest priority now.
Edited by balaton on 2023/7/2 13:05:42
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2023/6/30 19:15
#920
|
Quite a regular 
|
@geennaam Looks like it's liekely related to what I thought. If you read the backtrace the part where it's called is in vfio_probe_ati_bar4_quirk at ../hw/vfio/pci-quirks.c:471 which is where the comment says it won't work for older cards that don't have BAR4 so this function should be fixed first. I don't know what it does or what it should do so if somebody wants to have a look and find out then go ahead. I'm still looking at sam460 PCIe emulation.
Reading the comment refers to PCI config space access via the MMIO registers BAR and indexed access via the IO BAR. SImilar exists for older ati cards and it's documented somewhere but the offsetts are different. It is implemented in ati-vga, the 0/4 MM_INDEX/MM_DATA regs are the same, The IO BAR allows accessing the first 0x100 regs of the MMIO BAR and there's a read only mirror of PCI cfg regs int the MMIO BAR at offset 0xf00 ... 0xfff as can be seen in qemu/hw/display/ati-vga.c (although without me explaining it here it might be hard to find). I think that's what the function should do then: Use BAR2 for MMIO and implement config reg access at 0xf00 instead of 0x4000. Anybody wants to try to implement that?
As a first try just to test the theory you may try to not care about newer cards and just change the existing functions for older cards. Of course you need to read that code and understand what it does first at least roughly. Then if that works with older cards come up with a patch that does not break newer cards but makes it work with older ones too.
Also try runing with -trace enable="vfio_quirk*" to see which of these quirk functions are called for ATI there are more which may need tweaking but comments mention X550 where changes needed which aparently works like all older Radeon cards as it matches what I had in ati-vga. I actually have an X550 card so I could test this but it's not in my machine and don't have time anyway. Besides the X550 is not supported by Amiga like OSes so I could only test with Linux so I let this open for others to try to fix.
Edited by balaton on 2023/6/30 19:40:57 Edited by balaton on 2023/6/30 19:46:27
|
|
|
|
|
|