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.
Dec 16, 2023 at 20:16 by coreboot@coreboot.org:
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?
Right, Google builds from their own repositories. if you're using FSP binaries extracted from an image, you should get the headers associated with that build. They *may* be using the public headers, but maybe not.
The FSP headers look to be setting some address offsets, which would not end well, if the wrong values were being used by coreboot.
Agreed, you probably shouldn't use random pairings. We've always tried to keep things backward compatible, but unfortunately that isn't always the case.
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?
I'd say trial and error is a poor plan. Just get the associated FSP headers. You have build information available for any given firmware build. Google *should* have the FSP header in a public repo, though I don't know about this chip in particular. 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. 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.
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.
Yes, the coreboot payload is independent of the FSP binaries.
As far as playing with LinuxBoot itself, yes, I know that I may be on my own for that. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Sat, Dec 16, 2023 at 9:16 PM James Feeney james@nurealm.net wrote:
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?
no, the Google GLK FSP headers in upstream coreboot are correctly selected if using a Google mainboard. if you're using my tree, then I expect you're going to use my blobs submodule as well, and everything is correctly selected there.
Though I don't know why you'd want to use Google's older headers/binaries given the option.
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.
-
James Feeney -
Martin Roth -
Matt DeVillier