Pegasos2 with RadeonHD/RX via bridge

@Hans
Quote:
I wrote it after reading the OpenFirmware PCI doc I've linked to above. Maybe also check the Marvell Discovery II docs as that provides the PCI bus on pegasos2.
Quote:
These are from libpayload as can be seen in the comment at the top of the file.

Did you try if you can access the card behind the bridge with config-l@ config-w@ and so on from the SmartFirmware prompt? Maybe you're just passing the wrong address to the RTAS function that's why it does not read the right bus.

@balaton

Thanks. I'll have a look at the docs.

Quote:
I don't have physical access to a Pegasos-II, so this is something for kas1e to try. He might need a bit more guidance on how to use it...

Hans

@balaton
Quote:

Can you maybe point out of how/what exactly to check from OF ?

ps. If issue is passing the wrong address, it did't explain why debian fail to remap phys memory too and takes it as 0x000000.

@kas1e
I would also have to read the OpenFiware PCI docs to check how the config-* words work, I don't remember that now. So you could have a look at that doc then try to read config space vars like vendor/device ID and BARs of your gfx card behind the bridge from the OpenFirmware prompt just to verify it works on the OF level at least and to find the right address that should work with RTAS too. Maybe access the SmartFirmware prompt via serial from another machine so you can cut&paste and don't have to type that much.

I don't know what Debian did, you have not posted enough details to understand what happened there. Maybe posting full Debian logs from boot and BBoot output with the card may help to see more (BBoot won't handle bridges but if the card appears in the device tree it should at least list basic info on it).

But I don't have PegasosII hardware, don't have these gfx cards and even if I had a card and it works with QEMU with pass through I don't have AmigaOS drivers for it so I'm not much interested in this.

@balaton

Thanks for helping despite the lack of interest.

I find the OpenFirmware documentation to be rather difficult to understand. Theoretically, section 2.1.4 explains how to address a particular card's config registers. However, it glosses over the "PCI domain." How do we address a particular PCI domain? How do we even know how many PCI domains there are? It seems to be related to how many PCI root controllers there are.

Then there's this annoying statement:
"Note: the decoding mechanism (e.g., the address bit selected) from the Device Number is system dependent. Fur-
thermore, the implementation of the Open Firmware
config-xx words can "hide" this detail. However, it is
recommended that an Open Firmware implementation choose a numbering which is meaningful to the user."

So, we don't know in what format to pass the config-* parameters...

I have also been unable to find a specification for the RTAS feature. There are vague references to it in some documents, but no link to a specification.

Hans

@Hans
You probably don't have to be concerned about the PCI domain. I think a domain corresponds to a /pci node in the device tree but since the bridge and the devices behind it appear in the first domain where are all the other PCI devices it should be accessed the same way and don't need to consider the other domain where is only the AGP port. I don't know how this works with RTAS, but in OF you can cd into the right /pci node to call the corresponding config words for that domain or may need to open the device node first. The config words should take address in the same format as it appears in the device tree and I think the same should be true for RTAS or these mostly follow the same address encoding that the PCI spec describes and also shown in the OF PCI doc.

@balaton

Ah, okay. So if kas1e cd'd to the graphics card, then maybe config-l@ 16 would read BAR0 (BAR0's offset is 16, or 0x10).

AFAICT, with RTAS you need to pass the full PCI card address: PCI domain, bus, device, function. And, of course, the register you want to access. I've tried that, and it works for all cards except the one behind the PCI-to-PCI bridge.

Hans

@Hans,Balaton

Ok so, I attached the bridge with X1950 to the first after AGP PCI slot, and then bridge show up on /pci@8000000/pci@7, so:



So on PCI line we have bridge, with 2 displays in (probably for 2 different video outputs?)


going to any of them via "cd" and typing "config-l@16" cause :



Same if i tried with space between, i.e. config-l@ 16. Writing "config-l" or "config" or "config-w" without args cause the same error. Typing it all with dot at beginning like ".config-l@16" or ".config-l@ 16" (with space) cause same errors.

Any ideas ?:)

Shouldn't we do something else to be able to use those "config-" commands ? Maybe we should enter in some mode first or something ?

@kas1e
Try the other way round: 16 config-l@

I have very little experience with OpenFirmWare, and remember the syntax being unusual, and error messages being very cryptic. That's because it's based on the Forth scripting language, which is stack based. It takes some getting used to.

