Pegasos2 with RadeonHD/RX via bridge

@joerg
Quote:
But then, it was made via bridge to work on that hardware, and kernel was ok with. Especially on AmigaOne SE/XE/µA1.

@balaton
Will made another with loglevel 7, just need 30 mins out

@balaton
Quote:Should only be possible if it's changed to 32 bit PCI, by Forth firmware scripts or inside BBoot.
Except for 32 bit PCI vs. 64 bit PCIe BARs there is probably not much difference between PCI and PCIe for the kernel, and the kernel only uses what it gets from the firmware.

@joerg

Sam440 has no PCIe either. Yet, a Radeon R9 270x works just fine with a PCI to PCIe bridge. No conversion of bars to 32bit with scripts needed.

It looks like the firmware plays the decisive role and not the kernel. From a kernel pov, PCIe and PCI are similar. The additional features for PCIe like msi and msi-x are not supported anyways by amigaos4

@Balaton
full boot with bboot and adapter/radeonhd attached debug-level 7:
(yeah, [ScanController] strings added)

https://kas1e.mikendezign.com/pegasos2 ... ot_bboot_debuglevel_7.txt

I did brief search on 682B (device id of RadeonHD's display), and on AAB0 (hd-audio of RadeonHD) and find nothing. It just simply stop scanning after the bus.

It sounds like you were right : bboot didn't scan down to bridge, so amigaboot.of , and kernel then know nothing about too

@kas1e
It's not related that BBoot scns the bus and AmigaOS kernel scans it these just both seem to have the same issue to only consider the two top level PCI buses and not expect a lower level bridgw. Fising this in BBoot would print info and change 64bit BARs of the attached PCIe card but if then AmigaOS kernel does not read that info it won't fix it. Maybe we'd also need to make some other changes but that might be difficult or disable the AGP port if we move the info about the bridge there so it would be hard to debug but maybe still possible over serial. Also I can't test it so not sure yet how can I do this but did not have time to look at it in more detail yet.

I think on the AmigaOne XE this bridge also did not work but the other one did so maybe we'll have better luck with that. I think all the info needed can be gathered in one lot if you do dump-all then boot with BBoot with debug kernel and loglevel=7. I already have these for this bridge so only will be needed for the other bridge but then you can get it in one go and don't have to send different logs.

Pegasos 2, AmigaOne, Sam440ep-flex has no PCIe support. But it doesn't matter.

With transparent PCI-PCIe bridge firmware oprerates it like standart PCI-PCI bridge. And transparent means, that messages which the same both on PCI an PCIe definitions are passed-through, different are translated ( for example PCIe assert_int is "translated" to PCI hw interrupt ). Both PEX 8112 and P17C9X bridges are transparent. Hans made some driver optimalizations for 8112 bridge, but for me this bridge not worked.

The only important is, how is firmware capable recognize cards after bridge. Sam440ep do it perfectly, AmigaOne recognize card, but not setup the interrupt nr. and cache line - except this it work. PCIe cards works there with RadeonHD driver. Pegasos I don't know yet. Without correct recognition by firmware Operating System has no chance to operate the card.

Correctly recognized PCIe cards after briges is operated like standart PCI cards.
For me it works on Sam440ep-flex and AmigaOne with PCIe cards upto Southern Island, i.e. HD7970, HD7750, R9 270X. Polaris cards was not recognized.
Today I am using PCIe R9 270X with Sam440ep-flex, and on AmigaOne standart AGP card - there were problems with PCIe card speed.

@sailor

My Polaris was recognized in a sam44-flex. But the x86 emulator wasn't able to correctly init the card. This resulted in a RX driver error which in turn made the sam440 hang during boot.

@sailor

My Polaris was recognized in a sam44-flex. But the x86 emulator wasn't able to correctly init the card. This resulted in a RX driver error which in turn made the sam440 hang during boot.

@geennaam
I checked old logs and you are right - firmware recognized Polaris card ( my was RX460 ) and RadeonRX output was this:



and it ends with this messages and no graphics output.

@sailor
Quote:

As you can see in previous post : pegasos2 firmware did recognize and pci bridge and radeonhd card in : both video and audio part (see the post on previous page).

The problem now, its a kernel for pegasos2, which see only bridge and then nothing happens.

@sailor,geennaam
Issues with driver can be sorted, but for that, kernel should see the hardware in bridge, and so radeonhd driver will try to inits at all. Currently peg2 kernel even didnt know about card in bridge, while OF know about, so RadeonHD driver didnt starts at all

@sailor
Quote:
Maybe you remember how it not work exactly ? Wasnt seen by os4 kernel, so ranger and co fail to see it, or, wasnt seen by firmware ? Or were seen by firmware, and seen by os4 kernel, but driver wasnt working correctly ?

@kas1eQuote:

Here is simple description how 8112 not works for me.

Quote:

That's weird. I thought that the OS is not interested in what is in front or behind the bridge. I thought that OS simply access all cards with PCI addresses which are initialized by firmware.
But I am not kernel programmer, so I can be wrong

@kas1e

I've filed a bug report two years ago. Given the RadeonRX.chip.debug output, it was determined that it was the sam440 u-boot x86 emulator shortcoming and that Hans couldn't do anything about it on driver side.

@sailor
Quote:

So it works as hardware, Radeon drivers even see hardware through that bridge, it just was issues with driver. But hardware were visibly then.

But maybe it was 8111 version of chip, and 8112 have new issue ?

@All

Got power-adapter riser today : tried and it change nothing. The same i can see card in OF, but kernel simple skip it. So this is not the power issue for sure.

Also tried to boot without AGP card in at all : no luck, it just comes to the time when driver should find a card, and "no graphics card found" from graphics.library or so.

So, while i waiting for another bridge to arrive (it will take another 10 days), i will try to boot from Morphos and Linux, so to see, how they see it (and if they at all). By that we will know at least if morphos or linux can see that RadeonHD card in, as OF see it.

Did anyone know what software on Morphos list all the devices like Ranger/Sysmon on os4 ?

@All

So tried to boot morphos with adapter and RadeonHD in, just enabled for their kernel logging of PCI , and that what i have in output:

for bridge:


And for RadeonHD inserted into the bridge (both display and audio):

Display:



Audio:



So Morphos's kernel surely can see RadeonHD as hardware in the log, pointing out that hardware related it ok. Bridge works, RadeonHD in it can be seen from other OS.

Now we need to understand : what problem OS4 kernel have to see it as hardware (i didn't mean working drivers or anything currently, just why it did see bridge, but didn't see what inside of bridge).

Maybe OS4 do see them, but failed to do something, and so we have no logging about ?

Will be interesting to find an app kind of Randger/Sysmon for morphos, to see if from the OS side it see the RadeonHD from bridge too, and not just log the scanning pci bus details..

@kas1e

Quote:

Sound like does not do it recurseivly, I think it only does it as if it was a simple list.

https://www.youtube.com/watch?v=j9yL30R6npk

@LiveForIt

Quote:
Yes, it certainly sounds like it. So, a possible workaround would be to flatten the node structure. Ugly, but it's either that, or someone has to fix the OS' openfirmware PCI tree parsing code...

Hans

@kas1eQuote:

From MorphOS I am using PCItool

@Hans
Quote:

You mean it can be done from boot loaders like amigaboot/bboot, etc ?

Quote:

I think any changes in the kernel is close to 0 chance that anything will be done, or ever will be released even if it will be done :)

