Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip

[Jose Trujillo via coreboot]

I have no idea bro
I cannot help you with that.
I am just curious  Which brand and model of board are you using?

‐‐‐ Original Message ‐‐‐
On Friday, October 5, 2018 6:05 AM, Zvi Vered  wrote:

> Hi Jose, Mariusz,All,
>
> The vendor's rom file size is: 5,242,880 bytes
>
> After running:
> dd if=coreboot.rom of=coreboot.rom.new bs=1M skip=3
>
> I got a new file with the same size.
>
> I tried to program this new file and got the following message from the 
> vendor's utlity:
>
> WARNING !
> This Image file doesn't match current System design!
> Force update it will destroy the System's Activation Key.
> We do not recommend flashing your BIOS.
>   Press "Y" to force update BIOS.
>   Press "N" to quit flash.
> - Please select one of the options:
>
> I ignored the warning and programmed the BIOS.
>
> After reset, I got nothing.
>
> What is "System's Activation Key" ?
> I'm sure that FSP (and other files) for my board are not properly configured 
> yet.
> But I suspect this is not the reason for the message.
>
> Thank you,
> Zvika
>
> On Thu, Oct 4, 2018 at 9:47 PM Zvi Vered  wrote:
>
>> Hi Jose,
>>
>> I probably made a mistake and erased the main BIOS chip (and also the 
>> secondary one)
>> Currently my target is not booting OS at all.
>> So I can not try Mariusz procedure.
>> Hope to have an identical target soon.
>>
>> Thank you very much for your help,
>> Zvika
>>
>> On Thu, Oct 4, 2018 at 6:31 PM Jose Trujillo  wrote:
>>
>>> Zvika:
>>> Doing a full flash doesn't work for you, this is what I been doing.
>>> Try to use flashrom from linux if you want to do the full flash (may be it 
>>> will work).
>>>
>>> An external programmer would be the optimal choice.
>>>
>>> Did you tried what Mariusz said?
>>> Jose.
>>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Thursday, October 4, 2018 6:20 PM, Zvi Vered  wrote:
>>>
 Hi Mariusz, Jose, All,

 Mariusz - Thank you very much for the solution.
 Jose - You wrote "I have never done this way...".
 Can you please suggest a better alternative ?

 Thank you,
 Zvika

 On Wed, Oct 3, 2018 at 8:39 PM Mariusz Szafrański via coreboot 
  wrote:

