coreboot October 2018

coreboot@coreboot.org

53 participants
145 discussions

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

04 Oct '18

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

3 2

lower memory performance with coreboot on KGPE-D16
by Iru Cai 04 Oct '18

04 Oct '18

Hi, 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. Iru -- My website: https://vimacs.lcpu.club Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/

1 0

Re: [coreboot] microcode blob or ascii
by Jose Trujillo 03 Oct '18

03 Oct '18

Sorry, I cannot help you with this.... maybe I still don't understand. The only thing I can tell you that I use for this same SOC processor all the header files ".h" included in the kit and they work without problems. It would be good if you can enable the serial debug console and dump the log if you have problems. Good luck, Jose. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, October 2, 2018 5:23 PM, galla rao <galla.rao80(a)gmail.com> wrote: > Thanks Jose, > > My actual query is FSP Binary also has below ucode update which is same to coreboot\src\cpu\intel\microcode\microcode.c > > msr.lo = (unsigned long)m + sizeof(struct microcode); > msr.hi = 0; > wrmsr(0x79, msr); > > Atom E3845 BayTrail with D-Stepping never returns after writing uCode, tried different ucode revisions > > On Mon, Oct 1, 2018 at 1:49 PM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > >> Hello Ranga: >> It is ASCII just not properly formatted.... >> >> Just remove the text from this: >> >> 0x00000001, /* Header Version */ >> 0x00000901, /* Patch ID */ >> 0x04212014, /* DATE */ >> 0x00030679, /* CPUID */ >> 0x69c4e6f1, /* Checksum */ >> 0x00000001, /* Loader Version */ >> 0x00000001, /* Platform ID */ >> 0x0000cbd0, /* Data size */ >> 0x0000cc00, /* Total size */ >> 0x00000000, /* reserved */ >> 0x00000000, /* reserved */ >> 0x00000000, /* reserved */ >> >> to this format: >> >> 0x00000001, \ >> 0x00000901, \ >> 0x04212014, \ >> 0x00030679, \ >> 0x69c4e6f1, \ >> 0x00000001, \ >> 0x00000001, \ >> 0x0000cbd0, \ >> 0x0000cc00, \ >> 0x00000000, \ >> 0x00000000, \ >> 0x00000000, >> >> And try again... >> Jose Trujillo. >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Friday, September 28, 2018 7:28 PM, galla rao <galla.rao80(a)gmail.com> wrote: >> >>> Hi , >>> >>> How does the coreboot picks the cpu microcodes >>> >>> as a blob or ASCII ? >>> >>> Tried both option GENERATE FROM TREE and INCLUDE EXTERNAL HEADER >>> >>> In Memory it appears it picks the ASCII file, but not a blob >>> >>> intel/cpu/baytrail/microcode/M0130679901.h >>> >>> 0x00000001, /* Header Version */ >>> 0x00000901, /* Patch ID */ >>> 0x04212014, /* DATE */ >>> 0x00030679, /* CPUID */ >>> 0x69c4e6f1, /* Checksum */ >>> 0x00000001, /* Loader Version */ >>> 0x00000001, /* Platform ID */ >>> 0x0000cbd0, /* Data size */ >>> 0x0000cc00, /* Total size */ >>> 0x00000000, /* reserved */ >>> 0x00000000, /* reserved */ >>> 0x00000000, /* reserved */ >>> >>> Help me out in understanding this issue >>> >>> Regards >>> Ranga

1 0

[skylake] Can not turn monitor on
by Zheng Bao 03 Oct '18

03 Oct '18

Hi, All, I tried both the vgabios extracted in linux /sys/ and seavgabios. The coreboot and seabios are both latest. Neither way works. The debug message seems to be good, which is attached. Is there anything wrong? Zheng

1 0

Re: [coreboot] removing bounce buffers
by Peter Stuge 03 Oct '18

03 Oct '18

ron minnich wrote: > I think if somebody is building libpayloads with 64 MiB - 3 MiB bss > that's a crazy day :-) 61 MiB ought to be enough? It's probably fine for a while. //Peter

1 0

Re: [coreboot] USB 2.0 EHCI debug dongle doesn't print logs (at Lenovo G505S)
by Nico Huber 03 Oct '18

03 Oct '18

On 9/30/18 5:55 PM, Ivan Ivanov wrote: > Thank you very much for your help, Nico! Enabling CONFIG_CONSOLE_USB > indeed got FT232H working! :-) I wonder why CONFIG_CONSOLE_USB isn't > enabled by default if CONFIG_USBDEBUG is enabled... Maybe this default > behaviour should be changed? Yes, I think you are right. USB console is the most common use case (if not the only one), it should be enabled by default. I've pushed a patch for review [1]. Nico [1] https://review.coreboot.org/28892

1 0

Re: [coreboot] SPI controller and Lock bits
by Nico Huber 03 Oct '18

03 Oct '18

On 10/3/18 12:31 AM, Sam Kuper wrote: > On 02/10/2018, Nico Huber <nico.huber(a)secunet.com> wrote: >> Am 02.10.18 um 13:48 schrieb Sam Kuper: >>> On 02/10/2018, Nico Huber <nico.huber(a)secunet.com> wrote: >>>> You need to tamper more than just HEADS, otherwise the attestation of >>>> the firmware (e.g. via TOTP or a Librem Key) would fail. >>> >>> That was not my understanding. >>> >>> See this outline of a putative "BadHeads" attack: >>> https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-… >>> >>> Also see Kyle Rankin's apparent confirmation that such attacks succeed >>> (on current Librems): >>> https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-… >> >> Sorry, I won't have the time to read through all this. In theory, it >> depends on when the measuring is started. If the measuring starts only >> late in HEADS (and not in coreboot), you are right. Generally you'd have >> to tamper the piece of software that starts the measuring. > > The putative attack bypasses the measuring. As such, I can't see why > it makes any difference whether the measuring starts early (in > Coreboot), or late (in Heads). Sorry if I'm misunderstanding something > basic. Sorry, we might talk past each other here. I was talking about type 2. attacks (in your forum post). But if you consider type 1. and can just skip the attestation, you are right, the measuring doesn't matter any more. But there are other means to detect this (e.g. a TPM sealed disk- encryption key; if you can't boot anymore, you'll notice). About type 2.: To me HEADS is a coreboot payload that runs after core- boot. If the measuring starts in coreboot, you have to tamper coreboot which is "more than just HEADS" (in my terms). Nico

1 0

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Jose Trujillo 03 Oct '18

03 Oct '18

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

1 0

intel/i82801dx SMM memory size?
by ron minnich 03 Oct '18

03 Oct '18

I'm wondering ... does anyone know the limits on SMM memory size for this part? I'm looking for a mainboard emulation which can support the larger sizes, e.g. 8M. thanks ron

1 0

Re: [coreboot] removing bounce buffers
by Nico Huber 03 Oct '18

03 Oct '18

On 10/2/18 10:16 PM, ron minnich wrote: > we are at long last removing bounce buffers from selfboot. > https://review.coreboot.org/c/coreboot/+/28647 > > This greatly simplifies the code and there are almost no platforms left > that need them. Here are the ones that seem to: > > src/northbridge/amd/amdfam10/Kconfig > src/northbridge/amd/lx/Kconfig > src/northbridge/via/vx900/Kconfig > src/soc/intel/fsp_baytrail/Kconfig > src/soc/intel/fsp_broadwell_de/Kconfig Out of curiosity why this hits some but not all FSP1.0 platforms I checked the git history. I couldn't find an explanation why fsp_rangeley and fsp_sandybridge were skipped in 7904e72. Maybe they were just over- looked? > > For these boards, I made the following change: > "For these five boards we change CONFIG_RAMBASE from 0x100000 (the > value needed in 1999 for the 32-bit Linux kernel, the original ramstage) > to 0x3d00000 (64 MiB - 2 MiB) which will put the non-relocatable x86 nb. that's -3MiB > ramstage out of the way of any reasonable payload until we can > get rid of it for good." Not sure about this, but a wild guess: If you build a libpayload payload with a huge heap (part of .bss, IIRC), you might easily reach this area. Not that I would care (don't own any of the affected platforms), but if this is the case, it might be a problem for other people. Nico

2 1

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