Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
30 user(s) are online (18 user(s) are browsing Forums)

Members: 2
Guests: 28

Skateman, emeck, more...

Support us!

Headlines

 
  Register To Post  

« 1 ... 6 7 8 (9) 10 11 »
Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


See User information
@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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Not too shy to talk
Not too shy to talk


See User information
@kas1eQuote:
kas1e wrote:@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.


Yes! Pegasos 2 has MV64361 version:
Resized Image

AmigaOS3: Amiga 1200
AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000
MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Just can't stay away
Just can't stay away


See User information
@balaton
Quote:
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. [...] 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.
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.

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Just popping in
Just popping in


See User information
@kas1e

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

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Just popping in
Just popping in


See User information
@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:
I mean, what "config-addr -- data" mean...?

"(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.

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


See User information
@msteed
Thanks !

So, that what i tried then:

ok# cd /pci@80000000/pci@7
ok# ls
display@0
display
@0,1
ok
#

ok# 16 config-l@
ok# config-l@
ok# .
646011AB
ok
#


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:

/pci@80000000/host:     0:0.0   11ab:6460 60000 646011ab 0100 6
....
/
pci@c0000000/host:     0:0.0   11ab:6460 60000 646011ab 0100 7


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 ..

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


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

OF interface initialized
BBoot 0.7 
(15.4.2024)
/
pci@80000000io fe000000/10000 mem 80000000/40000000
/pci@80000000/host:     0:0.0   11ab:6460 60000 646011ab 0100 6
/pci@80000000/firewire0:1.0   1106:3044 c0010 30441106 0109 0
  2000810        0 80010000         0      800  
80010000
  1000814        0 fe001080         0       80  
| 00001081
/
pci@80000000/pci:      0:7.0   10b5:8112 60400 811210b5 0100 7
Truncated 64 bit BAR 43003810
 42003810        0 80000000         0    10000  
8000000c
/pci@80000000/isa:      0:c.0   1106:8231 60100 82311106 0000 7
/pci@80000000/ide:      0:c.1   1106:0571 1018f 05711106 010e 7
  1006110        0 fe001000         0        8  
00001001
  1006114        0 fe00100c         0        4  
0000100d
  1006118        0 fe001010         0        8  
00001011
  100611c        0 fe00101c         0        4  
0000101d
  1006120        0 fe001020         0       10  
00001021
/pci@80000000/usb:      0:c.2   1106:3038 c0300 30381106 0409 7
  1006220        0 fe001040         0       20  
00001041
/pci@80000000/usb:      0:c.3   1106:3038 c0300 30381106 0409 7
  1006320        0 fe001060         0       20  
00001061
/pci@80000000/other:    0:c.4   1106:8235 68000 82351106 0000 0
/pci@80000000/sound:    0:c.5   1106:3058 40100 30581106 0309 0
  1006510        0 fe001100         0      100  
00001101
  1006514        0 fe001030         0        4  
00001031
  1006518        0 fe001034         0        4  
00001035
/pci@80000000/pci1106,3068:     0:c.6   1106:3068 78000 30681106 0309 0
  1006610        0 fe001200         0      100  
00001201
/pci@80000000/ethernet0:d.0   1106:3065 20000 30651106 0109 0
  1006810        0 fe001300         0      100  
00001301
  2006814        0 80010800         0      100  
80010800
/pci@c0000000io f8000000/10000 mem c0000000/20000000
/pci@c0000000/host:     0:0.0   11ab:6460 60000 646011ab 0100 7


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

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


See User information
@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).

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


See User information
@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.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


See User information
@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.)


Edited by balaton on 2024/4/28 13:55:31
Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


See User information
@balaton
Quote:

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


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:

ok cd /pci/pci@7
ok ls
display
@0
display
@0,1
ok 
.properties
vendor
-id             0x10B5 (4277)
device-id             0x8112 (33042)
revision-id           0xAA (170)
class-
code            0x60400 (394240)
subsystem-id          0x0 (0)
subsystem-vendor-id   0x0 (0)
.
vendor-name          "PLX"
.class                "Bridge Device"
.subclass             "PCI/PCI"
interrupts            0x1 (1)
devsel-speed          0x1 (1)
66mhz-capable
device_type           
"pci"
#address-cells        0x3 (3)
#size-cells           0x2 (2)
clock-frequency       0x1FCA055 (33333333)
name                  "pci"
reg                   7:0
                      xp7
