coreboot

coreboot@coreboot.org

4 participants
39683 discussions

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

Re: geminilake fsp on Google Chromebook?
by Matt DeVillier 15 Dec '23

15 Dec '23

On Thu, Dec 14, 2023 at 6:07 PM James Feeney <james(a)nurealm.net> wrote: > > To get it to update values to new default settings, run: > > make savedefconfig && make defconfig KBUILD_DEFCONFIG=${PWD}/defconfig > > The Kconfig in coreboot document is written with developers writing > Kconfig files in mind, but it's got a lot of useful information about how > Kconfig works. > > That helps. It's sort of a "process", building a ".config", rather than a > single "make nconfig" and done. > since you're starting with my defconfigs, you don't need to change anything. They are the exact configs I use to build my release firmware and are known/tested working. > > > all this mess is because you're trying to use an existing config rather > than start from my defconfig, which is designed to work with my repo. The > selections are currently guarded appropriately. ADD_FSP_BINARIES only needs > to be selected if not using the 3rdparty/fsp repo (as it's selected by > default there). > > Ah! Ok, I see that now. I'm stumbling-around, trying to understand config > options. It's overwhelming at first. And it requires learning to "trust > the defaults". > you're not trusting the defaults, you're trusting my configs which are used to build working firmware. The defaults are not sane or there wouldn't be a dozen lines in the defconfigs and a handful more in my site-local/Kconfig > > Some config options for a board are "required - don't touch!", and others > really are "optional". I'm getting a sense of which is which, but there > doesn't seem to really be a "config overview" or centralized guidance. And > it's probably different for every different cpu architecture. > indeed, knowing what can/should be changed in many cases requires being a firmware developer with reasonable familiarity with coreboot, the platform, and the board in question > > >> … Hmm - so, if the blob files referenced in site-local/Kconfig are not > extracted from the stock ChromeOS firmware images for GLK boards, and they > are not built from source by coreboot, then where are they from? > > > they're extracted from another coreboot device which uses newer FSP > blobs than the Google ones. Which is why I use the newer headers. > > Aha! Thanks for that. > > Comparing the latest "bluebird" update, > bios-casta.ro-11297-222-0.rw-11297-411-0.bin, from > chromeos_15604.57.0_octopus_recovery_stable-channel_mp-v32.bin, and your > newer FSP blobs, I see: > > $ strings 2023Dec01/fsps.bin |grep octopus|head -n1 > > /build/octopus/tmp/portage/sys-boot/intel-glkfsp-0.0.1-r9/work/intel-glkfsp-0.0.1/Build/GeminilakeFspPkg/RELEASE_COREBOOT/IA32/GeminilakeFspPkg/FspHeader/FspHeader/OUTPUT/./FspHeader.dll > > $ strings 3rdparty/blobs/mainboard/google/octopus/casta/fsps.bin | grep > octopus | head -n1 > > /build/octopus/tmp/portage/sys-boot/intel-glkfsp-0.0.1-r8/work/intel-glkfsp-0.0.1/Build/GeminilakeFspPkg/RELEASE_COREBOOT/IA32/GeminilakeFspPkg/FspHeader/FspHeader/OUTPUT/./FspHeader.dll > > The most recent bios has that "-r9", versus the "-r8". 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" > 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. 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. TBF, this is unnecessarily confusing because Intel chose to not publicly release FSP headers/binaries for Geminilake (or Jasperlake). Everything is set correctly in my repo so that a user who clones my repo/submodules and uses my build script will end up with a functional firmware image for a given board. > Is that correct? > > >

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