coreboot December 2023

coreboot@coreboot.org

20 participants
50 discussions

Re: Google Embedded Controller blob - how does that get to the EC?
by James Feeney 18 Dec '23

18 Dec '23

> Since my MrChromebox firmware does not use vboot, I have ported the EC-RW firmware update code from vboot to coreboot, and check if an EC-RW update is needed on each boot as part of EC init in ramstage. This code is in my tree on github for inspection. Well, there are over 100 files named "ramstage.c" in the github repository. Do I understand correctly that the MrChromebox firmware generated will have a custom ramstage, different from the stock coreboot ramstage, just to check if an EC-RW update is needed? Coreboot would not typically try to do that? > It's not necessary to build your own EC-RW firmware or even update it unless there's a specific issue you're trying to resolve. But still, to play-around with different payloads, using mostly stock coreboot, the EC firmware could just be completely left out of the coreboot ROM image? And, if I still needed to update the EC firmware, I could use the Google flashrom fork, as in the Google example, just: flashrom -p internal:bus=lpc -w ec.bin ?

2 3

coreboot services are back up
by coreboot org 18 Dec '23

18 Dec '23

This should have taken care of the issues we've been seeing recently with gerrit. If you see any issues with any of the services, other than the redmine service at ticket.coreboot.org, which is on a different server, please respond to this email and let us know what you're seeing. Martin

1 0

coreboot.org downtime for a couple of hours right *NOW*
by coreboot org 18 Dec '23

18 Dec '23

Hi All, We're taking down the coreboot servers for a couple of hours to do some emergency maintenance. Sorry for the short notice - everything should be back up in a couple of hours. Martin

1 0

Re: Google Embedded Controller blob - how does that get to the EC?
by James Feeney 17 Dec '23

17 Dec '23

> If you do need to update the EC firmware, just flash it manually. Don't bother with the automatic update. It doesn't make sense for you to build it into the firmware. Thanks. That makes more sense. Though still, I don't know where or when this "automatic update" happens. Maybe it happens when ChromeOS itself starts? If that is the case, then the EC update would *never* happen automatically if ChromeOS is replaced with something else. On the other hand, if the EC binary itself is somehow searching the CPU ROM for an EC ROM image, then it might get confused if there is no EC ROM image to find. Maybe Matt knows how this works? Matt? I also see that the Google flashrom fork seems to know how to do this update manually, if a filesystem exists, where http://goo.gl/i5sMq , "Flashrom @ Chromium.org", has: Similarly, to write the x86 and EC firmware ROMs (assume write-protection disabled): flashrom -p internal:bus=spi -w bios.bin # write x86 firmware flashrom -p internal:bus=lpc -w ec.bin # write EC firmware As far as I know, linux does not know how to directly mount a ROM coreboot filesystem.

2 1

Re: geminilake fsp on Google Chromebook?
by James Feeney 17 Dec '23

17 Dec '23

>> Then, how do I find whether a particular fspm/fsps set is using the coreboot 2.2.0.0 headers or the 2.2.3.1 headers? Those headers are very similar. > you can't, without knowing the exact build they came from. If they are Google built firmware images, they are using the Google FSP binaries/headers. Is that to say that the Google FSP headers may not match *any* version of the coreboot headers available? The FSP headers look to be setting some address offsets, which would not end well, if the wrong values were being used by coreboot. > For anything else, you'd need to know the tree/hash it was built from and which header values were selected by the build. Hmm - so in the end, "trial and error", if I really wanted to use the extracted Google FSP binaries. I'm hoping that other extracted Google blobs are not so finicky - the Embedded Controller blob, for instance? >> Where your config is for the edk2 payload, is there any reason that these same edk2 FSP files would not also work with the LinuxBoot payload? > I have no idea what you are asking here - edk2 FSP files? That phrase does not make sense to me. I'm also not familiar with the LinuxBoot payload or how it would relate to edk2 Ha! I'm expecting that the FSP files being used should have nothing at all to do with the eventual coreboot payload. I was just asking for confirmation. Though I'm not completely unfamiliar with firmware generally, with coreboot and Google firmware, sometimes my assumptions are correct, and sometimes they are completely off-base and wrong. As far as playing with LinuxBoot itself, yes, I know that I may be on my own for that.

3 2

Google Embedded Controller blob - how does that get to the EC?
by James Feeney 17 Dec '23

17 Dec '23

