Pegasos2 with RadeonHD/RX via bridge

@joerg
Quote:

It looks like not pegasos2 smartfirmware : Check 2 previous posts of me with screenshot and info from morphos's boot. It explains everything probably, but bottom line is : morphos kernel do scan other BUSs than 0 on PCI0/1 lines and so find RadeonHD in bridge, while, the OS4 kernel seems didn't scan any other BUS than 0 on the PCI0/1 lines, so have flat list => fail to find RadeonHD which on the BUS1 of the PCI0 line of bridge.

On the screenshots you linked in the Sailor's article, it also shows that RadeonHD sits on the BUS2, of some PCI line. So it can one more time confirm that pegasos2 kernel do have issues with scanning any BUS except 0.

@kas1e
Maybe MorphOS is scanning the PCI bus(ses) and builds the PCI tree, incl. support for bridges, itself.
AmigaOS doesn't, it simply uses whatever it gets from the firmware.

@joerg
Not sure that there are any "Special support for bridges" anywhere, be it morphos or os4, as bridge is simple "PCI" from hardware point of view. PCI which have just different BUSs than the main (0) one.

And, all other AmigaOS machines do see bridges and Radeons in it, with the same version of kernels, and even on the same "32 bit only" kernels for machines such as XE, mA1 and sam440. This is limitation only of pegasos2 kernel and its PCI parsing code. Probably pegasos2's PCI scan code of OS4s kernel simple assume that on pegasos2 only PCI0/1 lines, with BUS 0 everywhere and that all.

And in firmware we do have RadeonHD visibly as i show before, just it's sitting on other BUS, and amigaos4 kernel fail to see that. But firmware definitely see it, and that probably what Morphos kernel get, just morphos's kernel do have correct parsing of BUSs, while OS4 pegasos2's (and only pegasos2) kernel don't do so.

@kas1e
Quote:Wrong, all AmigaOS 4.x kernels are very different and only include the required code for the specific hardware (only code for the CPUs supported on that hardware, motherboard specific hardware, etc.), and more important: AmigaOS 4.x kernels depend on the firmware, MorphOS may not (or much less).

Quote:Maybe, but since there is no bridge, and as result no PCI tree but just a flat PCI list in a Pegasos2, unlike on all other systems, support for it in the Pegasos2 kernel (or more specifically the conversion of the OpenFirmware PCI list to the PCI tree required by the kernel) wasn't required...
If there is only a single MorphOS kernel for all systems, unlike the different AmigaOS 4.x kernels for the different systems, it has to include support for bridges, for example for the Pegasos1.

Quote:Yes, because the Pegasos2 hardware only has 2 busses, no bridges.

Maybe BBoot can convert the OpenFirmware PCI tree to a simple list supported by the Pegasos2 kernel.

@joerg
Question is : can we, without patching the kernel or patching the firmware, flatten the list from Balaton's BBoot, so, things will have no needs to be scanned recursively by kernel ?
right, you already answer on.

At least, that probably the next step need to be done, to flatten the list, and see how kernel will eat that. Only need to ask Balaton to find time for it :)

@joergQuote:

It is a pitty. Generally, it was no good idea. Even if hardware has no bridges inside, such thing prevents future use of many combo PCI cards.

@sailor
Yes, pity that pegasos2 kernel of OS4 wasn't future-proof, while morphos's one are, and scan all the devices fine, including any bridge/bus/whatever extenders.. Morphos kernel maybe very well sharing big amount of code for all platforms (like PCI scanning), and only specific parts to hardware different. Dunno.

Or, maybe morphos kernel just simple more correctly parse the SmartFirmware output :)

Anyway, what we know now for sure, that is not Pegasos2 hardware to blame that we didn't see RadeonHD over bridge in os4, and not firmware (as both and firmware, and morphos kernel find it all fine and show the same as expected), but , OS4 kernel for pegasos2 which only accept flatten lists.


@All
Hans also have access to ExecSG code, and so he confirms that it doesn't recursively scan behind PCI bridges. And while we do have different kernels for each hardware, i still think that PCI scanning code still copy+paste for each platform and then altered . Possibly for pegasos2 was writing all from scratch, so it wasn't just future-proof ? Or maybe too much were deleted for simplicity code reading..

Anyway... What we left with is only one solution then: if BBOOT can convert the OpenFirmware PCI tree to a simple list, so OS4 pegasos2 kernel will eat it. Of course, if Balaton willing to do so still :)

@kas1e
>Anyway... What we left with is only one solution then: if BBOOT can convert the OpenFirmware PCI tree to a simple list, so OS4 pegasos2 kernel will eat it. Of course, if Balaton willing to do so still :)

You can always support/motivate @Balaton on his home page with some donation.
As he himself emphasizes he is not doing it for money.

"...Previously no donations were accepted and they are still not solicited but to respond to "popular demand" (i.e. a few people asked) now there is a way to...".

He would just have to chalk up (zero-one) whether he intends to do so.

I don't have Pegasos II hardware only Qemu, but I can make a donation as a thank you to the AOS4 community and for Balaton's work

http://zero.eik.bme.hu/~balaton/qemu/amiga/

edit:
I passed on because that's what I've always wanted to do anyway.
Not much but that's what I can currently afford.

@smarkusg
Yeah, that the good idea !

@balaton
check pm on this site plz :)

please, for blonde - what i BBoot ?
I found here many citations, but no what is it.

@sailor
Quote:

BBoot is opensource realization of bootloader by Balaton. So to use it instead of close-sourced amigaboot.of. Balaton did it initially for QEMU (so to be able to fix some issues to make ability to use real RAdeonHD/RX cards with it on QEMU), but then , this BBoot works for real pegasos2 too, and probably can be used to fix an issue with "os4 kernel read only pci0/1 lines without recursive reading of what firmware gives on other buses than 0".

Together with that, BBoot already faster on system loading : because it did use *.zip package with all kickstart modules, which loads to the memory, then unpacked, and loads from. This gives on real Pegaoss2 +10 seconds to load up the whole system. Quite a lot.

It also offers a lot of debug output, more control, and all that stuff, so, if not BBoot, there are surely no any hope for RadeonHD/RX for pegasos2, but with it, there is hope.

There are probably currently 2 ways to try with to fix this:

-- or flatten the list of PCI devices (so system will see it flat, and os4 kernel will see it too)
-- or disable the AGP port and move the info about the bridge's card there (which probably much harder)

You can grab latest bboot from Balaton's site (it's coming with nice Readme with all the info inside):

http://zero.eik.bme.hu/~balaton/amiga/bboot/

I also got to the same conclusion as @Hans that maybe if BBoot would move the device bekind the bridge to one level up to be at the same level as the bridge (and then fix up 64 bit BARs) then maybe the pegasos2 AmigaOS kernel might find it. But I don't have time to try that now so either wait until I get to that or the source is open so anybody can attempt to change it to do that.

(If you have a patch for BBoot I'd appreciate if you can send it to me so I can merge it and keep one up to date release with all the chnages just to make user's life easier so they don't have to follow a lot of forks.)

@sailor:

https://osdn.net/projects/qmiga/wiki/SubprojectBBoot

unfortunately OSDN is dying lately so here's an alternative download link that should work:

http://zero.eik.bme.hu/~balaton/amiga/bboot/

@kas1e, @balaton
thank you for explanation

@kas1e
Quote:All previous systems used U-Boot as firmware, Pegasos2 was the first which didn't (except for the classic Amigas, which use AmigaOS 3.x as "firmware").
Additionally the OS4 kernel developers modified and improved all firmwares, that way the kernel gets exactly what it needs from it. Only with the Pegasos2 SmartFirmware that wasn't possible, which obviously means the code converting firmware data to the one needed by the kernel had to be reimplemented from scratch for the Pegasos2.

Another problem: OS4 for Pegasos2 was implemented (or at least released) after the Pegasos2 wasn't produced anymore, only very few used ones were available for using AmigaOS 4.x on it, and next to no OS4 developer had a Pegasos2, while nearly all developers and beta testers had an AmigaOne and/or Sam4x0 and could help debugging problems on those systems.
The Pegasos2 is very likely the least used AmigaOS 4.x system, even classic Amiga should have more users (and that before WinUAE got PPC support), there are very likely much more users using AmigaOS 4.x with an QEmu emulated Pegasos2 already than AmigaOS 4.x users with a real Pegasos2.

@joerg
>The Pegasos2 is very likely the least used AmigaOS 4.x system, even classic Amiga should have more users (and that before WinUAE got PPC support), there are very likely much more users using AmigaOS 4.x with an QEmu emulated Pegasos2 already than AmigaOS 4.x users with a real Pegasos2.


Looking at the present time, the Pegasos 2 is probably the most documented hardware under AOS4 that a mere mortal has access to.

the ugly duckling grows into a swan

@smarkusg
Quote:Sam440 and Sam460 documentation should be available as well, at least the docs for the 440 and 460 SoC are.

>Looking at the present time, the Pegasos 2 is probably the most documented hardware under AOS4 that a mere mortal has access to.

not to say that Pegasos 2 is simply the best "1st generation AmigaNG"

@smarkusg
About donations, to quote from the same place you quoted it also says:
"I will work on what I like. I'd like this to become a collaborative effort so If you want some new feature or improvements then a better way is to start contributing to the project"
So donations won't change what I work on (I may still find something else more interesting and rather do that) but donations are appreciated of course so it's there if you think it's the best way to give a thanks but I'm also happy if people contribute their time to make this better so not all progress depends on me alone.

As for what I've found more interesting in tha past days than BBoot I'll say in the next post.

@All
I think i should share it : Today checked new beta of kernel, and there can see that Hans fixed 64-bit PCI BAR handling for Pegasos II. I am not test it at the moment, as issue with "flat node reading from smartfirmware" still there, and how driver works with new kernel can be only seen afte driver will try to loads, but then, anyway, no one know when new Kernel will be released, so for the good next few years BBoot with 32/64bit fixes still need it , of course.

@All
So, received a second bridge, this time : Startech's one, based on Pericom PI7CX9111SLBFDE chipset.

And situation (as expected) exactly the same as with previous one. It's the same detected fine by OF of pegasos2, the same i can see bridge on /pci/pci place, and same have inside both display@0 and pci1002,AAB0@0,1 for RadeonHD card. And on the boot with loglevel7 it shows exactly the same : Bridge detected, but nothing in.

Of course, that was expected after Hans confirm that pegasos2's kernel code for reading OF PCI tree is flat, but still, i tried it because received one anyway. Was in hope for some miracle, but nope :)

@Balaton
Do you think is it worth at this point at all to post any logs about new pci bridge ? Probably it will add nothing to what we know already ..

@Hans
Seeing that you add BAR fixes into the kernel for pegasos2, do you think it easy or hard to implement non-flat reading of PCI devices as well ? Or too much hassle ?