Re: [coreboot] Reducing the boot time

2018-08-11 Thread taii...@gmx.com 
On 08/11/2018 03:44 AM, Matt DeVillier wrote:
> or outputting the boot console to a non-existent serial port (which can slow 
> everything down).

Yeah ditto, and it could also be a high log level or other debug
features enabled that you don't need like the EHCI debug
console...probably a combination of things.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] HV121WX4-120 screen for X200

2018-08-11 Thread Merlin Büge 
Hey,

I also have that panel in my X200 and it's working fine here. Don't
remember if it worked with stock BIOS, but the latest libreboot release
(20160907) is working fine. I will also try latest coreboot in the next
weeks, and will report back if I experience strange behaviour.

For now it works quite stable (compared to what I've heard), I get
random hangs about 10 times a year with nearly constant uptime.

I also replaced the panel's CCFL with an LED stripe and therefore have
a modified version of the LED board (where the CCFL inverter was
located), but I'm very sure the panel worked fine before that
modification.

Regards,

Merlin



On Sat, 11 Aug 2018 00:34:35 +0200
Piotr Kubaj via coreboot  wrote:

> Hi,
> 
> I just wanted to share my experience of using alternative screens for
> ThinkPad X200 (HV121WX4-120) with coreboot.
> 
> After fitting the screen, it became apparent that something is wrong.
> Having turned on the X200, it ran happily for about 1 minute, then
> the screen just powered off. It didn't matter whether I stayed in
> SeaBIOS, or just booted my OS. And when the screen powered off, I
> could awake it after several minutes, but only for another minute.
> Apart from that, the laptop worked.
> 
> nico_h from IRC helped me (thank you!) by providing alternative
> values for devicetree, which could make the screen work orderly.
> Well, it did work better, but still wasn't stable (it worked for
> 10-20 minutes, once I even got it to 2 hours).
> 
> Still, that was a huge difference. I tried to experiment a little
> with it and set some crazy values: register
> "gpu_panel_power_up_delay" = "600" # T1+T2: 25ms register
> "gpu_panel_power_down_delay" = "3000"  # T3:25ms register
> "gpu_panel_power_backlight_on_delay" = "500"   # T5:   250ms register
> "gpu_panel_power_backlight_off_delay" = "2500" # Tx:   250ms register
> "gpu_panel_power_cycle_delay" = "255"  # T4:   200ms
> 
> After that, things seem to work fine.
> 
> I hope someone finds it useful if they replace their X200's screen
> with alternative one.
> 
> Again thanks to Nico for help!
> 



-- 
Merlin Büge

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Reducing the boot time

2018-08-11 Thread Antony AbeePrakash X V 
Hi,

Thanks for your feedback.

We enabled ENABLE_FSP_FAST_BOOT and MRC cache Training data in FSP using binary 
configuration tool. Also we reduced the console log level to 0.

Now the boot time is reduced to 23 secs for initial boot and 11 secs for 
upcoming power cycles.

Is this a normal behavior ?

Also from the console logs we found the following:

Coreboot FSP Performance Data
ID: 950 - 951: 8118676370 - 2354813461 --> 4433ms   (TS_FSP_MEMORY_INIT_START - 
TS_FSP_MEMORY_INIT_END)
ID: 952 - 953: 10675414728 - 8905813067 --> 1361ms  (TS_FSP_TEMP_RAM_EXIT_START 
- TS_FSP_TEMP_RAM_EXIT_END)
ID: 954 - 955: 11761158519 - 10934089420 --> 636ms   (TS_FSP_SILICON_INIT_START 
- TS_FSP_SILICON_INIT_END)
ID: 956 - 957: 19265617974 - 19265559282 --> 0ms   (TS_FSP_BEFORE_ENUMERATE 
- TS_FSP_AFTER_ENUMERATE)

Can we reduce the above mentioned time taken by modifying the FSP source ? 
Please advice.

Thanks

