With nVidia FCode ROM’s these AGP properties were just ignored by Open Firmware and the drivers for a hacked PCI nVidia card.
I don’t think they will be any trouble with ATI cards either, but we’ll burn that bridge when we get there, tho PCI FCode RoM’s have Fast-back-to-back.
0 > .properties vendor-id 00001002 device-id 00005245 revision-id 00000000 class-code 00030000 interrupts 00000001 min-grant 00000008 max-latency 00000000 subsystem-vendor-id 0000b530 subsystem-id 00000408 devsel-speed 00000001 fast-back-to-back fcode-rom-offset 00000000 ATY,Status 00000000 ATY,Flags 0717009b EDID 00ffffff ffffff00 1e6ddb56 f7470200 0c130103 6a301b78 ea3d85a6 564a9a24 125054a7 6b80b300 81808140 714f0101 01010101 0101023a 80187138 2d40582c 4500dd0c 1100001a 21399030 621a2740 68b03600 dd0c1100 001c0000 00fd0038 4b1e530f 000a2020 20202020 000000fc 00573232 35330a20 20202020 2020008a depth 00000008 device_type display character-set ISO8859-1 iso6429-1983-colors reg 00011800 00000000 00000000 00000000 00000000 02011830 00000000 00000000 00000000 00020000 42011810 00000000 00000000 00000000 08000000 02011818 00000000 00000000 00000000 00004000 name ATY,Rage128y model ATY,Rage128 ATY,Rom# 3131332d 35373430 312d3131 3600 ATY,Card# 3130392d 35373430 322d3030 00 ATY,Fcode 312e3633 00 driver,AAPL,MacOS,PowerPC 4a6f7921 70656666 70777063 00000001 b2943306 00000000 00000000 00000000 00030002 00000000 ffffffff 00000000 0000c4a8 0000c4a8 0000c4a8 00000630 00040400 ffffffff 00000000 00002b61 000026c3 00001c34 0000cae0 02010400 ffffffff 00000000 00000000 00000000 000005b0 00000080 04040400 00000000 ffffffff 00000000 ffffffff 00000000 ffffffff 00000000 00000005 0000002a 00000001 00000164 000001d0 0000058c 00000001 00000002 00000000 00000000 00000000 00000011 00000000 00000000 00000012 00000000 00000000 00000001 00000011 00000000 0000001f 00000000 00000000 0000000e 00000012 00000000 ... 0000e714 bytes total assigned-addresses c2011810 00000000 88000000 00000000 08000000 82011830 00000000 800a0000 00000000 00020000 82011818 00000000 80088000 00000000 00004000 address 88000000 width 00000280 height 000001e0 linebytes 00000280
ok
On Jul 20, 2019, at 11:31 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sat, 20 Jul 2019, Howard Spoelstra wrote:
This rom does define some AGP stuff, so I don't know whether that will be a problem with PCI?
Not sure but maybe not unless it wants to do something with AGP. As far as I could get from the FCode that only adds some AGP related parameters to device tree that are hard-coded and does not do anything with AGP itself so it should not be a problem for the ROM itself, maybe the OS later wants to set some AGP stuff but those are probably just ignored and if the right addresses of the card are available for frame buffer and mmio regs it should then work. But we'll see, this is again something that I don't know much about so will have to learn when it turns out to cause problem but until then I'm going to ignore it.
Regards, BALATON Zoltan
A thought on why our ATY ‘NDRV’s are going to abort:
I think the properties missing from the FCode ROM is really the EDID data from our virtual display device. So it maybe worth propagating the EDID data on the device tree to see if this is the property the FCode ROM sets up for the ‘NDRV’ that we are missing.
On Jul 20, 2019, at 7:06 PM, Jd Lyons lyons_dj@yahoo.com wrote:
With nVidia FCode ROM’s these AGP properties were just ignored by Open Firmware and the drivers for a hacked PCI nVidia card.
I don’t think they will be any trouble with ATI cards either, but we’ll burn that bridge when we get there, tho PCI FCode RoM’s have Fast-back-to-back.
0 > .properties vendor-id 00001002 device-id 00005245 revision-id 00000000 class-code 00030000 interrupts 00000001 min-grant 00000008 max-latency 00000000 subsystem-vendor-id 0000b530 subsystem-id 00000408 devsel-speed 00000001 fast-back-to-back fcode-rom-offset 00000000 ATY,Status 00000000 ATY,Flags 0717009b EDID 00ffffff ffffff00 1e6ddb56 f7470200 0c130103 6a301b78 ea3d85a6 564a9a24 125054a7 6b80b300 81808140 714f0101 01010101 0101023a 80187138 2d40582c 4500dd0c 1100001a 21399030 621a2740 68b03600 dd0c1100 001c0000 00fd0038 4b1e530f 000a2020 20202020 000000fc 00573232 35330a20 20202020 2020008a depth 00000008 device_type display character-set ISO8859-1 iso6429-1983-colors reg 00011800 00000000 00000000 00000000 00000000 02011830 00000000 00000000 00000000 00020000 42011810 00000000 00000000 00000000 08000000 02011818 00000000 00000000 00000000 00004000 name ATY,Rage128y model ATY,Rage128 ATY,Rom# 3131332d 35373430 312d3131 3600 ATY,Card# 3130392d 35373430 322d3030 00 ATY,Fcode 312e3633 00 driver,AAPL,MacOS,PowerPC 4a6f7921 70656666 70777063 00000001 b2943306 00000000 00000000 00000000 00030002 00000000 ffffffff 00000000 0000c4a8 0000c4a8 0000c4a8 00000630 00040400 ffffffff 00000000 00002b61 000026c3 00001c34 0000cae0 02010400 ffffffff 00000000 00000000 00000000 000005b0 00000080 04040400 00000000 ffffffff 00000000 ffffffff 00000000 ffffffff 00000000 00000005 0000002a 00000001 00000164 000001d0 0000058c 00000001 00000002 00000000 00000000 00000000 00000011 00000000 00000000 00000012 00000000 00000000 00000001 00000011 00000000 0000001f 00000000 00000000 0000000e 00000012 00000000 ... 0000e714 bytes total assigned-addresses c2011810 00000000 88000000 00000000 08000000 82011830 00000000 800a0000 00000000 00020000 82011818 00000000 80088000 00000000 00004000 address 88000000 width 00000280 height 000001e0 linebytes 00000280
ok
On Jul 20, 2019, at 11:31 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sat, 20 Jul 2019, Howard Spoelstra wrote:
This rom does define some AGP stuff, so I don't know whether that will be a problem with PCI?
Not sure but maybe not unless it wants to do something with AGP. As far as I could get from the FCode that only adds some AGP related parameters to device tree that are hard-coded and does not do anything with AGP itself so it should not be a problem for the ROM itself, maybe the OS later wants to set some AGP stuff but those are probably just ignored and if the right addresses of the card are available for frame buffer and mmio regs it should then work. But we'll see, this is again something that I don't know much about so will have to learn when it turns out to cause problem but until then I'm going to ignore it.
Regards, BALATON Zoltan
On Sun, 21 Jul 2019, Jd Lyons wrote:
A thought on why our ATY ‘NDRV’s are going to abort:
I think the properties missing from the FCode ROM is really the EDID data from our virtual display device.
Because that's the most prominent or why? It could be any other ATY,* attribute as well or just because the card is not set up the way as the FCode would have done.
So it maybe worth propagating the EDID data on the device tree to see if this is the property the FCode ROM sets up for the ‘NDRV’ that we are missing.
You can try that if you want but maybe easier to try other attributes first as they are simpler to add. You can get the edid blob bytes with:
qemu-edid | od -t x1
You only need the first 128 bytes because that's what drivers look at. Then you would need to add this to device-tree somehow, probably the same way as FCode adds NDRV.
I'd rather fix OpenBIOS to work but if you want to experiment with random options you could try, maybe you can identify what's needed that way.
Regards, BALATON Zoltan
I added the EDID too Openbios properties, but that didn’t do the trick:-(
Just really killing time while you and others work out what we need to run the FCode to the end.
On Jul 21, 2019, at 8:53 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sun, 21 Jul 2019, Jd Lyons wrote:
A thought on why our ATY ‘NDRV’s are going to abort:
I think the properties missing from the FCode ROM is really the EDID data from our virtual display device.
Because that's the most prominent or why? It could be any other ATY,* attribute as well or just because the card is not set up the way as the FCode would have done.
So it maybe worth propagating the EDID data on the device tree to see if this is the property the FCode ROM sets up for the ‘NDRV’ that we are missing.
You can try that if you want but maybe easier to try other attributes first as they are simpler to add. You can get the edid blob bytes with:
qemu-edid | od -t x1
You only need the first 128 bytes because that's what drivers look at. Then you would need to add this to device-tree somehow, probably the same way as FCode adds NDRV.
I'd rather fix OpenBIOS to work but if you want to experiment with random options you could try, maybe you can identify what's needed that way.
Regards, BALATON Zoltan
My resulting EDID was only 172 bytes long, I’m not sure that’s correct?
qemu-edid | od -t x1
0000000 00 ff ff ff ff ff ff 00 49 14 34 12 00 00 00 00 0000020 2a 18 01 04 a5 28 1e 78 06 ee 91 a3 54 4c 99 26 0000040 0f 50 54 21 08 00 e1 c0 d1 c0 01 01 01 01 01 01 0000060 01 01 01 01 01 01 25 20 00 66 41 00 1a 30 00 1e 0000100 33 40 93 2e 11 00 00 18 00 00 00 fd 00 32 7d 1e 0000120 a0 78 01 0a 20 20 20 20 20 20 00 00 00 fc 00 51 0000140 45 4d 55 20 4d 6f 6e 69 74 6f 72 0a 00 00 00 f7 0000160 00 0a 00 4a a2 24 29 20 00 00 00 00 00 00 01 19 0000200 02 03 0a 00 45 7d 65 60 59 1f 00 00 00 00 00 00 0000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 0000400
I realize the left hand coelom is offsets, not part of the EDID data, I’m not sure about the *, did that clip a bunch of zero’s, leaving me with 172 bytes rather than 256?
On Jul 21, 2019, at 10:42 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
I added the EDID too Openbios properties, but that didn’t do the trick:-(
Just really killing time while you and others work out what we need to run the FCode to the end.
On Jul 21, 2019, at 8:53 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sun, 21 Jul 2019, Jd Lyons wrote:
A thought on why our ATY ‘NDRV’s are going to abort:
I think the properties missing from the FCode ROM is really the EDID data from our virtual display device.
Because that's the most prominent or why? It could be any other ATY,* attribute as well or just because the card is not set up the way as the FCode would have done.
So it maybe worth propagating the EDID data on the device tree to see if this is the property the FCode ROM sets up for the ‘NDRV’ that we are missing.
You can try that if you want but maybe easier to try other attributes first as they are simpler to add. You can get the edid blob bytes with:
qemu-edid | od -t x1
You only need the first 128 bytes because that's what drivers look at. Then you would need to add this to device-tree somehow, probably the same way as FCode adds NDRV.
I'd rather fix OpenBIOS to work but if you want to experiment with random options you could try, maybe you can identify what's needed that way.
Regards, BALATON Zoltan
OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org
On Sun, 21 Jul 2019, Jd Lyons wrote:
My resulting EDID was only 172 bytes long, I’m not sure that’s correct?
Probably not, you should have the same amount of bytes as the device tree dump you quoted earlier. Actually you could just use that edid blob as that's from a valid monitor and frequencies really don't matter and the resolutions are standard so it would work the same I think.
qemu-edid | od -t x1
0000000 00 ff ff ff ff ff ff 00 49 14 34 12 00 00 00 00 0000020 2a 18 01 04 a5 28 1e 78 06 ee 91 a3 54 4c 99 26 0000040 0f 50 54 21 08 00 e1 c0 d1 c0 01 01 01 01 01 01 0000060 01 01 01 01 01 01 25 20 00 66 41 00 1a 30 00 1e 0000100 33 40 93 2e 11 00 00 18 00 00 00 fd 00 32 7d 1e 0000120 a0 78 01 0a 20 20 20 20 20 20 00 00 00 fc 00 51 0000140 45 4d 55 20 4d 6f 6e 69 74 6f 72 0a 00 00 00 f7 0000160 00 0a 00 4a a2 24 29 20 00 00 00 00 00 00 01 19 0000200 02 03 0a 00 45 7d 65 60 59 1f 00 00 00 00 00 00 0000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 0000400
I realize the left hand coelom is offsets, not part of the EDID data, I’m not sure about the *, did that clip a bunch of zero’s, leaving me with 172 bytes rather than 256?
Yes the * omitted some all 0 lines, but as I said:
On Jul 21, 2019, at 10:42 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
On Jul 21, 2019, at 8:53 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
You only need the first 128 bytes because that's what drivers look at. Then you would need to add this to device-tree somehow, probably the same way as FCode adds NDRV.
But I don't think it would make a difference, I don't think it's the missing EDID is what prevents it from working. Have you tried all other ATY,* properties that are easier to add from the command line before trying EDID?
Regards, BALATON Zoltan
-
BALATON Zoltan -
Jd Lyons