,0,10,0:10000
assigned
-addresses    xp7,0,10,80000000:10000
bus
-range             1:1
ranges                
[0x40 bytes]
        [
00001000000 00000000 FE002000 01000000
        
[01000000000 FE002000 00000000 00001000
        
[02002000000 00000000 80100000 02000000
        
[03000000000 80100000 00000000 1FF00000


The card in, display0:

ok cd display@0
ok 
.properties
vendor
-id             0x1002 (4098)
device-id             0x7244 (29252)
revision-id           0x0 (0)
class-
code            0x30000 (196608)
subsystem-id          0x1002 (4098)
subsystem-vendor-id   0xB12 (2834)
.
vendor-name          "ATI"
.class                "Display Controller"
.subclass             "PC Compatible"
interrupts            0x1 (1)
devsel-speed          0x0 (0)
min-grant             0x0 (0)
max-latency           0x0 (0)
rom                   [0x20000 bytes]
        [
000FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[010FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[020FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[030FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[040FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[050FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[060FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[070FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[080] FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[090] FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[0A0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[0B0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[0C0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[0D0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[0E0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[0F0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[100FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[110FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[120FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[130FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[140FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[150FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[160FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[170FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[180FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[190FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[1A0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[1B0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[1C0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[1D0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[1E0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
        
[1F0FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
[skipped]

name                  "display"
reg                   0:0
                      xp0
,0,10,0:10000000
                      x0
,0,18,0:10000
                      i0
,0,20,0:100
                      m0
,0,30,0:20000
assigned
-addresses    xp0,0,10,90000000:10000000
                      x0
,0,18,80100000:10000
                      i0
,0,20,FE002000:100
                      m0
,0,30,80120000:20000
ok cd 
..


And the card in display@0,1:

ok cd display@0,1
ok 
.properties
vendor
-id             0x1002 (4098)
device-id             0x7264 (29284)
revision-id           0x0 (0)
class-
code            0x38000 (229376)
subsystem-id          0x1002 (4098)
subsystem-vendor-id   0xB13 (2835)
.
vendor-name          "ATI"
.class                "Display Controller"
.subclass             "Other"
devsel-speed          0x0 (0)
min-grant             0x0 (0)
max-latency           0x0 (0)
name                  "display"
reg                   0,1:0
                      x0
,1,10,0:10000
assigned
-addresses    x0,1,10,80110000:10000
ok


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 :)


Edited by kas1e on 2024/4/28 17:16:36
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Just can't stay away
Just can't stay away


See User information
@balaton
Quote:
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.
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.


Edited by joerg on 2024/4/28 19:01:48
Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Home away from home
Home away from home


See User information
@balaton
Quote:

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.


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):

0000:00:06.0 PCI bridge [0604]: Pericom Semiconductor PI7C9X111SL PCIe-to-PCI Reversible Bridge [12d8:e111] (rev 02)
....
0000:01:00.0 VGA compatible controller [0300]: Advanced Micro DevicesInc. [AMD/ATIR580+ [Radeon X1950 XT] [1002:7244]


And on OS4 (this time with Radeon HD):

[_impl_AddLibraryAdding library graphics.library to the system
RadeonHD 
(5): findRXCard called
RadeonHD 
(5): Card 0 (0): 0x10020x682BRadeon HD Verde (Mob.), supportedinactive
RadeonHD 
(5): Found supported card
RadeonHD 
(5): initRXCard called
RadeonHD 
(5): Initializing card



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:

root@debian:/home/kas1e# dmesg | egrep 'drm|radeon'
[   30.283165] [drmInitialized drm 1.1.0 20060810
[   31.088890] [drmradeon kernel modesetting enabled.
[   
31.574171] [drminitializing kernel modesetting (R580 0x1002:0x7244 0x0000:0x0000).
[   
31.675977__ioremap(): phys addr 0x0 is RAM lr radeon_device_init [radeon]
[   
31.760392radeon 0000:01:00.0Fatal error during GPU init
[   32.791013radeonprobe of 0000:01:00.0 failed with error -12
root
@debian:/home/kas1e#


And see on OS4:

RadeonHD (2): Obtaining ITimer interface
RadeonHD (2): Got ITimer interface
RadeonHD (2): Returning from LibOpen().
RadeonHD (0): RadeonHD.chip 5.20 (25.5.2023)
RadeonHD (6): <rxOpen>
RadeonHD (4): Have altivec.
RadeonHD (4): CPU cache line length32
RadeonHD 
(4): PCI device is a graphics card.
RadeonHD (2): Identified the chipset as: VERDE
RadeonHD 
(2): Graphics card name isRadeon HD Verde (Mob.)
RadeonHD (2):   If - and only if - your card does not work or does not work optimally
        please submit a bug report at
:
        
http://www.amiga.org/developer/bugreports
        
Remember to include the driver version, and the following card details:
        
0x682B:0x0000:0x0000: <name of board>
        and *
pleasedescribe the problems you are seeing in detail.
RadeonHD (4): Obtaining memory and I/O addresses and sizes
RadeonHD 
(4): Video RAM at0x00000000size is 268435456 bytes
RadeonHD 
(0): ERRORVideo RAM base address was NULL
RadeonHD 
(6): <rxClose>
[
HAL_DfltTrapHandler] *** WarningFatal exception in task 0x6FFAB240 (exec.tasketask 0xEFFF4000)


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 :)


Edited by kas1e on 2024/4/28 19:27:26
Edited by kas1e on 2024/4/28 19:28:28
Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


See User information
@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.

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Quite a regular
Quite a regular


See User information
@joerg
Quote:
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.

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).

Go to top
Re: Pegasos2 with RadeonHD/RX via bridge
Just can't stay away
Just can't stay away


See User information
@balaton
Quote:
And there's a reason for that which is to ensure that GPL code is not used in commercial code ...
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.

Go to top

  Register To Post
« 1 ... 6 7 8 (9) 10 11 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project