From: Matt DeVillier [mailto:matt.devill...@gmail.com]
Sent: Saturday, August 11, 2018 1:15 PM
To: Antony AbeePrakash X V 
Cc: coreboot 
Subject: Re: [coreboot] Reducing the boot time

assuming you've built with CONFIG_COLLECT_TIMESTAMPS=y, you can build/run the 
cbmem utility and see how long each stage/section of coreboot is taking (up to 
the point of handing off control to the payload).  30s to boot sounds like 
either you're not caching the RAM training data (MRC cache) and therefore 
redoing RAM training each time, or outputting the boot console to a 
non-existent serial port (which can slow everything down).  Whatever it is, 
looking at the timestamps will go a long way towards identifying the issue

On Sat, Aug 11, 2018 at 2:13 AM Antony AbeePrakash X V 
mailto:antonyabee.prakas...@lnttechservices.com>>
 wrote:
Hi,

We have developed a coreboot image for Apollo lake custom board. The time taken 
for boot up is around 30 seconds.
We would like to reduce the boot time as much as possible.

Following codes are removed:


  1.  Non-intel Apollolake specific codes in below folders

 *   Arch
 *   Soc
 *   Mainboard
 *   Vendorcode



  1.  Splash screen loading
  2.  SPI support – other than our custom board SPI.

Also we have disabled the COMPRESS_RAMSTAGE. Still we are not able to reduce 
the boot time.

Please suggest the methods to reduce the boot time.
Thanks & Regards,
Antony


L Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

L Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Reducing the boot time

2018-08-11 Thread Antony AbeePrakash X V 
Hi,

Thanks for your feedback.

We enabled ENABLE_FSP_FAST_BOOT and MRC cache Training data in FSP using binary 
configuration tool. Also we reduced the console log level to 0.

Now the boot time is reduced to 23 secs for initial boot and 11 secs for 
upcoming power cycles.

Is this a normal behavior ?

Also from the console logs we found the following:

Coreboot FSP Performance Data
ID: 950 - 951: 8118676370 - 2354813461 --> 4433ms   (TS_FSP_MEMORY_INIT_START - 
TS_FSP_MEMORY_INIT_END)
ID: 952 - 953: 10675414728 - 8905813067 --> 1361ms  (TS_FSP_TEMP_RAM_EXIT_START 
- TS_FSP_TEMP_RAM_EXIT_END)
ID: 954 - 955: 11761158519 - 10934089420 --> 636ms   (TS_FSP_SILICON_INIT_START 
- TS_FSP_SILICON_INIT_END)
ID: 956 - 957: 19265617974 - 19265559282 --> 0ms   (TS_FSP_BEFORE_ENUMERATE 
- TS_FSP_AFTER_ENUMERATE)

Can we reduce the above mentioned time taken by modifying the FSP source ? 
Please advice.

Thanks


From: Matt DeVillier [mailto:matt.devill...@gmail.com]
Sent: Saturday, August 11, 2018 1:15 PM
To: Antony AbeePrakash X V 
Cc: coreboot 
Subject: Re: [coreboot] Reducing the boot time

assuming you've built with CONFIG_COLLECT_TIMESTAMPS=y, you can build/run the 
cbmem utility and see how long each stage/section of coreboot is taking (up to 
the point of handing off control to the payload).  30s to boot sounds like 
either you're not caching the RAM training data (MRC cache) and therefore 
redoing RAM training each time, or outputting the boot console to a 
non-existent serial port (which can slow everything down).  Whatever it is, 
looking at the timestamps will go a long way towards identifying the issue

On Sat, Aug 11, 2018 at 2:13 AM Antony AbeePrakash X V 
mailto:antonyabee.prakas...@lnttechservices.com>>
 wrote:
Hi,

We have developed a coreboot image for Apollo lake custom board. The time taken 
for boot up is around 30 seconds.
We would like to reduce the boot time as much as possible.

Following codes are removed:


  1.  Non-intel Apollolake specific codes in below folders

 *   Arch
 *   Soc
 *   Mainboard
 *   Vendorcode



  1.  Splash screen loading
  2.  SPI support – other than our custom board SPI.

