Greetings,
Because it's always good to check, I extracted the discrete GPU's vgabios rom from my G505s following method 3 ("Retrieval via Linux kernel") listed here: [1] I have no dGPU, and I assume that it was discovered that this produces a clean (correct) iGPU rom blob. Not that I wrote a '1' to the file first to enable reading, as noted here: [2] I compared the files using tkdiff in hexdump format. See attachments for the files.
Comparing the file that I extracted and pci1002,990b.rom from [3] (obtained via "./atombios.sh") they are definitely very similar, but there are many spots with discrepancies. The diff output is at the end of this email. Along the way I had to take the file from the patch and turn it back into a binary and then hexdump it with the same options to make sure they had the same formatting.
It was noted in [4] that there were some differences between the vgabios roms used for integrated GPUs in laptops with and without discrete ones, specifically with regard to supply voltage. Can anyone confirm that the version supplied via the patch is the one from laptops with a discrete GPU, and that what I have matches what would be expected for a dGPU-less laptop? Is there a hash of the rom itself somewhere to point to?
Sincerely, -Matt
Attachments: extracted_vgabios.rom => the rom I extracted myself extracted_vgabios.rom.txt => the result of "hexdump -C extracted_vgabios.rom" pci1002,990b.rom.txt => the rom from the patch (received along with 6663 and 6665) pci1002,990b.rom.txt.rom => the result of "cat pci1002,990b.rom.txt | xxd -r" pci1002,990b.rom.txt.rom.txt => the result of hexdumping pci1002,990b.rom.txt.rom as above
Checksums: 0c0543a28677baa75c49616e5fe326a413f779e77764f8a6dd13c798d3b076ee extracted_vgabios.rom 0515b8cbf184fbfba13ae48d70b1c5ae05405dd709e0eef2291c6d8a4a587287 pci1002,6663.rom.txt 416c748e5ad538593003e47a484067d7cbb509ddff7de079f5603b6d135898bf pci1002,6665.rom.txt c35f469b56c41385b0196c0c9df6599ef9e81e32078da2dd3cf81760c9bd3365 pci1002,990b.rom.txt
References: [1] https://coreboot.coreboot.narkive.com/zEkIcuSS/ultimate-vgabios-extraction-n... [2] https://www.coreboot.org/VGA_support [3] http://dangerousprototypes.com/docs/Lenovo_G505S_hacking [4] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWI...
Diff results: $ diff extracted_vgabios.rom.txt pci1002,990b.rom.txt.rom.txt 3c3 < 00000020 4d 49 00 00 00 00 00 00 00 00 00 00 00 00 00 04 |MI..............| ---
00000020 4d d3 00 00 00 00 00 00 00 00 00 00 00 00 00 04
|M...............| 27c27 < 000001a0 34 03 08 00 00 30 02 10 0b 99 b4 01 a4 a5 4a a6 |4....0........J.| ---
000001a0 34 03 08 00 00 40 02 10 0b 99 b4 01 a4 a5 4a a6 |4....@
........J.| 2735,2736c2735,2736 < 0000aae0 00 00 00 00 00 00 d1 00 01 03 12 1b 56 05 70 00 |............V.p.| < 0000aaf0 00 03 0e 00 20 00 20 00 02 00 04 00 59 01 c2 00 |.... . .....Y...| ---
0000aae0 00 00 00 00 00 00 d1 00 01 03 41 1c 56 05 a0 00
|..........A.V...|
0000aaf0 00 03 16 00 30 00 20 00 02 00 05 00 58 01 c2 00 |....0.
.....X...| 2841c2841 < 0000b200 06 00 00 00 00 00 00 00 4c 00 4e 00 03 00 74 01 |........L.N...t.| ---
0000b200 06 00 00 00 00 00 00 00 4a 00 4c 00 03 00 74 01
|........J.L...t.| 2848,2850c2848,2850 < 0000b290 00 00 72 00 32 89 00 00 01 00 4e 00 56 d0 00 00 |..r.2.....N.V...| < 0000b2a0 02 00 48 00 40 19 01 00 03 00 42 00 40 19 01 00 |..H.@.....B.@ ...| < 0000b2b0 03 00 42 00 8b 1e 00 00 70 11 01 00 00 00 00 00 |..B.....p.......| ---
0000b290 00 00 70 00 32 89 00 00 01 00 4c 00 56 d0 00 00
|..p.2.....L.V...|
0000b2a0 02 00 46 00 40 19 01 00 03 00 40 00 40 19 01 00 |..F.@
.....@.@...|
0000b2b0 03 00 40 00 8b 1e 00 00 70 11 01 00 00 00 00 00
|..@.....p.......| 2855c2855 < 0000b300 80 38 01 00 80 38 01 00 14 82 00 00 50 00 76 00 |.8...8......P.v.| ---
0000b300 80 38 01 00 80 38 01 00 14 82 00 00 4e 00 74 00
|.8...8......N.t.|
Hi, Matt! Thank you very much for your research. Yes, I confirm that the ROMs provided my patch [1] ( installed by ./atombios.sh from this wiki [3] ) have been obtained from two G505S: one with HD 8570M dGPU and another with R5 M230 dGPU ; and the iGPU ROM of this patch is "from G505S with R5 M230", with the differences outlined in our messages [4] . I don't have a G505S without a discrete GPU - so couldn't get its' iGPU ROM version from it by myself. However: the build with my ("from G505S with R5 M230") integrated GPU ROM version, discrete GPU ROMs and also the dGPU patches - has been tested by /u/QubesN00b at [2] thread - and no problems observed.
Maybe these differences at iGPU are related to dGPU, since these GPUs were meant to be working together in a Crossfire? Thank you for submitting your ROM, a bit later I'm going to use AtomDis to try to figure out what are these differences and report back. Hopefully these differences aren't significant and this iGPU ROM "from G505S with R5 M230" really could be used by everyone without any downsides (also because I don't want to overcomplicate my patches with multiple ROM versions for the same iGPU)
Best regards, Mike Banon
[1] https://review.coreboot.org/c/coreboot/+/31944 [2] https://www.reddit.com/r/coreboot/comments/ar8v7d/if_your_g505s_does_not_hav... [3] http://dangerousprototypes.com/docs/Lenovo_G505S_hacking [4] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWI...
On Sun, May 5, 2019 at 11:34 PM Matt B matthewwbradley6@gmail.com wrote:
Greetings,
Because it's always good to check, I extracted the discrete GPU's vgabios rom from my G505s following method 3 ("Retrieval via Linux kernel") listed here: [1] I have no dGPU, and I assume that it was discovered that this produces a clean (correct) iGPU rom blob. Not that I wrote a '1' to the file first to enable reading, as noted here: [2] I compared the files using tkdiff in hexdump format. See attachments for the files.
Comparing the file that I extracted and pci1002,990b.rom from [3] (obtained via "./atombios.sh") they are definitely very similar, but there are many spots with discrepancies. The diff output is at the end of this email. Along the way I had to take the file from the patch and turn it back into a binary and then hexdump it with the same options to make sure they had the same formatting.
It was noted in [4] that there were some differences between the vgabios roms used for integrated GPUs in laptops with and without discrete ones, specifically with regard to supply voltage. Can anyone confirm that the version supplied via the patch is the one from laptops with a discrete GPU, and that what I have matches what would be expected for a dGPU-less laptop? Is there a hash of the rom itself somewhere to point to?
Sincerely, -Matt
Attachments: extracted_vgabios.rom => the rom I extracted myself extracted_vgabios.rom.txt => the result of "hexdump -C extracted_vgabios.rom" pci1002,990b.rom.txt => the rom from the patch (received along with 6663 and 6665) pci1002,990b.rom.txt.rom => the result of "cat pci1002,990b.rom.txt | xxd -r" pci1002,990b.rom.txt.rom.txt => the result of hexdumping pci1002,990b.rom.txt.rom as above
Checksums: 0c0543a28677baa75c49616e5fe326a413f779e77764f8a6dd13c798d3b076ee extracted_vgabios.rom 0515b8cbf184fbfba13ae48d70b1c5ae05405dd709e0eef2291c6d8a4a587287 pci1002,6663.rom.txt 416c748e5ad538593003e47a484067d7cbb509ddff7de079f5603b6d135898bf pci1002,6665.rom.txt c35f469b56c41385b0196c0c9df6599ef9e81e32078da2dd3cf81760c9bd3365 pci1002,990b.rom.txt
References: [1] https://coreboot.coreboot.narkive.com/zEkIcuSS/ultimate-vgabios-extraction-n... [2] https://www.coreboot.org/VGA_support [3] http://dangerousprototypes.com/docs/Lenovo_G505S_hacking [4] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWI...
Diff results: $ diff extracted_vgabios.rom.txt pci1002,990b.rom.txt.rom.txt 3c3
< 00000020 4d 49 00 00 00 00 00 00 00 00 00 00 00 00 00 04 |MI..............|
00000020 4d d3 00 00 00 00 00 00 00 00 00 00 00 00 00 04 |M...............|
27c27
< 000001a0 34 03 08 00 00 30 02 10 0b 99 b4 01 a4 a5 4a a6 |4....0........J.|
000001a0 34 03 08 00 00 40 02 10 0b 99 b4 01 a4 a5 4a a6 |4....@........J.|
2735,2736c2735,2736 < 0000aae0 00 00 00 00 00 00 d1 00 01 03 12 1b 56 05 70 00 |............V.p.|
< 0000aaf0 00 03 0e 00 20 00 20 00 02 00 04 00 59 01 c2 00 |.... . .....Y...|
0000aae0 00 00 00 00 00 00 d1 00 01 03 41 1c 56 05 a0 00 |..........A.V...| 0000aaf0 00 03 16 00 30 00 20 00 02 00 05 00 58 01 c2 00 |....0. .....X...|
2841c2841
< 0000b200 06 00 00 00 00 00 00 00 4c 00 4e 00 03 00 74 01 |........L.N...t.|
0000b200 06 00 00 00 00 00 00 00 4a 00 4c 00 03 00 74 01 |........J.L...t.|
2848,2850c2848,2850 < 0000b290 00 00 72 00 32 89 00 00 01 00 4e 00 56 d0 00 00 |..r.2.....N.V...| < 0000b2a0 02 00 48 00 40 19 01 00 03 00 42 00 40 19 01 00 |..H.@.....B.@...|
< 0000b2b0 03 00 42 00 8b 1e 00 00 70 11 01 00 00 00 00 00 |..B.....p.......|
0000b290 00 00 70 00 32 89 00 00 01 00 4c 00 56 d0 00 00 |..p.2.....L.V...| 0000b2a0 02 00 46 00 40 19 01 00 03 00 40 00 40 19 01 00 |..F.@.....@.@...| 0000b2b0 03 00 40 00 8b 1e 00 00 70 11 01 00 00 00 00 00 |..@.....p.......|
2855c2855
< 0000b300 80 38 01 00 80 38 01 00 14 82 00 00 50 00 76 00 |.8...8......P.v.|
0000b300 80 38 01 00 80 38 01 00 14 82 00 00 4e 00 74 00 |.8...8......N.t.|
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Matt, so I compared the AtomDis dumps for iGPU ROMs ( yours vs mine ). There are some differences at " data_table 0000aae6 #06 (LVDS_Info): ", sLCDTiming structure: usPixClk ( 0x1b12 vs 0x1c41 ), usHBlanking_Time ( 0x0070 vs 0x00a0 ), usVBlanking_Time ( 0x000e vs 0x0016 ), usHSyncOffset ( 0x0020 vs 0x0030 ), usVSyncWidth ( 0x0004 vs 0x0005 ), usImageHSize ( 0x0159 vs 0x0158 ). Also, some differences at " data_table 0000b1b8 #1e (IntegratedSystemInfo): " : usNBP0Voltage ( 0x4c vs 0x4a ) and usNBP1Voltage ( 0x4e vs 0x4c ) - your values are slightly higher, and some of your usVoltageID values are also slightly higher (0x72 vs 0x70, 0x4e vs 0x4c, 0x48 vs 0x46, 0x42 vs 0x40, 0x42 vs 0x40). Finally, nearby there is also one different ulReserved3 ( 0x00760050 vs 0x0074004e ) - I don't know what this reserved value means, but perhaps it's also related to the voltages or power control.
What is interesting, at our messages [*] there also was a difference at usNBP0Voltage and usNBP1Voltage values: 0x4a vs 0x48 and 0x4c vs 0x4a , but these and your other voltage values are even slightly more higher than this, 2 points higher. Now I think that maybe these values are changing in runtime: while there is a higher CPU load (e.g. while I was reading a lot of RAM with Belkasoft RAM capturer to later extract the AtomBIOS ROMs from it), the performance of GPU could automatically decrease by slightly lowering the voltage, in order to fit the whole APU into 35 Watts TDP.
1) It will be great if you could test this theory by running some CPU-intensive program and dumping the AtomBIOS ROM while it's running.
I still don't know why your sLCDTiming structure is different. Is it also a variable value not tied to the specific hardware, or maybe you have a slightly different LCD panel - which I have never encountered before - and it has a slightly different settings?
2) It will be interesting if you could build a coreboot with my version of iGPU ROM, to see if there are any problems with your screen image.
Hope you could complete "1)" and "2)" quests when you have some free time ;-)
Best regards, Mike Banon
P.S. It could be that a few diffs, e.g. a couple of tiny diffs at the beginning, may have gone unnoticed while using AtomDis :P
[*] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWI...
On Mon, May 6, 2019 at 8:49 PM Mike Banon mikebdp2@gmail.com wrote:
Hi, Matt! Thank you very much for your research. Yes, I confirm that the ROMs provided my patch [1] ( installed by ./atombios.sh from this wiki [3] ) have been obtained from two G505S: one with HD 8570M dGPU and another with R5 M230 dGPU ; and the iGPU ROM of this patch is "from G505S with R5 M230", with the differences outlined in our messages [4] . I don't have a G505S without a discrete GPU - so couldn't get its' iGPU ROM version from it by myself. However: the build with my ("from G505S with R5 M230") integrated GPU ROM version, discrete GPU ROMs and also the dGPU patches - has been tested by /u/QubesN00b at [2] thread - and no problems observed.
Maybe these differences at iGPU are related to dGPU, since these GPUs were meant to be working together in a Crossfire? Thank you for submitting your ROM, a bit later I'm going to use AtomDis to try to figure out what are these differences and report back. Hopefully these differences aren't significant and this iGPU ROM "from G505S with R5 M230" really could be used by everyone without any downsides (also because I don't want to overcomplicate my patches with multiple ROM versions for the same iGPU)
Best regards, Mike Banon
[1] https://review.coreboot.org/c/coreboot/+/31944 [2] https://www.reddit.com/r/coreboot/comments/ar8v7d/if_your_g505s_does_not_hav... [3] http://dangerousprototypes.com/docs/Lenovo_G505S_hacking [4] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWI...
On Sun, May 5, 2019 at 11:34 PM Matt B matthewwbradley6@gmail.com wrote:
Greetings,
Because it's always good to check, I extracted the discrete GPU's vgabios rom from my G505s following method 3 ("Retrieval via Linux kernel") listed here: [1] I have no dGPU, and I assume that it was discovered that this produces a clean (correct) iGPU rom blob. Not that I wrote a '1' to the file first to enable reading, as noted here: [2] I compared the files using tkdiff in hexdump format. See attachments for the files.
Comparing the file that I extracted and pci1002,990b.rom from [3] (obtained via "./atombios.sh") they are definitely very similar, but there are many spots with discrepancies. The diff output is at the end of this email. Along the way I had to take the file from the patch and turn it back into a binary and then hexdump it with the same options to make sure they had the same formatting.
It was noted in [4] that there were some differences between the vgabios roms used for integrated GPUs in laptops with and without discrete ones, specifically with regard to supply voltage. Can anyone confirm that the version supplied via the patch is the one from laptops with a discrete GPU, and that what I have matches what would be expected for a dGPU-less laptop? Is there a hash of the rom itself somewhere to point to?
Sincerely, -Matt
Attachments: extracted_vgabios.rom => the rom I extracted myself extracted_vgabios.rom.txt => the result of "hexdump -C extracted_vgabios.rom" pci1002,990b.rom.txt => the rom from the patch (received along with 6663 and 6665) pci1002,990b.rom.txt.rom => the result of "cat pci1002,990b.rom.txt | xxd -r" pci1002,990b.rom.txt.rom.txt => the result of hexdumping pci1002,990b.rom.txt.rom as above
Checksums: 0c0543a28677baa75c49616e5fe326a413f779e77764f8a6dd13c798d3b076ee extracted_vgabios.rom 0515b8cbf184fbfba13ae48d70b1c5ae05405dd709e0eef2291c6d8a4a587287 pci1002,6663.rom.txt 416c748e5ad538593003e47a484067d7cbb509ddff7de079f5603b6d135898bf pci1002,6665.rom.txt c35f469b56c41385b0196c0c9df6599ef9e81e32078da2dd3cf81760c9bd3365 pci1002,990b.rom.txt
References: [1] https://coreboot.coreboot.narkive.com/zEkIcuSS/ultimate-vgabios-extraction-n... [2] https://www.coreboot.org/VGA_support [3] http://dangerousprototypes.com/docs/Lenovo_G505S_hacking [4] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWI...
Diff results: $ diff extracted_vgabios.rom.txt pci1002,990b.rom.txt.rom.txt 3c3
< 00000020 4d 49 00 00 00 00 00 00 00 00 00 00 00 00 00 04 |MI..............|
00000020 4d d3 00 00 00 00 00 00 00 00 00 00 00 00 00 04 |M...............|
27c27
< 000001a0 34 03 08 00 00 30 02 10 0b 99 b4 01 a4 a5 4a a6 |4....0........J.|
000001a0 34 03 08 00 00 40 02 10 0b 99 b4 01 a4 a5 4a a6 |4....@........J.|
2735,2736c2735,2736 < 0000aae0 00 00 00 00 00 00 d1 00 01 03 12 1b 56 05 70 00 |............V.p.|
< 0000aaf0 00 03 0e 00 20 00 20 00 02 00 04 00 59 01 c2 00 |.... . .....Y...|
0000aae0 00 00 00 00 00 00 d1 00 01 03 41 1c 56 05 a0 00 |..........A.V...| 0000aaf0 00 03 16 00 30 00 20 00 02 00 05 00 58 01 c2 00 |....0. .....X...|
2841c2841
< 0000b200 06 00 00 00 00 00 00 00 4c 00 4e 00 03 00 74 01 |........L.N...t.|
0000b200 06 00 00 00 00 00 00 00 4a 00 4c 00 03 00 74 01 |........J.L...t.|
2848,2850c2848,2850 < 0000b290 00 00 72 00 32 89 00 00 01 00 4e 00 56 d0 00 00 |..r.2.....N.V...| < 0000b2a0 02 00 48 00 40 19 01 00 03 00 42 00 40 19 01 00 |..H.@.....B.@...|
< 0000b2b0 03 00 42 00 8b 1e 00 00 70 11 01 00 00 00 00 00 |..B.....p.......|
0000b290 00 00 70 00 32 89 00 00 01 00 4c 00 56 d0 00 00 |..p.2.....L.V...| 0000b2a0 02 00 46 00 40 19 01 00 03 00 40 00 40 19 01 00 |..F.@.....@.@...| 0000b2b0 03 00 40 00 8b 1e 00 00 70 11 01 00 00 00 00 00 |..@.....p.......|
2855c2855
< 0000b300 80 38 01 00 80 38 01 00 14 82 00 00 50 00 76 00 |.8...8......P.v.|
0000b300 80 38 01 00 80 38 01 00 14 82 00 00 4e 00 74 00 |.8...8......N.t.|
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi,
Interesting results for sure.
It's probably important to note that I actually performed the dump while the laptop was running on a half-charged battery or somewhere in that ballpark. (and a really rather annoying Void Linux live-cd) It seems counter-intuitive that the system would raise voltages under this scenario.
I'll try dumping the rom again multiple times under various load/power conditions. I can probably accomplish this by the end of the day.
I'll look into seeing if I can get the model number of my panel too. At the same time, it would be good if there were a way to ask it about itself.
Sincerely, -Matt
On Wed, May 8, 2019 at 1:10 PM Mike Banon mikebdp2@gmail.com wrote:
Hi Matt, so I compared the AtomDis dumps for iGPU ROMs ( yours vs mine ). There are some differences at " data_table 0000aae6 #06 (LVDS_Info): ", sLCDTiming structure: usPixClk ( 0x1b12 vs 0x1c41 ), usHBlanking_Time ( 0x0070 vs 0x00a0 ), usVBlanking_Time ( 0x000e vs 0x0016 ), usHSyncOffset ( 0x0020 vs 0x0030 ), usVSyncWidth ( 0x0004 vs 0x0005 ), usImageHSize ( 0x0159 vs 0x0158 ). Also, some differences at " data_table 0000b1b8 #1e (IntegratedSystemInfo): " : usNBP0Voltage ( 0x4c vs 0x4a ) and usNBP1Voltage ( 0x4e vs 0x4c ) - your values are slightly higher, and some of your usVoltageID values are also slightly higher (0x72 vs 0x70, 0x4e vs 0x4c, 0x48 vs 0x46, 0x42 vs 0x40, 0x42 vs 0x40). Finally, nearby there is also one different ulReserved3 ( 0x00760050 vs 0x0074004e ) - I don't know what this reserved value means, but perhaps it's also related to the voltages or power control.
What is interesting, at our messages [*] there also was a difference at usNBP0Voltage and usNBP1Voltage values: 0x4a vs 0x48 and 0x4c vs 0x4a , but these and your other voltage values are even slightly more higher than this, 2 points higher. Now I think that maybe these values are changing in runtime: while there is a higher CPU load (e.g. while I was reading a lot of RAM with Belkasoft RAM capturer to later extract the AtomBIOS ROMs from it), the performance of GPU could automatically decrease by slightly lowering the voltage, in order to fit the whole APU into 35 Watts TDP.
- It will be great if you could test this theory by running some
CPU-intensive program and dumping the AtomBIOS ROM while it's running.
I still don't know why your sLCDTiming structure is different. Is it also a variable value not tied to the specific hardware, or maybe you have a slightly different LCD panel - which I have never encountered before - and it has a slightly different settings?
- It will be interesting if you could build a coreboot with my
version of iGPU ROM, to see if there are any problems with your screen image.
Hope you could complete "1)" and "2)" quests when you have some free time ;-)
Best regards, Mike Banon
P.S. It could be that a few diffs, e.g. a couple of tiny diffs at the beginning, may have gone unnoticed while using AtomDis :P
[*] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWI...
On Mon, May 6, 2019 at 8:49 PM Mike Banon mikebdp2@gmail.com wrote:
Hi, Matt! Thank you very much for your research. Yes, I confirm that the ROMs provided my patch [1] ( installed by ./atombios.sh from this wiki [3] ) have been obtained from two G505S: one with HD 8570M dGPU and another with R5 M230 dGPU ; and the iGPU ROM of this patch is "from G505S with R5 M230", with the differences outlined in our messages [4] . I don't have a G505S without a discrete GPU - so couldn't get its' iGPU ROM version from it by myself. However: the build with my ("from G505S with R5 M230") integrated GPU ROM version, discrete GPU ROMs and also the dGPU patches - has been tested by /u/QubesN00b at [2] thread - and no problems observed.
Maybe these differences at iGPU are related to dGPU, since these GPUs were meant to be working together in a Crossfire? Thank you for submitting your ROM, a bit later I'm going to use AtomDis to try to figure out what are these differences and report back. Hopefully these differences aren't significant and this iGPU ROM "from G505S with R5 M230" really could be used by everyone without any downsides (also because I don't want to overcomplicate my patches with multiple ROM versions for the same iGPU)
Best regards, Mike Banon
https://www.reddit.com/r/coreboot/comments/ar8v7d/if_your_g505s_does_not_hav...
[3] http://dangerousprototypes.com/docs/Lenovo_G505S_hacking [4]
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWI...
On Sun, May 5, 2019 at 11:34 PM Matt B matthewwbradley6@gmail.com
wrote:
Greetings,
Because it's always good to check, I extracted the discrete GPU's
vgabios rom from my G505s following method 3 ("Retrieval via Linux kernel") listed here: [1] I have no dGPU, and I assume that it was discovered that this produces a clean (correct) iGPU rom blob. Not that I wrote a '1' to the file first to enable reading, as noted here: [2] I compared the files using tkdiff in hexdump format. See attachments for the files.
Comparing the file that I extracted and pci1002,990b.rom from [3]
(obtained via "./atombios.sh") they are definitely very similar, but there are many spots with discrepancies. The diff output is at the end of this email. Along the way I had to take the file from the patch and turn it back into a binary and then hexdump it with the same options to make sure they had the same formatting.
It was noted in [4] that there were some differences between the
vgabios roms used for integrated GPUs in laptops with and without discrete ones, specifically with regard to supply voltage. Can anyone confirm that the version supplied via the patch is the one from laptops with a discrete GPU, and that what I have matches what would be expected for a dGPU-less laptop? Is there a hash of the rom itself somewhere to point to?
Sincerely, -Matt
Attachments: extracted_vgabios.rom => the rom I extracted myself extracted_vgabios.rom.txt => the result of "hexdump -C
extracted_vgabios.rom"
pci1002,990b.rom.txt => the rom from the patch (received along with
6663 and 6665)
pci1002,990b.rom.txt.rom => the result of "cat pci1002,990b.rom.txt |
xxd -r"
pci1002,990b.rom.txt.rom.txt => the result of hexdumping
pci1002,990b.rom.txt.rom as above
Checksums: 0c0543a28677baa75c49616e5fe326a413f779e77764f8a6dd13c798d3b076ee
extracted_vgabios.rom
0515b8cbf184fbfba13ae48d70b1c5ae05405dd709e0eef2291c6d8a4a587287
pci1002,6663.rom.txt
416c748e5ad538593003e47a484067d7cbb509ddff7de079f5603b6d135898bf
pci1002,6665.rom.txt
c35f469b56c41385b0196c0c9df6599ef9e81e32078da2dd3cf81760c9bd3365
pci1002,990b.rom.txt
References: [1]
https://coreboot.coreboot.narkive.com/zEkIcuSS/ultimate-vgabios-extraction-n...
[2] https://www.coreboot.org/VGA_support [3] http://dangerousprototypes.com/docs/Lenovo_G505S_hacking [4]
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GZNWI...
Diff results: $ diff extracted_vgabios.rom.txt pci1002,990b.rom.txt.rom.txt 3c3 < 00000020 4d 49 00 00 00 00 00 00 00 00 00 00 00 00 00 04
|MI..............|
00000020 4d d3 00 00 00 00 00 00 00 00 00 00 00 00 00 04
|M...............|
27c27 < 000001a0 34 03 08 00 00 30 02 10 0b 99 b4 01 a4 a5 4a a6
|4....0........J.|
000001a0 34 03 08 00 00 40 02 10 0b 99 b4 01 a4 a5 4a a6 |4....@
........J.|
2735,2736c2735,2736 < 0000aae0 00 00 00 00 00 00 d1 00 01 03 12 1b 56 05 70 00
|............V.p.|
< 0000aaf0 00 03 0e 00 20 00 20 00 02 00 04 00 59 01 c2 00 |.... .
.....Y...|
0000aae0 00 00 00 00 00 00 d1 00 01 03 41 1c 56 05 a0 00
|..........A.V...|
0000aaf0 00 03 16 00 30 00 20 00 02 00 05 00 58 01 c2 00 |....0.
.....X...|
2841c2841 < 0000b200 06 00 00 00 00 00 00 00 4c 00 4e 00 03 00 74 01
|........L.N...t.|
0000b200 06 00 00 00 00 00 00 00 4a 00 4c 00 03 00 74 01
|........J.L...t.|
2848,2850c2848,2850 < 0000b290 00 00 72 00 32 89 00 00 01 00 4e 00 56 d0 00 00
|..r.2.....N.V...|
< 0000b2a0 02 00 48 00 40 19 01 00 03 00 42 00 40 19 01 00 |..H.@
.....B.@...|
< 0000b2b0 03 00 42 00 8b 1e 00 00 70 11 01 00 00 00 00 00
|..B.....p.......|
0000b290 00 00 70 00 32 89 00 00 01 00 4c 00 56 d0 00 00
|..p.2.....L.V...|
0000b2a0 02 00 46 00 40 19 01 00 03 00 40 00 40 19 01 00 |..F.@
.....@.@...|
0000b2b0 03 00 40 00 8b 1e 00 00 70 11 01 00 00 00 00 00
|..@.....p.......|
2855c2855 < 0000b300 80 38 01 00 80 38 01 00 14 82 00 00 50 00 76 00
|.8...8......P.v.|
0000b300 80 38 01 00 80 38 01 00 14 82 00 00 4e 00 74 00
|.8...8......N.t.|
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi,
I didn't get a different binary (at least, using this method) when charging the battery, nor did I get different results when doing so under full CPU load under linux.
Getting frustrated with the livecd I took a break and tried Hardware Monitor under windows. The "GPU voltage" was static at 1.062 V while charging the battery and under none-to-light load. (graphics and memory clocks at 351 and 800 MHz respectively) The CPU voltages started to swing noticeably when the CPU was stressed, but the GPU voltages remained constant. This was confirmed by AMD OverDrive. (version 4.2.6.0659)
However, when stressing the GPU using a browser-based benchmark ( web.basemark.com), the GPU voltage spiked to as high as 1.137 Volts as reported by the windows software. I switched back to void linux and ran the same benchmark, but unfortunately the collected vgabios rom is still the same. (even while under such heavy load that the computer became difficult to use)
Sincerely, -Matt
Hi,
Real progress this time, on understanding the differences in the LVDS info.
I should note (btw) that I'm currently testing with the most up-to-date version of the proprietary G505s bios.
I dumped the EDID information for my display panel from the following files: /sys/devices/pci0000:00/0000:00:01.0/drm/card0/card0-HDMI-A-1/edid /sys/devices/pci0000:00/0000:00:01.0/drm/card0/card0-VGA-1/edid /sys/devices/pci0000:00/0000:00:01.0/drm/card0/card0-eDP-1/edid The first two were blank (which seems to be normal for Lenovo) and the third contained an EDID blob, see the end of the email for the raw bytes, attachments for the file itself.
I pasted this into the online tool www.edidreader.com and made some interesting findings, like that my panel's serial number is zero or that the manufacturing date seems to be incomplete. (some time in 2012?) However, most notably the detailed timing characteristics are: Pixel Clock: 69.3MHz Horizontal Active: 1366 Horizontal Blanking: 112 Vertical Active: 768 Vertical Blanking: 14 Horizontal Sync Offset: 32 Horizontal Sync Pulse: 32 Vertical Sync Offset: 2 Vertical Sync Pulse: 4 Horizontal Display Size: 345 Vertical Display Size: 194 Horizontal Border: 0 Vertical Border: 0 Interlaced: false Stereo Mode: 0 Sync Type: 3 2-Way Line-Interleaved Stereo: true
The weird thing is that it was the *eDP* EDID file which was non-empty, when I could have sworn that the G505s uses a 40 pin LVDS cable.
When these values are compared with the LVDS values you flagged, every single one of them is a match when your values are converted to decimal. It might be worthwhile to compare the two sets in their entirety to see if there's anything that doesn't match up.
This is *pure* speculation on my part, but I'm suspecting that the proprietary bios patches the vgabios rom with the timing information it extracts from the panel's EDID information. For the sake of argument, I suppose that the EDID information presented could be derived from the blob, but this seems unlikely.
As luck would have it, I have another laptop with a display panel that (I suspect) is a compatible replacement for the one in the G505s, and which I am *very* experienced at replacing. :) It will have to wait, but it's theoretically possible I could frankenstein this panel into the G505s and check to see if the above theory is correct. The blob as it exists in the spi flash could also be examined.
This raises an interesting question: Does coreboot have machinery to patch vgabios blobs based on EDID codes? I have to imagine it might improve compatibility, and parts of it might even be helpful to libgfxinit.
Sincerely, -Matt
EDID bytes: 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x30 0xE4 0x9F 0x03 0x00 0x00 0x00 0x00 0x00 0x16 0x01 0x03 0x80 0x23 0x13 0x78 0x0A 0x05 0xF5 0x94 0x58 0x56 0x92 0x28 0x1E 0x50 0x54 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x12 0x1B 0x56 0x70 0x50 0x00 0x0E 0x30 0x20 0x20 0x24 0x00 0x59 0xC2 0x10 0x00 0x00 0x19 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFE 0x00 0x4C 0x47 0x20 0x44 0x69 0x73 0x70 0x6C 0x61 0x79 0x0A 0x20 0x20 0x00 0x00 0x00 0xFE 0x00 0x4C 0x50 0x31 0x35 0x36 0x57 0x48 0x33 0x2D 0x54 0x4C 0x53 0x31 0x00 0xE3
On Thu, May 9, 2019 at 7:03 PM Matt B matthewwbradley6@gmail.com wrote:
Hi,
I didn't get a different binary (at least, using this method) when charging the battery, nor did I get different results when doing so under full CPU load under linux.
Getting frustrated with the livecd I took a break and tried Hardware Monitor under windows. The "GPU voltage" was static at 1.062 V while charging the battery and under none-to-light load. (graphics and memory clocks at 351 and 800 MHz respectively) The CPU voltages started to swing noticeably when the CPU was stressed, but the GPU voltages remained constant. This was confirmed by AMD OverDrive. (version 4.2.6.0659)
However, when stressing the GPU using a browser-based benchmark ( web.basemark.com), the GPU voltage spiked to as high as 1.137 Volts as reported by the windows software. I switched back to void linux and ran the same benchmark, but unfortunately the collected vgabios rom is still the same. (even while under such heavy load that the computer became difficult to use)
Sincerely, -Matt
Matt, what a great research! Thank you very much for your findings! No need to replace your screen (unless you'd like to upgrade it for other reasons). Soon I'm going to get my own eDP_EDID.bin for comparison. Also, I could run your version of iGPU blob out of curiosity, while you could try to run my version meanwhile - and then, after flashing a coreboot.rom with this blob included and booting, we can extract it again, to see if anything changed there during a boot.
I hope this AtomBIOS blob somehow autoconfigures itself at least regarding these LVDS screenpanel-specific values - so even if it contains a not-matching set of LVDS values, they would be overwritten by what is correct during the runtime. Or at least that the display panels of G505S are very similar to each other and there wouldn't be any screen problems from using a iGPU blob of another G505S. Luckily getting your own iGPU ROM is much easier than dGPU
On Fri, May 10, 2019 at 3:14 AM Matt B matthewwbradley6@gmail.com wrote:
Hi,
Real progress this time, on understanding the differences in the LVDS info.
I should note (btw) that I'm currently testing with the most up-to-date version of the proprietary G505s bios.
I dumped the EDID information for my display panel from the following files: /sys/devices/pci0000:00/0000:00:01.0/drm/card0/card0-HDMI-A-1/edid /sys/devices/pci0000:00/0000:00:01.0/drm/card0/card0-VGA-1/edid /sys/devices/pci0000:00/0000:00:01.0/drm/card0/card0-eDP-1/edid The first two were blank (which seems to be normal for Lenovo) and the third contained an EDID blob, see the end of the email for the raw bytes, attachments for the file itself.
I pasted this into the online tool www.edidreader.com and made some interesting findings, like that my panel's serial number is zero or that the manufacturing date seems to be incomplete. (some time in 2012?) However, most notably the detailed timing characteristics are: Pixel Clock: 69.3MHz Horizontal Active: 1366 Horizontal Blanking: 112 Vertical Active: 768 Vertical Blanking: 14 Horizontal Sync Offset: 32 Horizontal Sync Pulse: 32 Vertical Sync Offset: 2 Vertical Sync Pulse: 4 Horizontal Display Size: 345 Vertical Display Size: 194 Horizontal Border: 0 Vertical Border: 0 Interlaced: false Stereo Mode: 0 Sync Type: 3 2-Way Line-Interleaved Stereo: true
The weird thing is that it was the *eDP* EDID file which was non-empty, when I could have sworn that the G505s uses a 40 pin LVDS cable.
When these values are compared with the LVDS values you flagged, every single one of them is a match when your values are converted to decimal. It might be worthwhile to compare the two sets in their entirety to see if there's anything that doesn't match up.
This is *pure* speculation on my part, but I'm suspecting that the proprietary bios patches the vgabios rom with the timing information it extracts from the panel's EDID information. For the sake of argument, I suppose that the EDID information presented could be derived from the blob, but this seems unlikely.
As luck would have it, I have another laptop with a display panel that (I suspect) is a compatible replacement for the one in the G505s, and which I am *very* experienced at replacing. :) It will have to wait, but it's theoretically possible I could frankenstein this panel into the G505s and check to see if the above theory is correct. The blob as it exists in the spi flash could also be examined.
This raises an interesting question: Does coreboot have machinery to patch vgabios blobs based on EDID codes? I have to imagine it might improve compatibility, and parts of it might even be helpful to libgfxinit.
Sincerely, -Matt
EDID bytes: 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x30 0xE4 0x9F 0x03 0x00 0x00 0x00 0x00 0x00 0x16 0x01 0x03 0x80 0x23 0x13 0x78 0x0A 0x05 0xF5 0x94 0x58 0x56 0x92 0x28 0x1E 0x50 0x54 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x12 0x1B 0x56 0x70 0x50 0x00 0x0E 0x30 0x20 0x20 0x24 0x00 0x59 0xC2 0x10 0x00 0x00 0x19 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xFE 0x00 0x4C 0x47 0x20 0x44 0x69 0x73 0x70 0x6C 0x61 0x79 0x0A 0x20 0x20 0x00 0x00 0x00 0xFE 0x00 0x4C 0x50 0x31 0x35 0x36 0x57 0x48 0x33 0x2D 0x54 0x4C 0x53 0x31 0x00 0xE3
On Thu, May 9, 2019 at 7:03 PM Matt B matthewwbradley6@gmail.com wrote:
Hi,
I didn't get a different binary (at least, using this method) when charging the battery, nor did I get different results when doing so under full CPU load under linux.
Getting frustrated with the livecd I took a break and tried Hardware Monitor under windows. The "GPU voltage" was static at 1.062 V while charging the battery and under none-to-light load. (graphics and memory clocks at 351 and 800 MHz respectively) The CPU voltages started to swing noticeably when the CPU was stressed, but the GPU voltages remained constant. This was confirmed by AMD OverDrive. (version 4.2.6.0659)
However, when stressing the GPU using a browser-based benchmark (web.basemark.com), the GPU voltage spiked to as high as 1.137 Volts as reported by the windows software. I switched back to void linux and ran the same benchmark, but unfortunately the collected vgabios rom is still the same. (even while under such heavy load that the computer became difficult to use)
Sincerely, -Matt
-
Matt B -
Mike Banon