coreboot October 2018

coreboot@coreboot.org

53 participants
145 discussions

Re: [coreboot] Source code for "Intel Firmware"
by Angel Pons 06 Oct '18

06 Oct '18

Hello Zvika, The vendor's bin file starts with the following pattern: > 00000000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF > 00000010: 5AA5F00F 03000402 0602100B 20002100 > > Can you confirm that this is the start of IFD ? > The magic "5A A5 F0 0F" at offset 0x10 indicates the start of the IFD. Regards, Angel Pons >

1 0

Re: [coreboot] Source code for "Intel Firmware"
by Nico Huber 06 Oct '18

06 Oct '18

On 10/6/18 6:50 AM, Zvi Vered wrote: > 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. Right. > > coreboot only replaces the BIOS part developed by vendors like "AMI bios". Yes, mostly. For some platforms, coreboot also replaces reference code of the silicon vendor, but today it's mostly just what an IBV like AMI does. > > Where can I find full source code for "Intel FW" ? Most of the regions you mentioned above don't contain code at all. Beside the BIOS, there is ME/TXE code but Intel provides only binaries for these, AFAIK. > > 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. That is possible but will require you to dive even deeper in Intel's platform configuration. I can only advice you to treat each of the firmware parts individually as much as possible. For instance, first try to replace the BIOS with coreboot (while keeping the original other parts), then try to replace the ME/TXE firmware, then the GBE and IFD (the latter both only contain configuration data, AFAIK). You will need an NDA with Intel. Then ask them for their binaries, docu- mentation and (Windows) tools to create your own configuration. Don't underestimate the effort. You'll probably need some months to get your own coreboot running, then few more to read through all the docu- mentation and craft your own IFD etc. Nico

2 1

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Nico Huber 06 Oct '18

06 Oct '18

Hi Zvi, On 10/5/18 8:46 PM, Zvi Vered wrote: > 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. there is no standard for neither .bin nor .rom files. Most often these file-name extensions just mean the file contains raw data. If any program implies a special meaning to .rom or .bin, then that meaning is vendor specific. So to flashrom, .rom and .bin is the same. Flashrom doesn't look at the file contents at all. It just copies them to the flash chip (much like the `dd` command copies file contents no matter what they are). If you tell flashrom to write a complete file that doesn't contain a firmware descriptor, then the system can't boot anymore. But if you have a descriptor and other required firmware parts in the flash already, you can tell flashrom to only flash the BIOS region, e.g.: # flashrom -p ... --ifd -i bios -w coreboot.rom This is just more convenient and reliable than stitching files (but the result should be the same). Nico

1 0

Re: [coreboot] Source code for "Intel Firmware"
by Nathaniel Roach 06 Oct '18

06 Oct '18

Hi Zvika, In the case of a very limited number of chips, the IFD and GbE regions can be generated, and the ME region skipped entirely (see libreboot/ich9gen). For the others, some reverse engineering may be possible for the IFD and GbE regions but generating even a "me_cleaner" comparable region would require substantial reverse engineering, due to the obfuscation and protection measures in the ME. Essentially these regions are not publicly documented and are probably covered under NDA, and in the case of the ME likely not available unless you're Intel yourself. On 06/10/18 12:50, Zvi Vered wrote: > 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 >

1 0

Re: [coreboot] [skylake] Can not turn monitor on
by Nico Huber 06 Oct '18

06 Oct '18

Hi Zheng, On 10/6/18 4:58 AM, Zheng Bao wrote: > Sorry for being unclear. no worries, it seems I wasn't very attentive anyway. I just implied you have an integrated (laptop) panel; maybe because you have a mobile processor or maybe because the 1440x900 resolution is common for lap- tops. Anyway, now that you mentioned VGA... May I assume that you don't have an integrated panel and just want an external VGA monitor to work? > 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 The VBT is a configuration file for the VBIOS/GOP and graphics drivers. It has to be adapted for each board, so the one from github would only work by low chance. > extracted from original AMI BIOS. How did you extract it? using uefitool on a BIOS image? or from RAM when the original BIOS booted? > My board uses IT6515FN to transfer the display to VGA. This sounds like something libgfxinit could support. I would just try it. You'd have to enable support for your board like this [1]. Your `Port_List` should be `(DP1, DP2, DP3, Internal)`. `Internal` means the eDP here. If you know exactly to which physical port this IT6515FN is connected, you can also specify only that port. Then, in your .config you should have: CONFIG_MAINBOARD_USE_LIBGFXINIT=y CONFIG_VGA_TEXT_FRAMEBUFFER=y If you try that and it fails, please also enable CONFIG_DEBUG_ADA_CODE=y and send us a coreboot log. Nico [1] https://review.coreboot.org/28620

1 0

Source code for "Intel Firmware"
by Zvi Vered 06 Oct '18

06 Oct '18

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

1 0

Re: [coreboot] [skylake] Can not turn monitor on
by Nico Huber 06 Oct '18

06 Oct '18

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-vol… [2] PP_* and SBLC_PWM_CTL[12] in https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol…

3 2

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Mariusz Szafrański 05 Oct '18

