coreboot October 2023

coreboot@coreboot.org

29 participants
43 discussions

coreboot Leadership Meeting
by mina＠coreboot.org 16 Oct '23

16 Oct '23

Dear coreboot Community, We are pleased to announce the upcoming coreboot leadership meeting scheduled for October 18, 2023[1]. Please add things you wish to see addressed during the meeting to the agenda[2]. # Current Agenda Items *[Martin] OSFC was fantastic. It was great to see everyone who could attend. Hopefully the economy is better next year so we can have more attendees. *[Martin (for Ron)] Our current website looks like an open source project’s website. If we want to convince people to use or work with coreboot, it should look like a company’s website. Ron pointed to https://go.dev/ (https://go.dev/) with their table of “Companies using go” as an example of what he thinks might be better. Listing these companies makes other companies feel like they may be missing out by not using go. *[Martin] coreboot gerrit statistics: https://docs.google.com/spreadsheets/d/1q_OdePsm1DHUUJxrO1cWce99lOFd9wKiEZC… (https://docs.google.com/spreadsheets/d/1q_OdePsm1DHUUJxrO1cWce99lOFd9wKiEZC…) This is a set of statistics that I’ve been keeping unofficially for a while. I showed it to some people at OSFC, and they suggested sharing it more widely. The data is collected from gerrit with the gerrit_stats perl script in the util/release directory: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util… (https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util…) Please note - These statistics are terrible for specifics, and can definitely be gamed. Patches vary in quality, and some people choose to spread their patches into a large number, while others choose to do everything in a single patch. Please don’t read too much into anything in these charts. *[Martin] We have a new coreboot store - https://coreboot.myspreadshop.com (https://coreboot.myspreadshop.com). This is in the US, but we can create a similar store with their European group. Unfortunately, that needs to be set up and configured separately. This is just a typical swag store where you can get the coreboot logo printed on random stuff. Anyone need a coreboot apron? This is being run by Martin, not the coreboot project, so that the project doesn’t have to deal with taxes and such. Any profits made will be donated to coreboot through the SFC. If anyone wants a new design added, let me know. [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

RTL8111F MAC address not parsed correctly on new ASUS P8H77-M port
by Kevin Keijzer 16 Oct '23

16 Oct '23

Hello, I have been working on a port/variant for the ASUS P8H77-M, which I recently got from a friend. At this point I have almost everything working, with the exception of the onboard Realtek RTL8111F ethernet NIC. Or at least, it does allow for network traffic, but the MAC address is set to 00:00:00:00:00:05. When I boot the vendor BIOS, the actual MAC address is shown when I run `ip link`. I also have a P8Z77-M with coreboot, which has the same NIC and is overall a pretty similar board. On that board I do not have any issues with the MAC address. Maybe I'm wrong, but I suspect the PCI subvendor and subdevice strings to potentially be the cause of this. When I run `hwinfo` with the vendor BIOS on the P8H77-M, the output shows: path = /devices/pci0000:00/0000:00:1c.4/0000:03:00.0 modalias = "pci:v000010ECd00008168sv00001043sd00008505bc02sc00i00" class = 0x20000 vendor = 0x10ec device = 0x8168 subvendor = 0x1043 subdevice = 0x8505 So the subvendor should be 1043 and the subdevice should be 8505. When I do the same when running my WIP coreboot port on the P8H77-M, I get this: pci device: name = 0000:03:00.0 path = /devices/pci0000:00/0000:00:1c.4/0000:03:00.0 modalias = "pci:v000010ECd00008168sv000010ECsd00008168bc02sc00i00" class = 0x20000 vendor = 0x10ec device = 0x8168 subvendor = 0x10ec subdevice = 0x8168 Here the subvendor and the subdevice are equal to the vendor and the device, which I think is wrong and maybe causes this issue. For reference, I also ran `hwinfo` on the P8Z77-M with coreboot: pci device: name = 0000:04:00.0 path = /devices/pci0000:00/0000:00:1c.5/0000:04:00.0 modalias = "pci:v000010ECd00008168sv00001043sd00008505bc02sc00i00" class = 0x20000 vendor = 0x10ec device = 0x8168 subvendor = 0x1043 subdevice = 0x8505 This shows the same subvendor/subdevice as the vendor BIOS on the P8H77-M. (And this board does *not* have the MAC address issue in coreboot.) So I figured that I could set the subsystemid in overridetree.cb to set these values correctly, but no matter what I try, I can't seem to get any other output than 0x10ec:0x8168. First I tried this: device pci 1c.4 on subsystemid 0x1043 0x8505 device pci 00.0 on end end Then this: device pci 1c.4 on device pci 00.0 on subsystemid 0x1043 0x8505 end end And then this: device pci 1c.4 on subsystemid 0x1043 0x8505 device pci 00.0 on subsystemid 0x1043 0x8505 end end But in all cases, `hwinfo` showed 0x10ec:0x8168 and `ip link` gave me 00:00:00:00:00:05. Interestingly, I did see the values I set reflected in the coreboot log: [DEBUG] PCI: 03:00.0 subsystem <- 1043/8505 [DEBUG] PCI: 03:00.0 cmd <- 103 On the other hand, when I looked in the coreboot log of the P8Z77-M, it didn't set it to those values at all: [DEBUG] PCI: 04:00.0 subsystem <- 1043/84ca [DEBUG] PCI: 04:00.0 cmd <- 103 Yet, `hwinfo` still showed 1043:8505 on that board, and the MAC address was correct. So that made me doubt if these values were retrieved from devicetree.cb at all. Anyway, I am kind of at a loss here.. I have two very similar boards with the same NIC. On one of them the MAC address is parsed correctly, and on the other one it is not. The only difference that I can see is the subdevice/subvendor, but I can't get coreboot to set it correctly, even though the vendor BIOS works fine. As for the P8Z77-M board that doesn't have this issue, I can't even find the string "8505" anywhere when I recursively grep through src/mainboard/asus; yet it does seem to use that as the subdevice id somehow. So where are the subvendor/subdevice strings for the NIC retrieved from then? Or could the MAC address issue be caused by something completely different? -- With kind regards, Kevin Keijzer