Alternatively, we can disassemble pegasos2 kernel, find out the parts which do PCI tree parsing code, make a jump from assembler code to our new C based code, doing correct parsin, and at end jump back to the end of PCI scanning code (like viruses do). Then assemble whole thing back to working kernel code. That of course kind of hardcore, but can be done if nothing help.

At least i doing the same back in the past with the Cisco's firmwares when was in needs to update some parts and didn't have source code of it. And then makes .diff patch for.

Maybe that way will be also the solution and not _that_ hard (see futher in the post for more info).

@sailor
Quote:

Thanks, that the good one !

@All

So, from morphos, bridge definitely sees together with RadeonHD in it, check this out:

(click open images in new window for full sizes):

Bridge:



RadeonHD video part:



RadeonHD audio part:



What i can see from those screenshoots, is that everything on PCI0 except RadeonHD9250 in PCI1 (so AGP), but, the RadeonHD in the bridge (which on PCI0, and which OS4 kernel find), are on BUS#1 . Which mean that OS4 kernel, do read PCI0 and PCI1 lines, but scan (or read from firmware), no other BUS than 0.

Also, we can see, that RadeonHD both Video and Audio pars, sitting automatically on IRQ9 again (dunno if it's done by Morhos's kernel or by Firmware).

So either OS4 kernel didn't scan any other BUS than 0 on PCI0/1 lines (which probably the case), or, it internally scans it, but didn't see it on IRC9, and fail as well (Through i assume we should have errors from kernel logs).

I wrote mail to OS4-Beta about, so anyone with access to source code may check what actually the case there. Maybe Thomas can check it, but if not, as far as i know from the ones lurking around TonyW and Salas00 also have access to ExecSG code, so maybe they can confirm it..

@kas1e
Quote:Your Ranger PCI result, as well as any other Pegasos2 ones I've seen so far, no matter if real hardware or QEmu, are just a simple list.
Check for example https://www.amigaportal.cz/filedata/fetch?id=159426&d=1669032514 how it has to look like on a system with bridge support: It's a tree, not just a flat list.
I don't know if the problem is the Pegasos2 SmartFirmware doing something different than U-Boot, or the Pegasos2 kernel not supporting bridges/trees because, unlike for example AmigaOne SE/XE/µA1 and Sam4x0, the Pegasos2 hardware doesn't include any PCI-to-PCI bridges and therefore including support for it wasn't required.