> Hi Jose,
>
> In your case set:
> ROM chip size = 8MB (your case)
> CBFS_SIZE <= 5MB (your specific case)
>
> This will build 8M file. After that just cut last 5M of this 8M file 
> (using any hexeditor) or use something like below from command line:
>
> dd if=coreboot.rom of=corebootout.rom bs=1M skip=3
>
> (before doing that double check if original vendor`s rom file size is 
> 5242880 bytes long)
>
> Mariusz
>
> W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze:
>
>> You can do that but I have never done this way and I cannot help you 
>> with that.
>>
>> Someone else can advise on this?
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, October 2, 2018 9:39 PM, Zvi Vered 
>> [](mailto:vered...@gmail.com) wrote:
>>
>>> Hi Jose, All,
>>>
>>> Highly appreciate your answers.
>>> It seems the vital information in your replies are not documented.
>>>
>>> The original vendor's rom file size is 5MB.
>>> Do you think I can create a 5MB coreboot.rom ?
>>>
>>> It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom 
>>> file like the original one. For any other file size, AfuEfix64 fails.
>>>
>>> Thank you,
>>> Zvika
>>>
>>> On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo  
>>> wrote:
>>>
 Zvika:

 There are 2 ways to build coreboot: (choose one)
 1.- Including IFD, TXE, GBE etc inside coreboot CBFS.
 2.- Using the original firmware(FW) with IFD, TXE, GBE already in 
 flash and just rewrite coreboot on top of the BIOS block.

 Your original computer Firmware = Intel FW + "BIOS"

 Intel FW = IFD +PD+ME/TXE+GBE
 BIOS=AMI-Phoenix etc...

 IFD=Intel Firmware Descriptor Table.
 PD=Parameters
 ME=Management Engine (For "Core" kind of processors).
 TXE=Trusted Execution Engine (For "Atom" kind of processors).
 GBE=Network card firmware.

 Zvika said:
 "After creating coreboot.rom should I always use the original BIOS 
 with ifdtool to convert rom to bin ?"
 Answer:
 No, there are other methods and tools that can do the merge 
 (ifdtool and Intel's FIT are working fine for me)

 After the creation of the coreboot build you have 2 ways of doing the 
 flashing for your case: (with fpt).
 1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank 
 or have unknown firmware.
  Use IFDTool in this case to inject coreboot to Intel FW. then 
 flash it with fpt .
 2.- Flash only the BIOS block (5MB your specific case) in

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip

[Mariusz Szafrański via coreboot]

Also have no idea :(
My solution should work when vendor`s utility just put unmodified whole 
5M coreboot.rom.new at top of the flash chip space.

But this could not be true and vendor`s utility is doing something else :(
(e.g. put it on other location, split it and place chunks on non 
continuous areas or injects some kind of "id" or "keys" before flashing)


Mariusz

W dniu 05.10.2018 o 10:50, Jose Trujillo pisze:

I have no idea bro
I cannot help you with that.
I am just curious  Which brand and model of board are you using?

‐‐‐ Original Message ‐‐‐
On Friday, October 5, 2018 6:05 AM, Zvi Vered  wrote:


Hi Jose, Mariusz,All,

The vendor's rom file size is: 5,242,880 bytes

After running:
dd if=coreboot.rom of=coreboot.rom.new bs=1M skip=3

I got a new file with the same size.

I tried to program this new file and got the following message from 
the vendor's utlity:


WARNING !
This Image file doesn't match current System design!
Force update it will destroy the System's Activation Key.
We do not recommend flashing your BIOS.
  Press "Y" to force update BIOS.
  Press "N" to quit flash.
- Please select one of the options:

I ignored the warning and programmed the BIOS.

After reset, I got nothing.

What is "System's Activation Key" ?
I'm sure that FSP (and other files) for my board are not properly 
configured yet.

But I suspect this is not the reason for the message.

Thank you,
Zvika


On Thu, Oct 4, 2018 at 9:47 PM Zvi Vered > wrote:


Hi Jose,

I probably made a mistake and erased the main BIOS chip (and also
the secondary one)
Currently my target is not booting OS at all.
So I can not try Mariusz procedure.
Hope to have an identical target soon.

Thank you very much for your help,
Zvika

On Thu, Oct 4, 2018 at 6:31 PM Jose Trujillo
mailto:ce.au...@protonmail.com>> wrote:

Zvika:
Doing a full flash doesn't work for you, this is what I been
doing.
Try to use flashrom from linux if you want to do the full
flash (may be it will work).

An external programmer would be the optimal choice.

Did you tried what Mariusz said?
Jose.



‐‐‐ Original Message ‐‐‐
On Thursday, October 4, 2018 6:20 PM, Zvi Vered
mailto:vered...@gmail.com>> wrote:


Hi Mariusz, Jose, All,

Mariusz - Thank you very much for the solution.
Jose - You wrote "I have never done this way...".
Can you please suggest a better alternative ?

Thank you,
Zvika


On Wed, Oct 3, 2018 at 8:39 PM Mariusz Szafrański via
coreboot mailto:coreboot@coreboot.org>> wrote:

Hi Jose,

In your case set:
ROM chip size = 8MB (your case)
CBFS_SIZE <= 5MB (your specific case)

This will build 8M file. After that just cut last 5M of
this 8M file (using any hexeditor) or use something like
below from command line:

dd if=coreboot.rom of=corebootout.rom bs=1M skip=3

(before doing that double check if original vendor`s rom
file size is 5242880 bytes long)

Mariusz


W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze:

You can do that but I have never done this way and I
cannot help you with that.

Someone else can advise on this?

‐‐‐ Original Message ‐‐‐
On Tuesday, October 2, 2018 9:39 PM, Zvi Vered
  wrote:


Hi Jose, All,

Highly appreciate your answers.
It seems the vital information in your replies are not
documented.

The original vendor's rom file size is 5MB.
Do you think I can create a 5MB coreboot.rom ?

It seems that AfuEfix64.efi supplied by vendor is
looking for 5MB rom file like the original one. For
any other file size, AfuEfix64 fails.

Thank you,
Zvika

On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo
mailto:ce.au...@protonmail.com>> wrote:

Zvika:

