I've never build a Linux kernel before so that might take a while to figure out
Not sure what blacklisting is supposed to help. Pass-through of a Radeon 9250 currently works for MorphOS. The issue seems to be related to the AmigaOS driver. But I can give it a try in a couple of days.
Radeon HD and RX do not correctly configure in SmartFirmware. This is to be expected because of its age. Both MorphOS and AmnigaOS4 can't handle a non-configured gfx card.
19.839| Radeon: Failed to initialise Radeon DMA
19.840| Radeon: Failed to allocate CCE DMA memory
MorphOS includes an ATI Rage driver (no CCE required), maybe parts of the Rage driver were included in the MorphOS Radeon driver as fallback. AFAIK all 3 AmigaOS ATI Radeon drivers depend on working DMA (GART) and CCE instead.
@geennaam I think neither SmartFirmware not AmigaOS needs the vga regs but the card BIOS might to maybe instead of removing you can also try adding x-vga=on to 9250 too but not sure if that would change anything.
Recompiling the kernel to add quirks to avoid resetting the card should not be needed this is just a possible error I've heard about before but I don't think it's the problem here.
You may also not need to change kernel if you can avoid loading the driver. Blacklisting means to add a "blacklist <driver name>" to some modprobe config file to avoid it to load that driver which only works if your other card does not use the same driver as it disables that driver for every card. The idea is to not load any driver in the host OS for the card but bind it to vfio without anything touching it before that to avoid any problems that previous drivers might change some card settings and leave it in a state that is not what the card ROM expects after power on. If resetting the card does not work and you can't change the kernel to avoid that then preventing other drivers to change anything before the card ROM runs might help.
But I don't think the issue is with AmigaOS driver. it's more likely some PCI DMA related stuff is not emulated in QEMU because it was not needed so far and I know nothing about that.
MorphOS includes an ATI Rage driver (no CCE required), maybe parts of the Rage driver were included in the MorphOS Radeon driver as fallback. AFAIK all 3 AmigaOS ATI Radeon drivers depend on working DMA (GART) and CCE instead.
Since MorphOS is also closed source we can only guess but it may be possible it can either fall back or just does not use DMA for simple desktop stuff. One way to test might be to try some 3D apps which should need a fully working card so I'd guess at least at that point MorphOS might also fail.
I think we should change QEMU pegasos2 emulation for DMA to work but I know nothing about GART or what is that on PCI (was that MTRR?) so I'd first need to learn about all this, then find out how it should work on pegasos2 and then check what we do in QEMU and fix it. This might take some time unless somebody with more knowledge on this could give a head start here.
Managed to completely brick my Ubuntu install while trying to load the vfio drivers before Radeon drivers.
So I have to reinstall. Now the Ubuntu installer didn't like my Radeon 9250. It made both gfx card outputs flicker on and off while showing no image. Installing with safe graphics mode works. But this means that only the main gpu is enabled.
Edit1: Never mind. Install completed and both cards show the Ubuntu desktop. But the mouse pointer is very sluggish on the 9250 screen. Seems like some acceleration is missing
@geennaam You don't have to load vfio driver before the other one but you don't want your host to load any other driver at all for the additional card that you intend to pass through. Nothing should show on that monitor until the guest is started and no driver should be loaded for it on the host. Then you can assign it to vfio as before. If that driver is only used for this card you can blacklist that from modprobe.d or modprobe.conf so it won't be loaded or if you need the same driver for other hardware on the host then you'd need to make a udev rule to prevent module loading for that card but I don't know how to do that, you'd need to read udev.conf man page or search for it.
But if there's a problem with missing emulation currently and that's causing your problem then the above will not change anything.
Edit: In general don't try to emulate something with QEmu which doesn't even work on real hardware. Not just limited to unsupported CPUs like the 7400, but for example trying to use a Radeon HD or RX gfx card behind a PCI/PCIe bride with pass-through in QEmu, which doesn't work on a real Pegasos2 either, doesn't make any sense.
I'd say instead you can try but don't expect it to work or don't expect it to be fixable. So sticking to what should work on real hardware at least at first has a higher chance of working or at least should be fixable if it doesn't work but I don't think we should limit ourselves to what's possible on real hardware if it can be made working. So I would not be as strict saying don't even try it. Just know what you can expect.
Even if you get the hardware emulation working you still have a software problem: SmartFirmware doesn't support Radeon HD and RX gfx cards, and without initialising the the gfx card by the firmware the AmigaOS gfx drivers can't work. AFAIK SmartFirmware is closed source, if that's the case the only way would be to port the open source U-Boot to the Pegasos2, adding Radeon HD+RX support and using U-Boot instead of SmartFirmware. If you'd do that the OpenFirmware dependant Pegasos2 AmigasOS kernel can't work any more, you'd have to use an AmigaOne SE/XE/µA1 U-Boot kernel instead, but that might not work either since the AmigaOnes are PReP systems (PowerPC Reference Platform) while the Pegasos2 is a CHRP one (Common Hardware Reference Platform)...
Edit: In general don't try to emulate something with QEmu which doesn't even work on real hardware. Not just limited to unsupported CPUs like the 7400, but for example trying to use a Radeon HD or RX gfx card behind a PCI/PCIe bride with pass-through in QEmu, which doesn't work on a real Pegasos2 either, doesn't make any sense.
I'd say instead you can try but don't expect it to work or don't expect it to be fixable. So sticking to what should work on real hardware at least at first has a higher chance of working or at least should be fixable if it doesn't work but I don't think we should limit ourselves to what's possible on real hardware if it can be made working. So I would not be as strict saying don't even try it. Just know what you can expect.
Even if you get the hardware emulation working you still have a software problem: SmartFirmware doesn't support Radeon HD and RX gfx cards, and without initialising the the gfx card by the firmware the AmigaOS gfx drivers can't work. AFAIK SmartFirmware is closed source, if that's the case the only way would be to port the open source U-Boot to the Pegasos2, adding Radeon HD+RX support and using U-Boot instead of SmartFirmware. If you'd do that the OpenFirmware dependant Pegasos2 AmigasOS kernel can't work any more, you'd have to use an AmigaOne SE/XE/µA1 U-Boot kernel instead, but that might not work either since the AmigaOnes are PReP systems (PowerPC Reference Platform) while the Pegasos2 is a CHRP one (Common Hardware Reference Platform)...
Another variant would be to improve the Sam460 emulation in the overall speed, the submarine firmware is already used for this emulation. It has already been said that the firmware on real hardware is being worked on to implement RadeonHD/RX support.
19.839| Radeon: Failed to initialise Radeon DMA
19.840| Radeon: Failed to allocate CCE DMA memory
MorphOS includes an ATI Rage driver (no CCE required), maybe parts of the Rage driver were included in the MorphOS Radeon driver as fallback. AFAIK all 3 AmigaOS ATI Radeon drivers depend on working DMA (GART) and CCE instead.
I could reproduce this with ati-vga so I could debug it a bit more. It does not do the same as the Rage driver but the MorphOS Radeon driver seems to run the CCE and use the command FIFO in push (PIO) mode so not using DMA. I was trying to see where it would set up GART or DMA but it does not seem to even try it just gives the errors. I've found some explanation here: https://www.amigaportal.cz/node/154597 which suggests this is normal because the Pegasos2 while has an AGP port does not actually has AGP but only PCI 66MHz so the card is used in PCI mode without DMA. I wonder if this is really the case. Could anybody with a real Pegasos2 and an ATI card check if these messages appear there when booting MorphOS?
@geennaam If you want to match real hardware better you can attach the graphics card to the AGP port by adding ,bus=pci.0 to the -device adding the card (vfio-pci in case of pass through). Also if you have other functions of the card such as x:y.0 and x:y.1 then you may need to add the .0 device with ,multifunction=on so the other function will be found but these won't fix AmigaOS pass through.
(The PIC buses on pegasos2 are numbered strangly because the PCI slots use Marvell's chip pci.1 bus but the firmware calls that PCI0 while the AGP slot the firmware calls PCI bus 1 is connected to the Marvell chip's pci.0. Thus to add the card as if it was in the AGP slot you need ,bus=pci.0 but that's also a PCI bus even on real hardware so should not make a difference other tnan maybe avoid running out of PCI memory space with larger video memory.)
Testing with ati-vga I've found AmigaOS driver tries to write some GART regs but then seems to do the same as the MorphOS driver and poke the command FIFO in PIO mode. But all the CCE reg writes come out byte swapped so it won't work. So it seems that MorphOS writes little endian values without any special hacks but AmigaOS may rely on some hardware byte swapping which is not emulated correctly. It would help me to check and fix it if somebody who knows how tt works could tell me which feature is used here and could cause values with wrong endian show up when writing to graphics card regs. I have logging in MV64361 for that and haven't seen those logged so I don't think that's it but it could be some ATI aperture stuff as well. But then why it would not work with a passed through card?
This needs some more debugging but I don't have time now.
It seems that your post the Marvell Discovery II supports the byte swapping engine. But that its not implemented in qemu. I cannot find a datasheet. So I can't check it for you. What I do know is that the P5020 in the X5000 contains a 32bit byte swapping engine on its PCIe controllers and this one is activated for BAR read/writes when you go through the OS4 API. For direct access, you'll need to swap yourself. I use this feature in my drivers because it's convenient. So I guess that others do so as well.
@geennaam That mail is about a different endianness problem with APCI which at the end turned out not be related to endianness. Now there's a patch in QEMU master for that already so that will be fixed in next QEMU version. This is needed for ACPI shutdown.
I know about the Marvell chip's byte swapping but you see there's logging for that if the guest tries to enable it and I did not see that log message firing but I may need to check that again. The ATI cards also have hardware features to do byte swapping but then those should work on a real card so first question is which of these (or some third option) is used by the AmigaOS driver for byte swapping ATI MMIO register writes, then check how that's handled in QEMU and implement if it it's missing. Currently I don't know what to check so waiting for some hints on where to go.
Even if you get the hardware emulation working you still have a software problem:
I'd say software problems are more likely to be fixable than hardware emulation. E.g. if there's simply not enough room for mapping large video memory or 64 bit BARs that may not be supported on pegasos2 then that cannot be emulated. If the problem is only with some software then that could be replaced and fixed.
Quote:
SmartFirmware doesn't support Radeon HD and RX gfx cards, and without initialising the the gfx card by the firmware the AmigaOS gfx drivers can't work.
Are you sure the drivers can't init the card without the card ROM running first? I think it only needs the info tables from the card ROM but can do the init itself. Although that may be untested as on real hardware the firmware would run the card ROM on boot but this is not something that could not be fixed.
Quote:
AFAIK SmartFirmware is closed source, if that's the case the only way would be to port the open source U-Boot to the Pegasos2, adding Radeon HD+RX support and using U-Boot instead of SmartFirmware. If you'd do that the OpenFirmware dependant Pegasos2 AmigasOS kernel can't work any more, you'd have to use an AmigaOne SE/XE/µA1 U-Boot kernel instead, but that might not work either since the AmigaOnes are PReP systems (PowerPC Reference Platform) while the Pegasos2 is a CHRP one (Common Hardware Reference Platform)...
I would not do that and don't think it's the only way or a good way. SmartFirmware is largely open source see detail on my devel page at https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 The only part that is not open source is the machine specific init but that's already done in QEMU in case the built in minimal Open Firmware is used. So the pegasos2 firmware could be reimplemented and the BIOS emulator in it updated but it would be even simpler to reimplement amigaboot.of instead and make it work with the QEMU built in virtual open firmware that already works with the MorphOS boot.img. That way the pegasos2 firmware would not be needed at all and all limitations that come with it is gone. We could handle the needed stuff in the reimplemented amigaboot.of then. All I'd need for that is to know what it does and what the AmigaOS kernel needs at boot. Is this documented somewhere? Or if it's easier to just open source amigaboot.of I can figure that out without docs fron the source. The AROS boot loader does something very similar so likely it would not be too difficult to reimplent amigaboot.of based on that or even from scratch. That seems to be a better path then rewriting the pegasos2 firmware.
As an alternative route we're not limited to emulating real hardware. That limitation only comes from that the guest OS only has drivers for real hardware. But if there were guest drivers for other QEMU devices we could use them without needing to emulate a real machine. Some arch in QEMU such as arm mips or m68kl have virt boards that don't emulate any real machine but can run Linux only using virtio devices so with guest support anyting is possible (like uaegfx is also a non-existent hardware that is now widely supported) but if we run OSes made for specific machines then we're limited by those machines. We can still try to extend those limits and see if that's possible or not.
@geennaam I already have some patches for sam460ex PCIe but so far they are only clean up to make the model more managable to be able to implement the missing registers. I don't think I can finish these for the next release so these would only be in a QEMU release by end of the year. The data sheet that is available does not have register docs only some very high level generic info but the U-Boot sources have register names from which their function can be guessed and also the code in U-Boot shows how they are used. It would just need more time to implement these.
@geennaam Yes that should show up if you run QEMU with -d unimp option but I haven't seen that message but could be I've missed it. Can you try if this shows when trying AmigaOS with a passed through card? If so we've found the place to be fixed otherwise it's somewhere else.
Could anybody with a real Pegasos2 and an ATI card check if these messages appear there when booting MorphOS?
There is what i have when boot my pegasos2 till promot where to choose morphos/os4:
PegasosII Boot Strap (c) 2002-2004 bplan GmbH
Running on CPU PVR:80020101
Enable L1 ICache... Done.
Clean/Flush Block enabled
Reading W83194 : 5CFFFFFFFFFFFF00 Done.
Setting Front Side Bus to 133MHz... Done.
Memory has not changed
Configuring Memory
Memory Config Done
Configuring PCI0... Done.
Configuring PCI1... Done.
Configuring ETH... Done.
Releasing IDE reset ... Done.
Configuring Legacy Devices
Initializing KBD... Done.
Memory Test skipped (Warmboot detected)
SmartFirmware:
cpu0: PowerPC,74x7 CPUClock 999 Mhz BUSClock 133 Mhz (Version 0x8002,0x0101)
no/bad nvramrc - performing default startup script
channel 0 unit 0 : ata | KINGSTON SA400S37240G | SBFK61K1
ATA device not present or not responding
EMULATION INT HANDLER ENTERED WITH:
INT NO: 15
EAX=0003 EBX=1111 ECX=2222 EDX=3333 ESP=0000 EBP=5555 ESI=6666 EDI=7777
AX=4E08 BX=C305 CX=0003 DX=102A SP=6CAF BP=5555 SI=6CBD DI=9C48
DS=C000 ES=BAD0 SS=C000 CS=F000 IP=FE15 NV UP -- PL ZR NA PE NC
CS:IP = F4 FS=BAD4 GS=BAD5C40E C000 0244 3000 0000 01B4 AE57 0200
UNHANDLED INT 10 FUNCTION 0007 WITHIN EMULATION
VM using 4857513 x86 cycles for GFX init
auto-booting...
And that what i have when manually type "boot /pci/ide/disk@0,0:3 boot.img bootdevice=dh2":
Memory used before SYS_Init: 9MB
ABox 1.30 (2.7.2018) ▒ 1999-2018 by Ralph Schmidt, Emmanuel Lesueur, Teemu Suikki, Harry Sintonen
PCI ATA/ATAPI Driver@0: PIO Mode 4
PCI ATA/ATAPI Driver@0: UDMA Mode 5
ide.device@0: ATA-HD KINGSTON SA400S3 <DIRECT_ACCESS>
ide.device@0: Mount <boot>
ide.device@0: Partition <boot> DosType 0x444f5301
ide.device@0: Mount <DH0>
ide.device@0: Partition <DH0> DosType 0x53465300 BootPri 0
ide.device@0: Mount <DH1>
ide.device@0: Partition <DH1> DosType 0x53465300
ide.device@0: Mount <DH2>
ide.device@0: Partition <DH2> DosType 0x53465300 BootPri 0
ide.device@0: Mount <DH3>
ide.device@0: Partition <DH3> DosType 0x53465300
Radeon: Failed to initialise Radeon DMA
Radeon: Failed to allocate CCE DMA memory
And then Ambient show ups and working. But sure, there are the same “failed to” words at the end.
My card is radeon9250, and from "info about card" on morphos side it show device as "RV280 [Radeon 9200 PRO] (0x5960)". And loaded driver is "ATIRadeon 52.37 (06.09.2020)"
Edited by kas1e on 2023/6/28 15:26:36 Edited by kas1e on 2023/6/28 15:28:35 Edited by kas1e on 2023/6/28 15:30:49 Edited by kas1e on 2023/6/28 15:50:25
Or if it's easier to just open source amigaboot.of
That's next to impossible since it includes code from several developers and you'd need to get new licences from all of them, or remove their parts. For example you wont get any open source licence from me and at least the support for booting from SFS partitions would have to be removed in open source versions of amigaboot.of and amigaboot.ub, and if it's using anything from the CDFileSystem sources support for booting from ISO9660 has to be removed, or reimplemented from scratch, as well.
Quote:
As an alternative route we're not limited to emulating real hardware. That limitation only comes from that the guest OS only has drivers for real hardware. But if there were guest drivers for other QEMU devices we could use them without needing to emulate a real machine. Some arch in QEMU such as arm mips or m68kl have virt boards that don't emulate any real machine but can run Linux only using virtio devices so with guest support anyting is possible (like uaegfx is also a non-existent hardware that is now widely supported) but if we run OSes made for specific machines then we're limited by those machines. We can still try to extend those limits and see if that's possible or not.
I very much doubt there are developers in A-EONs kernel team with the time and/or motivation to implement an AmigaOS 4.1 QEmu kernel. That A-EON has any interest in porting the kernel to QEmu is unlikely as well.
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