1 0

coreboot store & contribution spreadsheet
by coreboot org 12 Oct '23

12 Oct '23

I'm at the OSFC right now, and presented a couple of links. I've set up a very preliminary coreboot store: https://coreboot.myspreadshop.com/ This is mostly just a standard store printing the logo on random *stuff*. The nice thing about this particular store is that you can (for a fee) customize locations, sizes, and the such Here's a sheet with some history of commits to coreboot from 4.0 to 4.21: https://docs.google.com/spreadsheets/d/1q_OdePsm1DHUUJxrO1cWce99lOFd9wKiEZC… Martin

1 0

Alderlake-P DDR4 RVP Graphics issue
by mahesh 10 Oct '23

10 Oct '23

Hi folks, Myself Building image for ADL-P DDR4 RVP, by using coreboot 4.21 & Mrchromebox EDK-II as a UEFI payload. By default, RVP don't have a *"libgfxinit" *support *in coreboot *but with the help of Mrchromebox i have integrated the *"libgfxinit" support.* from make menuconfig->> under devices ->> Graphic Initialization -> libgfxinit Vbt ->> extracted Vbt file from the Stock BIOS with the above config, I am able to see the BIOS Menu only on *uart console* However, on External Monitor (HDMI display) appeared with blank screen (No backlight) I inspected the debug log and it says "*HW.GFX.EDID.Sanitize: EDID header pattern mismatch!".* Debug logs: https://pastebin.com/Y8y78Xv1 kindly please advise the solution for this issue.. Thanks in advance..

1 0

New JPEG decoder available for testing
by Patrick Georgi 07 Oct '23

07 Oct '23

Hi everybody, coreboot has a "bootsplash" feature that allows showing an image on the screen relatively early during boot (although rather late in terms of coreboot). It comes with a JPEG decoder that served us for last nearly 20 years, although it is rather limited: It only supports a subset of JPEG's features, so care had to be taken to pre-process the bootsplash image in just the right way for the decoder to accept it. It was also somewhat fragile: util/fuzz-tests/ ships a test harness for our JPEG API, and afl-fuzz++ runs into lots of crashes with that decoder. Enter Wuffs[0]: It's a programming language tailored towards processing "some piece of data" into "another piece of data", with very strict semantics. It comes with a standard library implementing all kinds of things that fit that category from deflate decompression to jpeg. Its compiler emits portable C code, so we don't need to support the language in the coreboot environment at all. https://review.coreboot.org/78271 integrates a pre-release version of Wuffs, replacing our jpeg decoder with the one from there. If you're dealing with bootsplashes, I'd appreciate testing on your image files to see how well it fares. Regards, Patrick PS: Many thanks to Nigel Tao, Wuffs' principal author, who dug through the complications of relicensing the project so it becomes compatible with GPLv2, enabling this integration. [0] https://github.com/google/wuffs

1 0

Re: [NixOS/nixpkgs] Build failure: diffoscobe broken by coreboot-utils 4.21 upgrade (Issue #256896)
by ehaouas 06 Oct '23

06 Oct '23

Hi Ivan, Please send an email to coreboot(a)coreboot.org Thx De : "Ivan Jager" A : "NixOS/nixpkgs" ,"Elyes HAOUAS" ,"Mention" Envoyé: samedi 23 Septembre 2023 15:19 Objet : [NixOS/nixpkgs] Build failure: diffoscobe broken by coreboot-utils 4.21 upgrade (Issue #256896) Steps To Reproduce Steps to reproduce the behavior: build diffoscope Eg: nix-build -A diffoscope Build log https://gist.github.com/aij/ffc8e357eed2c6f4411910972ce0b920 Additional context Broken since #251110 merged per git bisect I looked into this a bit and I'm not sure if it's a diffoscope bug or a coreboot bug. The failing tests generate test files with cbfstool (from coreboot) and the files generated by cbfstool 4.21 are using 4 bytes less space for the "header" (trailer) at the end of the file: $ diffoscope coreboot1.rom.4.20 coreboot1.rom.4.21 --- coreboot1.rom.4.20 +++ coreboot1.rom.4.21 @@ -2039,10 +2039,10 @@ 00007f60: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007f70: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007f80: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007f90: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007fa0: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007fb0: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007fc0: ffff ffff ffff ffff ffff ffff ffff ffff ................ -00007fd0: ffff ffff ffff ffff ffff ffff 4f52 4243 ............ORBC -00007fe0: 3131 3132 0000 8000 0000 0000 0000 0040 1112...........@ -00007ff0: 0000 0000 0000 0001 ffff ffff dcff ffff ................ +00007fd0: ffff ffff ffff ffff ffff ffff ffff ffff ................ +00007fe0: 4f52 4243 3131 3132 0000 8000 0000 0000 ORBC1112........ +00007ff0: 0000 0040 0000 0000 0000 0001 e0ff ffff ...@............ As a result, CbfsFile.recognizes does not match. My first thought was to change the matcher @@ -139,7 +138,7 @@ class CbfsFile(File): rel_offset = struct.unpack("<i", f.read(4))[0] if ( rel_offset < 0 - and -rel_offset > CBFS_HEADER_SIZE + and -rel_offset >= CBFS_HEADER_SIZE and -rel_offset < size ): f.seek(rel_offset, io.SEEK_END) but then the rom2 tests still fail... Looking into the relevant change on the coreboot side it looks like the change to the cbfs_header size may have been accidental. (C99 flexible arrays are nice for filename and data but not for fixed size padding...) Anyway, even if this is a coreboot bug, it may still be useful to update diffutils to be able to recognize files produced by coreboot 4.21. Notify maintainers Diffoscope: @dezgeg @danielfullmer @RaitoBezarius coreboot-utils: @felixsinger @yuka Other: @ElyesH @jmbaur @felixsinger @lamby Metadata Please run nix-shell -p nix-info --run "nix-info -m" and paste the result. ivan@tobati:~/nixops/aij/unstable$ nix-shell -p nix-info --run "nix-info -m" - system: `"x86_64-linux"` - host os: `Linux 6.1.50, NixOS, 23.11 (Tapir), 23.11.git.bfb7dfec93f3` - multi-user?: `yes` - sandbox: `yes` - version: `nix-env (Nix) 2.17.0` - channels(root): `"nixos-21.11pre329341.9e70e9f732f"` - nixpkgs: `/etc/nixos/aij/unstable` — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: <NixOS/nixpkgs/issues/256896(a)github.com>

2 1

Re: The GIT server on the downloads page is unreachable suddenly
by Martin Roth 05 Oct '23

05 Oct '23

Hey Gregg, Glad to help. I'm sure there are plenty of others on the mailing list that aren't familiar with uptime.coreboot.org as well. After I sent the email, I did notice that you referenced an old url that is no longer active - http://review.coreboot.org/p/coreboot/. We retired the /p url a couple of years ago, as I recall. Unfortunately I don't remember where it used to point, but I'm suspecting the replacement is this url: https://review.coreboot.org/plugins/gitiles/coreboot You shouldn't see the error you referenced at that url, but you'd get a 404 instead, which is also sub-optimal. Take care. Martin Oct 5, 2023, 10:01 by gregg.drwho8(a)gmail.com: > Hello! > That's what I wanted to know. Good to know of course. Mostly because > early on I needed to redo this laptop, and that meant starting all > over again inside the WSL framework. Sadly the firewall I use cannot > tell the difference between a malicious activity and a planned and > proper one, so it blocked the first, and wanted to do so when I > confirmed for myself that it does work, So all is well. > ----- > Gregg C Levine gregg.drwho8(a)gmail.com > "This signature fought the Time Wars, time and again." > > On Thu, Oct 5, 2023 at 11:33 AM Martin Roth <gaumless(a)tutanota.com> wrote: > >> >> Hi Greg, >> Sorry about any outages that the server has suffered. Obviously, keeping things online is very important to us, but unfortunately, outages do happen for various reasons. >> >> Monitoring of coreboot sites and services is done at https://uptime.coreboot.org - that's where you can check the status of everything. >> You can check the git service here: https://uptime.coreboot.org/service/22 >> >> That said, I don't see any serious outages in the logs for the past few days, so maybe the issue you were seeing was somewhere else on the internet? >> >> Either way, everything seems to be working at this point, so hopefully you aren't seeing any issue. If you still are, it doesn't seem to be a coreboot issue directly. >> >> Take care >> Martin >> >> Oct 4, 2023, 19:16 by gregg.drwho8(a)gmail.com: >> >> > Hello! >> > I just tried to retrieve a fresh set for the coreboot materials from >> > the site and my WSL set complains that git clone >> > https://review.coreboot.org/coreboot.git does not work because the >> > server is itself unreachable. For example when trying to update an old >> > install of the code on the server and I get this response: >> > fatal: unable to access 'http://review.coreboot.org/p/coreboot/': >> > Could not resolve host: review.coreboot.org >> > ----- >> > Gregg C Levine gregg.drwho8(a)gmail.com >> > "This signature fought the Time Wars, time and again." >> > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

2 1

How to get reviews on gerrit? aka. patches ignored for three years.
by Daniel Gröber 05 Oct '23

05 Oct '23

Hi, could someone tell me how I'm supposed to deal with unresponsive reviewers on gerrit? Clearly I must be doing something wrong as the patches have been gathering dust for around three years now. https://review.coreboot.org/q/topic:%22macronix-spi-bp%22 --Daniel

6 11

2023-10-04 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 05 Oct '23

05 Oct '23

# 2023-10-04 - coreboot Leadership Meeting Minutes ## Attendees David Hendricks, Christian Walter, Daniel Maslowski, Felix Held, Jay Talbott, Julius Werner, Karthik Ramasubramanian, Martin Roth, Matt Devillier, Maximilian Brune, Mickey, Simon Glass, Tim Crawford, Werner Zeh, Wilhelmina Asante, Stefan Reinauer. ## Action Items - Martin: Write a tutorial for gerrrit. - OSFF: Look into making a video about using gerrit. - Martin: Write a documentation about vendorcode submodules. - Martin: Work with David to create a vendorcode submodule for intel. - Simon: Will send patches related to RFCv2 for post-build control of the serial console. > Fallback method > Add enums. ## Minutes: ### OSFC 2023 - California Bay-area in October - Next week! * Tickets are available at [https://osfc.io](https://osfc.io) ### sjg - RFCv2: Post-build control of serial console There’s been a lot of discussion about this on the mailing list, but not much contribution from anyone other than Simon and Martin. Are others ambivalent? * There have been complaints about people just doing things without consulting the community first, but this lack of comment makes it feel like that’s just complaining, and it doesn’t actually matter. * Simon will send patches. * Fallback method * Add enums ### Martinr] How do people feel about recording the coreboot leadership meeting and posting them on youtube or something so that others can watch them later? * Martin] I got one comment opposed to this idea because we sometimes discuss things of a more private nature that we don’t want to go into the minutes. If we record a video, these items can’t be private. * [FelixS] I don’t like that for that same reason either. Also, I fear that it becomes more comfortable to do discussions (or even decisions) at the meeting instead of on the mailing list where more people can participate. * Nobody is in favor of this. ### Martinr] Gmail has flattened the minutes to a list instead of maintaining indentation a couple of times. The coreboot blog does the same. What’s the best way to distribute the meeting minutes? * [PatrickG] won’t be there, so put it on here: markdown files in Documentation/? That keeps them for eternity, though… (but so do mailing list and blog posts) * [Martin] If we’re satisfied with just text formatting, we can just keep posting the minutes to the mailing list, it just seems like we could do something with better native formatting. * This makes it hard to have a dialog. * Mailing list should work even if the minutes are just text. * Look at attaching as markdown. * Look at modifying the way we’re taking minutes? * Use a different service - Use a markdown editor to take minutes? - Etherpad - Trippad - [https://codepen.io/](https://codepen.io/).(Online code editor) - [https://hackmd.io/](https://hackmd.io/). (Hackmd.io) - [https://hedgedoc.org/](https://hedgedoc.org/) (hedge) - [https://codi.hostile.education](https://codi.hostile.education) - [https://codepen.io/](https://codepen.io/).(Online code editor) - [https://hackmd.io/](https://hackmd.io/). (Hackmd.io) - [https://hedgedoc.org/](https://hedgedoc.org/) (hedge) - ( [https://codi.hostile.education](https://codi.hostile.education) is Daniel Maslowski's personal instance) * Something that formats the meeting minutes so they can be easily copy+pasted to the mailing list without ruining formatting. ### Martinr] Incentives for work. * In an email exchange Daniel Gröber mentioned that he feels like gerrit gives less incentive to do work as it isn’t seen as widely. Thoughts? * [https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/DPF… _I like to philosophize about incentives. So what incentives does a contributor have to get themselves added to that maintainers list?_ _The cynic in me says: none. It's just hard work nobody wants to do, but that doesn't explain the fact that there are in fact plenty of mostly-volunteer projects with a thriving development community._ _My current theory is, this happens when people see some kind of social reward for doing that hard work._ * One big issue is a lack of hardware. Most modern platforms are not hackable easily. * New platforms are mostly done by companies, so focus on community work? * How can we improve as a community? * Can we find a cheap board that can be ported? Make a class? * FelixS is working on this with the up-extreme - unfortunately a little bit expensive. Has everything that’s needed for development, and are very small. * Need documentation * Simon] Indexed approach to finding docs. * What infrastructure there is. * [Maximilian] Enhance online presence for blogs * Martin] I’m not sure if this is accurate, but I’m often wrong. We could do a number of things, like send merged patches to email, weekly lists of contributors to email, add contributors to release notes, or something similar. * Simon] Gerrit does make patches sort of invisible. * Maximilian] Not sure of the issue with gerrit. * DanielM: Maybe do some gerrit documentation. * Martin is willing to write up a tutorial. * Many people are used to github workflow, which is very different. Need to educate people. * Matt] In the dashboard it shows patches in order of activity - This is frustrating. Documentation could help - how to view patch trains. * FelixH] Multiple people confused about merge conflicts later in the patch train. * Werner] Make a webinar talk about using gerrit? * [FelixS] People could record a video and upload it on our youtube channel as a timeless alternative * Felixs] What can we link to? * https://review.coreboot.org/c/coreboot/+/76937 * Pretty much anything that people think would be useful. ### Martinr] Make vendor code submodules that the vendors are responsible for instead of having that code go directly into coreboot? * Embedded into the structure, not at the top vendor code level. * All submodules will have a copy of the code hosted by coreboot.org * Not forcing vendors to use submodules, but making them available. # Next meeting October 18th, 2023 * [Meeting link](https://meet.google.com/pyt-newq-rbb (https://meet.google.com/pyt-newq-rbb)) * [coreboot Calendar](https://coreboot.org/calendar.html (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 https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj... (https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…)

1 0

The GIT server on the downloads page is unreachable suddenly
by Gregg Levine 05 Oct '23

05 Oct '23

Hello! I just tried to retrieve a fresh set for the coreboot materials from the site and my WSL set complains that git clone https://review.coreboot.org/coreboot.git does not work because the server is itself unreachable. For example when trying to update an old install of the code on the server and I get this response: fatal: unable to access 'http://review.coreboot.org/p/coreboot/': Could not resolve host: review.coreboot.org ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2023