[coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch

[Mark Wylde]

Hi Julius.

Thanks so much for your message it was a great help.

So looking at the specs for the display that comes with the ASUS Chromebook C201 I can see the following PIN structure [1] is required on the display end. Also my new monitor [2] has the exact same PIN structure for the display, but unfortunately uses the ML1 lane.

------------------ eDP Pins for C201 Display ------------------
1  = NC No Connection (Reserved for LCD test)
2  = H_GND High Speed Ground
3  = NC No Connection ( Reserved for ML1 - )
4  = NC No Connection (Reserved for ML1+)
5  = H_GND High Speed Ground
6  = ML0 - Complement Signal - Lane 0
7  = ML0+ True Signal - Main Lane 0
8  = H_GND High Speed Ground
9  = AUX+ True Signal - Auxiliary Channel
10 = AUX - Complement Signal - Auxiliary Channel
11 = H_GND High Speed Ground
12 = VCCS Power Supply +3.3 V (typical)
13 = VCCS Power Supply +3.3 V (typical)
14 = NC No Connection (Reserved for LCD test)
15 = GND Ground
16 = GND Ground
17 = HPD Hot Plug Detect
18 = BL_GND BL Ground
19 = BL_GND BL Ground
20 = BL_GND BL Ground
21 = BL_GND BL Ground
22 = LED_EN BL_Enable Signal of LED Converter
23 = LED_PWM PWM Dimming Control Signal of LED Converter
24 = NC No Connection (Reserved for LCD test)
25 = NC No Connection (Reserved for LCD test)
26 = LED_VCCS BL Power
27 = LED_VCCS BL Power
28 = LED_VCCS BL Power
29 = LED_VCCS BL Power
30 = NC No Connection (Reserved for LCD test)
--------------------------------------------------

I think I understand by your response that ASUS has used a 20 pin connector on the motherboard part. Therefore they haven't connected up the the ML1 lane. It also looks like with only 1 lane you can only have a resolution of 1680×1050 (18 bit color depth) [3] which would be a waste of the 15'' display. Although even if they did have the lane exposes it looks like your helpful advice on the coreboot function would be a bit out of my depth.

So I think we can conclude it's impossible to get a bigger monitor (or at least one with a bigger resolution) through the eDP port. I guess one could get a controller board and hook the monitor up via the HDMI mini port, but I think I'll pass on that. It was interesting to learn more about eDP though.

Thanks Julius and Nico for all your help.

1. http://www.szdengyi.com/upload/web/lcdspec/N116BGE-EB2-LR-Asus-notebook-pc.pdf
2. http://www.yslcd.com.tw/docs/product/N156HGE-EAB.pdf
3. https://forums.lenovo.com/t5/Lenovo-U-and-S-Series-Notebooks/Lenovo-U430p-screen-upgrade/m-p/2155787/highlight/true#M42366
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 5, 2018 11:50 PM, Julius Werner <jwerner at chromium.org> wrote:

> I have access to the schematics for Speedy... I'm not allowed to share them, but I'm happy to look up something specific for you if it helps.
>
> Nico is right, only one of the four DP lanes coming out of the SoC is routed to the connector. If your panel requires more than that, you're probably SOL. Although I'm not even sure where they would go on that connector... there's only 20 pins, and they all seem to be used already. (I'm not really sure how standardized those connectors are, tbh... if you buy a panel with a different pinout, obviously nothing will work and it might even damage the panel and/or the mainboard.)
>
> I also remember that RK3288 PLLs often had some issues with jitter (at least they had for HDMI, not sure if it applies to DP). The code we implemented (clock.c:pll_para_config) does whatever it can to meet the pixel clock as exactly as possible, but maybe that wasn't actually the best way to do it. In your case you end up with a very large input divisor (NR = 59), so you're essentially dividing the 24MHz oscillator down to 407KHz and then multiplying it back up (thus amplifying noise). Maybe try hacking that function to hardcode the result to NR = 1, NF = 23, NO = 4 (leading to VCO = 552000KHz, output = 138000KHz) or NR = 4, NF = 91, NO = 4 (leading to VCO = 546000KHz, output = 136500KHz) and see if that helps. (In fact, that latter configuration is closer to the target frequency of 136620KHz than the one you get... what you're seeing is sort of a freak accident resulting from a compounding of rounding errors during the calculation. You're welcome to try to fix the code if you want, but it's kinda difficult to get all the different requirements right at once... for example, you'd have less errors if it were calculating in Hz, but we went with KHz since we were afraid it could overflow in some situations.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180306/f6ca2128/attachment.html>