coreboot April 2022

coreboot@coreboot.org

51 participants
44 discussions

2022-03-29 - coreboot UEFI working group meeting minutes
by coreboot org 23 Apr '22

23 Apr '22

# 2022-03-29 - coreboot UEFI working group Next meeting: 2022-04-26 ## Attendees: Jay, Werner, Martin, Sheng, Ron, David ## Minutes: * In the coreboot meeting last week, we discussed a proposal from Intel to change the handoff mechanism to payloads [1]. 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 [2] initiative. * The current payload handoff method has a number of flaws that they’d like to fix, such as the address for stack being hardcoded. * 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 suggestion. * If anyone is not familiar with CBOR, you can get more information at cbor.io [3]. * 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 ACPI tables. * 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 & HOBs. * 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 [4]. 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 [5]. * 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. [1]: https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… [2]: https://universalscalablefirmware.github.io/documentation/ [3]: https://cbor.io/ [4]: https://calendar.google.com/event?action=TEMPLATE&tmeid=NHVvZDRuYXZ2bjdtZTJ… [5]: https://docs.google.com/document/d/1IDQqr4cv8dQHa9faSxBc29xHSeKuXNTiMP3a3bL…

6 13

Flashing EC is getting failed
by Sameeruddin Shaik 23 Apr '22

23 Apr '22

hi, I am getting the below error while flashing the EC image with the micro servo, Did anyone know about this?. sudo ./util/flash_ec --board=adlrvpp_ite --image build/adlrvpp_ite/ec.bin INFO: Using servo_micro. INFO: Using ec image : build/adlrvpp_ite/ec.bin INFO: Flashing chip it83xx. INFO: Asking servo to send the dbgr special waveform to it83xx 2022-04-02 11:38:29,203 - Controls - ERROR - (ptyError) Failed getting enable_ite_dfu: servo_micro: Timeout waiting for response. There was output: enable_ite_dfu, Command 'enable_ite_dfu' not found or ambiguous., > Problem with ['enable_ite_dfu'] :: servo_micro: Timeout waiting for response. There was output: enable_ite_dfu, Command 'enable_ite_dfu' not found or ambiguous., > ERROR: command exited 1 (non-zero): dut-control enable_ite_dfu INFO: Restoring servo settings... Please help!!!, thanks in advance --sameer

1 1

Two Payloads
by Lukas Jungbauer 21 Apr '22

21 Apr '22

Hi, is it possible to run two Payloads on Coreboot at the same Time, like Heads and TianoCore? Payloads can only be installed by building a new Image and Software-Flashing it, correct? Best Regards, Lukas

3 2

Coreboot : Change/modify Boot maintenance manager for auto boot support.
by Putsala Amar 21 Apr '22

21 Apr '22

Hi, We are working on intel c508 intel denverton board. We have programmed coreboot image in 16MB NOR flash. After the coreboot hw initialization , it moves to payload stage by default it is entering to "boot maintenance manager" . We expect the node to boot without getting into boot manager(without waiting for any key) . Made below experiment which i found in BIOS : Change/Modify Auto Boot Time-out option as "0" in "Boot Maintenance manager". but this timeout parameter is not allow to commit/save the new changes. As per the Auto Boot Time-out description : Range: 0 means no wait , 65535 means waiting for Key. By default timeout hold 65535. Thanks in advance.., Thanks & Regards, Amar Putsala ( ID : 2353 ) 4th Floor , Cubical : 4058 J.P. Software Park, Electronic City Phase-1, Hosur Road, 560100 Ext. No: 8110

3 3

RFC: Clarifying use of GCC extensions in the coding style
by Julius Werner 18 Apr '22

18 Apr '22

Hi, We occasionally get into discussions in code reviews when code uses a GCC extension, and a reviewer asks that it be rewritten to be C standard compliant instead. A recent example was on the use of `void *` arithmetic in this patch https://review.coreboot.org/c/coreboot/+/56791/9/src/soc/mediatek/common/pc… , and there have been others in the past. I would like to come to a consensus on this topic here and add some blurb to the coding style document so we don't have to rehash the same discussion over and over again. In my opinion, GCC extensions are absolutely necessary for coreboot development and there should be no reason to reject them. Inline assembly is the most obvious example -- without it we would have to convert a ton of static inline functions that wrap special instructions into full linker-level functions in a separate assembly file instead, and eat all the unnecessary function call overhead that comes with that. Others enable such important features that it would become much more dangerous and cumbersome to develop without them -- most importantly statement expressions (https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Statement-Exprs.html) which are necessary to write things like double-evaluation safe macros, expression-assertions like dead_code_t() and simple convenience shortcuts like wait_us(). And some extensions just offer a small bit of convenience to reduce boilerplate -- for example, `void *` arithmetic just tends to be useful to prevent cluttering the code with a bunch of unnecessary casts to other types that don't add any additional meaning to the data (e.g. for an unspecified buffer of opaque data I think `void *` is a much more appropriate type than `uint8_t *`, even if I want to add a byte offset to it), and I've never seen a case where I think it would have actually been unclear to anyone what step width the pointer arithmetic was done at (there's no reason to assume anything other than bytewise for a `void *`). If we need some extensions anyway, and coreboot will never be "fully C standards compliant" (not that that would actually be very useful for anything in practice), I don't see a reason why we should still avoid some extensions when we're using others. I think if an (official, long-term supported) extension exists and it allows us to write better code than standard C, there should be no reason not to use it. (Note that for those people who are trying to get coreboot working with clang, it generally supports all the same extensions as GCC.) I've written a draft CL to add a section for this to the coding style, please let me know what you think: https://review.coreboot.org/c/coreboot/+/63660

2 1

lb_serial: drop 'uart_pci_addr' entry
by Arthur Heymans 17 Apr '22

17 Apr '22

Hi In 2016 'uart_pci_addr' was added to the coreboot table entry for serial devices. (https://review.coreboot.org/c/coreboot/+/14609) It was done for the Intel Quark platform which has its uart on a PCI device like other Intel hardware. Right now only Quark sets this to a non zero value using an awkwardly defined Kconfig parameter: CONFIG_UART_PCI_ADDR. It looks like only tianocore uses this and it's pretty much a NOOP used only to get the VID/DID of the PCI device. Should we update tianocore and just drop this for the lb_table? Most other payloads don't even have this struct entry updated to contain this entry... Now our codebase has awkward code with "serial.uart_pci_addr = CONFIG_UART_PCI_ADDR;" on a lot of platforms that don't even feature PCI and there is no real use case as far as I can tell. Do any of your payloads use this in a meaningful way? If not, can we just drop it? Kind regards Arthur

2 2

review.coreboot.org 's wget is working unreliable today
by Mike Banon 17 Apr '22

17 Apr '22

Downloading the patches by wget from review.coreboot.org - really often results in these errors today. my Internet connection is OK and I'm able to load review.coreboot.org at the same time with a browser. --2022-04-17 **:**:**-- https://review.coreboot.org/changes/58748/revisions/1/patch?zip Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt' Resolving review.coreboot.org (review.coreboot.org)... 78.46.105.101, 2a01:4f8:121:1254::2 Connecting to review.coreboot.org (review.coreboot.org)|78.46.105.101|:443... failed: Connection timed out. Connecting to review.coreboot.org (review.coreboot.org)|2a01:4f8:121:1254::2|:443... failed: Network is unreachable. WARNING: can't download a ./patch?zip file ! Please check your Internet connection and try again. press [ENTER] to continue... -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

Re: Deprecation of the Intel Quark SoC
by Martin Roth 14 Apr '22

14 Apr '22

Apr 14, 2022, 14:06 by 0xloem(a)gmail.com: > Hi Martin, > >> I think we all agree that it'd be good to have test racks that have all of the boards in the coreboot repository for verification, however that's currently not practical with the resources we have. The whole thing just isn't a simple problem to solve. >> > > Often the biggest impediment to something like this is simply holding it as a shared goal, and continuing to do so when issues arise. > > If public test labs were desired, a callout for donations of space and hardware could be placed on the main page. If somebody had the capacity to do more than that, then local makerspaces and hackerspaces could be reached out to. > It's a good point. Maybe we can put up a webpage with how an individual can help the coreboot project. Put up a list of boards to be adopted for testing and how to find which commit broke them if they're broken. >> I'm actually also not completely convinced that just testing the boards is the solution to whether or not we keep a board/chip on the mastre branch. If there really aren't any people using coreboot on their quark boards, then personally, I don't see any need to keep it in the master branch. I know others feel differently, but as I said earlier in this thread, I don't think there's actually any harm in moving an aging or little-used platform to be maintained on a branch. >> > > Sounds like there is a difference of opinion in the community. > Always. ;-) > It seems obvious to me that there would be people using coreboot on their quark boards. The world is gigantic. > > But you have a different opinion, which is fine. > > It seems to me the reason to include a board is because people care about doing so. > Agreed. Currently we have no way of knowing whether or not anyone cares about a board. There are two ways people typically make it known - by working on a board or by testing a board. > I care enough about including boards that I'd test this one if it was needed to do so to retain it. But I'm just a visitor. And it seems more productive to discuss public test labs that could grow to support more boards. > Sure, and I'm not trying to advocate that we remove anything. Mostly right now I'm trying to figure out how we should decide when things should or should not be moved to a branch to make it easier going forward. Take care Martin