There are 2 ways to build coreboot: (choose one)
1.- Including IFD, TXE, GBE etc inside
coreboot CBFS.
2.- Using the original firmware(FW) with IFD, TXE,
GBE already in flash and just rewrite coreboot on
top of the BIOS block.

Your original computer Firmware = Intel FW + "BIOS"

Intel FW = IFD +PD+ME/TXE+GBE
BIOS=AMI-Phoenix etc...

IFD=Intel Firmware Descriptor Table.
PD=Parameters
ME=Management Engine (For "Core" kind of processors).
TXE=Trusted Execution Engine (For "Atom" kind of
processors).

Re: [coreboot] SPI controller and Lock bits

[Nico Huber]

Hi,

Am 05.10.18 um 08:39 schrieb Martin Kepplinger:
> is there already a gerrit change you are working on this? Do plan to
> support / test
> a X230 flash chip's lock bits?
> * MX25L6406E/MX25L6408E
> * EN25QH64
> * MX25L3206E

not about this request in particular but such flash-chip features in
general: IMO, the best solution is to implement these in (lib)flashrom
and integrate that into coreboot. I wouldn't say that it's wasted time
to implement it in coreboot directly. But, in the long run, taking
shortcuts or maintaining redundant implementations will slow the pro-
ject down overall.

Nico


0xBD56B4A4138B3CE3.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] New Defects reported by Coverity Scan for coreboot

[scan-admin]

Hi,

Please find the latest report on new defect(s) introduced to coreboot found 
with Coverity Scan.

1 new defect(s) introduced to coreboot found with Coverity Scan.


New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)


** CID 1396010:  Null pointer dereferences  (FORWARD_NULL)
/src/security/tpm/tss/tcg-2.0/tss.c: 68 in tlcl_send_startup()



*** CID 1396010:  Null pointer dereferences  (FORWARD_NULL)
/src/security/tpm/tss/tcg-2.0/tss.c: 68 in tlcl_send_startup()
62  response = tpm_process_command(TPM2_Startup, &startup);
63 
64  if (response && (response->hdr.tpm_code == 0 ||
65   response->hdr.tpm_code == TPM_RC_INITIALIZE)) {
66  return TPM_SUCCESS;
67  }
>>> CID 1396010:  Null pointer dereferences  (FORWARD_NULL)
>>> Dereferencing null pointer "response".
68  printk(BIOS_INFO, "%s: Startup return code is %x\n",
69 __func__, response->hdr.tpm_code);
70  return TPM_E_IOERROR;
71 }
72 
73 uint32_t tlcl_resume(void)



To view the defects in Coverity Scan visit, 
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbLuoVetFLSjdonCi1EjfHRqWGQvojmmkYaBE-2BPJiTQvQ-3D-3D_q4bX76XMySz3BXBlWr5fXXJ4cvAsgEXEqC7dBPM7O5bH-2FZ483O-2BcxFXL8EnScZk-2FK03sQPuIY-2F-2BUC5-2F1MeibpqZsG2gXVlJA6FVsrtmuM9Ns-2FKS5K-2B4Be9MvFTuwTv9EAL55BaWDAMdHVuxqXH7XPbEH2HA46iXnpL5-2BV2L6i0-2Bcr5zLQ81YuKKOXlIIygMe0YQPW74Y4gQNVJoNbSMTASg6DbeYITRMKVyEtWm0qAU-3D


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

Re: [coreboot] [skylake] Can not turn monitor on

[Zheng Bao]

I transfer all the GPIO setting to my code.
After this, the linux can turn the monitor on, but in BIOS stage, monitor can 
not be turn on.
Is that the way it is? Can BIOS turn the display on?

zheng


From: Nico Huber 
Sent: Wednesday, October 3, 2018 2:48 PM
To: Zheng Bao; coreboot@coreboot.org; youness.ala...@puri.sm
Subject: Re: [coreboot] [skylake] Can not turn monitor on

Hi Zheng,

On 10/3/18 4:06 PM, Zheng Bao wrote:
> I tried both the vgabios extracted in linux /sys/ and seavgabios.

don't know why GOP+SeaVGABIOS fails but an Intel VBIOS extracted from
memory never worked for me. You might have more luck by extracting it
from a firmware image with uefitool.

> The debug message seems to be good, which is attached.

Looks rather good:

  Found FB @ c000 1440x900 with 32 bpp (5760 stride)