05 Oct '18

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 <veredz72(a)gmail.com> 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 <veredz72(a)gmail.com >> <mailto:veredz72@gmail.com>> 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 >> <ce.autom(a)protonmail.com <mailto:ce.autom@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 >> <veredz72(a)gmail.com <mailto:veredz72@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 <coreboot(a)coreboot.org >>> <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 >>>> <veredz72(a)gmail.com> <mailto:veredz72@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 >>>>> <ce.autom(a)protonmail.com >>>>> <mailto:ce.autom@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). >>>>> 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 this case ask someone else how to do it >>>>> with fpt.... >>>>> >>>>> I hope this answered your questions. >>>>> Jose.. >>>>> >>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>>>> On Saturday, September 29, 2018 12:24 AM, Zvi >>>>> Vered <veredz72(a)gmail.com >>>>> <mailto:veredz72@gmail.com>> wrote: >>>>> >>>>>> Hi Jose, >>>>>> >>>>>> You wrote: >>>>>> "My recommended approach is using the original >>>>>> Intel FW with already included the FD, TXE". >>>>>> >>>>>> What is "original intel FW" ? >>>>>> What is FD, TXE ? >>>>>> >>>>>> After creating coreboot.rom should I always use >>>>>> the original BIOS with ifdtool to convert rom to >>>>>> bin ? >>>>>> >>>>>> Thank you, >>>>>> Zvika >>>>>> >>>>>> On Wed, Sep 26, 2018 at 7:27 PM Jose Trujillo >>>>>> <ce.autom(a)protonmail.com >>>>>> <mailto:ce.autom@protonmail.com>> wrote: >>>>>> >>>>>> You are right Nico, >>>>>> >>>>>> I just forgot the troubles this caused me. >>>>>> I am sorry Vika... My mistake. >>>>>> >>>>>> I can confirm with Nico: >>>>>> ROM chip size = 8MB (your case) >>>>>> CBFS_SIZE = 2 to 5MB (your specific case) >>>>>> >>>>>> My recommended approach is using the original >>>>>> Intel FW with already included the FD, TXE. >>>>>> >>>>>> I never tested adding regions to coreboot but >>>>>> you can try. >>>>>> >>>>>> To have better chances of success you should >>>>>> be dumping hardware settings booting with >>>>>> your original "BIOS" (look for the attached >>>>>> file). >>>>>> >>>>>> Check if the system is "Memory down"or/and >>>>>> ECC because it will be needed to edit FSP (if >>>>>> using it). >>>>>> Dump memory settings with the following commands: >>>>>> >>>>>> sudo dnf install i2c-tools-perl >>>>>> sudo modprobe eeprom >>>>>> decode-dimms >>>>>> >>>>>> If you have not done this already there is >>>>>> still a long way to go. >>>>>> Don't get intimidated, just do it, if you >>>>>> have questions just ask.... I will try to help >>>>>> >>>>>> Good luck, >>>>>> Jose. >>>>>> >>>>>> >>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>>>>> On Wednesday, September 26, 2018 6:28 PM, >>>>>> Nico Huber <nico.h(a)gmx.de >>>>>> <mailto:nico.h@gmx.de>> wrote: >>>>>> >>>>>> > Hi, >>>>>> > >>>>>> > On 9/26/18 9:19 AM, Jose Trujillo via >>>>>> coreboot wrote: >>>>>> > >>>>>> > > No, don't change it, you change the size >>>>>> of coreboot only if during the >>>>>> > > building process "make" complain that >>>>>> there is not enough space but in >>>>>> > > your case your build was already >>>>>> successful leave it like that. >>>>>> > >>>>>> > this advice seems very weird to me. I'm not >>>>>> experienced with Bay Trail. >>>>>> > But unless there is a bug in the Bay Trail >>>>>> code, you should always set >>>>>> > the correct ROM_SIZE (to the full flash >>>>>> chip size). Otherwise you may >>>>>> > introduce bugs in code that relies on this >>>>>> setting (e.g. saving the >>>>>> > MRC cache might fail and so would S3 resume). >>>>>> > >>>>>> > CBFS_SIZE however is the setting to adjust >>>>>> according to your needs. It >>>>>> > should be at most the size of the BIOS region. >>>>>> > >>>>>> > > In the rare circumstance that more space >>>>>> is required you can increase >>>>>> > > coreboot size to 4MB and istill will fit >>>>>> into your system 5MB of space >>>>>> > > available. >>>>>> > > "ifdtool" will inject coreboot in the top >>>>>> of the BYT_orig.bin and save >>>>>> > > as BYT_orig.bin.new that you can flash to >>>>>> your system. >>>>>> > >>>>>> > I assume this doesn't work oob if you set >>>>>> ROM_SIZE correctly. But it is >>>>>> > unnecessary to craft a single file by hand. >>>>>> You can either only flash >>>>>> > the BIOS region (recommended) or add the >>>>>> other regions in coreboot's >>>>>> > config (HAVE_{IFD,ME,GBE}_BIN). >>>>>> > >>>>>> > Nico >>>>>> >>>>>> >>>>> >>>> >>>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> <mailto:coreboot@coreboot.org> >>> https://mail.coreboot.org/mailman/listinfo/coreboot >>> >> > -- Pozdrawiam, Regards AKUMAT Mariusz Szafrański +48 501786602 mariusz.szafranski(a)akumat.pl www.akumat.pl

2 1

Re: [coreboot] [skylake] Can not turn monitor on
by Nico Huber 05 Oct '18

05 Oct '18

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 @ c0000000 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.

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 05 Oct '18

05 Oct '18

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-2BfV0V0…

1 0

← Newer
1
...
8
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2018