2 2

libpayload CBFS API deprecation; please port payloads to new API
by Julius Werner 14 Apr '22

14 Apr '22

The libpayload CBFS stack ("libcbfs") has recently been rewritten from scratch in order to eliminate a bunch of very old warts and better match the new CBFS API in coreboot (https://review.coreboot.org/59497). For the time being, the old libcbfs code remains side-by-side to the new one so that the old API functions still work for existing payloads. However, we would like to remove this code eventually as it still presents a maintenance burden. All payloads that use the CBFS API in libpayload should please upgrade to the new API. Among the payloads hooked up to the coreboot build system, I think this only affects depthcharge (we already ported that one), BOOTBOOT and FILO. See https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/pa… for available interfaces (they match the coreboot API which is documented in more detail in https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr…). If you have a use case that cannot be implemented with this interface please let me know. If there are no objections I'd suggest that we target the official deprecation and removal of the old API for the release after next, i.e. 4.18 around the end of this year.

2 1

Fwd: Refactoring duplicate Embedded Controller code
by Ivan Ivanov 13 Apr '22

13 Apr '22

G505S has KB9012 chip on board, I can guarantee this. However, maybe KB9012 is a bit similar to the older chips, and just the internal 128KB memory and some features got added. If you'd look at KB9012 dataset available online, I think it had a comparison table of KB9012 vs some older chip. Hope this helps! пт, 8 апр. 2022 г., 16:46 Abel Briggs <abelbriggs1(a)hotmail.com>: > Yes, I was looking at the G505S and its EC when considering these patches. > > The situation with the EC in the G505S seems a bit odd. The EC is named > `ene932`, but there are several commits in the codebase which reference the > chip as a KB9012. The KB9012 datasheet, however, reference the ENE930 > series chips as the predecessor chip to the KB9010 series. > > The S230U has a KB9012 and the Compal firmware seems to have a similar > `OperationRegion` layout to the firmware in the `ene932`, but the EC query > values are completely different. The S230U basically defines its own EC in > its mainboard tree and only uses the `ene932` code for its helper I/O space > functions. > > If anyone has a G505S or its vendor documentation to check that the chip > on the board is really an ENE930 series, I think that would help clear this > up. > > This is something I was considering trying to refactor as well, by giving > the S230U its own `ec/` common code. However, I would probably throw that > patch in with my mainboard's patchset (Lenovo Edge E530), since otherwise > the S230U would be the only user of that code. > > ------------------------------ > *From:* Ivan Ivanov <qmastery16(a)gmail.com> > *Sent:* Friday, April 8, 2022, 4:38 AM > *To:* Abel Briggs <abelbriggs1(a)hotmail.com> > *Cc:* coreboot(a)coreboot.org <coreboot(a)coreboot.org> > *Subject:* Re: [coreboot] Refactoring duplicate Embedded Controller code > > If this could help you, coreboot-supported Lenovo G505S also has EC KB9012 > > чт, 7 апр. 2022 г. в 06:44, Abel Briggs <abelbriggs1(a)hotmail.com>: > > > > Hello, > > > > I was looking at the code and ACPI for a number of different embedded > > controllers while adding support for a Lenovo mainboard. > > The mainboard in question has an EC nearly identical to the Twist S230U > > (Compal KB9012), so I planned to factor out the S230U's EC code/ACPI > > into its own chip. > > > > While doing this, I noticed there were several duplicate functions > > across the `ec/` directory, so I'd like to potentially submit some > > patches to clean them up. However, I'm not sure of the best way to > > go about this. > > > > The following is what I currently have in mind: > > > > - Removing most individual `ec_write_cmd()` > > and similar functions andreplacing calls with their respective > `ec/acpi/ec.c` library functions > > - Removing individual `kbc_` polling functions and sharing the ones > defined > > in `drivers/pc80/keyboard.c` > > - Should public library functions for sending and receiving data from > > a PC80 keyboard controller be defined in the PC80 driver and exported > > in `include/pc80/keyboard.h`? > > - We already have `send_keyboard()` there, > > which sends a command and receives data - would it be good to add > > individual functions for those operations as well? > > > > Any suggestions or recommendations would be appreciated. I looked for > > guidelines on suggested code organization in the docs/commit history/ > > mailing list, but came up mostly empty-handed. > > > > Thanks! > > > > _______________________________________________ > > coreboot mailing list -- coreboot(a)coreboot.org > > To unsubscribe send an email to coreboot-leave(a)coreboot.org > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2022