coreboot

coreboot@coreboot.org

4 participants
39683 discussions

Critical bug in RTC code for a leap year
by Michał Żygowski 29 Feb '24

29 Feb '24

Hi folks, Another leap year, another problem with RTC in firmwares :) This time, unfortunately, this kind of bugs hit coreboot. I have issued a patch that fixes off-by-one error in the days count in month for a leap year: https://review.coreboot.org/c/coreboot/+/80790 It is quite critical, because depending on build date, it may revert to some very old date, like January 2023 or even older (depending on how long you run on current firmware). That said, the consequences are enormous: from false-negative expired certificates, to problems with filesystems, etc. It is worth considering an emergency coreboot release, is it not? Best regards, -- Michał Żygowski Firmware Engineer GPG: 6B5BA214D21FCEB2 https://3mdeb.com | @3mdeb_com

2 1

Re: Are we running libpayload unit tests in the CI?
by Martin Roth 29 Feb '24

29 Feb '24

Hey Julius, Here's what we running: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util… Martin Feb 27, 2024 at 18:31 by jwerner(a)chromium.org: > Hi, > > We've had unit test support in libpayload for over two years now, but > I just noticed that it doesn't look like we're actually running them > in the CI? E.g. if I look through a test run like this > https://qa.coreboot.org/job/coreboot-gerrit/252761/testReport/(root)/ > I can't find them anywhere (most of them have confusingly similar > names with coreboot unit tests, but "fmap_locate_area-test" is a > unique one). > > Is that intended or an oversight? Would it be easy to fix? (I'm not > super familiar with how the tests are integrated into Jenkins, but the > libpayload framework is pretty much a direct copy of the coreboot > framework, so if we can run the coreboot ones hopefully it should be > easy to run the libpayload ones as well?) > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

2 1

The road towards LTO: an update and a few question
by Arthur Heymans 28 Feb '24

28 Feb '24

Hi community I picked up the good work done by Jacob Garber to implement link time optimization. The size gains are very substantial, with sometimes up to 15% reduction in binary size! Besides the size benefit it can make us a bit more lazy programmers: for instance we often put static inline functions in headers guarded by preprocessing depending on Kconfig options to not generate code we won't use. With LTO that can be relaxed a bit and the condition to do nothing can come from a separate linked object (at least I presume, I haven't tested). So to do LTO, both with clang and GCC, you use the compiler as a linker frontend, rather than invoke the linker directly. Object files that are optionally generated with the -flto flag to generate LTO optimized binaries. See https://review.coreboot.org/c/coreboot/+/40811 Jacob's patches dealt with GCC. I toyed around with clang. The clang linker frontend only works with LTO if using the GOLD or LLD linker. GCC can use the BFD linker we currently use, so that's an easy transition. Both those linkers, GOLD and LLD are less capable at parsing linker scripts than the BFD linker. Especially for the x86 bootblock, in which we do a lot of stuff, like ID, FIT pointer, ECFW pointer, early 16 bit code, ..., is complicated and those linkers fail on the arithmetics doing all that optimized linking. So my question would be, whether we want to support non BFD linkers and therefore not support all the magic in linker scripts we currently have. At most we are a few bytes less optimal than possible by for instance setting a good hardcoded size and offset of the early 16bit code rather than have the linker script optimize that. As a side note, LTO size gainz are bigger than what would be lost, by a large margin. https://review.coreboot.org/c/coreboot/+/80724/1/src/arch/x86/bootblock.ld is a crude example of how I got lld to be happy with the script. If non BFD linkers are acceptable, how do you propose we deal with it? When not using LTO you could in principle use a different linker of your choosing. Should we just move to lld to make sure CI is happy about linker scripts? Should it be an option, but then we won?t have CI being able to test it except on a few boards put in configs/ ? Maybe have both, but then change the default once LLD is known to work well enough? Sidenote: LLD is faster than BFD but linking is not an expensive step in coreboot anyway. Other more typical linker scripts like the ones you find on ARM and ARM64 platforms work just fine. There are some subtle differences e.g. https://review.coreboot.org/c/coreboot/+/80735 where the heap needs to be declared to not be loaded. There are a few issues though. LLD does not like the RISCV relocation symbols of libgcc.a... I read upstream bugreports about this issue, so maybe that will resolve itself. Same questions with LTO and CI. Should it be an option (IMO yes, as that's what both Linux and u-boot do) and which default settings do we want. For CI reasons LTO is a bit more strict and therefore useful, as the compiler frontend does throw more warnings than the plain linker when linking. What are your thoughts? Are there some caveats about linkers and LTO that are worth knowing, before moving forward? Kind regards Arthur

