@MartinW
Quote:Looks like all of his software, for example nvme.device as well, was removed from OS4depot, the only exception I found is ahidrv-filesave

@joerg,geennaam
So that prove my troughs that if issue with 64/32bit BARs still there, then OS4 kernel (and so all the apps using OS calls), can't see a shit :)

But then, RadeonHD have both video and audio parts. And still, in the Ranger/SysMon it not only didn't list video part (which is 64bit, so ok, understandable), but also hd-audio. It didn't show anything, like, bridge is empty.

From another side, probably we do have good news anyway : OF itself
see both bridge, and RadeonHD in, so it's OS4 issue.

@geennaam
Btw, is it possible to boot QEMU with pass through card attached, but display over something else, and to test to boot with BBOOT and AmigaBoot.of , to see, if Ranger will show pass through card attached at all with AmigaBoot.of and / or Bboot.

I.e. if amigaboot.of booting will show nothing about card in Ranger, but BBOOT booting will show it, then it will mean that on real pegasos2 we still have issues with 32vs64bit BARs things left.

@all
Maybe worth to try to boot with Morphos and Linux ? To see what they tell, about, etc. ?

Has this driver been pulled for some reason? I can't find it on OS4Depot.

@geennaam
Quote:Yes, it just displays what the AmigaOS 4.x kernel found and added to the expansion.library lists, it doesn't include own PCI(e) hardware scanning code.

Quote:Unless I understood something wrong the Marvell has no bridges, just 2 PCI busses.
The Articia-S (MAI Teron CX/PX/Mini PReP reference/evaluation boards, AmigaOne SE/XE/µA1, and Pegasos1) has 2 busses as well (first one, 0.0.0, directly connected to the onboard ethernet chip, the VIA southbridge incl. PATA, USB, etc. and the 3 PCI33 slots, 0.6.x-0.A.x), but the other one (0.1.0) uses an internal PCI-to-PCI bridge for the AGP and PCI66 slots (1.0.x + 1.1.x).

@kas1e

I think that Ranger just lists the PCI devices which are reported by the system.
The pegasos has two bridges. That results in two busses. Ranger reports my RX 560 just fine behind the AGP bridge. With the assumption that you already use the PCIe power inserter, it looks like the kernel is not able to scan behind your 8112. Maybe you have better luck with the pericom bridge. This was also the key to get those HD cards working on a sam440.

@kas1e
Quote:In AmigaOS 4.x kernels only supporting 32 bit PCI, like the Pegasos2 one, 64 bit BARs don't exist at at all, nothing, incl. drivers and tools like Ranger, can access it.
In your dump_all_with_bridge_and_radeonhd.txt for the PCI->PCIe bridge there is "xp6" in reg and assigned-addresses. I don't know what "xp6" is, but since for memory BARs "x" is 64 bit and "m" is 32 bit it may be something 64 bit related, and therefore not supported by the kernel, as well.

@balaton,geennaam
So, takin into account latest pciconfigs and what geennam says we do have pci bridge seen on pci@6 and radeonhd card witb hdaudio visibly too.

Question is : why os4 apps such as ranger and sysmon didnt see card ? I assume if it issues with BARs we still should see it as hardware with wrong memory regions,etc, right ? Or issues with bars can be resulted with os4 not see card as hardware at all ?

@kas1e

In case you didn't know: 1002,AAB0 is the hdaudio soundcard endpoint for audio over HDMI or DP.

@balaton
Quote:



/pci/pci there is the same as /pci@80000000/pci@6
I just before forget to do "ls" inside as well, so didn't see display@0 and pci1002,AAB0@0,1


Then you can also get .properties of that to see how the firmware sees this:

for display@0:




For pci1002,AAB0@0,1:




Quote:

full dump-all with bridge + inserted RadeonHD:
https://kas1e.mikendezign.com/pegasos2 ... h_bridge_and_radeonhd.txt


Quote:

It's like same like .properties looks like, you shoud inter to the directory to be able to have output from, so that the outputs:

/pci/pci:




/pci/pci/display@0:



and /pci/pci/pci1002,AAB0@0,1:

@balaton

One thing to note is that I do not experience any freeze. And I don't have that patch applied. Maybe because I'm running on an Intel platform.

It's just slow.

@geennaam
On pegasos2 ultimately everything uses the ISA IRQ 9 and PCI INT pins are handled within PCI bus emulation so they are also shared. The pci.1 and pci.0 are separate buses so they have different PCI bus emulation but I think they PCI interrupts are connected to vt8231 PINT inpits which is then uses the PCI interrupt handler of the PCI bus the VT8231 is connected to that is pci.1 even for devices on pci.0 which may or may not be a problem. I also don't fully understand how this works in QEMU and this may have problems. I had may patch originally track each interrupt source separately but testing by Martin found it made no difference regarding freeze so that maybe caused by something else.

@MartinW
You'd need GNU make, maybe try gmake if make is a BSD make, I may be using some GNU extensions. For the library that's probably 64 bit but BBoot is 32 bit so needs corresponding libgcc. In makefile I have: powerpc64-linux-gnu-gcc -print-file-name=32 because in /usr/lib/gcc I have a libgcc.a for 64bit but there's a subdir called 32 with 32 bit versions of the same. If your distro packages it differently you may need to adjust it or it may have a different package for powerpc-linux-gnu-gcc instead of powerpc64 that contains the 32 bit version.

@geennaam
Good to hear it works. Having BBoot output from where it works would still be good to at least know what settings work and what don't.
The problem with resetting the card is independent of AmigaOS or BBoot or any of my code so can't help with that but I guess this may have something to do with the VGA part of the card being used by something. You should make sure your BIOS does not try to use the card and no driver is loaded for it in Linux. There were some mentions of vga arbitration and some patches needed for ATI cards somewhere but I may be completely wrong about this so try to search for and check info on this. The same problem happens when someone passes through GPU for Windows guest so I think there's some info on that somewhere.

That's not the entire issue though - there's a message lost in the wilds of this thread somewhere. The RX driver doesn't correctly ACK with a 1 or a 0 as it should do once it has serviced the interrupt. That may not be exactly correct, but something like that.

But yes, I saw the same behaviour with the RX cards.

@kas1e
Every PCI-PCIe bridge is in real PCIe x1.
Even if it has ×16 mechanical connector, electrically it is only x1. So you can connect x1 extender to x16 bridge connector with no slowdown.

And powered PCIe x1 - PCIe x16 adapter ( for minig rigs as geennam suggested ) is simple serial lines extension, totally passive. You not see it in Ranger.

@MartinW

Quote:

I have my RX on the AGP bus. As far as I can tell it has its own interrupt.

@geennaam

Yes, unusably slow but AFAIK Hans is potentially looking into the shared interrupt support so I'm guessing if that happens then it would help, if not fix it.

You also have the problem of having to reboot the host which if you think about it isn't unreasonable behaviour as a reset of the card either via reboot or shutdown would always happen on real hardware.

@MartinW

The performance is slow on your RX cards as well?

I didn't apply the interrupt patch. So just a clean build of the QEMU master sources

@balaton

I installed a Debian VM, installed the packages and the linker doesn't like the version of the library. I've tried Ubuntu, Arch, Debian - I can only guess (and it is a guess) that the version of GCC is too new?

I also had a quick go under AOS4 but that just throws makefile errors which I've got when I've tried to compile anything so far (something about invalid separator). I need to look at that independently to this.

@geennaam

The previous error you showed is what happens on a card that doesn't release everything properly on QEmu shutdown. I've found that the RX cards do that, especially if the emulator doesn't shut down properly using the power off option in AOS4. You have to reboot the host.