Pegasos2 with RadeonHD/RX via bridge

@All

Is it correct datasheet for pegasos2's MartvelDiscovery2 MV64351 northbridge ?:

https://www.freecalypso.org/pub/PowerP ... eets/DS_64360_1_2.pdf.zip

Sounds like this, just need to be sure.

@kas1eQuote:

Yes! Pegasos 2 has MV64361 version:

@balaton
Quote:If you want a free AmigaOS-like OS there is AROS. After only about 30 years of open source development they manged to re-implement about 80% of AmigaOS version 3.1, released in 1993. Most of the AmigaOS compatibility was added to AROS in the last 2-3 years. AROS is, or at least was in early versions of it, the base of large parts of MorphOS, it's the base of ApolloOS as well as part of the OS used by the A600GS (improved by Enhancer/SystemV46/V54 parts to make it usable).

However, AROS is really free software (the APL licence used for most of it's parts is similar to MIT, BSD, Mozilla and Apache licences), i.e. the exact opposite of the GPL you seem to prefer.

@kas1e

It could be really useful to improve QEMU PegII board, there's really everything on this PDF.

@flash
What needs improving on the MV64361 emulation in QEMU? I think it works well enough now. This chip has tons of features but if nothing uses them it does not worth emulating all details that will be unused. I think I already have a few unused things that weren't needed but implemented it anyway.

@joerg
Of course I know about AROS and maybe if it weren't for the fights between 3 independent groups in tha past 30 years but instead of duplicated efforts everybody could have agreed on contributing to one free and open source code base that would benefit everybody then it could be where Linux or at least Haiku is now. Unfortunately it did not go that way but maybe after 30 years it's not too late to try that eventually. I'm sure this was discussed before and what I say is nothing new so no need to repeat all the past debates but maybe people change and can reconsider decisions to keep AmigaOS alive in some form. If not then that's OK too, things will just go on like before.

I prefer GPL over BSD license for this because it makes sure that everyting will remain free for everybody so the most developers could contribute. Both who allow free like BSD and don't care much what it's used for and those who want it to be kept free. This worked for Linux and QEMU. The AROS license is similar to MPL which also says it should be kept free so it's not opposite and completely free like BSD but maybe less strict than GPL. Contrary to what some may believe GPL does not prevent commercial use, it just gives equal opportunity to everybody. There are/were whole companies like RedHat and Suse for example who lived from supporting open source operating systems and the base of macOS is also freely available so opening up AmigaOS would not make business impossible but those who hold the pieces maybe don't get this or think otherwise.

@kas1e

I don't know anything about OpenFirmware, but I did program the Amiga in Multi-Forth for a time way back when, and still remember some things about Forth.

Quote:
"(config-addr -- data)" is a Forth stack use diagram. It means that the word 'config-l@' expects to see 'config-addr' on the top of the stack when it is executed, and it leaves behind 'data' on the top of the stack when it has finished executing.

Typing a number alone adds that number to the top of the stack. So the correct sequence would be "16 config-l@", which puts the value 16 (the "config-addr") on the stack, then executes config-l@. In Forth you would then type a single period ('.') to print the top value on the stack, which would be whatever config-l@ left there (the "data"). But maybe that's not required in OpenFirmware.

@msteed
Thanks !

So, that what i tried then:



So yes, syntax exactly like you say, and while i am in the bridge it return 0x646011AB. But then if i type "12 config-l@" , it return same address. Same as 16, same as 20, or 50 config-l@ , return the same address.

And even if i go to any other directory, be it another /pci@C0000000 , or anything, typing those "16 config-l@" , "config-l@" and "." combo, always return at me 646011AB. Like, it does not matter where i am are in the FW, it just read by absolute address.. But what i need is to check BAR0 of the video card in the bridge..

I do check some older output from BBOOT by balaton, and this 0x646011ab address happens to be in the log like this:



So it seems to read some first (base) address of whole PCI thing, probably without depending on where we are at now in OF.. Question is how to read BAR0 of video card in bridge ..

@kas1e
That's what the OpenFirmware PCI doc should tell you as all this is documented there. BBoot might also help but you haven't posted the BBoot output with your bridge and card so I don't know. Or you can go back to the long thread where we've patched tha 64bit BARs from Forth, I think there was a script for it there so you can start from that too.

@balaton
There is a bboot output with only attached bridge+radeonx1950 in it (i.e., radeon9250 removed from AGP slot):



I don't see if it shows a card behind the bridge ?

@kas1e
BBoot on pegasos2 just lists the devices that the firmware detected so if the firmware does not look behind the bridge then BBoot won't do that by itself. This shows two things however. The correct format for config-addr which is more difficult to get from SmartFirmware so BBoot can help here, that's why I've added this output when we needed it for the 64bit BAR script (16 is not even a BAR, those are at 10,14 etc.). And that the firmware may not correctly init the bridge so to access devices behind it you'd need a driver for PCI bridge in AmigaOS first (or teach BBoot to handle bridges but then it would also need to modify the device tree which would get complex as AmigaOS gets the device tree from RTAS so then BBoot would also need to replace RTAS and that's the point where I said it would be too much work for a use case better fixed in AmigaOS in the first place and doing something else is better use of my time).

@balaton
Sorry for being lame, i am not too deep in techincal knowledge there, but did you mean that OF also didn't recognize card behind the bridge ? How then it see when i do "ls" and .properties in necessary dir ? And then , Linux surely list the card behind the bridge too, as well as some beta-kernels we test , just issue is with proper accessing too.

And what we tried to be sure of : if the OF can read a card's registers properly or not, but only list it. If not, then it mean Linux have its own code, but still, while see the card, fail to init the base address of it.

@kas1e
Technical knowledge isn't something god given or special talent. All it needs is ability to think logically and be able to read documentation ant then it only takes time. No need to say sorry, just spend the time needed to acquire technical knowledge.

I don't quite know what you get as I only see what you post here so I don't know what beta kernels do or how it appears in firmware. If there's a device node then that means the firmware does look behind the bridge but I'm not sure it inits the card correctly or AmigaOS can handle it without further tweaking like what BBoot does for cards not on the bridge. It does not show in BBoot output because BBoot does not handle bridges. I could enhance that but as I said it's probably a limited use case better handled in AmigaOS so even if BBoot fixed 64bit BARs behind the bridge maybe that would not be enough for it to work and still would need AmigaOS changes so then all of it could be handled there.

(Also realised where did you get 16 for BAR address. Forth is hex by default do dec# 16 is wriiten as 10 in Forth.)

@balaton
Quote:

You probably don't remember it all, as everything started before were with full logs about bridge and card in, to repeat them:

Bridge itself:



The card in, display0:



And the card in display@0,1:



So, firmware definitely can see the card in behind bridge, and it definitely can't be done without reading a proper registers from the card itself , right ?

And what we want to just confirm by this "config-l@", is that indeed firmware can or can't read correctly registers from the card.

I mean, one thing it build devie three, and can see card (mean that it can read registers from card), and another thing how : if we can do it by config-l@ too, then it mean that it works at least from firmware side 100% (just to confirm that building of three mean reading from registers too).

Then, from kernel/driver side, we tried RTAS and fail : but we need to know that RTAS indeed fail (by compare addresses , etc). And if yes, and that true, we need to go this direct register reading way, as OF do (seems so).

Of course doing this in bboot which is opensource are preferable way for all of us, but as you lack interst in, and don't want to do it even for a bit of $ to cover hassle (i asking about before if you remember), then we forced to work with the kernel, which maybe someday will be released :)

@kas1e
I remember that we've concluded that you can't use my donate button and I can't accept what you can use so we've left it at that. It's OK, it's not about money as I've made it clear before, donations aren't required, it's just there to allow people who want to thank me that way can do so if they wanted. I prefer to work on what I'm interested in and I can't use this bridge support much as I have no real pegasos2 (also no real gfx card or driver for it) and on QEMU even with PCI pass through there's no bridge visible for the guest so there the problem is already solved by current BBoot.

This looks like primarily a problem in AmigaOS kernel. If it can't even see the card then maybe it also does not look behind the bridge like BBoot (so does not even read the device tree below the bridge) and when it did, it might get problems with 64bit BARs and RTAS not supporting bridges. Patching all this from BBoot is too much work (almost like reimplementing a large part of the firmware) which I'm not interested to do just to fix a closed source OS that's not even free and others would want to benefit from it. This is something that should be fixed in the AmigaOS kernel and I'm not the right person for that job.

I remember you've posted info about this before but it's in that long thread somewhere and was a long time ago so I don't remember the details any more. From the firmware listings it seems the firmware did find the card and could access BARs and config registers but the ROM is missing so not sure it could run it and init the card fully. If AmigaOS only needs the data from the device tree then maybe it does not need RTAS just to parse the tree but if it needs access to config regs and ROM then it might need to access PCI directly and not via RTAS if that cannot handle the card behind the bridge.

I think Hans already understands the problem, it just takes time to do all this by him alone.

@balaton
Quote:Main difference: APL/MPL only requires to release changes you did in those sources. Everything which is free code stays free, but it doesn't affect your own/other code used in the same project, which you can release, or not, as open source as well. It's your choise.

OTOH with the GPL you have no choice/control over your own code any more, even just linking with a GPL library will force you to release any sources linked with it, no matter if you want to do that or not. Even worse: Any output/data generated by GPL software is GPL as well. A lot of GPL software like GCC includes special exceptions to the GPL allowing to use the code generated by it to be released with another licence. If GCC or glibc would be just GPL, without such exceptions invalidating the worst parts of the GPL, it wouldn't be usable at all for most software.

@balaton
Quote:

Both OS4 kernel and Linux kernel do see card in the bridge (Linux kernel by default, os4 kernel with bar fix, or via bboot), see on Linux for example (with Radeon x1950):



And on OS4 (this time with Radeon HD):




Problem comes after, when both, Linux and OS4 kernel tried to find a base video RAM address, which result in 0x000000 for both kernels, see on Linux:



And see on OS4:



Error exactly the same for both cases: 0x00000000 as base address, while shouldn't.

I do not know details about linux kernel for pegasos2 (maybe worth to check source to be 100% sure), but it seems it's the same as OS4 kernel for peg2 tries to use RTAS for getting base address of video card behind the bridge, and can't (in both cases 0x00000000). As i do not know PCI stuff for the moment (reading the doc now), i assume that to know base video address you need to read some configuration registers, which, by some reasons, fail, when RTAS is used (if, that is what Linux use too, same as OS4). That why we worry at all with "config-l@" , so to check if we can from firmware get the base video address of card behind the bridge, because , if we can have this card listed, then we somehow already can read configuration registers behind the bridge, just not for base video address by some reasons.

In other words, interesting to know why RTAS for both kernels (and OS4, and Linux too), can see the video cards behind the bridge (i.e. can read configuration registers via RTAS seems so), but then , can't get the same way the base video address and fail the same with 0x0000000 when trying to read configuration registers again.

But i need to read some pci/marvel pdfs too for now, yep :)

@kas1e
I think Linux also uses RTAS on pegasos2 if I remember correctly but I could be wrong. It can be checked in Linux source or you could boot Linux on QEMU pegasos2 and add debug log to RTAS calls to see if they are called. Even if config-l@ can access card regs you can only use that from firmware before OS boots but the BAR addresses are also in the device tree so you could get it from there without reading the register. Otherwise if you need to write or access other regs and can't get it using RTAS then it needs to access PCI directly.

@joerg
Quote:
And there's a reason for that which is to ensure that GPL code is not used in commercial code only in free software so it cannot be exploited without the developer's consent (who still has the right to sell their work under a different license as they own the copyright so commercial vendors could buy a license from the author for code otherwise available as GPL but cannot just copy and use parts of GPL code unless they also publish the result as GPL). If less strict MPL like license is needed there's LGPL for that which only applies it to the code itself and allows it to be combined with non free software (but still does not allow copying part of LGPL code into non LGPL or GPL code and make it non-free).

@balaton
Quote:Obviously you don't understand what the GPL is about.
At least 90% of the GPL software is sold commercially (Google, Samsung, LG, Sony, etc.: Android, based on the GPL Linux kernels and several other GPL software, Xiaomi: MIUI, which in most parts is based on AOSP, the open source parts of Android, Apple: iOS, based on NextStep (not GPL Linux but a BSD though, but still no big difference), etc.).
For PCs and servers: Red Hat Enterprise, SLES (SUSE), IServ, UCS and several other commercial Linux distributions.