Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
> > While this might be closer to the optimum for 60Hz, it would still try > to pump data at around 136MHz. DP doesn't use a variable pixel clock on > the physical layer. It's using either 1.62GHz (reduced bit-rate, RBR) or > 2.7GHz (high bit-rate, HBR). Or (not supported by this code and likely > not by the SoC) 5.4GHz (HBR2) or 8.1GHz (HBR3). Data is encoded with 10 > bits per 8 bits of payload, so for a single lane at HBR you can only get > up to 2.7GHz / 10 * 8 / 18 = 120MHz. Okay, you clearly know more than me. ;) All I know is that the pixel clock is supposed to match the value in the EDID descriptor, and that we had problems with jitter on it (although that might have just been HDMI). But I'm not sure how exactly it is used... if you say the eDP clock is constant, maybe it's just being used internally on the SoC (in the connection between Video Output Processor and the eDP block)? > If it relates to what I know from Intel graphics, M/N gives the ratio > how much of the bandwidth on the lanes is used for actual picture data. I think I found it now. We're passing CALCULATED_M to that function, so it's using the second path (which only initializes N to 0x8000). It clears the FIX_M_VID bit which I think means that M is being calculated automatically by the controller. > > The other lanes aren't routed on the board. This isn't going to help. > > To be clear, I meant to override it with 1. As far as I understand the > code, this should configure both sink and source to use only a single > lane. Oh, okay, yes, I guess that could help. Although it sounds(?) like at that point you're essentially ignoring the EDID and just trying to make up your own video mode, so it seems more like a shot in the dark. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] armv8 mmu limitation?
On 2018-03-06 12:57, mtur...@codeaurora.org wrote: Folks, We are working with a device that has 8GB DDR. Using the basic mmu_config_range() call, twice, like this: mmu_config_range((void *)0x08000, DRAMSIZE, UNCACHED_MEM); mmu_config_range((void *)0x18000, DRAMSIZE, UNCACHED_MEM); print messages from Coreboot suggest the mmu calls are happy: Mapping address range [8000:00018000) as non-cacheable | read-write | non-secure | normal Mapping address range [00018000:00028000) as non-cacheable | read-write | non-secure | normal The debugger is not convinced and believes only 6GB got mapped. This came back to BITS_PER_VA being hard-coded to 33 which is currently being discussed in another thread. If we change to 34 we see full 8GB mapping that we were expecting. I'm guessing tables are overflowing and perhaps granule or page sizes need to be changed or? As mmu_init() takes no parameters, what mmu options are easily configurable within Coreboot? Any pointers to correct code to look at is appreciated. Cheers, T.mike -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Debug suspend to RAM on KGPE-D16
That must have been someone else, as I've not been on the IRC. If you could share some logs that would be great. On Tue, Mar 6, 2018 at 11:34 AM, Merlin Büge wrote: > Hey Rob, > > was it you discussing suspend to RAM with tpearson on > #coreboot@freenode ? > > If not I could send you some logs, maybe it has useful information for > you (tpearson knows the D16 very well, he did the coreboot port). > > Cheers, > > Merlin > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
On 06.03.2018 22:13, Julius Werner wrote: >> 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. > > It's pretty simple... try this patch (untested) which should implement what > I suggested. I think there's a decent chance this might make your other > panel work as well. (Note that this is *only* for the exact panel you > originally posted log output for. Also: I think this should work, but > there's a slim chance wrong pixel clocks may damage a panel, no warranty, > yada yada.) > > diff --git a/src/soc/rockchip/rk3288/clock.c b/src/soc/rockchip/rk3288/clock > .c > index 74151e85cb..4474ff81aa 100644 > --- a/src/soc/rockchip/rk3288/clock.c > +++ b/src/soc/rockchip/rk3288/clock.c > @@ -539,6 +539,11 @@ static int pll_para_config(u32 freq_hz, struct pll_div > *div, u32 *ext_div) > return -1; > } > > + div->no = 4; > + div->nf = 91; > + div->nr = 4; > + return 0; > + > div->no = no; > > best_diff_khz = vco_khz; > While this might be closer to the optimum for 60Hz, it would still try to pump data at around 136MHz. DP doesn't use a variable pixel clock on the physical layer. It's using either 1.62GHz (reduced bit-rate, RBR) or 2.7GHz (high bit-rate, HBR). Or (not supported by this code and likely not by the SoC) 5.4GHz (HBR2) or 8.1GHz (HBR3). Data is encoded with 10 bits per 8 bits of payload, so for a single lane at HBR you can only get up to 2.7GHz / 10 * 8 / 18 = 120MHz. > > I'm not sure if the coreboot source is prepared for that, though. There >> are some pieces in the code that confuse me (e.g. the zeros passed to >> rk_edp_set_video_cr_mn(), Julius, do you happen to know something about >> that? is there public documentation for Rockchip's display engine?). >> > > Sorry, I gotta admit I'm not a display guy at all. We mostly just took what > they gave us. The reference manuals were all shared with us under NDA... > you could try asking them directly, but I doubt you'll have much luck. The > document you're looking for is called "Rockchip EDP TX IP Interface". It > has lots of nice explanations including about M and N, but I don't really > understand them without background. If it relates to what I know from Intel graphics, M/N gives the ratio how much of the bandwidth on the lanes is used for actual picture data. > > >> I would, however, give the following one shot: >> >> 1. in soc/rockchip/common/edp.c line 615 override the lane count: >> >> edp->link_train.lane_count = 1; >> > > The other lanes aren't routed on the board. This isn't going to help. To be clear, I meant to override it with 1. As far as I understand the code, this should configure both sink and source to use only a single lane. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
> 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. I'm confused... there's 30 pins there, but there should only be 20 on the connector. I guess you got this from the panel datasheet directly? If you bought your panel together with the cable, you still don't know how those map to what's on the connector. Looks like they're dropping 10 of them and rearranging the rest, because this looks nothing like the schematics I have. (For reference it starts with two VCC_LED, two VCC33_LCD, then HOTPLUG and two backlight-related pins.) > 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. It's pretty simple... try this patch (untested) which should implement what I suggested. I think there's a decent chance this might make your other panel work as well. (Note that this is *only* for the exact panel you originally posted log output for. Also: I think this should work, but there's a slim chance wrong pixel clocks may damage a panel, no warranty, yada yada.) diff --git a/src/soc/rockchip/rk3288/clock.c b/src/soc/rockchip/rk3288/clock .c index 74151e85cb..4474ff81aa 100644 --- a/src/soc/rockchip/rk3288/clock.c +++ b/src/soc/rockchip/rk3288/clock.c @@ -539,6 +539,11 @@ static int pll_para_config(u32 freq_hz, struct pll_div *div, u32 *ext_div) return -1; } + div->no = 4; + div->nf = 91; + div->nr = 4; + return 0; + div->no = no; best_diff_khz = vco_khz; I'm not sure if the coreboot source is prepared for that, though. There > are some pieces in the code that confuse me (e.g. the zeros passed to > rk_edp_set_video_cr_mn(), Julius, do you happen to know something about > that? is there public documentation for Rockchip's display engine?). > Sorry, I gotta admit I'm not a display guy at all. We mostly just took what they gave us. The reference manuals were all shared with us under NDA... you could try asking them directly, but I doubt you'll have much luck. The document you're looking for is called "Rockchip EDP TX IP Interface". It has lots of nice explanations including about M and N, but I don't really understand them without background. > I would, however, give the following one shot: > > 1. in soc/rockchip/common/edp.c line 615 override the lane count: > > edp->link_train.lane_count = 1; > The other lanes aren't routed on the board. This isn't going to help. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware
An update on the use of Index I/O to access the SPI flash from software. I figured out the problem with coreboot. We weren't setting the LPC I/O decode range 0x380-0x383 in the LPC PCI config (gen1_dec config in devicetree) which would allow us to talk to the EC using Index I/O on port 0x380. Once I set that, I was able to access Index I/O on my coreboot-ed machine, and that opens up the software-based flashing support. On Mon, Mar 5, 2018 at 5:34 PM, Youness Alaoui wrote: > Thanks for the advice Mike, but I think you misunderstood the issue. I > wasn't talking about the internal memory of the EC, but rather about > accessing the EC firmware in SPI flash via an external SPI flasher. > The problem is that the SPI flash power rail is the same as the EC > chip, so as soon as we power the SPI flash to read it, it will also > power the EC chip, which will drive the SPI I/O pins high/low to read > its firmware, and since the EC executes the firmware from the flash, > that means that the SPI flash will constantly be accessed by the EC > and the external flasher can't take control of the I/O. > However, it looks like if the EC firmware crashes, it will stop using > the flash and will therefore 'release' the I/O pins for the external > flasher to use them. > If I short MISO with VCC, then the EC will read its firmware as being > all 0xFF (which is the same as when I corrupted the flash by erasing > its first sector), and that will cause it to crash and release the SPI > flash, then we can read it. No need to solder or enable debug mode or > anything like that. > > Anyways, my true purpose is to use software flashing only, I already > have read/write/sector_erase support written but it requires the use > of the Index I/O (LPC port 0x380) which I can only access when I flash > the machine with the AMI BIOS, but which becomes inaccessible if I > only have coreboot. I think it's because AMI will send EC > vendor-specific commands via LPC port 62h/66h to configure it and > enable the Index I/O access. I've suggested to Paul if we could a > reduced firmware that would only log to UART all the accesses to the > EC via the LPC port 62/66 (kind of like doing SerialICE for the EC) so > we could document the vendor specific commands AMI uses to enable > Index I/O. Once we know that, we should be able to read/write to the > EC flash using software only. > > > On Mon, Mar 5, 2018 at 4:04 PM, Mike Banon wrote: >>> otherwise, the EC prevents us from accessing it >> Maybe KB3940Q has the same protection as KB9012 : unless the EC's >> ground pin has been shortened with motherboard's ground _before_ you >> have powered a motherboard, you would not have any access; otherwise, >> EC will go into debug mode and you'll have the full access to its' >> internal memory. To avoid the soldering, you could look through the >> instructions described here - >> http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ; >> in short : use a keyboard flex cable to reach EC spi pins as well as >> its' ground, and a test hook clip to easily get a ground of your >> motherboard >> >> On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui >> wrote: >>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski wrote: Hi, Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit : > > > Sure, you can trust hardware flashing more than software flashing, > > > but > > > I really need software flashing. If it was just for me, yeah, I > > > could > > > fiddle with it to flash it by hardware for my personal needs, but > > > when > > > it's about deploying it to all our customer base, that's another > > > story, the only solution is software flashing. Obviously, it would > > > have to work in coreboot, so whatever coreboot is doing wrong (or > > > AMI > > > is doing right.. my guess is that it's probably something with the > > > EC > > > ACPI code), we'd have to figure that out first in order to get the > > > read/write support. > > > > Either way, since the EC firmware resides in the SPI flash, it'll be > > no > > issue to reflash it both by software and hardware. > > On the librems, the EC firmware resides in a separate 64KB SPI flash, > it's not shared with the bios, and I haven't found a way to access it. Is it really only 64 KiB? The chip definitely supports more and it seems a bit small to fit the whole firmware. >>> >>> Yes, it's a MX25L512. I can send you the firmwares that were on it if >>> you're curious (each machine revision had a different firmware, even >>> though it's the same ene chip in all of them, I don't know enough >>> about the EC to know if that's normal). >>> >>> The cool thing is that I was able to flash the chip externally, but >>> only when I corrupted the EC firmware (I erased the first page and the >>> laptop crashed before I finished re-programming it by software). I >>> reproduced it twice again, if the
[coreboot] armv8 mmu limitation?
Folks, We are working with a device that has 8GB DDR. Using the basic mmu_config_range() call, twice, like this: mmu_config_range((void *)0x08000, DRAMSIZE, UNCACHED_MEM); mmu_config_range((void *)0x18000, DRAMSIZE, UNCACHED_MEM); print messages from Coreboot suggest the mmu calls are happy: Mapping address range [8000:00018000) as non-cacheable | read-write | non-secure | normal Mapping address range [00018000:00028000) as non-cacheable | read-write | non-secure | normal The debugger is not convinced and believes only 6GB got mapped. I'm guessing tables are overflowing and perhaps granule or page sizes need to be changed or? As mmu_init() takes no parameters, what mmu options are easily configurable within Coreboot? Any pointers to correct code to look at is appreciated. Cheers, T.mike -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Real name policy
On Tue, Mar 6, 2018 at 9:04 AM, wrote: > On 2018-03-05 17:50, David Hendricks wrote: > >> On Mon, Mar 5, 2018 at 1:13 PM, taii...@gmx.com >> wrote: >> >> I can't understand as to why doing a git commit requires your "real" >>> name >>> >> >> SCO. >> >> Ref: https://lkml.org/lkml/2004/5/23/10 >> > > Wow, SCO, really? > Well, any (likely failing) company who would rather litigate and "play the US legal system as a lottery" (as Torvalds put it) instead of investing in engineering to build/improve their own product. > If anybody on list is interested, I gave a presentation on the SCO > litigation to a local LUG in April.2005. > > http://recipes4linux.com/os-presentations/2005apr.pdf Nice! BTW, did you know the case is still ongoing? Check out https://www.ca10.uscourts.gov/opinions/16/16-4040.pdf . Section G begins with "We are now almost fifteen years into this litigation." As silly as SCO's claims were, last I heard (years ago) IBM had spent over a hundred million dollars on the case. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Real name policy
On 2018-03-05 17:50, David Hendricks wrote: On Mon, Mar 5, 2018 at 1:13 PM, taii...@gmx.com wrote: I can't understand as to why doing a git commit requires your "real" name SCO. Ref: https://lkml.org/lkml/2004/5/23/10 Wow, SCO, really? If anybody on list is interested, I gave a presentation on the SCO litigation to a local LUG in April.2005. http://recipes4linux.com/os-presentations/2005apr.pdf Cheers, T.mike -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
06.03.2018 09:55, Mark Wylde wrote: > 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. The resolution isn't limited, only the data rate is. If the display supports different refresh rates than the usual 60Hz (possible, the datasheet isn't clear about that, IMHO), you can have a higher reso- lution at a lower refresh rate. So FHD at 50Hz might be possible with a single lane. You could try to figure the display's support for lower rates using the OS' driver (e.g. xrandr with Linux/X.Org). I'm not sure if the coreboot source is prepared for that, though. There are some pieces in the code that confuse me (e.g. the zeros passed to rk_edp_set_video_cr_mn(), Julius, do you happen to know something about that? is there public documentation for Rockchip's display engine?). I would, however, give the following one shot: 1. in soc/rockchip/common/edp.c line 615 override the lane count: edp->link_train.lane_count = 1; 2. in soc/rockchip/rk3288/display.c line 101 override the pixel clock: edid.mode.pixel_clock = 113850; The number assumes that the display can do 2.7GHz on the lane. You'd have to go down to 30Hz (68310) otherwise. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Real name policy
On Tue, March 6, 2018 9:22 am, Carl-Daniel Hailfinger wrote: > > Besides that, any project knowingly accepting code from an entity known > for questionable provenance of submitted code would itself become an easy > target for lawsuits. Sorry, bad idea then- will retract. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Real name policy
On 06.03.2018 09:13, awokd via coreboot wrote: > On Tue, March 6, 2018 1:58 am, Gregg Levine wrote: >> That's a great reason right there. Who knows how much they contributed >> to the state of the art, and did not properly sign it. But in the end while >> their world was collapsing around them, we knew who they were via Groklaw. >> >> >> On Mon, Mar 5, 2018 at 8:50 PM, David Hendricks >> wrote: >> >>> On Mon, Mar 5, 2018 at 1:13 PM, taii...@gmx.com >>> wrote: >>> I can't understand as to why doing a git commit requires your "real" name >>> >>> SCO. >>> >>> Ref: https://lkml.org/lkml/2004/5/23/10 > Could some type of asset-less legal entity be set up (cheaply, > anonymously) somewhere in the world to accept anonymous code donations and > commit them on behalf of their submitter? Would shield open source > projects from frivolous lawsuits and protect contributors' privacy. > Apologies if this has already all been discussed thoroughly somewhere else... You're suggesting to set up a corporation. Your model would be almost the code equivalent to a patent troll, a non-practicing entity set up for lawsuit purposes. Besides that, any project knowingly accepting code from an entity known for questionable provenance of submitted code would itself become an easy target for lawsuits. Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
Typical luck, just as I sent my last message my new monitor arrives. I've just hooked it up and it actually worked. Unfortunately it's not a 15'' monitor, but a 14'' one. Not sure how it works on only 1 lane, but not going to complain. For anyone else interested the monitor specs are here: http://www.bvslcd.cn/uploads/2016/11/261508375971.pdf ‐‐‐ Original Message ‐‐‐ On March 6, 2018 8:55 AM, Mark Wylde wrote: > 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 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 erro
Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
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 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.)-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Real name policy
On Tue, March 6, 2018 1:58 am, Gregg Levine wrote: > Hello! > That's a great reason right there. Who knows how much they contributed > to the state of the art, and did not properly sign it. But in the end while > their world was collapsing around them, we knew who they were via Groklaw. > - > Gregg C Levine gregg.drw...@gmail.com > "This signature fought the Time Wars, time and again." > > > > On Mon, Mar 5, 2018 at 8:50 PM, David Hendricks > wrote: > >> >> >> On Mon, Mar 5, 2018 at 1:13 PM, taii...@gmx.com >> wrote: >> >>> >>> I can't understand as to why doing a git commit requires your "real" >>> name >> >> >> SCO. >> >> >> Ref: https://lkml.org/lkml/2004/5/23/10 Could some type of asset-less legal entity be set up (cheaply, anonymously) somewhere in the world to accept anonymous code donations and commit them on behalf of their submitter? Would shield open source projects from frivolous lawsuits and protect contributors' privacy. Apologies if this has already all been discussed thoroughly somewhere else... -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot