Good day folks,
In a recent change, it was proposed that we drop support for the Intel
Ice Lake platform.
The only mainboard supporting the platform was the Intel RVP, but as far as
it appears the project never progressed past the initial silicon, and so
the code is now
unmaintained and also unused. Since Ice Lake is very similar to TGL & ADL,
it poses a
maintenance burden when dealing with Intel common code e.g., anything in
According to , this should be announced in upcoming release notes first,
could happen in 6 months.
Wondering if anyone has any thoughts on why we should keep it around,
otherwise let's update the upcoming release notes to give the "official"
that it will be dropped.
Dear coreboot community.
I guess the most of you have seen the tension that was introduced to the
community once Intel started to enable the Programmable Service Engine on
the new IOTG SoC called Elkhart Lake (for reference, please see ).
One of the outcome of this difficulties was to ask Intel for open sourcing
the PSE code in order to avoid a new blob being introduced to coreboot.
I took this action item and reached out to Intel in this regard. As a result
I have had two meetings with the responsible people at Intel and they
started to look into this request. So as of now Intel is analyzing the code
to understand what needs to be done to open source it.
What has been mentioned by Intel to me is that up to now nobody else have
ever requested this for the PSE. Furthermore Intel let me know that it would
be easier to convince the management layer to spend work on open sourcing
the code if there would be more people from different companies requesting
the same. My first guess was: we can do this! Therefore I have drafted up an
open letter which I would like share with all of you:
The wording have now been reviewed for two days between different parties
and I would like to keep it as it is in order to get it done in time.
This is now the moment where you can raise your voice! Please have a look at
the open letter and sign it if you agree with the terms and if you support
this approach. The more people we get the higher are our chances to be
visible as an open source community. And it would be really helpful if we
could get this letter signed by companies, this will for sure increase the
traction of this request.
I will keep this letter in "signing" state until 2021-12-09 07:00 am German
time. Once we are there I will hand it over to Intel.
Thank you for your support in advance
Hello coreboot community,
For our work on POWER9 coreboot port we were using Skiboot  packed into
FIT payload. While it worked fine, we wanted to provide users with easier
way of testing it on hardware. I believe it may be possible to modify only
one of PNOR (fancy name for flash given by POWER people) partitions.
In order to do this, we would have to fit whole CBFS into 512k (actually
1M including ECC, but that would require non-power-of-2 size), which
should be doable with LTO and compressed payload.
According to , whole file compression is not available for FIT payloads.
I understand that this makes sense, thanks to this we can decompress/load
individual parts of payload (e.g. kernel and initramfs) once, otherwise we
would have to decompress it to read metadata first and then move code
around in memory.
However, FIT format doesn't hold information about uncompressed sizes of
its components, required by decompressing functions in coreboot. Instead,
their compressed sizes  are used to initialize output region sizes 
and those are then passed to decompressors . Only FDT has a workaround
to this problem , and kernel's size is calculated in an arm64-specific
way in . On other architectures components (other than FDT) are
partially decompressed until they run of of space, silently ignoring the
What should be "the proper way" of getting uncompressed size? I can think
of the following options, listed in no particular order:
1. Extend hack used for FDT to other components, use it for all compressed
parts. Arbitrary size multiplier may either waste some space potentially
overlapping other component's memory range or not be enough in edge
cases (e.g. mostly zeroed file).
2. For LZMA you may get decompressed size from the header, unfortunately
this is not possible with LZ4.
3. Dry decompression just to check proper size - sounds too costly.
4. New properties for components' nodes in ITS file. May need changes in
mkimage, haven't looked yet. Preferably shouldn't have to be manually
written to ITS as that would be prone to error. While playing with
mkimage, may add automatic compression, right now it expects already
compressed files in ITS, although this can also be scripted.
5. Add more arch- and payload-specific parsing of images, as was done for
arm64. This may require some kind of mark that a payload needs special
handling (new CBFS attribute maybe?)
6. Enable whole file compression of FIT payloads, which results in juggling
7. Mix of the above.
For our current issue we can also load Skiboot from another PNOR partition
(from where it is normally loaded by Hostboot  which we are basically
substituting with coreboot) and manually create FDT for it. This would
however break normal coreboot boot flow and we would like to avoid that.
https://3mdeb.com | @3mdeb_com
to me it seems like the Intel Quark SoC has been unmaintained and
unused for a long time now. So I'm proposing to deprecate the support
for it with coreboot release 4.17 , in order to drop the support
with release 4.19 so that the community has less maintenance overhead.
Does anyone use this platform? Any opinions against this?
# 2022-03-29 - coreboot UEFI working group
Next meeting: 2022-04-26
Jay, Werner, Martin, Sheng, Ron, David
* In the coreboot meeting last week, we discussed a proposal from Intel
to change the handoff mechanism to payloads . After that
discussion, the decision was made to move further discussion of that
topic over to the UEFI working group meeting. There was another
meeting on Monday, March 28th where we got a much better understanding
of what’s going on and the reasons behind the proposal.
* Intel wants to look at modifying the payload handoff as a part of
their universal-scalable-firmware  initiative.
* The current payload handoff method has a number of flaws that
they’d like to fix, such as the address for stack being
* This likely also gives coreboot an opportunity to address
other parts of the USF spec that cause issues or
incompatibilities for us.
* The coreboot project got involved when Sheng suggested to Intel
that it would be good to align the payload-handoff format with
other projects such as coreboot.
* Thanks Sheng!
* Using CBOR is the current proposal, but Intel was open to
discussing different formats than CBOR if anyone has a better
* If anyone is not familiar with CBOR, you can get more
information at cbor.io .
* In the coreboot meeting, it was suggested that we push to just use
coreboot tables as they’re already supported in a number of
payloads. This really isn’t practical however. Intel would need
to be able to modify the list of known cbmem IDs and they would
need to be able to change the description format to something
that’s more self-describing.
* The coreboot project can, however, encapsulate a CBOR-based
handoff-structure into cbmem, similar to what we currently do with
* Additionally Intel was willing to look at using CBOR structures as
input and output to the FSP, so we could get rid of both the UPDs
* The coreboot community can help to drive this, and Intel has said
that they will send an email to the coreboot mailing list.
* Since this is a part of the Universal-Scalable-Firmware
initiative, it would be good to look that over for issues as well.
Currently, it’s very Intel oriented, and specifies that the FSP
will be used as the silicon initialization layer, which obviously
doesn’t work for non-x86 platforms.
* The details for the weekly meeting are below.
* Self Describing Blob discussion.
A copy of this meeting has been added to the coreboot calendar .
Biweekly on Monday, 4:00 – 5:00pm CET/CEST Berlin (Currently UTC+2)
Video call link: https://meet.google.com/gha-shza-wnw
Or dial: (DE) +49 30 300195187 PIN: 848 847 031#
More phone numbers: https://tel.meet/gha-shza-wnw?pin=2380921555764
Self Describing Blob discussion Meeting minutes .
* Sean Rhodes from StarLabs has worked to get all of the coreboot
related EDK2 patches submitted to their repo. These are still
currently in review.
Hi all Coreboot folks,
I'm a first year graduate student in CS, been hanging around on
#coreboot IRC (Libera.Chat server) and was thinking if it was possible
or not to port Coreboot to a Thinkpad T495 (AMD Ryzen 7 3700U PRO) 
manufactured in May 2019, I successfully dumped the BIOS using flashrom
internally, see `flashrom_info.log` and 'flashrom_info.err.log`.
It is unclear if there is any AMD protection that does the same as Intel
BootGuard on Ryzen 3rd gen (there is for sure this  since the 1st gen
of Ryzen which is the equivalent to Intel Management Engine).
AMD has a whitepaper stating that from Ryzen 5000s mobile generation
, AMD PSB (Platform Secure Boot) is activated, and it looks like kind
of the same as Intel BootGuard if I'm not mistaken here.
I know so far that the BIOS SPI chip is operating at 1.8v, and is a
Winbond flash chip "W25Q128.W" (16384 kB, SPI), will be useful in case I
need to externally flash the SPI ROM to unbrick the laptop.
I still have to :
- Test whether there is a protection that checks if the firmware was
changed or not by patching the original bios ROM, I was told for this to
change a copyright string or changing the logo :
- it is a gif file and has a sha2-256 signature in its properties,
which isn't the sha256sum of the file.
- I've attached the `identify -verbose logo.gif` output) and trying
to boot could allow checking for any tamper protection on the ROM flash
(bricking intentionally the device if there is).
- Understand if the EC RAM is something I can make out of or not (so far
there is a lot of FF and 00 in it, the last line shows the version of
the embedded firmware), so far I'm not too sure I can make sense of it
- Get the model of the EC and try to find datasheets online.
I have at my disposal:
- A kind of cheap 16 channel logic analyzer  with a software
available on Linux/Windows with a few decoders for most known serial
protocols such as SMBUS, I2C, SPI and more.
- Raspberry Pi 3 model B+ (will be used as an external programmer, but I
still need to find out how I could pull down the power to 1.8v since the
VCC is 3.3v).
- SOIC clip 8 pins (will be delivered to me in 2 weeks), I took the best
one from this guide .
- A cheap multimeter with basic probes, capable of continuity test.
And possibly more such as FPGAs by going to hackerspaces in my vicinity.
I have built Coreboot for qemu with the Seabios payload as the
documentation for GSoC recommended, see coreboot-serial.log output
attached as a text file.
In the case where there is indeed a protection, maybe a solution could
be found by using a flash emulator (spispy ?)  but I need more
details on this.
I am also aware that a complete port will not be feasible under the time
period of GSoC hence I need to know what should be the basics that needs
to be covered for a Coreboot port to be considered minimally working
first ? USB should work ? Charging is made using a USB-C port, this
might be partly handled by the EC Embedded Controller.
Finally, if nothing could be done on this Thinkpad because it is too
recent, I also have an older Intel Thinkpad a T450, that has Intel
BootGuard but that I'm looking try to port Coreboot to it too, using a
flash emulator and possibly this attack .
Thanks for the time taken to read this lengthy mail, I hope the goal of
this mail is clear.
Recently I have decided to give a try to coreboot for first time and
flashed my ThinkPad T420, but a few weeks ago I have swapped the USB
controller on the back, next to the battery, with a FireWire/USB controller
(40GAB5809-G200) from another T420. Nothing special, since some models have
been shipped like this. The controller is no longer accessible on my laptop.
It seems like it may have been detected as an "SD Host Controller" or not
detected at all. I will probably have to remove the chip and compare the
output of lspci and lshw. If nothing has changed, I will probably have to
return the stock BIOS and compare the results again. I have also tried to
load some of the firewire kernel modules manually with modprobe.
The operating systems I have tested so far are Arch Linux and Xubuntu. I am
willing to provide more useful information, boot into a fresh Windows
install, flash the chip again or whatever else. Correct me if I am wrong,
but if I go back to the stock BIOS, the next time I flash, I will have to
disassemble the laptop again and otherwise I must be fine with flashing
the openpower have created this new firmware for boot openpower platforms
is possible to coreboot use this base to write a new code for best support
in openpower socs?