This means most already succeeded. The FSP/GOP driver run and set a
framebuffer up. Maybe the problem is that the backlight stays dark?
Since Skylake, coreboot lacks all backlight initialization. Only the
GOP driver can set it up and whether that works depends on your VBT.

I would try with a bright light to spot something on the screen to
confirm if it's a backlight issue.

Where did you get the VBT from?

Nico

PS. Btw. the lack of backlight initialization is all that keeps you
from using a reliable, pure open-source solution. libgfxinit
already works well for Skylake. Just coreboot doesn't do it's
job for the backlight.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip

[Zvi Vered]

Hi Jose, Mariusz, All,

The vendor is Adlink. The board is called LEC-BTS
https://www.adlinktech.com/Products/Computer_on_Modules/SMARC/LEC-BTS?lang=en
The CPU is Intel's Bay Trail.

According to the help of flashrom, it works with bin files only.
So I should take coreboot.rom and stitch it to the parts of the original
vendor's bin file.
Am I right?

Thank you,
Zvika

On Fri, Oct 5, 2018 at 12:12 PM Mariusz Szafrański via coreboot <
coreboot@coreboot.org> wrote:

> Also have no idea :(
> My solution should work when vendor`s utility just put unmodified whole 5M
> coreboot.rom.new at top of the flash chip space.
> But this could not be true and vendor`s utility is doing something else :(
> (e.g. put it on other location, split it and place chunks on non
> continuous areas or injects some kind of "id" or "keys" before flashing)
>
> Mariusz
> W dniu 05.10.2018 o 10:50, Jose Trujillo pisze:
>
> I have no idea bro
> I cannot help you with that.
> I am just curious  Which brand and model of board are you using?
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 5, 2018 6:05 AM, Zvi Vered 
>  wrote:
>
> Hi Jose, Mariusz,All,
>
> The vendor's rom file size is: 5,242,880 bytes
>
> After running:
> dd if=coreboot.rom of=coreboot.rom.new bs=1M skip=3
>
> I got a new file with the same size.
>
> I tried to program this new file and got the following message from the
> vendor's utlity:
>
> WARNING !
> This Image file doesn't match current System design!
> Force update it will destroy the System's Activation Key.
> We do not recommend flashing your BIOS.
>   Press "Y" to force update BIOS.
>   Press "N" to quit flash.
> - Please select one of the options:
>
> I ignored the warning and programmed the BIOS.
>
> After reset, I got nothing.
>
> What is "System's Activation Key" ?
> I'm sure that FSP (and other files) for my board are not properly
> configured yet.
> But I suspect this is not the reason for the message.
>
> Thank you,
> Zvika
>
>
> On Thu, Oct 4, 2018 at 9:47 PM Zvi Vered  wrote:
>
>> Hi Jose,
>>
>> I probably made a mistake and erased the main BIOS chip (and also the
>> secondary one)
>> Currently my target is not booting OS at all.
>> So I can not try Mariusz procedure.
>> Hope to have an identical target soon.
>>
>> Thank you very much for your help,
>> Zvika
>>
>> On Thu, Oct 4, 2018 at 6:31 PM Jose Trujillo 
>> wrote:
>>
>>> Zvika:
>>> Doing a full flash doesn't work for you, this is what I been doing.
>>> Try to use flashrom from linux if you want to do the full flash (may be
>>> it will work).
>>>
>>> An external programmer would be the optimal choice.
>>>
>>> Did you tried what Mariusz said?
>>> Jose.
>>>
>>>
>>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Thursday, October 4, 2018 6:20 PM, Zvi Vered 
>>> wrote:
>>>
>>> Hi Mariusz, Jose, All,
>>>
>>> Mariusz - Thank you very much for the solution.
>>> Jose - You wrote "I have never done this way...".
>>> Can you please suggest a better alternative ?
>>>
>>> Thank you,
>>> Zvika
>>>
>>>
>>> On Wed, Oct 3, 2018 at 8:39 PM Mariusz Szafrański via coreboot <
>>> coreboot@coreboot.org> wrote:
>>>
 Hi Jose,

 In your case set:
 ROM chip size = 8MB (your case)
 CBFS_SIZE <= 5MB (your specific case)

 This will build 8M file. After that just cut last 5M of this 8M file
 (using any hexeditor) or use something like below from command line:

 dd if=coreboot.rom of=corebootout.rom bs=1M skip=3

 (before doing that double check if original vendor`s rom file size is
 5242880 bytes long)

 Mariusz


 W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze:

 You can do that but I have never done this way and I cannot help you
 with that.

 Someone else can advise on this?

 ‐‐‐ Original Message ‐‐‐
 On Tuesday, October 2, 2018 9:39 PM, Zvi Vered 
  wrote:

 Hi Jose, All,

 Highly appreciate your answers.
 It seems the vital information in your replies are not documented.

 The original vendor's rom file size is 5MB.
 Do you think I can create a 5MB coreboot.rom ?

 It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom
 file like the original one. For any other file size, AfuEfix64 fails.

 Thank you,
 Zvika

 On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo 
 wrote:

> Zvika:
>
> There are 2 ways to build coreboot: (choose one)
> 1.- Including IFD, TXE, GBE etc inside coreboot CBFS.
> 2.- Using the original firmware(FW) with IFD, TXE, GBE already in
> flash and just rewrite coreboot on top of the BIOS block.
>
> Your original computer Firmware = Intel FW + "BIOS"
>
> Intel FW = IFD +PD+ME/TXE+GBE
> BIOS=AMI-Phoenix etc...
>
> IFD=Intel Firmware Descriptor Table.
> PD=Parameters
> ME=Management Engine (For "Core" kind of processors).
> TXE=Trusted Execution Engine (For "Atom" kind 

Re: [coreboot] lower memory performance with coreboot on KGPE-D16

[Daniel Kulesz via coreboot]

Hi Iru,

> I just found the memory performance on KGPE-D16 is lower when running with
> coreboot. I have two Opteron 6276 and 8 16GB DDR3-1600 RDIMM on all orange
> slots. I tested it with `hdparm -tT /dev/sda` and see the `Timing cached
> reads` result. With coreboot, this value is around 3000 MB/s, but with OEM
> firmware it can go to around 3600 MB/s. I think the disk cached read speed
> is related to memory performance.

Are you using DDR3L-RDIMMs? And did you check whether your memory really runs 
at 800 MHz? My experience is that coreboot sets the clock down to 667 MHz when 
running on 1.35V (low voltage), while the vendor bios seems to run modules at 
800 MHz in low voltage mode,  resulting in higher performance. According to 
Timothy, this is  "over the spec" and thus not set in coreboot by default (you 
can choose between 1.5V 800 MHz or 1.35V at 667 MHz - but may depend on the 
used modules).

You can check e.g. in dmidecode. Below is an example (serial number x'd out):

Handle 0x000E, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0006
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: NODE 0 DIMM_D2
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous Registered (Buffered)
Speed: 800 MHz
Manufacturer: Samsung
Serial Number: x
Asset Tag: Not Specified
Part Number: M393B1K70DH0-YK0  
Rank: 2
Configured Clock Speed: 800 MHz
Minimum Voltage: 1.35 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.5 V

Btw.: I am getting around 3700 MB/sec with hdparm -Tt on my /dev/sda 
(mechanical disk) and around 3840 MB/sec on /dev/nvme0n1 (PCIe M.2 SSD).

Cheers, Daniel

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

Re: [coreboot] [skylake] Can not turn monitor on

[Nico Huber]

On 10/5/18 4:43 PM, Zheng Bao wrote:
> I transfer all the GPIO setting to my code.

What do you mean? did you have wrong GPIO settings before?

> After this, the linux can turn the monitor on, but in BIOS stage,
> monitor can not be turn on.
> Is that the way it is? Can BIOS turn the display on?

What exactly do you mean with BIOS? a VGA BIOS? it should work with the
correct VBT. Same with a GOP driver. I'll add Matt in CC who has more
experience with the proprietary graphics solutions.

Personally, I would just implement the backlight control in coreboot
and use libgfxinit as open-source solution. Register documentation can
be found here [1][2] and soc/intel/broadwell/igd.c:311..344 as example
how it worked on older platforms. Everything else you need are the
correct settings for your board/panel which you can find by decoding
the VBT or just dump the registers when Linux initialized it.

Nico

[1] BLC_PWM_(CTL|DATA) in

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol02c-commandreference-registers-part1.pdf

[2] PP_* and SBLC_PWM_CTL[12] in

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol02c-commandreference-registers-part2.pdf

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

Re: [coreboot] [skylake] Can not turn monitor on

[Matt DeVillier]

On Fri, Oct 5, 2018 at 3:27 PM Nico Huber  wrote:
>
> On 10/5/18 4:43 PM, Zheng Bao wrote:
> > I transfer all the GPIO setting to my code.
>
> What do you mean? did you have wrong GPIO settings before?
>
> > After this, the linux can turn the monitor on, but in BIOS stage,
> > monitor can not be turn on.
> > Is that the way it is? Can BIOS turn the display on?
>
> What exactly do you mean with BIOS? a VGA BIOS? it should work with the
> correct VBT. Same with a GOP driver. I'll add Matt in CC who has more
> experience with the proprietary graphics solutions.
>
> Personally, I would just implement the backlight control in coreboot
> and use libgfxinit as open-source solution. Register documentation can
> be found here [1][2] and soc/intel/broadwell/igd.c:311..344 as example
> how it worked on older platforms. Everything else you need are the
> correct settings for your board/panel which you can find by decoding
> the VBT or just dump the registers when Linux initialized it.

that's certainly the ideal way to do it, but using the FSP GOP init
with the VBT extracted from the vendor UEFI firmware should work as
well (ASCII search for $VBT, it's a 4-5kb file), combined with
SeaVGABIOS and using SeaBIOS master (I pushed a few fixes for
SeaVGABIOS recently).  This is what we're currently testing on the
Purism Librem laptops; the current release firmware uses a VBIOS
(extracted from another Skylake proprietary firmware) which is
executed by SeaBIOS, but seems to have some artifacting issues for
some users.

>
> Nico
>
> [1] BLC_PWM_(CTL|DATA) in
>
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol02c-commandreference-registers-part1.pdf
>
> [2] PP_* and SBLC_PWM_CTL[12] in
>
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol02c-commandreference-registers-part2.pdf

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

Re: [coreboot] [skylake] Can not turn monitor on

[Zheng Bao]

Sorry for being unclear.

By BIOS stage,  I mean I need to see the text "Press ESC for boot menu." on 
screen. It also means it needs to boot DOS with display on.
But I can not. I have to wait for the linux to boot. Only Linux (driver?) can 
turn the display on. I tried with both vbt from github and extracted
from  original AMI BIOS.
My board uses IT6515FN to transfer the display to VGA.

Zheng


From: Nico Huber 
Sent: Friday, October 5, 2018 8:27 PM
To: Zheng Bao
Cc: coreboot@coreboot.org; youness.ala...@puri.sm; Matt DeVillier
Subject: Re: [coreboot] [skylake] Can not turn monitor on

On 10/5/18 4:43 PM, Zheng Bao wrote:
> I transfer all the GPIO setting to my code.

What do you mean? did you have wrong GPIO settings before?

> After this, the linux can turn the monitor on, but in BIOS stage,
> monitor can not be turn on.
> Is that the way it is? Can BIOS turn the display on?

What exactly do you mean with BIOS? a VGA BIOS? it should work with the
correct VBT. Same with a GOP driver. I'll add Matt in CC who has more
experience with the proprietary graphics solutions.

Personally, I would just implement the backlight control in coreboot
and use libgfxinit as open-source solution. Register documentation can
be found here [1][2] and soc/intel/broadwell/igd.c:311..344 as example
how it worked on older platforms. Everything else you need are the
correct settings for your board/panel which you can find by decoding
the VBT or just dump the registers when Linux initialized it.

Nico

[1] BLC_PWM_(CTL|DATA) in

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol02c-commandreference-registers-part1.pdf

[2] PP_* and SBLC_PWM_CTL[12] in

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol02c-commandreference-registers-part2.pdf
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Source code for "Intel Firmware"

[Zvi Vered]

Hello,

A bin file burned on a BIOS chip contains "Intel FW":

Intel FW = IFD +PD+ME/TXE+GBE

IFD=Intel Firmware Descriptor Table.
PD=Parameters
ME=Management Engine (For "Core" kind of processors).
TXE=Trusted Execution Engine (For "Atom" kind of processors).
GBE=Network card firmware.

If I'm not mistaken, this package is not supplied within coreboot.

coreboot only replaces the BIOS part developed by vendors like "AMI bios".

Where can I find full source code for "Intel FW" ?

Currently, in order to replace vendor's BIOS we must take binary parts
of the original bin file and then stitch it to coreboot.rom built with
the coreboot project.

I want to depend only on Intel.

Thank you,
Zvika

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