coreboot June 2018

coreboot@coreboot.org

40 participants
105 discussions

Re: [coreboot] Porting Kabylake laptop
by Zaolin 27 Jun '18

27 Jun '18

Hey Chris, yes it does. The PI interface is in terms of encapsulation somewhat cleaner then the FSP integration. I think that was Ron concern using PI instead of FSP. If we talking about full customization up to the bootblock and vboot2 support I would recommend to use coreboot in combination with LinuxBoot payload. If we talk less effort to get your firmware running maybe LinuxBoot is the better approach depending on your platform. Best Regards, Philipp On 27.06.2018 13:37, chrisglowaki(a)tutanota.com wrote: > 26. Jun 2018 20:02 by rminnich(a)gmail.com <mailto:rminnich@gmail.com>: > > >> For a case like this, where your choice is between two binary blobs (FSP or UEFI) I would argue that linuxboot is a better way to go. >> See > github.com/osresearch/heads <http://github.com/osresearch/heads>> or > linuxboot.org <http://linuxboot.org>> for more info. >> ron > > > Doesn't linuxbootalso require the FSP blob for memory and silicon initialization on any Intel board after Ivy Bridge? > > > > > Thanks > > Chris > > > >

1 0

flashrom programmer
by Zvi Vered 27 Jun '18

27 Jun '18

Hello, How can I know what is the right flashrom programmer I should use ? under DOS\EFI I have a vendor's utility that enables flash programming. But it can flash to a specified address. The vendor's programmer works without any external hardware. When I tried: flashrom --programmer internal, I got: ---------------------- flashrom v0.9.9-rc1-r1942 on Linux 4.13.0-36-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. WARNING: No chipset found. Flash detection will most likely fail. No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. ---------------------- Thank you, Zvika

1 0

Re: [coreboot] Bayley Bay FSP-based CRB
by Zvi Vered 27 Jun '18

27 Jun '18

Dear Jose & Nico, Thank you very much for your help ! Best regards, Zvika On Thu, Jun 21, 2018 at 11:28 AM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > Hello Zvika, > Look for the list of Linux commands to dump many of the information from > your original BIOS running, maybe there you will find this information. > > Also, some configuration can be seen from your original BIOS running Intel > FIT for Baytrail in Windows. > > About configuring those settings in coreboot look for other examples in > the coreboot tree about configuring PCI devices in devicetree.cb and other > places. > > I Am new to coreboot too and please correct me if I Am wrong. > Good Luck! > J. Trujillo > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On June 21, 2018 3:34 AM, Zvi Vered <veredz72(a)gmail.com> wrote: > > Hello, > > Thank you very much for the detailed reply. > Vendor's BIOS contains few peripherals initialization. > For example: PCIe enumeration, SATA controller, USB etc. > In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set. > Should vendor supply code for this ? or any other information ? > How can I write it from scratch ? Can Intel provide information on how to > implement this initialization ? > > Thank you, > Zvika > > > On Mon, Jun 18, 2018 at 11:22 AM Jose Trujillo via coreboot < > coreboot(a)coreboot.org> wrote: > >> Hello Zvika: >> 1.- Usually it is not necessary to change the CBFS size unless the >> compiler complain of lack of space. >> 2.- You should not worry about this setting to make your system to work. >> 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO >> because it will enable SOC internal COM1, instead (if your plan is to use >> FSP) enable FSP and add a VGA bios bin manually.... (The use of FSP is >> optional but I never tried without FSP). >> 4.- You need to add them yourself, there are examples to follow in this >> mail list. >> Good luck! >> J.Trujillo >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On June 18, 2018 6:24 AM, Zvi Vered <veredz72(a)gmail.com> wrote: >> >> Hello, >> I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after >> make distclean I chose: >> Mainboard vendor: Intel >> Mainboard model: Bayley Bay FSP-based CRB >> 1. The size of CBFS is: 0x200000. Is it a fix size or should I change it >> according to my board (which is also bay trail) ? >> 2. According to "dmidecode" I ran on my target, "Address: 0xE0000" >> Should I set this address in coreboot configuration ? How ? >> >> 3. In this board default configuration, "Configure defaults for the Intel >> FSP package" is not selected. Is it possible that this board does not use >> Intel FSP at all ? >> Under "Generic Drivers", "Use Intel firmware Support Package' is also not >> selected. >> >> 4. Under "chipset", there is no option to set "Super I/O". Can you please >> tell why ? >> 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of >> coreboot.rom is also 4MB. >> >> Thank you in advance, >> Zvika >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

Re: [coreboot] Porting Kabylake laptop
by chrisglowaki＠tutanota.com 26 Jun '18

26 Jun '18

Hi Nico On 26. Jun 2018 12:56 nico.huber(a)secunet.com <mailto:coreboot%40coreboot.org?Subject=Re%3A%20%5Bcoreboot%5D%20Porting%20Kabylake%20laptop&In-Reply-To=%3C7bc3873d-a7f3-1981-3b3b-fa6abc86bf8b%40secunet.com%3E> wrote: > If you use the exact same processor SKU as the reference board: yes. > Otherwise: no. Both the people who implemented FSP and who integrated > it into coreboot were lazy: They could have provided defaults for all > SKUs but didn't. If in doubt (and in case you don't have an NDA with > Intel) better ask here what the right defaults are for your processor. I have a i5-7200U. Intel has some datasheets available for Kabylake-U. Can they be used to get VR values? > 2. Can the laptop work properly without GPIO? I don't know if there is > >> a way to dump the GPIO config in vendor firmware on Kabylake. > > What works with the reset default configuration and what not depends on > each board. It is likely to boot in my experience. Have a look at `util/ > inteltool/` in our source tree. It can dump the GPIO registers for Sun- > rise Point (the 100-series PCH that comes with Skylake). The 200-series > PCH should be the same, but if you have an SoC version of Kaby Lake > (known as Kabylake-U / -Y / -R) things are different. I'll add Youness > in CC who might have a patch for that. > Unfortunately inteltool doesn't support my PCH yet, probably because I have a Kabylake-U processor. >> 3. Are there other settings that could damage the hardware? > > I can't tell if that is the case for your board without knowing your > board. Is it generally possible? yes. Though, it is unlikely that core- > boot contains code that would harm your board. When you copy code for > a reference board, you should also check the C code. It's not much and > if there is something you don't understand, better ask. All the board- > agnostic code should be safe (but there is no guarantee). > Do evaluation boards like KBL RVP8 have only board-agnostic code or do they also have some board-specific code? > And, as you need an FSP binary by Intel for Kaby Lake, it also has a > huge amount of settings (over 700 if you count them individually (but > they are actually grouped)). Some of these settings are overridden by > coreboot (devicetree settings or static platform code). And their code > quality is generally worse than coreboot's (maybe not over all but com- > pared to coreboot). So I can't say if FSP doesn't do any harm (though > unlikely, as it works for most everybody else so far). The binaries > on Github likely have defaults for the non-SoC version btw. Alas, FSP > is basically undocumented. The FSP package from GitHub comes with config files for FSP. Do they need to be used or do only the settings in devicetree matter? Thanks a lot for your help, it is very helpful. Chris

2 1

Re: [coreboot] Porting Kabylake laptop
by chrisglowaki＠tutanota.com 26 Jun '18

26 Jun '18

On 25. Jun 2018 18:18 nico.h(a)gmx.de <mailto:nico.h@gmx.de> wrote: > you can generally boot without a complete port. But you can also damage > the hardware if you are not careful. Beside the devicetree settings (pay > attention when it comes to the voltage regulator settings!), the GPIO > configuration should also match your board. You can try to boot without > GPIO configuration (it should be safe because the hardware has to expect > the reset defaults for the GPIOs). But *never* try to boot with a copied > GPIO configuration from another board. Thank you Nico for the warnings! A few questions: 1. Is it safe to leave default VR settings from Kabylake Reference Board? 2. Can the laptop work properly without GPIO? I don't know if there is a way to dump the GPIO config in vendor firmware on Kabylake. 3. Are there other settings that could damage the hardware? > Regarding the EC, you can learn a lot about its interface from the ven- > dor's ACPI implementation. Unless the board uses a lot of PnP interfaces > of the EC (unlikely for a modern laptop), the datasheet is usually not > helpful. What you really would need is documentation about the EC firm- > ware and its OS interface. And you'll likely not get that. > Can the laptop boot to Linux without EC support in coreboot? Regarding the ACPI implementation, can that be dumped using acpidump and then used in the ec.asl file? Thanks, Chris

3 2

Re: [coreboot] Porting Kabylake laptop
by chrisglowaki＠tutanota.com 26 Jun '18

26 Jun '18

26. Jun 2018 07:44 by alexfeinman(a)hotmail.com <mailto:alexfeinman@hotmail.com>: > > Chris, > > The GPIO tables are usually compiled into the BIOS C code and not into ASL. While decompiling DSDT can give you some insight into what GPIOs are used for say WLAN power control or some of the hardware interrupts, there is also a number of Kaby Lake pins that drive system signals or control onboard hardware without going through ASL. For instance Coreboot build for KBL RVP3 uses this: > > https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/kblrvp… <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/kblrvp…> > > > What Niko suggests is to review carefully all the lines that use GPIO_CFG_GPO (output) to ensure that no pins that are configured as output unless you are absolutely sure about where they go. Of course, this requires you to understand the code > Hi Alex, I mentioned dumping the ACPI code to ask if I can use it in the .asl files in mainboard directory (for example https://github.com/coreboot/coreboot/blob/master/src/mainboard/purism/libre… <https://github.com/coreboot/coreboot/blob/master/src/mainboard/purism/libre…>). Dumping data for gpio.h I guess is hard because inteltool doesn't support Kabylake and I have no schematics. Nico said I can try booting without the GPIO config, but I don't know if the laptop will be usable without it. Thanks, Chris

1 0

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Shawn 26 Jun '18

26 Jun '18

On Mon, Jun 25, 2018 at 11:39 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Mon, Jun 25, 2018 at 12:55 AM Shawn <citypw(a)gmail.com> wrote: >> >> Hi Ron, >> >> >> IIRC, Machine mode in RISC-V is just looking similar to SMM in x86. >> But it can do more than what SMM does. > > > that's in my view not good, since in many cases, M mode code is part of > firmware, not the kernel image. Kernels don't get to change or ignore it. M > mode can protect itself from the kernel, even from being read. So it can > hide its presence, what it does, and might even be able to change itself. > > I had a talk with a BIG ARM SOC vendor not long ago. They said that at one > point a big x86 company proposed that their company implement SMM for ARM. > "so they asked us to implement this SMM-like thing that had unlimited > privilege. We said no, no no, there's no reason to repeat x86 mistakes on > ARM". Good call on that company's part. > > I argued several years ago that M mode code should be supplied by the > kernel, not firmware, for the obvious reasons: M mode is a great place to > put a persistent threat. The various x86 experiences were well known by that > time, so the problem should have been pretty clear. > Well, from that perspective I'm totally agree w/ SMM is a big threat especially when the machine was compromised and then attacker implant a rootkit running in SMM. If that happened in x86, it's pretty much fuc*ed up. Cu'z it's unlikely detect the smm rootkit at runtime, while the static analysis of forensics cost more time/money. Maybe we should've taken mitigation( SMRAM?) into this case in the 1st place. -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
by Nico Huber 26 Jun '18

26 Jun '18

On 25.06.2018 09:55, Shawn wrote:> Hi Ron, > On Sun, Jun 24, 2018 at 12:55 AM, ron minnich <rminnich(a)gmail.com> wrote: >> On Wed, Jun 20, 2018 at 11:03 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >>> Whats the deal with SMM? What a shame they thought to add it. >> >> It's a huge disappointment. I made some effort a few years ago to try to >> convince folks this was a bad idea and failed. >> >> I'm no longer as optimistic as I was about RISC-V. There seems to be a real >> push to be "just like x86". > > IIRC, Machine mode in RISC-V is just looking similar to SMM in x86. > But it can do more than what SMM does. It helps to enclave-based > solution. I'm looking forward to see the open solution, e.g: Sanctum, > Keystone, etc to land into production environment. IMO, putting enclaves on the same silicon as the code you want to protect them from is a failed concept. And more, it's bullshit, it means two separate entities have to own the same physical chip. And SGX proves that it doesn't work (they can't protect the OS from being spied upon from the enclave (see Spectre), how can they ever hope to protect the enclave from the much more powerful OS?). IMHO, not RISC-V but the whole industry is at least 20 years away from getting that going (software separation in one piece of silicon, with- out help from the software). So, no, no marketing false-security tech* that doesn't provide what it promises can justify to pollute an architecture like RISC-V. Nico * I know there is a lot of honest research around enclaves, but they all seem to ignore the reality of today's processors.

2 1

Re: [coreboot] Fixing gitweb links on coreboot.org
by Julius Werner 25 Jun '18

25 Jun '18

> sorry for the late response. I setup forwarders so these links resolve > to the right location. Cool, that works, thanks! The ref-specific links are still broken (e.g. when you click through from https://review.coreboot.org/admin/projects/coreboot,branches and get a link like https://review.coreboot.org/admin/projects/gitweb?p=coreboot.git;a=shortlog…), but as long as we have the other one there's a path to figure it out.

1 0

Re: [coreboot] Fixing gitweb links on coreboot.org
by Patrick Georgi 25 Jun '18

25 Jun '18

Hi Julius, sorry for the late response. I setup forwarders so these links resolve to the right location. As an aside, an entrypoint to cgit that already worked is the commit ID in the CL view of gerrit (eg. "595e777" on https://review.coreboot.org/10000). Patrick Am Fr., 22. Juni 2018 um 00:29 Uhr schrieb Julius Werner <jwerner(a)google.com>: > > Hi coreboot.org admins, > > For a while now (probably since we switched to the PolyGerrit UI?), > the gitweb links on pages like > https://review.coreboot.org/admin/projects and > https://review.coreboot.org/admin/projects/coreboot,branches have been > broken. They link to pages like > https://review.coreboot.org/admin/gitweb?p=coreboot.git;a=summary > which just says "Server Error: gitweb" and hangs. > > Instead, we have a perfectly working Cgit implementation at > https://review.coreboot.org/cgit/coreboot.git, but you can't find it > unless you happen to know the URL or switch back to the old UI. > There's not even a link to it on the coreboot.org landing page or > https://coreboot.org/developers.html. > > Can we fix this to make it more discoverable and get rid of the broken > links in Gerrit? It keeps tripping me up every time I'm trying to link > anyone to coreboot sources... -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2018