3 3

Need help from anyone at Meraki/Cisco
by David Hendricks 28 Feb '24

28 Feb '24

Hi folks, As discussed in the Feb. 21 coreboot leadership meeting [1][2], concerns have been raised about coreboot source code releases for certain Meraki switch products. Requests have been made to open-source(a)meraki.com (mailto:open-source@meraki.com) about this with limited success in the past (MX84, MX250), though current requests for MS350 have gone practically unanswered. Since this problem scales with the product line-up, it seems an engineering approach to get code published - preferably upstream - will be a better way to solve it rather than repeated requests or escalation to the SFC. We're looking for anyone from Meraki/Cisco who would like to solve this by getting the code published. Several members of the coreboot community have experience working at (or with) companies in similar situations, and we're willing to help with this process. A few quick ideas mentioned in the recent meeting include a packaging tool to remove unused modules, a repo or branch on coreboot.org to host Meraki changes if they can't be mainlined easily, a license package that can integrate with Meraki's OS installer, etc. It's great that coreboot is used on these products and we believe that the coreboot community and corporate users such as Meraki mutually benefit when everyone's rights are respected. We strongly prefer an engineering approach to compliance with the GPLv2, but will look to other options if progress can't be made. If anyone at Meraki/Cisco happens to be reading this, feel free to contact me privately. [1] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… (https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…) [2] https://www.mail-archive.com/coreboot@coreboot.org/msg58333.html (https://www.mail-archive.com/coreboot@coreboot.org/msg58333.html)

1 0

Are we running libpayload unit tests in the CI?
by Julius Werner 28 Feb '24

28 Feb '24

