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 [1]).
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:
https://openletter.earth/request-for-opening-the-source-code-for-the-pse-on-
elkhart-lake-26bad82a
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
Werner
[1] <https://review.coreboot.org/c/coreboot/+/55367>
https://review.coreboot.org/c/coreboot/+/55367
Hello coreboot community,
For our work on POWER9 coreboot port we were using Skiboot [1] 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 [2], 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 [3] are used to initialize output region sizes [4]
and those are then passed to decompressors [5]. Only FDT has a workaround
to this problem [6], and kernel's size is calculated in an arm64-specific
way in [7]. On other architectures components (other than FDT) are
partially decompressed until they run of of space, silently ignoring the
rest.
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
in RAM.
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 [8] 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.
[1] https://github.com/open-power/skiboot
[2] https://doc.coreboot.org/lib/payloads/fit.html#supported-compression
[3]
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr…
[4]
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr…
[5]
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr…
[6]
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr…
[7]
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr…
[8] https://github.com/open-power/hostboot
--
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com
Hello,
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
internally, right?
Thanks
Hi all,
I wanted to work on below ticket
https://ticket.coreboot.org/issues/184
Is there anyone working on it.
Any inputs/hints would be appreciated.
--sameer.
Hello everyone,
I hope you're doing fine
I would like to do some trials to see if I may be able to support few boards I have cause they are aftermarket withoout EFI and without firmware updates and not working as I would like them to.
(https://askubuntu.com/questions/1370496/cant-boot-latests-lives-for-install…)
I really would not like to throw them...
They are X58 chipset with ICH10 with Xeon Westmere on socket 1366 and SuperIO NCT5532D.
(https://www.intel.com/content/dam/doc/datasheet/x58-express-chipset-datashe…)
(https://www.intel.com/content/dam/doc/datasheet/io-controller-hub-10-family…)
(https://datasheetspdf.com/pdf-file/1042365/novoTon/NCT5532D/1)
I have the tooling to backup and restore the flash and already done that few time.
I have built latest coreboot (4.14 using lenovo x201 config) with EDK2 firmware as payload (edk2-stable202108 NOOPT) successfully but nothing is happening after flash swap and power on.
I have RS232 debug working at ttyS0 (at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A)
From the original firmware, just after power on, even before any bip or display or keyboard light I see "Socket = 0" on serial, so the the original firmware is able to output to this serial very early.
I read quite a lot of literature about coreboot, but still, I am not sure how to pursue now.
Thanks in advance,
Have a nice day,
Best Regards,
Mickaël.
Hi everyone,
As you may recall, coreboot has now gone to a quarterly release
cadence. That means that it's now time for the 4.16 release, which
will happen around the weekend of Feb 12.
If there's anything significant that you want to get in before the
next release is done, please do that in the next week or so.
I'll be asking for people to test any boards that they have available
after the release is done, but it'd be very useful to test them now,
before the release so that anything that's broken can be fixed before
the release is finalized.
Current stats since the 4.15 release:
- Total Commits: 1266
- Average Commits per day: 15.09
- Total lines added: 302355
- Average lines added per commit: 238.83
- Total lines removed: 25937
- Total difference between added and removed: 276418
Static analysis:
Our Coverity build has unfortunately been down for a bit as the build
time went past its limit of 10 hours. The next build will run
tonight, and the limit has been extended to allow for even longer
build times.
In addition to Coverity, we also run LLVM's Scan-build tool on every
platform several times a week. You can see that scan information for
each platform at https://www.coreboot.org/scan-build/
Thanks!
Martin
Hi,
*Supplement:
I've noticed that the name of the USB stick is a Linux distribution so I assume I wrote a .iso or .img to it in the past what possibly changed partitions and/or file formats. How can I restore the stick back to "normal" with Ubuntu?*
while copying the coreboot/SeaBIOS installation (folder coreboot) to a USB stick I got the following error message:
Error with copying of >>usb_tcpm_v2_rev30_fuzz.c<<.
With copying of the file to ... /coreboot/3rdparty/-chromeec/fuzz an error occurred.
The file system doesn't support symbolic links
Cancel | Skip all | Skip
What can I do?
Regards,
Bernd
Hi All,
Trying to pass data between EFI Payload and coreboot, my use case is
when a setup token is enabled, the data should be read by coreboot and
change the DEBUG options in coreboot
In EFI Payload values in PcdDebugPropertyMask can be toggled to ON/OFFit
Please shed some light onto it
Thanks
Rao
Hello dear team of Coreboot I tried to install CoreBoot with SeaBios on
my T440p with dGPU but I can not get the graphics card to show up and
when installing Arch also always come errors can you help me please?
Best Regards