I did manage to piece together a script for fixing up the previous PCI issues (i.e., making a 64-bit PCI device look like a 32-bit one), and the syntax looked something like this:
s" /pci/display@2" find-device

Hans

@kas1e

Quote:

Not here. I just booted my Debian net installer on my XE. Exactly as on the Sam. It wants a mirror and won't continue without it. It needs to download the base system. The net installer must have been updated since.

Quote:

I searched for hours and didn't crack it. It always gives a bad mirror at first. If I manage to give it a mirror it accepts it ends in an arch error as ppc not supported. In addition it wants Jessie but that's obsolete as Jessie isn't stable any more. The problem is you can't exactly tell it you want jessie or enter jessie as it always looks for stable, oldstable, etc. It's just too hard coded. It's ppc which always has the worse support. Especially Ubuntu where they break ppc32 files so they don't work in the archive but don't care because it's ppc and not x86 despite both being an obsolete 32 bit arch.

Anyway you were looking for some ISOs. Here's Ubuntu. But these are a full image so will work!

I found a good list of PPC images is here:
https://vivapowerpc.eu/software/Ubuntu/

lubuntu-16.04-desktop-powerpc.iso
ubuntu-16.04.6-server-powerpc.iso
ubuntu-mate-16.04-desktop-powerpc.iso

There is also an extra archived mate with 16.04.1 from 2019 and a 16.10 from 2020:
https://releases.ubuntu-mate.org/archived/16.04/
https://releases.ubuntu-mate.org/archived/16.10/

@Hans
Tried all different ways of syntax and still have no luck (with 16 before, after, with spaces, etc ,etc).

But, what i find in some docs are:

There are two types of words, global and local. Global words come with the version of Open Firmware present on the computer. Some of these are placeholders that get overwritten by device specific local words. Local words are restricted in scope to the device that contains the word. The available global and local commands can be listed with the command "words"

So, if i come to the exactly video card and type "words", i then have nothing, see:



But if i go only to the bridge itself , i.e. just cd /pci/pci@7 and type "words", then:



As i understand, those local words (like config-l@) can be used only when we in some device which can be used with.

Then when i am in the bridge, then typing "config-l@" without args do not cause error. But also other ways too:




Simple help on config-l@ (while being in the bridge directory), print out that:



But i not sure, if that can help us ? I mean, what "config-addr -- data" mean, and, can we provide as argument "display@0" or "display@0,1" to read what we want to read ?

So far tried that with no luck:

config-l@ display@0 16
config-l@16 display@0

Question now what is that "config-addr -- data" , from where get it, and will it of any help for us.

Maybe we somehow need to open/select the card in firmware to be able to have those words like "config-l" to work with ..

@kas1e
I've read somewhere: "If all else fails read documentation." Ever thought about that? If you want to learn Forth try forth.com. Have you even seen old reverse Polish notation calculators that are stack based? Those where you had to type 5 3 + Enter or something like that to add two numbers and display the result? Forth works like that, so you have to push arguments to stack then call operation word and then you can find results on the stack that you need to print to get the result.

But this probably does not matter as it seems even if you can get the needed values from the SmartFirmware prompt they may not be accessible via RTAS.

@Balaton
Quote:

Aren't we trying to play with all this config-l@ stuff exactly for the reasons to know if smartfirmware read things correctly already, so to see if address we find is correct, so to not use RTAS if RTAS fail, but direct access ?

I mean what make you think that "they may not be accessible via RTAS" ?

@Hans
Quote:

Then this may be a limitation in RTAS as it only has provision to pass a single address but not PCI domain or host. So if RTAS on pegasos2 interprets bus 1 as the AGP port (which is really another PCI domain) then maybe there's no way to access devices on bus 1 on the default PCI domain. You can test this theory if you get data from the AGP port with bus 1 and device for the card on that bus. Then reading bus 1 for device behind the bridge would try to access the wrong PCI domain and so won't find a device there because you can't have bus mean both bus and PCI domain so you could either access all devices on one domain or bus 0 of all domains depending on what RTAS uses the bus part of the PCI address for.