Also we have disabled the COMPRESS_RAMSTAGE. Still we are not able to reduce 
the boot time.

Please suggest the methods to reduce the boot time.
Thanks & Regards,
Antony


L Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

L Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Reducing the boot time

2018-08-11 Thread Matt DeVillier 
assuming you've built with CONFIG_COLLECT_TIMESTAMPS=y, you can build/run
the cbmem utility and see how long each stage/section of coreboot is taking
(up to the point of handing off control to the payload).  30s to boot
sounds like either you're not caching the RAM training data (MRC cache) and
therefore redoing RAM training each time, or outputting the boot console to
a non-existent serial port (which can slow everything down).  Whatever it
is, looking at the timestamps will go a long way towards identifying the
issue

On Sat, Aug 11, 2018 at 2:13 AM Antony AbeePrakash X V <
antonyabee.prakas...@lnttechservices.com> wrote:

> Hi,
>
>
>
> We have developed a coreboot image for Apollo lake custom board. The time
> taken for boot up is around 30 seconds.
>
> We would like to reduce the boot time as much as possible.
>
>
>
> Following codes are removed:
>
>
>
>1. Non-intel Apollolake specific codes in below folders
>   1. Arch
>   2. Soc
>   3. Mainboard
>   4. Vendorcode
>
>
>
>1. Splash screen loading
>2. SPI support – other than our custom board SPI.
>
>
>
> Also we have disabled the COMPRESS_RAMSTAGE. Still we are not able to
> reduce the boot time.
>
>
>
> Please suggest the methods to reduce the boot time.
>
> Thanks & Regards,
>
> Antony
>
>
>
> *L Technology Services Ltd*
>
> www.LntTechservices.com 
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Reducing the boot time

2018-08-11 Thread Antony AbeePrakash X V 
Hi,

We have developed a coreboot image for Apollo lake custom board. The time taken 
for boot up is around 30 seconds.
We would like to reduce the boot time as much as possible.

Following codes are removed:


  1.  Non-intel Apollolake specific codes in below folders
 *   Arch
 *   Soc
 *   Mainboard
 *   Vendorcode



  1.  Splash screen loading
  2.  SPI support - other than our custom board SPI.

Also we have disabled the COMPRESS_RAMSTAGE. Still we are not able to reduce 
the boot time.

Please suggest the methods to reduce the boot time.
Thanks & Regards,
Antony


L Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] HV121WX4-120 screen for X200

2018-08-11 Thread Piotr Kubaj via coreboot 

Hi,

I just wanted to share my experience of using alternative screens for ThinkPad 
X200 (HV121WX4-120) with coreboot.

After fitting the screen, it became apparent that something is wrong.
Having turned on the X200, it ran happily for about 1 minute, then the screen 
just powered off. It didn't matter whether I stayed in SeaBIOS, or just booted 
my OS. And when the screen powered off, I could awake it after several minutes, 
but only for another minute. Apart from that, the laptop worked.

nico_h from IRC helped me (thank you!) by providing alternative values for 
devicetree, which could make the screen work orderly. Well, it did work better, 
but still wasn't stable (it worked for 10-20 minutes, once I even got it to 2 
hours).

Still, that was a huge difference. I tried to experiment a little with it and 
set some crazy values:
   register "gpu_panel_power_up_delay" = "600" # T1+T2: 25ms
   register "gpu_panel_power_down_delay" = "3000"  # T3:25ms
   register "gpu_panel_power_backlight_on_delay" = "500"   # T5:   250ms
   register "gpu_panel_power_backlight_off_delay" = "2500" # Tx:   250ms
   register "gpu_panel_power_cycle_delay" = "255"  # T4:   200ms

After that, things seem to work fine.

I hope someone finds it useful if they replace their X200's screen with 
alternative one.

Again thanks to Nico for help!

--
_ 
/ I'd rather have a bottle in front of me \

\ than a frontal lobotomy./
- 
   \   ^__^

\  (oo)\___
   (__)\   )\/\
   ||w |
   || ||


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot