coreboot September 2018

coreboot@coreboot.org

59 participants
160 discussions

Re: [coreboot] SPI controller and Lock bits
by Nico Huber 29 Sep '18

29 Sep '18

On 9/27/18 6:24 PM, Lance Zhao wrote: > Okay, then I believe we should leave the decision on CONFIG instead of > force lockdown blindly. As of now, that's still optional I believe. AFAIK, EISS is not a configurable option in coreboot atm. And it shouldn't be, IMHO, as it encourages to weaken security. Nico

1 0

Re: [coreboot] Fwd: Thinkpad W520 external monitor over Nvdia GPU
by kinky_nekoboi 29 Sep '18

29 Sep '18

nope, so is the patch for the gpu advertised in the wiki page merged into the upstream code? Am 29. September 2018 16:53:45 MESZ schrieb Iru Cai <mytbk920423(a)gmail.com>: >The coreboot port of Lenovo W520 is in the upstream code now, are you >using >the upstream code? > >On Sat, Sep 29, 2018 at 10:36 PM Kinky Nekoboi ><kinky_nekoboi(a)bluetardis.de> >wrote: > >> Hello ! >> >> Thank to charlotteplusplus`s reddit post i have succesfully running >> coreboot with a skrinked ME image on my W520. Everything works fine >> exacpt the fact that the nvidia GPU is not reconnicest by any linux >> distro. (not shown in lspci) >> >> is here anyuser with an W520 and got coreboot running with the nvidia >> GPU enabled? >> >> Maybe somebody can send me their rom or help somehow. >> >> Greetings >> >> the kinky nekoboi >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > > >-- >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] SPI controller and Lock bits
by Peter Stuge 29 Sep '18

29 Sep '18

Youness Alaoui wrote: > We don't have/use ChromeEC and I think that telling every user that > they'd need dedicated hardware to update their BIOS makes no sense. I think you can decide what hardware your products include, right? I meant dedicated hardware on the mainboard. > > > Looking for a software solution is IMO like Intel trying to secure SMM. > > I don't see why that would be true, the software solution is pretty > simple. You boot, you can write to the flash in a secure environment, Intel also considered SMM a secure environment, until they realised that it isn't. These days I think they consider ME a secure environment. //Peter

2 1

Porting coreboot to another Intel's bay-trail
by Zvi Vered 28 Sep '18

28 Sep '18

Hello, I created a new mainboard based on "Bayley Bay FSP-based CRB" It seems that (at least) the following files are mandatory for build: cmos.layout devicetree.cb romstage.c Am I right ? If yes - what info required to write those files ? Can I use coreboot default files instead ? Honestly - I thought that FSP binary configuration is all I have to do. And few changes in menuconfig (e.g ROM size). Thank you, Zvika

1 0

USB 2.0 EHCI debug dongle doesn't print logs (at Lenovo G505S)
by Ivan Ivanov 28 Sep '18

28 Sep '18

Thank you for spkmodem comments, now I'm trying out a more reliable way - FT232H dongle - to extract the logs from AMD Lenovo G505S. I plug it into the correct port - USB 2.0 at laptop's right side. However it doesn't print anything except this short test message: --- /* Perform a small write. */ --- ret = dbgp_bulk_write_x(&pipe[DBGP_CONSOLE_EPOUT], "USB\r\n", 5); ------ line 322 of ./coreboot/src/drivers/usb/gadget.c Thinking that it breaks during the relocation from romstage to ramstage (migrate_ehci_debug function at ehci_debug.c ?) , I disabled CONFIG_USBDEBUG_IN_ROMSTAGE - but the results are the same: only "USB" message. I could see --- dprintk(BIOS_INFO, "Test write done\n"); ------ line 328 of ./coreboot/src/drivers/usb/gadget.c at cbmem logs, but even that doesn't get copied to FT232H output. Please could you take a look at my coreboot .config and cbmem logs, what if this FT232H dongle doesn't get selected as console output for some reason? CONFIG_CONSOLE_CBMEM is still enabled, but maybe I should disable it? Best regards, Ivan Ivanov

1 0

Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
by Zvi Vered 28 Sep '18

28 Sep '18

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

Re: [coreboot] flashrom and 256 MiB S256FL256S
by ron minnich 28 Sep '18

28 Sep '18

I spoke too soon. It just flat out does not work to have sf100 and 256Mbit part AFAICT On Fri, Sep 28, 2018 at 11:19 AM ron minnich <rminnich(a)gmail.com> wrote: > Got the fix. I used dpcmd to update the firmware on the FS100 to 5.5.3 > > Then flashrom can program it with ease. > > And, ironically, while dpcmd can update the firmware, it still can't flash > the part :-) > > ron >

1 0

Re: [coreboot] SPI controller and Lock bits
by Youness Alaoui 28 Sep '18

28 Sep '18

On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper <sam.kuper(a)uclmail.net> wrote: > > On 28/09/2018, Peter Stuge <peter(a)stuge.se> wrote: > > Youness Alaoui wrote: > >> avoid any malware writing to the flash > > > > Just disallow flash writes by the platform. Allow flash writes only > > by dedicated hardware (maybe ChromeEC?) which implements a simple and > > efficient security protocol. > > Relevant URL: https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect We don't have/use ChromeEC and I think that telling every user that they'd need dedicated hardware to update their BIOS makes no sense. > > > > Looking for a software solution is IMO like Intel trying to secure SMM. > > Hear, hear! > I don't see why that would be true, the software solution is pretty simple. You boot, you can write to the flash in a secure environment, once you decide you don't need to write to the flash, you lock it until your next reboot. > This is a pretty useful feature, and it would be nice if it weren't tied to heads (or any payload for that matter). What about tianocore's capsule update mechanism, as well as stuff like fwupd ? Any way to have something like a common solution ? Tianocore is a payload, so tianocore's update mechanism is still about doing the update in the payload.. All heads is going to do is to run a script that calls flashrom (and actually use cbfstool to extract/inject the heads-specific cbfs files into the new image, such as the user's pgp keys for example, before flashing).. so it will have to be tied to heads either way. Heads is the one booting into your OS, so it can read-only lock the entire flash before the user (real or malicious) gets control. The use of heads is already tied in with the use a gpg key (nitrokey, yubikey, librem key), and you'd already need to have the key inserted (and pin valid) before it would give you access to a recovery shell, and the same can be done before it allows the flash to be updated. I hadn't thought of the use case of fwupd (which we're currently adding support for) since it wouldn't be able to flash from the OS, but I think that having the update file deosited in /boot under a specific filename and rebooting would be all that fwupd would need to do, then on the next boot, heads would find the file and suggest to the user to flash it. > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] flashrom and 256 MiB S256FL256S
by Nico Huber 28 Sep '18

28 Sep '18

On 9/27/18 10:11 PM, ron minnich wrote: > yeah, also is there a programmer you recommend for 32MiB parts? Any programmer that can handle arbitrary SPI commands, e.g. single- board computers with native SPI interface (RPi, BeagleBone Black etc.), CH341A is popular but slow, FTDI based programmers are faster (FT232H/ FT2232H/FT4232H), serprog programmers (some may not be too slow), Bus- Pirate rather slow too. Nico > > thanks > > ron > > On Thu, Sep 27, 2018 at 1:10 PM Nico Huber <nico.h(a)gmx.de> wrote: > >> Ah, dediprog... you happen to have the one programmer that is hard to >> support. >> >> On 9/27/18 9:49 PM, ron minnich wrote: >>> hmm, is this useful? >>> >>> Found Spansion flash chip "S25FL256S......0" (32768 kB, SPI) on dediprog. >>> Erasing and writing flash chip... 4-byte address requested but master >> can't >>> handle 4-byte addresses. >> >> That is expected, native 4-byte instructions are tried first but they >> are not implemented yet for dediprog. It should fall back to another >> instruction though. Unless the dediprog resets the chip between in- >> structions, it should actually work. Though, David seemed to have >> trouble with that too, I didn't test it myself yet. >> >>> Looking for another erase function. >> >> Can you please just post the whole log (best taken with -o logfile). >> >> Nico >> >

3 2

Re: [coreboot] microcode blob or ascii
by galla rao 28 Sep '18

28 Sep '18

This issue is sorted out cpu_microcode_blob.bin matches the ".h" file for microcode the SoC still fails at this point msr.lo = (unsigned long)m + sizeof(struct microcode); msr.hi = 0; *wrmsr(0x79, msr);* Any clues? On Fri, Sep 28, 2018 at 5: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

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