Radeon X1900 G5 Mac Edition Cheap 'n Easy Flashing Guide

[FerociousPPC]

TechPowerUp

Extensive repository of graphics card BIOS image files. Our database covers submissions categorized by GPU vendor, type, and board partner variant.

www.techpowerup.com

TechPowerUp

Extensive repository of graphics card BIOS image files. Our database covers submissions categorized by GPU vendor, type, and board partner variant.

www.techpowerup.com

Thanks for the link but it seems the Video card will not display on a PC anymore so no way to re-flash in FreeDOS.

 

[Tratkazir_the_1st]

@FerociousPPC
Try to flash with another built-in/pci/Pci-ex videocard as primary.

 

[ToniCH]

I had a bricked GPU and it didn't display anything in PC or Mac. And it was not possible to use another videocard either. If it was installed the PC would not boot at all.

But, then I managed to flash it out of computer all together. And its also possible to buy a new ROM-chip and flash it with a CH341A Mini Programmer and then solder it into place of the original. I was ready to do that but then I managed to flash the original chip in situ with an adapter that came with the programmer.

This was not a Radeon X1900 but I guess the same approach could work with them too (?).

 

[mrkapqa]

hello œToniCH i have a similar issue with RX 580 after flash gone wrong it would not display image neither one PC or Mac; can you advise which chip would need to be "reprogrammed" and how?

Thanks-allot!

 

[ToniCH]

hello œToniCH i have a similar issue with RX 580 after flash gone wrong it would not display image neither one PC or Mac; can you advise which chip would need to be "reprogrammed" and how?

Thanks-allot!

Send me a message and I'll try to find pics etc. on what I did. It's been awhile and I cannot remember all out of my mind.

 

[AmigaG5Quad]

Hi guys, I bought an PC X1900XT with 512MB Ram on ebay and would like to know if I can flsahen it? would be very grateful for help, as the card is not recognized in my g5 Quad.


I understood that the Intel MAC Cards cannot be flashed, what about the PC Cards?

 

[AmigaG5Quad]

Can no one help me with this question? i don't want to break the card.

 

[z970]

@AmigaG5Quad Howdy. Welcome to the forum.

As I understand it, the 512 MB X1900 XTs were either BIOS-only (PC), or could alternatively be flashed to the equivalent Intel Mac EFI for use in early Mac Pro models. Furthermore if I remember correctly, it was the 256 MB X1900 GT cards in particular that could be flashed to Open Firmware for use in PowerPC systems. For a Quad, this would be the card you want (if you're adverse to NVIDIA's alternatives).

Otherwise, I'm not aware of anyone ever getting the stock X1900 XT cards running on a G5, unfortunately.

 

[PowerPC74]

I think I found where the 256MB is set in the ATI Fcode ROM for the X1900, unless the drivers are locked to 256MB I do believe I can get the card to work with 512MB if anyone has a card and still cares about this?

 

[LightBulbFun]

I think I found where the 256MB is set in the ATI Fcode ROM for the X1900, unless the drivers are locked to 256MB I do believe I can get the card to work with 512MB if anyone has a card and still cares about this?

that would be quite cool! I dont think the drivers are hard coded to 256MB, in-fact the PPC X1900 G5 card uses the same Personality name as the 512MB X1900 XT found in the MacPro1,1 and I have always found that in itself quite curious!

 

[jktwice]

I think I found where the 256MB is set in the ATI Fcode ROM for the X1900, unless the drivers are locked to 256MB I do believe I can get the card to work with 512MB if anyone has a card and still cares about this?

