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 <matthewwbradl...@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 <matthewwbradl...@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 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