Hi, We've had unit test support in libpayload for over two years now, but I just noticed that it doesn't look like we're actually running them in the CI? E.g. if I look through a test run like this https://qa.coreboot.org/job/coreboot-gerrit/252761/testReport/(root)/ I can't find them anywhere (most of them have confusingly similar names with coreboot unit tests, but "fmap_locate_area-test" is a unique one). Is that intended or an oversight? Would it be easy to fix? (I'm not super familiar with how the tests are integrated into Jenkins, but the libpayload framework is pretty much a direct copy of the coreboot framework, so if we can run the coreboot ones hopefully it should be easy to run the libpayload ones as well?)

1 0

CHIP_NAME history
by ron minnich 26 Feb '24

26 Feb '24

I notice in bfb11bec3b3fec638adf864a9b9b2cff6671fed8 that CHIP_NAME is gone. I am glad to see it go, but I figured a quick note on history would help. Back in the day, we had coreboot on systems with as little as 256 KiB of memory. That was hard. One of the build options was to have CHIP_NAME result in "", which saved the length of the string + 4 bytes (the pointer). This was, on occasion, the difference between fitting an image or overflowing. It mattered. So the comment: " It was decided to remove this macro altogether, as it does not do anything special and incurs a maintenance burden." is accurate now, since CHIP_NAME always returns the string. But in the era in which CHIP_NAME was created, this comment is not correct.

1 0

Introducing OSFF ByteTalks - Online Webinars about OSF
by Christian Walter 26 Feb '24

26 Feb '24

Hi coreboot community, The Open-Source Firmware Foundation (OSFF) is pleased to announce ByteTalks, a new series of online webinars focused on the open-source firmware community. ByteTalks aims to provide a platform for learning, sharing, and discussing the latest developments in open-source firmware. Each session features talks by experienced professionals, practical tutorials, and a chance for participants to ask questions and engage with the speakers. Whether you're deeply involved in firmware development or just interested in learning more about the field, ByteTalks offers valuable insights and connections to help you grow. Join us to explore the evolving world of open-source firmware together. Announcing OSFF ByteTalks Vol. 1: “*FSP Customization - Remove non-mandatory components in the Intel FSP*” In the realm of open-source firmware, creating a custom Firmware Support Package (FSP) binary is a pivotal step for developers aiming to enhance hardware compatibility and performance. The process involves understanding the hardware's initialization requirements, integrating coreboot or similar open-source firmware solutions, and customizing the FSP to meet specific system needs. Our guests Subrata and Vincent will talk about the process on customizing the Intel FSP and removing non-mandatory components. For more information, check out the event page here: https://osfw.foundation/events/bytetalks-vol.-1/ In case you have any questions, feel free to reach out to me. In case you are also interested in joining the ByteTalks series as a speaker, feel free to reach out to me as well :) Best, Chris -- *Christian Walter* Open-Source Firmware Foundation Email: christian.walter(a)osfw.foundation

1 0

[coreboot - Bug #527] (New) Can't compile coreboot on Arch Linux
by naixin Lv 24 Feb '24

24 Feb '24

Issue #527 has been reported by naixin Lv. ---------------------------------------- Bug #527: Can't compile coreboot on Arch Linux https://ticket.coreboot.org/issues/527 * Author: naixin Lv * Status: New * Priority: Normal * Assignee: naixin Lv * Category: build system * Target version: none * Start date: 2024-02-23 * Affected versions: master * Needs backport to: none * Affected hardware: GIGABYTE GA-H61M-DS2 * Affected OS: none ---------------------------------------- I want to compile coreboot for my Gigabyte GA-H61M-DS2 mainboard, but I only found a short guide for this board at this site: https://www.iot-tech.dev/full.php?ar=166 After downloaded the coreboot git repository, It gave me this error: ``` shell /home/zhongli/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/console/vtxprintf.o: in function `number': /home/zhongli/coreboot/src/console/vtxprintf.c:63:(.text.number+0x12b): undefined reference to `__udivmoddi4' /home/zhongli/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/lib/gcc.o: in function `__wrap___divdi3': /home/zhongli/coreboot/src/lib/gcc.c:19:(.text.__wrap___divdi3+0x1): undefined reference to `__divdi3' /home/zhongli/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/lib/gcc.o: in function `__wrap___udivdi3': /home/zhongli/coreboot/src/lib/gcc.c:20:(.text.__wrap___udivdi3+0x1): undefined reference to `__udivdi3' make: *** [src/arch/x86/Makefile.mk:191: build/cbfs/fallback/romstage.debug] Error 1 ``` And I'll put my config file on here. Any help ? ---Files-------------------------------- defconfig (726 Bytes) ifd_shrinked.bin (4 KB) me_shrinked.bin (96 KB) -- 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

3 4

coreboot/linuxbios for oldies insyde?
by meaudron 24 Feb '24

24 Feb '24

hello i have several old laptops here (2010/20) those are running general public/retail "insyde" h2 bios, specially made for grandma (hp, toshiba, vaio, asus..) i'd like to know if it's possible to make working a linuxbios/coreboot image for those. as : a/ is it possible to check if insyde bios could be replaced by a type of linuxbios? b/ is it possible as flashing it directly on the internal programmer?c/ does linuxbios is able to manage a windosw boot, as some laptops have dual win/nux boot (some with bsd on it too)

1 0

I can't build crossgcc
by Keith Hui 23 Feb '24

23 Feb '24

Hi guys, I was unable to build crossgcc. The important tail end of build log is included at the end. I couldn't figure out why. There should be no binutils-2.33.1 anywhere on my system. The build script is pulling in 2.41, and my host binutils is 2.40. Appreciate any help. Thanks Keith ---8<--- make[2]: Entering directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS/zlib' make[2]: *** No rule to make target '../../binutils-2.33.1/zlib/adler32.c', needed by 'libz_a-adler32.o'. Stop. make[2]: Leaving directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS/zlib' make[1]: *** [Makefile:10810: all-zlib] Error 2 make[1]: Leaving directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS' make: *** [Makefile:1004: all] Error 2 make[1]: Entering directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS' /bin/sh ../binutils-2.41/mkinstalldirs /usr/src/coreboot/util/crossgcc/xgcc /usr/src/coreboot/util/crossgcc/xgcc /bin/sh: line 4: cd: ./libsframe: No such file or directory make[1]: *** [Makefile:12900: install-libsframe] Error 1 make[1]: Leaving directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS' make: *** [Makefile:2580: install] Error 2

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot