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

[Julius Werner]

>
> 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?

[mturney]

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

[Robert Reeves]

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

[Nico Huber]

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

[Julius Werner]

> 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

[Youness Alaoui]

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
>>> 

[coreboot] armv8 mmu limitation?

[mturney]

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

[David Hendricks]

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

[mturney]

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

[Nico Huber]

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

[awokd via coreboot]

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

[Carl-Daniel Hailfinger]

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

[Mark Wylde]

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 

Re: [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  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

[awokd via coreboot]

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