>> I'm hoping that other extracted Google blobs are not so finicky - the Embedded Controller blob, for instance? > As far as the EC, it's all open source, and in public repos at Google. You can rebuild it instead of using their binary. Thanks for that Martin. Still, I'm intimidated by the EC blob. On my board, Google's forked flashrom says: Found Nuvoton flash chip "NPCX796F". Some Nuvoton ECs, and probably this one, are ARM chips. 3rdparty/chromeec/README.md says: If you want instant gratification, you can fetch the source code directly. However, you will need the tool-chain provided by the Chromium OS development environment to build a binary. And then, at http://goo.gl/i5sMq, "Flashrom @ Chromium.org" says: For these examples, we assume the x86 firmware ROM is connected directly to the host via SPI and the EC ROM is connected via the EC to LPC. And then, no matter how this EC blob is acquired, that Google page does not seem to disclose exactly *how* this EC ROM image is suppose to get from the coreboot ROM image, and into the separate EC ROM. But, for instance, I see u-boot/cmd/Kconfig actually has: menu "Firmware commands" config CMD_CROS_EC bool "Enable crosec command" depends on CROS_EC default y help Enable command-line access to the Chrome OS EC (Embedded Controller). This provides the 'crosec' command which has a number of sub-commands for performing EC tasks such as updating its flash, accessing a small saved context area and talking to the I2C bus behind the EC (if there is one). So, even after going to the trouble of getting an EC ROM image into coreboot, how does this get into the EC ROM? Does coreboot have some "magic" that checks the EC ROM version, and then automatically flash the EC ROM? Or, does this have to be done manually? And, if manually, and if u-boot is not being used, does this "crosec" command have to be found or built, to run in an x86 linux for instance, and used to actually flash the EC ROM?

3 2

Re: geminilake fsp on Google Chromebook?
by Martin Roth 17 Dec '23

17 Dec '23

Actually, Intel doesn't have much to do with this. I can look at adding the feature, but the chromeos team would need to evaluate the size differences and decide to whether to enable it. Dec 17, 2023 at 12:09 by coreboot(a)coreboot.org: > Dec 16, 2023 at 20:16 by coreboot(a)coreboot.org: > >> Just a thought, the FSP headers are pretty small. Maybe they can be compressed and added to the firmware image to make this easier, the way we do for the config file. >> > > Considering that coreboot needs to know these FSP address offsets, that would seem an excellent idea. Or, at least a reference to the actual version of the headers used could be added to the firmware image, if a unique header version number exists. > > I notice that in the documentation, referenced at 3rdparty/fsp/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf, Intel mentions Coreboot specifically by name. So maybe the coreboot developers would hold some sway with this idea. > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

Re: geminilake fsp on Google Chromebook?
by James Feeney 17 Dec '23

17 Dec '23

Dec 16, 2023 at 20:16 by coreboot(a)coreboot.org: > Just a thought, the FSP headers are pretty small. Maybe they can be compressed and added to the firmware image to make this easier, the way we do for the config file. Considering that coreboot needs to know these FSP address offsets, that would seem an excellent idea. Or, at least a reference to the actual version of the headers used could be added to the firmware image, if a unique header version number exists. I notice that in the documentation, referenced at 3rdparty/fsp/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf, Intel mentions Coreboot specifically by name. So maybe the coreboot developers would hold some sway with this idea.

1 0

COM Express type 7 / 6 board?
by ron minnich 15 Dec '23

15 Dec '23

I'm looking for a COM Express board, type 6 or 7, that runs coreboot, thought I would start here.

4 5

Re: geminilake fsp on Google Chromebook?
by James Feeney 15 Dec '23

15 Dec '23

>> … I expect that that refers to an even newer "release 9" versus a "release 8". And, this "-r9" should also work with the setting: CONFIG_FSP_HEADER_PATH= "src/vendorcode/intel/fsp/fsp2 _0/geminilake/ 2.2.3.1 " Is that correct? > NO! those strings are simply build paths, they have no correlation to the version of headers which need to be used with a given binary/binaries. Google binaries use Google's headers. Intel's binaries use Intel's headers. Then, how do I find whether a particular fspm/fsps set is using the coreboot 2.2.0.0 headers or the 2.2.3.1 headers? Those headers are very similar. > Also, the binaries in my repo would not have anything resembling that build path as it's specific to a Google ChromeOS build system, and my binaries are not from a ChromeOS device. Oops! I was looking at your binaries in 3rdparty/blobs/mainboard/google/octopus/casta/ instead of your binaries from the site-local/Kconfig, 3rdparty/blobs/soc/intel/glk/fsp/release/. $ strings 3rdparty/blobs/soc/intel/glk/fsp/release/Fsp_M.fd |grep -i gemini|head -1 c:\tcwork\bxt_ap7829\Build\GeminilakeFspPkg\RELEASE_VS2013x86\IA32\GeminilakeSiliconPkg\NorthCluster\MemoryInitGlk\MemoryInitFsp\DEBUG\AutoGen.c Where your config is for the edk2 payload, is there any reason that these same edk2 FSP files would not also work with the LinuxBoot payload?

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2023