The 4.10 release covers commit a2faaa9a2 to commit ae317695e3
There is a pgp signed 4.10 tag in the git repository, and a branch will
be created as needed.
In nearly 8 months since 4.9 we had 198 authors commit 2538 changes
to master. Of these, 85 authors made their first commit to coreboot:
Welcome!
Between the releases the tree grew by about 11000 lines of code plus
5000 lines of comments.
Again, a big Thank You to all contributors who helped shape the coreboot
project, community and code with their effort, no matter if through
development, review, testing, documentation or by helping people asking
questions on our venues like IRC or our mailing list.
What's New
----------
Most of the changes were to mainboards, and on the chipset side, lots
of activity concentrated on x86. However compared to previous releases
activity (and therefore interest, probably) increased in vboot and in
non-x86 architectures. However it's harder this time to give this release
a single topic like the last: This release accumulates some of everything.
Clean Up
--------
As usual, there was a lot of cleaning up going on, and there notably,
a good chunk of this year's Google Summer of Code project to clean out
the issues reported by Coverity Scan is already in.
The only larger scale change that was registered in the pre-release
notes was also about cleaning up the tree:
### `device_t` is no more
coreboot used to have a data type, `device_t` that changed shape depending on
whether it is compiled for romstage (with limited memory) or ramstage (with
unlimited memory as far as coreboot is concerned). It's an old relic from the
time when romstage wasn't operated in Cache-As-RAM mode, but compiled with
our romcc compiler.
That data type is now gone.
Release Notes maintenance
-------------------------
Speaking of pre-release notes: After 4.10 we'll start a document for
4.11 in the git repository. Feel free to add notable achievements there
so we remember to give them a shout out in the next release's notes.
Known Issues
------------
Sadly, Google Cyan is broken in this release. It doesn't work with the
"C environment" bootblock (as compared to the old romcc type bootblock)
which is now the default. Sadly it doesn't help to simply revert that
change because doing so breaks other boards.
If you want to use Google Cyan with the release (or if
you're tracking the master branch), please keep an eye on
https://review.coreboot.org/c/coreboot/+/34304 where a solution for this
issue is sought.
Deprecations
------------
As announced in the 4.9 release notes, there are no deprecations after 4.10.
While 4.10 is also released late and we target a 4.11 release in October we
nonetheless want to announce deprecations this time: These are under
discussion since January, people are working on mitigations for about as long
and so it should be possible to resolve the outstanding issues by the end of
October.
Specifically, we want to require code to work with the following Kconfig
options so we can remove the options and the code they disable:
* C\_ENVIRONMENT\_BOOTBLOCK
* NO\_CAR\_GLOBAL\_MIGRATION
* RELOCATABLE\_RAMSTAGE
These only affect x86. If your platform only works without them, please
look into fixing that.
Added 28 mainboards:
--------------------
* ASROCK H110M-DVS
* ASUS H61M-CS
* ASUS P5G41T-M-LX
* ASUS P5QPL-AM
* ASUS P8Z77-M-PRO
* FACEBOOK FBG1701
* FOXCONN G41M
* GIGABYTE GA-H61MA-D3V
* GOOGLE BLOOG
* GOOGLE FLAPJACK
* GOOGLE GARG
* GOOGLE HATCH-WHL
* GOOGLE HELIOS
* GOOGLE KINDRED
* GOOGLE KODAMA
* GOOGLE KOHAKU
* GOOGLE KRANE
* GOOGLE MISTRAL
* HP COMPAQ-8200-ELITE-SFF-PC
* INTEL COMETLAKE-RVP
* INTEL KBLRVP11
* LENOVO R500
* LENOVO X1
* MSI MS7707
* PORTWELL M107
* PURISM LIBREM13-V4
* PURISM LIBREM15-V4
* SUPERMICRO X10SLM-PLUS-F
* UP SQUARED
Removed 7 mainboards:
---------------------
* GOOGLE BIP
* GOOGLE DELAN
* GOOGLE ROWAN
* PCENGINES ALIX1C
* PCENGINES ALIX2C
* PCENGINES ALIX2D
* PCENGINES ALIX6
Removed 3 processors:
---------------------
* src/cpu/amd/geode\_lx
* src/cpu/intel/model\_69x
* src/cpu/intel/model\_6dx
Added 2 socs:
-------------
* src/soc/amd/picasso
* src/soc/qualcomm/qcs405
Toolchain
---------
* Update to gcc 8.3.0, binutils 2.32, IASL 20190509, clang 8
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Hi everybody,
I'm _really_ late with the 4.10 release and I'm sorry. Too much other
things intervened and then there were a few issues on a couple of targets
that were close to being fixed.
While we don't provide any guarantees for our releases, they're still a
good opportunity to try to wrap things up. I tested the commit in question
on all QEmu targets and on Getac/P470, and it's looking reasonable.
So in the light of getting things out, I prepared the release notes and
pushed them to https://review.coreboot.org/c/coreboot/+/34469. Please
take a look and comment if there's anything missing.
I plan to put up the release on Monday evening European time (Monday morning
in the US, early Tuesday in Asia).
Thanks,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Hello!
I wanted to share my experiences with corebooting the X131e (Intel edition) and
hope to be able to resolve some of the remaining issues. Previously I used a
corebooted X131e Chromebook (Stout) and it worked perfectly - I didn't have any
of the issues, which I'm going to detail further down. I got the X131e Intel as
an "upgrade" and because I thought that migrating would be trivial. I'm using
the same peripherals with the Intel boards, but installed new RAM.
Turns out the stock BIOS had hardware whitelists, so that was a good pretext to
try out coreboot.
I based my build on the 4.9 release but ended up applying some X131e patches by
James Ye, which are still pending in Gerrit. The following changes on top of 4.9
to be precise:
commit b21539d2c4f57518b964949b30ebdd200a8d1f5a
Author: James Ye <jye836(a)gmail.com>
Date: Thu Jan 24 00:18:28 2019 +1100
mb/lenovo/x131e: add function key support
Enables function keys for X131e.
SMI handler based on google/stout. ACPI code and event masks are
reverse-engineered.
The IT8518e EC of this board uses some different ACPI methods compared to the
regular Lenovo H8. Add an option to use the alternative set of methods.
Change-Id: Ib3a01f37a8b54889b55e92c501c9350e6c68bd57
commit 178cf723697b9d069810fd404dcabd448d136503
Author: James Ye <jye836(a)gmail.com>
Date: Fri Feb 1 13:29:02 2019 +1100
mb/lenovo/x131e: correct USB port config
Based on schematic and register dumps.
Change-Id: I91fc47022988cfe986fb8c1ed21dc073ee7d16bc
commit 750432f7a1487175243065d95c57f9e0e6c21204
Author: James Ye <jye836(a)gmail.com>
Date: Tue Feb 12 22:17:52 2019 +1100
mb/lenovo/x131e: enable mSATA slot
Per google/stout. Functionality untested.
Change-Id: I7cc9837f572236acac2007e95990e64c25a5d6e2
commit 151019a9d21c612834dacad649cde7aec3132844
Author: James Ye <jye836(a)gmail.com>
Date: Sat Jan 19 18:25:44 2019 +1100
mb/lenovo/x131e: enable WWAN detection
Per schematic. Non-presence is detected correctly, but presence is untested.
Change-Id: I4cfefb06556c9d69bc8e4a4f9d112246885c253a
commit 5bdb3cd2a802b0654feeeb19471c719db62a23c4
Author: James Ye <jye836(a)gmail.com>
Date: Sat Jan 19 18:25:04 2019 +1100
mb/lenovo/x131e: remove PMH7
This board does not have PMH7.
Change-Id: I382958f012e5f4445efc76c7f36bbdf460c29be4
commit 1cd0a5920fb93489aa1fe5b1c0be6170f88f23da
Author: James Ye <jye836(a)gmail.com>
Date: Thu Jan 17 22:00:14 2019 +1100
mb/lenovo/x131e: add VBT
VBT was extracted from VBIOS ROM.
Tested with libgfxinit, booting SeaBIOS into Linux.
Change-Id: Ibedb43852dc9b846850e1070b84f708c847b7dbf
Here's the board-status report:
https://coreboot.org/status/board-status.html#lenovo/x131e
The EC is probably rather old, as I didn't do a BIOS upgrade before flashing
coreboot. If possible, I'd like to avoid upgrading the EC now, as that would
require extracting it from the Lenove BIOS and programming it externally. Isn't it?
Now regarding the remaining issues, in order of significance (for me):
1.) There are infrequent system freezes - possibly a kernel panic? - without any
visible reason in the system journal. Unfortunately, I haven't run the board
long enough on the original BIOS to judge whether this is Coreboot-specific.
At least I tried performing some SMART and memtest86 tests - to no avail.
2.) At some point during my experimenting, only 4 of the 8GB RAM I've installed
would be detected. This wasn't the case in the beginning, when I started out
with a clean 4.9-build. I've attached a board status report from this time.
Maybe somebody can see why the 2nd 4GB module is no longer detected.
Naturally, one of the commits I later added might be responsible. If really
necessary, I could do a git-dissect.
3.) The internal speakers __sometimes__ don't work after startup. They are
simply mute. I initially thought this depends on the headphones being plugged in
at boot, but there is no causal relation.
None of the thinkpad_acpi-kernel-modules' `volume_*` params have any effect.
Changing the settings of the enigmatic "ThinkPad Console Audio Control" sound
card (created if volume_mode != 2 (N/A)) does not have any audible effect at all
- even while headphones are working.
Rerouting pins with hdajackretask does not help.
Comparing Linux kernel logs (dmesg) does not yield any difference between
working and non-working boots in the output of the relevant audio drivers.
4.) My 1600Mhz DDR3 RAM supposedly runs at 666Mhz (dmidecode --type 17).
I think it's running at 1330 MHz, though. I somewhere read that 1600 Mhz CL11 is
equivalent to 1300 Mhz CL9, which could explain this.
So I guess, I simply bought crappy RAM.
5.) The Fn-keys work after the corresponding patch. But is it possible to use
the Fn-key like any other (modifier) key? I do not get separate key-down/release
events and events for any other key-presses (except for a few that have assigned
Fn-functions). That's a bit of a waste. I guess, this is an EC "feature"...
6.) I have a WWAN mPCI card (Sierra 7710). It used to be reported as
always-hard-blocked (rfkill list).
WWAN was enabled in NVRAM. All of these (WIFI, Bluethooth, WWAN)
Enable-NVRAM-settings have no effect on the hard-block state of any of the
corresponding devices, though.
thinkpad_acpi reads these values from the EC via ACPI as far as I could follow
the sources. So I conclude that this is probably a Coreboot-EC-communication
problem!? h8_wwan_enable() probably has no effect on this board.
The infamous trick of taping the miniPCI pin 20 did not help either in
unblocking the card. Neither did disabling power-off mode per AT commands on the
modem.
Turned out however that the card wasn't really physically blocked, as scanning
would still work via modem-manager-gui.
thinkpad_acpi simply reported it as blocked, which is probably what rfkill
reported as well.
So I was able to work around this issue with the following module params (e.g.
store as /etc/modprobe.d/thinkpad_acpi.conf):
options thinkpad_acpi dbg_wwanemul=1 wwan_state=1 dbg_wlswemul=1 wlsw_state=1
(Interestingly `dbg_wwanemul` seems to have no effect.)
The modem now appears to work.
7.) The internal PS2 keyboard does not work in some secondary payloads (eg.
nvramcui). Only USB-keyboards do. That's a bit annoying in a notebook,
especially since...
8.) nvramtool crashes. Is that known and fixed, or would you like a core dump?
Needless to mention that I enabled CONFIG_USE_OPTION_TABLE and nvramcui also
generally works.
9.) Waking up from sleep-mode does not work. I haven't investigated this
thoroughly and I haven't tested hibernation. Quite possibly an OS issue.
10.) Maybe off-topic, but relevant for anybody trying to coreboot this board:
flashrom had to be patched in order to work with the flash chip.
Turns out the probing/identification command would not be answered correctly by
the chip (found out after attaching a logic analyzer), even though I checked
against the datasheet. Didn't dive into this question too deeply but simply
worked around it by letting flashrom skip the probing.
Flashing externally is quite unreliable, and needs to be repeated often until a
complete image would be flashed.
This could be because of long and crappy wires, though. Internal flashing does
currently not work.
In a related matter: There is zero documentation on how to coreboot this board
in the entire internet AFAIK. That's a bit sad, as it significantly decreases
its possible audience and might also result in the port dying once the initial
maintainer looses interest. Maybe including documentation should be made
mandatory for every new port?
I can also confirm that the WWAN detection
(I4cfefb06556c9d69bc8e4a4f9d112246885c253a) works for detecting a card's
presence as well.
Any ideas, especially on how to proceed with 1.) and 2.)?
Best regards,
Robin
Yes its sandy bridge. What is proper way to do this though. On flash descriptor (and if so, how?) or through coreboot option?
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, July 15, 2019 12:37 AM, werner.zeh(a)siemens.com <werner.zeh(a)siemens.com> wrote:
> IIRC X220 uses Sandy Bridge. I think there is a flag somewhere in the descriptor where you can lock down your BIOS-region as read-only for the x86 host.
> I never have tried it but in theory this should lead to errors on every write attempt to the BIOS region therefore disabling write access to the flash from OS/flashrom.
>
> Werner
Hi all,
Have a few patchsets waiting for review related to vendor implementation of 'verified boot' and 'measure boot'.
This implementation is working/booting on Facebook FBG1701 (Intel Braswell), but not chipset related.
Anyone have time for review.
Thanks in advance.
Met vriendelijke groet / Best regards,
Frans Hendriks
www.eltan.com