If my theory is true then you probably can't use RTAS and you'd need to write a proper PCI driver in AmigaOS to be able to access all devices on all domains. I could help with that but I only work for free on open source projects that I can then also use myself. But if I won't get the result and you're payed to do that and not me I'll let you figure that out (or you can hire me for consulting if needed). It's not difficult though, accessing PCI is not much different from other platforms which is well documented and I've already given you the docs where it's explained for pegasos2 as well. Also my code is free to study (not for copying into commercial projects though, so you should not copy&paste it but write your own from what you've learned from it).

Sorry for that but I believe in free software. I don't mind if others don't but then the rules of commercial software should be applied for those projects which means you get what you pay for.

@balaton
Quote:I don't know much about this low-level PCI stuff, but there is a big difference between Pegasos2 and AmigaOne:
AmigaOne/Articia-S uses a PCI tree (0.0.0 and 0.1.0 are Host/PCI-to-PCI bridges), supported by it's U-Boot firmware and as result by the AmigaOS 4.x kernel as well.
OTOH Pegasos2/Marvell Discovery II only has 2 flat PCI busses, it's firmware, and as result the AmigaOS 4.x kernel for it, may not support any bridges nor a PCI tree since the hardware doesn't.

@joerg
Quote:

Of course os4 kernel for peg2 do not support it : that the point of whole thread. And Hans trying to add support of it in the kernel. And while we are able to find RX/HD card behind the bridge, we fail to read things/addresses from properly : that need kernel fixes/changes, of course. Hans trying firstly RTAS , and fail. Now our way is direct access. And lately we trying to find if "config-l" commands and co can read from the card from firmware, to see correct adresses and stuff, and compare if it indeed RTAS do not works, or we just may use wrong addresses, etc.

@balaton

Quote:
Thanks for your help so far.

This would have been better left unsaid, though. It reminds me of another person who refused to give any assistance because I'm "working on the wrong OS." I would have helped him out if he asked...

BTW, kas1e offered a small bounty to get this fixed. That's all the "reward" that's available monetarily. If this were on a commercial basis, then I wouldn't be here.

Quote:
I appreciate free software, but I certainly don't demand it. I'm also sick and tired of the passive-aggressive bullying & harassment that comes from open-source advocates.

It is entirely reasonable to want to be paid for your work so that you can practise your craft full-time. And yes, that includes the craft of writing software. As a solo developer I don't have big budgets, I don't have a "day job," or a trust fund, or anything else to keep my family fed and sheltered. If I can't earn enough to support my family from writing software, then I simply won't have the time to write any more code.

Sorry for the rant, but I'm sick of this kind of attitude.

Hans


p.s., To be clear, I don't expect any help from you (although what you've given is appreciated). Just lighten up on the attitude, please.

@kas1e

The kernel was already using RTAS for accessing PCI configuration registers.

Hans

@Hans
I said I don't mind if others don't support or believe in free software and have other views. I just wanted to make clear my point of view and explain why I won't do much with this problem. I think it's better to be clear about that than just saying nothing so you don't have to wait if I reply or not and can go ahead with this task. What I said is not against you personally so don't take it as that.

I think keeping things closed especially in such small community just hinders progress and leads to unnecessary fights over who owns what and who gets the crumbs. It may be better to do like other communities who are keeping their beloved platform alive together like Haiku for example. AmigaOS is already obsolete and not fit for daily use (e.g. lacking support for modern hardware, memory protection, security and SMP just to name a few) so there's not much commercial value there and there isn't much hope that the handful of people who can be payed to work on it will ever make it reach the level of modern systems (or if their work will be published at all as others are still fighting over who can publish it in the first place). Making AmigaOS modern and a viable alternative OS would only be possible by allowing contribution from passionate developers but if they are discouraged seeing this state there won't be much progress. It reminds me of the book title from David "From Vultures to Vampires", looks like for AmigaOS4 we're still watching the vultures tearing apart the remains of it. I'd like to see a modern AmigaOS but I don't think the current closed source way will lead to that in our lifetime. So those who in charge may consider if there's some better way. That's why I don't want to help to keep the status quo and rather advocate free software. Sorry if this offends some people, I don't want to attack anybody just discuss views and get people consider alternative ways.

Some people are payed to work on free software so closed source is not the only way to earn a living. Even if kas1e could pay me I could not do much as I don't have the AmigaOS kernel source. If you get payed and fix it that still won't help me as I likely won't get a fixed version so there isn't much motivation for me to do much with this.

@balaton

It is a lost war. Unlucky amigaos developers stays in 90's where you could live selling your software. And don't understand that 90% of threads here on amigans are based on open source software. And without it most probably OS4 would be dead since years. Try to live with this mentality because most probably it will never change.
Not only as you said open sourcing stuff on OS4 will help new developers to understand how things works and maybe help to fix problems