Dear coreboot community,
Please be reminded that our upcoming leadership meeting is on Wednesday, June 26.[1]
You are welcome to review and update the current agenda items with any matters you wish to see
discussed during the meeting.[2]
Below are the items currently on the agenda.
## Current Agenda Items
## Improving coreboot processes
### [Martin] bi-weekly review meetings
* In an attempt to get patches merged more quickly, we’re looking at adding a meeting to review
patches and try to get blocking issues sorted out. This will start as a bi-weekly meeting of 1 hour
and we’ll see where things progress from there.
Any preference for Tues/Wed/Thurs? 16:00, 17:00, or 18:00 UTC? (should we define it in UTC or in
some other time zone that may switch based on daylight savings?)
### [Martin] Merge SLOs
* Can we define objectives for timeframes to get patches merged to different areas in the codebase?
An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform.
### [Karthik] RFC - Extend Coreboot FileSystem to disk
* [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tU….
## Announcements & Events
* FOSSY conference: August 1-4 2024 in Portland, Oregon, USA
https://sfconservancy.org/fossy
* COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04
https://coscup.org/2024/en/landing
* OSFC will be in Bochum Germany - September 3-5, 2024
https://www.osfc.io
* OCP Global Summit: San Jose, California on October 15–17, 2024
https://www.opencompute.org/summit/global-summit
[1](https://www.coreboot.org/calendar.html).
[2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….
Issue #534 has been updated by Mahesh Kilumu.
% Done changed from 0 to 100
----------------------------------------
Support #534: Enable Ethernet (LAN) on ADL-P Custom Board
https://ticket.coreboot.org/issues/534#change-1865
* Author: Mahesh Kilumu
* Status: New
* Priority: Normal
* Target version: 4.21
* Start date: 2024-03-21
----------------------------------------
Hi, With respect to the Alderlake-P RVP platform designed Custom Board.
i have been trying to implement the Ethernet(LAN) on my Custom Board. on RVP intel team used GBE PHY but on my custom board we have used the External Realtek RTL8111H controller over PCIe Root port7 for Ethernet.
Below are the configuration details:
1) Devicetree.cb:
device ref pcie_rp7 on end
# Enable PCH PCIE RP 7 using CLK 6
register "pch_pcie_rp[PCH_RP(7)]" = "{
.clk_src = 6,
.clk_req = 6,
.flags = PCIE_CLK_LAN
}"
2) gpio.c:
/* 19: PCIE SRCCLKREQ6- same as RVP */
PAD_CFG_NF(GPP_F19, NONE, DEEP, NF1),
/* 2: GPD_2_LAN_WAKE_N- same as RVP*/
PAD_CFG_NF(GPD2, NONE, DEEP, NF1),
/* 21 : LAN_ISOLATE# -New Implementation */
PAD_CFG_GPO(GPP_A21, 1, DEEP),
from the logs observed that,
Root port got enabled ->> [SPEW ] PCI: 00:00:1c.6: enabled 1
But observed the few Error & warnings in the log with respect to the above configuration
[WARN ] Missing root port clock structure definition
[ERROR] PCI: 00:00:1c.6 missing read_resources
full log details :
https://pastebin.com/zWcsEZvL
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #276 has been updated by Arthur Heymans.
config SMM_MODULE_STACK_SIZE
hex
default 0x800 if ARCH_RAMSTAGE_X86_64
default 0x400
So just bumping this to always use 0x800 might be a solution
----------------------------------------
Bug #276: SPI flash console output causes `SMM Handler caused a stack overflow`
https://ticket.coreboot.org/issues/276#change-1864
* Author: Paul Menzel
* Status: New
* Priority: Normal
* Start date: 2020-07-19
----------------------------------------
On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow:
```
FMAP: area COREBOOT found @ 60200 (1703424 bytes)
CBFS: Locating 'fallback/dsdt.aml'
CBFS: Found @ offset 39300 size 3138
FMAP: area COREBOOT found @ 60200 (1703424 bytes)
CBFS: Locating 'fallback/slic'
CBFS: 'fallback/slic' not found.
ACPI: Writing ACPI tables at bfb51000.
ACPI: * FACS
ACPI: * DSDT
FMAP: area CONSOLE found @ 0 (131072 bytes)
coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)...
canary 0x0 != 0xbfeffc00
SMM Handler caused a stack overflow
```
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #276 has been updated by Filip Lewiński.
Paul Menzel wrote:
> On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow:
>
> ```
> FMAP: area COREBOOT found @ 60200 (1703424 bytes)
> CBFS: Locating 'fallback/dsdt.aml'
> CBFS: Found @ offset 39300 size 3138
> FMAP: area COREBOOT found @ 60200 (1703424 bytes)
> CBFS: Locating 'fallback/slic'
> CBFS: 'fallback/slic' not found.
> ACPI: Writing ACPI tables at bfb51000.
> ACPI: * FACS
> ACPI: * DSDT
> FMAP: area CONSOLE found @ 0 (131072 bytes)
>
>
> coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)...
> canary 0x0 != 0xbfeffc00
> SMM Handler caused a stack overflow
> ```
I've experienced the same with coreboot+EDK2(MrChromeBox) on a Thinkpad T400. If you still have trouble booting the platform, I've somehow managed to bypass it by rebuilding with 64bit mode enabled.
----------------------------------------
Bug #276: SPI flash console output causes `SMM Handler caused a stack overflow`
https://ticket.coreboot.org/issues/276#change-1863
* Author: Paul Menzel
* Status: New
* Priority: Normal
* Start date: 2020-07-19
----------------------------------------
On the Lenovo T60 (Type 2007 with dedicated ATI/AMD graphics device), coreboot built with *SPI Flash console output* (`CONFIG_CONSOLE_SPI_FLASH=y`) fails to boot due to a stack overflow:
```
FMAP: area COREBOOT found @ 60200 (1703424 bytes)
CBFS: Locating 'fallback/dsdt.aml'
CBFS: Found @ offset 39300 size 3138
FMAP: area COREBOOT found @ 60200 (1703424 bytes)
CBFS: Locating 'fallback/slic'
CBFS: 'fallback/slic' not found.
ACPI: Writing ACPI tables at bfb51000.
ACPI: * FACS
ACPI: * DSDT
FMAP: area CONSOLE found @ 0 (131072 bytes)
coreboot-4.12-1529-gaba8103093 Sun Jul 19 07:24:18 UTC 2020 smm starting (log level: 7)...
canary 0x0 != 0xbfeffc00
SMM Handler caused a stack overflow
```
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Dear coreboot folks,
I noticed commit 5d1494adda44 (mb/system76/tgl: Update VBTs to version
250) [1]:
> mb/system76/tgl: Update VBTs to version 250
>
> Commit 4c7e97b26a34 ("Update fsp submodule to upstream master branch")
> included an update to the VBT from 240 to 250, breaking parsing of
> existing VBTs.
>
> After that commit, the VBT was parsed as (from gaze16-3060-b):
>
> [DEBUG] PCI: 00:02.0 init
> [INFO ] GMA: Found VBT in CBFS
> [INFO ] GMA: Found valid VBT in CBFS
> [INFO ] framebuffer_info: bytes_per_line: 4096, bits_per_pixel: 32
> [INFO ] x_res x y_res: 1024 x 768, size: 3145728 at 0xd0000000
> [DEBUG] PCI: 00:02.0 init finished in 6 msecs
>
> When the expected output is:
>
> [DEBUG] PCI: 00:00:02.0 init
> [INFO ] GMA: Found VBT in CBFS
> [INFO ] GMA: Found valid VBT in CBFS
> [INFO ] framebuffer_info: bytes_per_line: 7680, bits_per_pixel: 32
> [INFO ] x_res x y_res: 1920 x 1080, size: 8294400 at 0xd0000000
> [DEBUG] PCI: 00:00:02.0 init finished in 6 msecs
>
> Generate blobs for the new version using Intel Display Configuration
> Tool (DisCon) v3.3, based on the existing 237 and 240 VBTs.
>
> (For our edk2 payload, the UEFI GOP driver was updated to 17.0.1077.)
Updating the submodule pointer of 3rdparty/fsp brings in commit
849ce8261bb0 (Tiger Lake FSP A.0.7E.70) with no commit message body. The
diff contains:
TigerLakeFspBinPkg/Client/SampleCode/Vbt/Vbt.json
@@ -23891,7 +24584,7 @@
},
{
"WidgetType": "Label",
- "WidgetName": "VBT Version: 240",
+ "WidgetName": "VBT Version: 250",^M
"Visibility": "",
"Data": [],
"HelpText": "",
Vladimir (φ-coder) also published the tool intelvbtupgrader [2] to
address this problem.
I would have assumed that FSP versions would be backwards compatible. I
attache the output of `intel_vbt_decode` of both VBT files.
Does somebody have more insight?
Kind regards,
Paul
[1]: https://review.coreboot.org/c/coreboot/+/82246
[2]: https://review.coreboot.org/c/coreboot/+/82722
As coreboot changed its version numbering to a YYMM scheme earlier this
year, MrChromebox releases will now do the same.
This new release is based on the coreboot 24.05 tag (May 2024) and now
supports well over 300 different devices. It includes the following notable
changes:
- Rebased on coreboot tag 24.05
- Added support for several new Intel Jasperlake boards (beadrix, boxy,
dexi, peezer, taranza)
- Added latest Google-built EC-RW updates for all Jasperlake boards
- Updated the EC-RW firmware for Fizz boards (Intel 7th/8th-gen Chromeboxes)
- Updated the EC-RW firmware for Zork boards (AMD Picasso)
- Updated the signed PSP verstage binaries for Zork/Guybrush boards (AMD
Picasso, Cezanne)
- Updated EC-RW software update code for improved compatibility
- Fixed SMBUS subsystem ID on several Sandy/Ivybridge Chromebooks
- Increased the UMA VRAM to 128MB on Zork boards (AMD Picasso boards)
- Filtered out some spurious error messages in the coreboot console log
All source code (and blobs) for coreboot, edk2, and Chrome-EC can be found
on my github repos:
https://github.com/MrChromebox/coreboot/commits/MrChromebox-2405https://github.com/MrChromebox/edk2/commits/uefipayload_2402https://github.com/MrChromebox/chrome-ec/branches/allhttps://github.com/MrChromebox/blobs/
For device compatibility and installation, see https://mrchromebox.tech
cheers,
Matt
# 2024-06-12 - coreboot Leadership Meeting
## Attendees
Werner Zeh, Matt DeVillier, David Hendricks, Mina Asante, Jonathan Hall, Martin Roth, Felix Singer,
Felix Held, Nico Huber, Jay Talbott, Rhys Perry, Karthik Ramasubramanian, Shelley Chen, Nicholas
Chin, Ron Minnich, Mike Banon, Julius Werner, Marshall Dawson.
## Announcements & Events
* FOSSY conference: August 1-4 2024 in Portland, Oregon, USA
https://sfconservancy.org/fossy
* COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04
https://coscup.org/2024/en/landing
* OSFC will be in Bochum Germany - September 3-5
https://www.osfc.io
* OCP Global Summit: San Jose, California on October 15–17, 2024
https://www.opencompute.org/summit/global-summit
## Open Action Items
* 2024-05-01
* Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?)
* 2024-03-20
* Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and
guidance when code submissions are not up to standard.
* 2024-03-06
* Martin: To update gerrit contributing guidelines documentation.
(https://doc.coreboot.org/contributing/index.html)
* 2024-01-10
* Nico: [https://review.coreboot.org/q/topic:enforce_region_api]
* Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project.
## Minutes
### [Felix S/Martin] We’ve got a OSFF booth accepted for [FOSSY conference](https://sfconservancy.org/fossy)
* 1st - 4th August
* Looking for volunteers to help with the booth.
* Please reach out to FelixS or Martin if you’re interested. We might be able to help out some with
travel or hotel costs.
### [Martin] Infrastructure
* We need additional people to help with coreboot infra.
* Using NixOS for the base OS
* Docker images for gerrit, jenkins, other services.
* Reach out to coreboot leadership if interested.
* Felix will be the infra lead, but if we can’t find people in the community, we may need to hire
someone (some company) to help with this.
* Obviously this will cost the project cash
* [MattD] We need a backstop, even if we have volunteers, so hiring a company would probably be good anyway.
* If any or our contract companies have recommendations, please suggest good companies.
### [Elyes] Add lint rule to avoid duplicated includes.
* I’ve added some lint rules to warn when a header is duplicated through another header which is supposed to provide it.
(see [https://review.coreboot.org/c/coreboot/+/81907]) The rules I’ve used are those in:
``Documentation/contributing/coding_style.md``
As per Nico’s comments, we need some rules (if this is something we want to do.)
* Headers can still be included in other header files.
* [Martin]: This is (or should be) just enforcing what’s already documented in the coding style document.
If this is a bad idea, let’s remove it from the coding style and not have a conflict
between what we’re willing to enforce and the coding style guide.
* [Nico]: This could make updating headers more difficult.
* [Ron]: This seems like a slippery slope - do we want to alphabetize the header list? Christmas tree header list.
* Those aren’t how we do things here. No required alphabetization or other styles for headers.
* [David]: IWYU may make things fragile. Good in theory, if it's easy and reliable to use/enforce
then we should do it.
* [Julius]: The coding style wastes reviewers time. Do we really need to worry about this?
* [Martin]: This patch would fix that.
* [Nico]: Do we want to just prohibit bulk cleanups?
* [Martin]: Does that mean we should get rid of the coding style? If we’re not going to enforce it, why have it?
* [Nico]: it’s good for new users.
* [FelixS]: could IWYU be used instead of self-written scripts to supply suggestions?
* [David]: Maybe we should roll this out slowly before enforcing it. Hopefully this won’t introduce a bunch of Diffs.
* The work is already done, so let’s prevent new style violations from going in.
* [Martin]: Can we agree that we can submit this and if it causes issues we can roll it back?
* [David]: We shouldn’t block it unless we can articulate exactly why it’s a problem. Let’s think
about it for a week and if there aren’t any explicit issues, then let’s merge it.
### [Yidi Lin] [Do we consider GPIO ball names definitions in <soc/gpio.h> as part of
<gpio.h>](https://review.coreboot.org/c/coreboot/+/82813/1/src/mainboard/google/kukui/gpio.h) ?
* This is related to the above header issue.
* Listed in the style guide as an example
* [Nico]: These two gpio headers aren’t really the same thing. One is hardware, the other is the general function headers.
* [Matt]: Does the main GPIO.h automatically include soc/gpio.h?
* Felix: Yes, and includes the IWYU annotation that it should be supplied.
* [Matt]: As long as we’re being consistent across the codebase, it should be fine. It looks like
we’re normally including soc/gpio.h in mainboards. There are currently 364 instances of that - so
let’s not change it to comply with the style guide. Let’s update the style guide and update the
patch.
* [Julius]: Let’s just leave things as they are and not do bulk updates.
* [Jonathan]: This seems like a misinterpretation of the style guide - it’s saying that you don’t
need to include both. It doesn’t seem to say that you should use gpio.h instead. Let’s edit the style guide to clarify this.
* **Decision**: Let’s just edit the style guide for clarity and not force inclusion. That means
that we’d drop these patches (unless the board owner prefers it.)
### [Felix H] Usage of LLM outputs making the commit messages bad
* I’ve seen commit messages (patchset 2 of 82871, 82872) that look very much like output from some
LLM that say little in much text and I’d very much prefer that we keep commit messages concise, so
I’d like to discuss if we want to allow usage of LLM output and if so how we should make sure to
mainly get possible advantages of that but keep the disadvantages to a minimum
* [Martin] Yes, I think we want to allow the output from LLMs in patch descriptions, in fact I was
just talking about creating some automation to generate a description of the patch that could be
(optionally) used to update the commit message. People who are less fluent in English could really
benefit from this.
* [Martin]: Let’s just say that commit messages should be concise and related to the patch.
### [Karthik] RFC - Extend Coreboot FileSystem to disk
* [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tU…
Look at the document for reasoning. Please review it and make comments.
* [Martin]: I kind of hate the idea of loading firmware from the drive for stages before the
payload - this feels like a slippery slope and that next we’re going to need network drivers in
coreboot to support loading the firmware over the network. Payload can do what it wants.
* [David]: This sort of thing is pretty normal in the non-x86 world.
* [Werner]: The mass storage device is really owned by the OS. If the firmware is on the drive, we
could break the boot when the drive is formatted or replaced.
* [Karthik]: only boot critical components would be moved to the disk.
* [Martin/Felix]: This seems like a large security hole - your system can be owned from the boot firmware instead of just the OS.
* [Julius]: This is just extending cbfs to the disk and not a part of an OS file system. This is
mainly intended for CSME update. This would be only Ramstage or later and would be optional.
* [Werner]: Requires adding mass storage devices. Allows coreboot to read the entire disk. How does that affect security?
* [David]: Let’s assume that Google didn't screw up their implementation, and focus on how this
would fit into upstream or if it should be blocked. It seems like it could be an advantage for cost
savings (as Julius points out) by making it so laptop vendors don't need a huge flash chip for things like CSME binaries.
* [Martin]: This needs further discussion, so please review the document and make comments there.
In general I feel like if something is needed by some coreboot users, we should try to be accepting
of their needs (assuming that it’s not adding additional binary blobs.
# Next Leadership Meeting
* June 26,2024.
* [coreboot Calendar](https://coreboot.org/calendar.html).
# Notice
* Decisions shown here are not necessarily final, and are based
on the current information available. If there are questions or comments
about decisions made, or additional information to present, please put
it on the leadership meeting agenda and show up if possible to discuss it.
Of course items may also be discussed on the mailing list, but as it's
difficult to interpret tone over email, controversial topics frequently
do not have good progress in those discussions. For particularly
difficult issues, it may be best to try to schedule another meeting.
# coreboot leadership meeting minutes
*[2024-06-12](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?p1).
Issue #121 has been updated by Patrick Rudolph.
> I tried booting with kernel command line parameter idle=nomwait.
That should make the OS use the `hlt` instruction instead of `mwait`, which is similar to package C1-state.
When using `powertop` or similar tools it should show how much time it spends in specific C-states.
I would expect it to draw a bit more power, but probably just ~1Watt.
> not in my case (t520i, i7-3840qm) - its almost as if the freezes are more frequent with this option 🤷
I would also expect it to not freeze any more, since C1-states where reported to be working fine. Quote:
> As an update to the above, intel_idle.max_cstate=3 was not stable but intel_idle.max_cstate=2 was and I haven't had any crashes in about a month.
----------------------------------------
Bug #121: T520: Hangs in OS
https://ticket.coreboot.org/issues/121#change-1860
* Author: Firstname Lastname
* Status: In Progress
* Priority: Normal
* Category: chipset configuration
* Start date: 2017-06-09
* Affected hardware: SNB, IVY
* Affected OS: -
----------------------------------------
I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors.
Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing.
Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs.
---Files--------------------------------
config (20.7 KB)
dmesg.txt (57.3 KB)
cbmem-raminit.txt (62 KB)
lspci.txt (29.6 KB)
cpuinfo.txt (3.94 KB)
defconfig (1023 Bytes)
defconfig (699 Bytes)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #121 has been updated by Anastasios Koutian.
Alex Gravitos wrote in #note-97:
> Anastasios Koutian wrote in #note-96:
> > I tried booting with kernel command line parameter idle=nomwait.
> > There were no freezes for 1 week, 5 days and 16 hours, which was not possible previously.
> > After this, I powered down and removed the parameter to see what happens. The system froze after 15 hours and 7 minutes.
> > Intel PCM is showing no negative impact on idle power consumption with idle=nomwait.
> > I recommend to people following this bug to try this out and confirm if it works for them.
>
> not in my case (t520i, i7-3840qm) - its almost as if the freezes are more frequent with this option 🤷
That's interesting. I have not seen freezes since adding this option, but it's possible that it's just a coincidence, since this bug is quite random.
----------------------------------------
Bug #121: T520: Hangs in OS
https://ticket.coreboot.org/issues/121#change-1859
* Author: Firstname Lastname
* Status: In Progress
* Priority: Normal
* Category: chipset configuration
* Start date: 2017-06-09
* Affected hardware: SNB, IVY
* Affected OS: -
----------------------------------------
I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors.
Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing.
Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs.
---Files--------------------------------
config (20.7 KB)
dmesg.txt (57.3 KB)
cbmem-raminit.txt (62 KB)
lspci.txt (29.6 KB)
cpuinfo.txt (3.94 KB)
defconfig (1023 Bytes)
defconfig (699 Bytes)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account