That would be so sick considering I just put mine in. Will stay tuned for updates (and see if I can get a machine around here booting FreeDOS... I believe I have one.

 

[joevt]

I think I found where the 256MB is set in the ATI Fcode ROM for the X1900, unless the drivers are locked to 256MB I do believe I can get the card to work with 512MB if anyone has a card and still cares about this?

The fcode has code to read the BAR size from the BAR registers.

10 my-space + " config-l@" $call-parent -1 10 my-space + " config-l!" $call-parent 10 my-space + " config-l@" $call-parent 0f invert and invert 1+ to value_9f9_10000000 10 my-space + " config-l!" $call-parent
18 my-space + " config-l@" $call-parent -1 18 my-space + " config-l!" $call-parent 18 my-space + " config-l@" $call-parent 0f invert and invert 1+ to value_9fb_10000    18 my-space + " config-l!" $call-parent

value_9f9_10000000 contains the size for BAR 0x10. It was initialized to 0x10000000 but that gets changed by the above code in the fcode if the BAR size is different.
Have you checked the BAR to see what size it reports? Is the size controlled by a soft straps?

The fcode starts with some bytes that are ignored by the fcode. They may be used by the GPU for soft straps? What do the soft straps control?

fcode-version2
\ format:    0x08
\ checksum:  0xe504 (ok)
\ len:       0x83ac (33708 bytes)

" "(0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0098 065C 0048 0210 4072 4072 1890 0000)"
2drop

There is another value value_bb0_10000000 which is also initialized to 0x10000000 but it is never modified. It is used by the VRAM,totalsize and ATY,FCODE_MEM properties. It is stored to register 0xf8

value_9fd_10 is the top 12 bits of the minimum of value_9f9_10000000 and value_bb0_10000000. The initialized size of 0x10 would mean 16 MB.

Is there an Linux open source driver for the X1900? It will have a list of registers.

 

[Matias_]

Linux radeon driver should support it, a card with a PC ROM at least. Refuses to work with a Mac ROM because it checks the signature.

 

[PowerPC74]

The fcode has code to read the BAR size from the BAR registers.

10 my-space + " config-l@" $call-parent -1 10 my-space + " config-l!" $call-parent 10 my-space + " config-l@" $call-parent 0f invert and invert 1+ to value_9f9_10000000 10 my-space + " config-l!" $call-parent
18 my-space + " config-l@" $call-parent -1 18 my-space + " config-l!" $call-parent 18 my-space + " config-l@" $call-parent 0f invert and invert 1+ to value_9fb_10000    18 my-space + " config-l!" $call-parent

value_9f9_10000000 contains the size for BAR 0x10. It was initialized to 0x10000000 but that gets changed by the above code in the fcode if the BAR size is different.
Have you checked the BAR to see what size it reports? Is the size controlled by a soft straps?

The fcode starts with some bytes that are ignored by the fcode. They may be used by the GPU for soft straps? What do the soft straps control?

fcode-version2
\ format:    0x08
\ checksum:  0xe504 (ok)
\ len:       0x83ac (33708 bytes)

" "(0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0098 065C 0048 0210 4072 4072 1890 0000)"
2drop

There is another value value_bb0_10000000 which is also initialized to 0x10000000 but it is never modified. It is used by the VRAM,totalsize and ATY,FCODE_MEM properties. It is stored to register 0xf8

value_9fd_10 is the top 12 bits of the minimum of value_9f9_10000000 and value_bb0_10000000. The initialized size of 0x10 would mean 16 MB.

Is there an Linux open source driver for the X1900? It will have a list of registers.

There is no documentation for any 'Soft Straps' for ATI cards, if they exist nobody knows what they do or what offsets in the ROMs maybe copied over from a PC VBIOS to the Mac FCode Option ROM.

Linux radeon driver should support it, a card with a PC ROM at least. Refuses to work with a Mac ROM because it checks the signature.

What do you mean by 'signature'?

The Radeon driver can load a PC bios from file if you put it in the proper directory in Linux and it matches one of you ATI graphics cards.

 

[Matias_]

If the card has a Mac video BIOS, the radeon driver does not want to use it because it checks for an x86 VBIOS. I can provide some dmesg output later today.

Edit, something like:

radeon 0000:00:10.0: Invalid PCI ROM header signature: expecting Oxaa55, got 0xffff
[drm] Not an x86 BIOS ROM, not using.

 

[PowerPC74]

4072 1890<---Mac x1900 256MB ROM
4972 1890<-- PC X1900 XT 512MB ROM

These are the only similarities in the same offsets of the ROM's that maybe soft straps.

 

[PowerPC74]

If the card has a Mac video BIOS, the radeon driver does not want to use it because it checks for an x86 VBIOS. I can provide some dmesg output later today.

Edit, something like:

radeon 0000:00:10.0: Invalid PCI ROM header signature: expecting Oxaa55, got 0xffff
[drm] Not an x86 BIOS ROM, not using.

Move a compatible VBIOS to the proper directory.

They never updated the Radeon code for PPC to look for a valid ROM header for PPC.

 

[Matias_]

So if I understand correctly, Linux needs a copy of the VBIOS on disk that is identical to the one flashed on the card?

 

[PowerPC74]

So if I understand correctly, Linux needs a copy of the VBIOS on disk that is identical to the one flashed on the card?

There is likely a check of vendor(0x1002) and device ID, maybe a little more. If I remember
correctly it checks for a valid ROM file first and only falls back to reading the EEROM as a last resort.

The **** thing is Linux on Big Endian graphics stack is broken upstream so you are stuck with outdated Linux if you want a Desktop environment.

Pull the available firmwares to install to the proper DIR....

sudo apt-get install firmware-linux-nonfree

And/or

sudo apt-get install linux-firmware

 

[joevt]

There is no documentation for any 'Soft Straps' for ATI cards, if they exist nobody knows what they do or what offsets in the ROMs maybe copied over from a PC VBIOS to the Mac FCode Option ROM.

If the bytes are not used by hardware/GPU then they might be used by software (drivers, flashers, etc.).
They are not used by the fcode (the ROM is not mapped in by the fcode).

If the card has a Mac video BIOS, the radeon driver does not want to use it because it checks for an x86 VBIOS. I can provide some dmesg output later today.

Edit, something like:

radeon 0000:00:10.0: Invalid PCI ROM header signature: expecting Oxaa55, got 0xffff
[drm] Not an x86 BIOS ROM, not using.

Every PCI Option ROM has aa55 as the first two bytes.

\                   PCI expansion PROM header
\        00000000:                              PCI magic number (55AA): 55AA
\        00000002:                   Processor architecture unique data: 0040
\        00000004:      Reserved for processor architecture-unique data: 00000000 00000000 00000000 00000000 00000000  ....................
\        00000018:               Pointer to start of PCI Data Structure: 0020
\        0000001A:                                            Pad bytes: 0000
\                                             Variable length pad bytes:
\        0000001C: 00000000                                                                 ....
\                   PCI Data Structure (4 byte aligned)
\        00000020:                              Signature string (PCIR): PCIR
\        00000024:                         Vendor ID = config reg 00/01: 1002
\        00000026:                         Device ID = config reg 02/03: 7240
\        00000028:                        Pointer to Vital Product Data: 0000
\        0000002A:                            PCI Data Structure length: 0020
\        0000002C:                          PCI Data Structure revision: 00 = PCI 2.2
\        0000002D:                     Class Code = config reg 09/0a/0b: 030000 (Class code / Subclass code / Programming interface code)
\        00000030:                            Image Length in 512 bytes: 0042 (* 0x200 = 0x8400)
\        00000032:                          Revision Level of Code/Data: 0000
\        00000034:                                            Code Type: 01 = Open Firmware
\        00000035:                                            Indicator: 80 = last image
\        00000036:                                             Reserved: 0000
\                                             Variable length pad bytes:
\        00000038: 00000000 00000000                                                        ........

hex

tokenizer[ 0000 ]tokenizer set-rev-level
tokenizer[ 0040 ]tokenizer pci-architecture
tokenizer[ 0020 ]tokenizer pci-data-structure-start
tokenizer[ 0020 ]tokenizer pci-data-structure-length
tokenizer[ 1002 7240 030000 ]tokenizer pci-header
tokenizer[ 8400 ]tokenizer rom-size

fcode-version2
\ format:    0x08
\ checksum:  0xe504 (ok)
\ len:       0x83ac (33708 bytes)
hex

\ Soft Straps?
" "(0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0098 065C 0048 0210 4072 4072 1890 0000)"
2drop

Are you sure the card is flashed?
The "Invalid PCI ROM header signature" check happens in a loop. The loop ends when it reaches an image that has the "last image" indicator set to 0x80. Does your header have this indicator?
./drivers/pci/rom.c

What version of the kernel are you running? Maybe earlier versions of the code does not stop at the last image.

The real problem is the "[drm] Not an x86 BIOS ROM, not using." message. I suppose if the ROM were big enough, you could add the Open Firmware image after the end of the BIOS image.
./drivers/gpu/drm/radeon/radeon_bios.c

How big is the ROM? The fcode hard-codes the size as 128K but the fcode is less than 64K (doesn't contain an NDRV for Mac OS 9).
Probe the ROM BAR to find out what size it is.

: get-bar-size ( config-reg -- size )
dup config-l@ swap -1 over config-l! dup config-l@ -10 and negate -rot config-l! ;

: calc-config ( bus device function reg -- config-reg )
swap 8 << or swap d# 11 << or swap d# 16 << or ;

\ config-reg has bus:device.function 00:10.0, reg 0x30 (ROM-BAR) = 0x8030
0 h# 10 0 h# 30 calc-config get-bar-size .

You can replace 0 h# 10 0 h# 30 calc-config with the value from the reg property which would be 8030.

 

[Matias_]

Ignore the specific bytes in my example, that dmesg excerpt is from my PowerMac G4 which has a flashed Radeon 9800 Pro.

The behavior however is very similar if not identical with my X1900. It is an original ATI X1900GT G5 Mac edition with a 128k ROM so I have not flashed it since it already had an OF ROM . I think this should be the corresponding ROM.

Kernel is something recent, 6.13.x or 6.14.x.

Thank you for all the pointers, I will check this out tomorrow and will be able to provide more info then.

The **** thing is Linux on Big Endian graphics stack is broken upstream so you are stuck with outdated Linux if you want a Desktop environment.

This is not a problem for me. I run ArchPOWER which holds on to mesa 24.1 and works very nicely, especially with newer TeraScale GPUs. But I would like to have the X1900 working to have a decent card for both MacOS and Linux.

 

[PowerPC74]

If the card has a Mac video BIOS, the radeon driver does not want to use it because it checks for an x86 VBIOS. I can provide some dmesg output later today.

Edit, something like:

radeon 0000:00:10.0: Invalid PCI ROM header signature: expecting Oxaa55, got 0xffff
[drm] Not an x86 BIOS ROM, not using.

The radeon driver is likely trying to read the ROM from shadow memory like it can on x86, that's why it's returning 0xffff as we don't do that on PPC.

 

[joevt]

The radeon driver is likely trying to read the ROM from shadow memory like it can on x86, that's why it's returning 0xffff as we don't do that on PPC.

So even if the BIOS is added to the ROM, the driver is not going to find it because it's not reading the ROM?
The radeon driver needs to be changed to read the ROM from the ROM by mapping it into memory correctly.