@joerg Yes I know, maybe my wording was not clear. What GPL prevents is one party turning GPL software into closed source software which is what I really meant by "commercial code", so maybe that's what causes misunderstanding. BSD license has no such restriction so somebody can take it and use it in part or change it and make it closed source, they only cannot claim they wrote it and have to keep copyright messages to acknowledge original developers. GPL also requires to keep the sources free and available for everybody and not use it in code that does not allow the same. So when you substitute commercial code with closed source code that's what I meant but failed to describe properly.
By the way it's not the GPL code that's sold commercially because the code itself is freely available (and cannot be charged more than the fair amount needed to transfer it) but additional services using that code like making distros or providing services based on that code and so on. But GPL software can be developed commercially for sure.
I think you should only execute config-l@ once, not twice. When you execute it the second time it takes the value that the first execution left on the stack (the result you're trying to see) as the address to report on, which is not what you want (and may be why you're getting strange results). You should just do:
16 config-l@ .
Quote:
(Also realised where did you get 16 for BAR address. Forth is hex by default do dec# 16 is wriiten as 10 in Forth.)
Good point. Forth itself is decimal by default, but OpenFirmware may not be. The value '646011AB' is clearly in hex, so the number '16' is probably taken as hex as well. You could try something like:
20 1 - .
If you get 13 (the value 19 in hex) then the numbers are being interpreted as decimal. If you get 1F then they're being interpreted as hex.
I think you should only execute config-l@ once, not twice. When you execute it the second time it takes the value that the first execution left on the stack (the result you're trying to see) as the address to report on, which is not what you want (and may be why you're getting strange results). You should just do:
16 config-l@ .
It's strangely return 0, does not matter where i am in : in /pci/ , or in /pci/pci@7 (in bridge), see:
ok cd /pci
ok pwd
/pci@80000000
ok 16 config-l@ .
0
ok cd pci@7
ok pwd
/pci@80000000/pci@7
ok 16 config-l@ .
0
ok
At first i think that maybe it's exactly issue in bridge, but then the same happens if i go to any pci based directory, always zero..
Quote:
If you get 1F then they're being interpreted as hex.
@Joerg Same 0 as expected :( (there should be values anyway, even with wrong 16). Question is : what BAR we tried to read with this "16", i mean first BAR of what, if it the same does not matter in what directory (be it root /pci, or /pci/pci@7, or any other pci) happens to be. Like it just general offset of 16 of whole PCI thing, but we need first BAR of the card behind the bridge : how to say/calculate that ?
@Sailor It takes a while, but i at last received this AGP-to-PCI(e) adapter we talk about on the first page from there: https://www.ebay.com/itm/125723908233
Takes 2 just in case, but then i probably will test them once Hans deal with casual bridge , as there are changes that with this kind of adapters and tests around it my pegasos2 will burn and die, so firstly want to be able to finish testing of what Hans is working on, and then will test this adapter.
@All Hans progressing pretty well with replacing non-working-with bridges RTAS way os4 kernel uses for pegasos2, to the direct PCI reading/writing way, and currently there few bits to fix before it can come up with something, but at least we surely have correct addresses of video memory now, things which remain is to fix some registers reading, and then there high chance it will work! Rise of Frankenstein !
Tried it with both bridges : pericom and pex ones, and in both cases in firmware when i go to the pci@C0000000 (agp area) all i have is pci@8 , properties on which show that this is bridge (so both bridges detects correctly via adapter), but , both didn't see a graphics card in.
One time i was lucky (probably was some bad attachment of adapter or something), and instead of just pci@8 in pci@C0000000, i did have about 20 different pci's (pci@1, pci@2, pci@3, etc), in which card were detected ! (both audio and video parts). But that was just one time, and does not matter how hard i tried to reproduce it, i always can't. While when bridge just in pure PCI without adapters all fine and detects by firmware fine.
So probably conclusion is : this missed "lock" signal is what made it not works. The one time detecting was probably some bug in this lock signal handling or something.