- coreboot - mail.coreboot.org

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 27 Feb '24

27 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 27 Feb '24

27 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 22 Feb '24

22 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

2024-02-21 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 22 Feb '24

22 Feb '24

# 2024-02-21 - coreboot Leadership Meeting Minutes ## Attendees Martin Roth, Felix Held, Felix Singer, Jay Talbott, Julius Werner, Marcus Andrews, Matt DeVillier, Maximilian Brune, Nicholas Chin, Nico Huber, Stefan Reinauer, Patrick Georgi, Paul Menzel, Werner Zeh, Mina Asante, Daniel Maslowski, David Hendricks, Jules Irenge, Lean Sheng Tan, Marshall Dawson, Kharthik Ramasubramanian. ## Open Action Items * 2024-01-10 * Open Werner: Push patch based on https://ticket.coreboot.org/issues/522 * Nico: https://review.coreboot.org/q/topic:enforce_region_api * Open Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### We’ve switched to BigBlueButton for this meeting * https://bbb.sfconservancy.org/b/mar-sfn-e22-axi * For phone access, call +1-718-247-9666, then enter 89421 as the conference PIN number. * It looks like there’s only a USA phone number. * I found some apps, but they seem to be to run the meeting, not to join it. * See the coreboot calendar for times and more information. * There are a number of reasons for this change - I’ve listed 2 of the major reasons below. * We’d like to use open source projects in our infrastructure when we can, and not rely on proprietary services. * We’ve been using a google chat meeting set up by a google employee for all this time. This allows us to have more than the default number of users in a meeting, but has the downside that a google employee must be present on the call to allow people into the meeting. We’ve had several meetings recently where people were not being allowed in simply because no google employees had joined. We want to get rid of that issue. * [Felixh] Audio is much better than the last time we tried BBB. * Paul is a fan of BBB over google chat. * Julius usually does the meeting “on the go” and the BBB doesn’t work well for that. * Despite some small issues due to needing to learn about the new platform, the meeting went smoothly. BBB seems to work well enough to keep. ### [FelixH] Look at the type that we should be using for readXX * Currently we’ve been using void*, but it’s been argued that using an uintptr_t would be preferable. * Should we use ‘_Generic’? * We’d like to have just a single type. * Turned out to be very tedious to gather statistics. * Most values come from #defines and are integer types to begin with. * Things getting cast as (void *)(uintptr_t)var to use the current functions. * If there weren’t Arm code that was using pointers in structures, the recommendation would be to switch to uintptr_t, but with those, it would take a lot of reworking. * Can we just continue as we have been and cast everything to void * before reading and writing? Can we use macros to do this? * Objection to using an inline function that takes a uintptr_t and converts it to a void * - this can lead to bad practices? * FelixH - Opposed to getting rid of the uintptr_t functions * Werner - what is the most used type? Uintptr or void *? * Felix everything but arm uses more uintptr - arm uses void *. * It sounds like there are reasons for both functions. * Both functions go through the void* function, so it’s not two completely separate functions. * Shouldn’t have any real impact. * Felix will write up a document and present at least a few examples. **Decision: Due to the above, there are no objections to keeping both sets of functions at this point.** * David: But please let's avoid excessive casting or conversions. Go to EDK2 sources and grep for UINT and VOID in the same line to get a sense of what we should avoid… * Some data (added after the meeting): * It was a bit difficult and tedious manual process to get at least some statistics, since in some of the cases it wasn’t completely clear if some MMIO address should be counted as originally integer or originally pointer; if in doubt, I also looked at the call sites of functions to see which type the parameter that was used had originally. There are also quite a few helper macros and inline functions that wrap the different read/write functions making it even more difficult to get some good quantitative data, so this is mostly qualitative. * [read,write][8,16,32,64]p use integer MMIO addresses in all but 2 call sites * A lot of MMIO addresses are from defines and uintptr_t * Also some uint32_t, uint64_t or resource_t * The native RAM init for different Intel SoCs heavily uses read/write functions taking the MMIO addresses as uintptr_t * [read,write][8,16,32,64] use sometimes integer and sometimes pointer as source of the MMIO address that gets passed in as pointer * ‘&struct->element’ is a common construct to get the MMIO addresses in the Cavium, Mediatek, Nvidia, Qualcomm, Rockchip, Samsung, TI, and Sifive code; also used in the Designware I2C driver. Mediatek however also uses the [read,write][8,16,32,64]p functions in some places. * ‘&array[offset]’ is also a construct used in some places * res2mmio casts the resource_t value with (void *)(uintptr_t) so changing that to uintptr_t would be a bit more native * Buffer returned by rdev_readat is a pointer * Some ARM SoCs have the cast to a pointer in the defines * Other defines are mainly integers that get cast to pointers somewhere in the code * x86 SoC code uses a mixture of both integer and pointer MMIO functions, but the original MMIO addresses are in most cases integers. ### [Nico] Revoking Gerrit privileges as punishment. * I would like to discuss two matters about this. Not sure about the order. * My own case: I was removed from the core developers and reviewers groups 20 months ago. Without any charge nor chance to defend myself. There was Stefan's sentence, a discrediting rant about me with accusations that fit me not more than many other people, and an offer to reduce the sentence to a month if I were willing to come to the table. Which didn't make sense because I reached out to people long before Stefan's mail and it took Stefan, not me, over three months "to come to the table". And then he still couldn't tell me what I did worse than others. I asked again, Werner this time, what my charge is in 2023, again without results. And now I'm asking again. How can we make things better when we can't even say what was wrong? * [Martin] These issues are not discussed in a public forum where everyone with a pitchfork can get involved. That’s not useful. If you feel that the issues which led to this action being taken have changed, please email all the members of the leadership. Matt, Werner, and David. * Should we use Gerrit privileges as punishment at all? If so, shouldn't we have rules about it? * We will add this to the code of conduct page: ``` As a part of running the project, coreboot leadership has the right to revoke privileges as they see fit. This is not done lightly. Over the history of the coreboot project, there have been only a handful of times where an action needed to be taken. Discussions about these actions are not done publicly, for obvious reasons. If someone believes that the circumstances that led to an action have changed, please send an email to all the members of the leadership team for discussion. ``` I will note that this text is already there: ``` If a community member engages in unacceptable behavior, the community organizers may take any action they deem appropriate, up to and including a temporary ban or permanent expulsion from the community without warning (and without refund in the case of a paid event). ``` * [Code of Conduct](https://doc.coreboot.org/community/code_of_conduct.html). * Doesn't it hurt the project more when it loses a reviewer? (who can still get their own patches merged anyway) * [Martin] I’d say yes, and that’s something that the leadership group has to weigh when they decide to take an action against an individual. * [David] Yes, it does hurt the project when it loses a reviewer (or any contributor, for that matter). That's why it's important to deal with "toxic developers" effectively - to prevent others from leaving the project. No one developer is worth several others who will refuse to work with them. * Should we maybe do the opposite? don't merge their patches unless they do review? * [Martin] When the issue is something other than the quality of a person’s code, it doesn’t make sense to punish them by refusing to allow their patches to be merged. As many people in the community have jobs where they’re required to push code to coreboot, that could be the equivalent to getting them fired, which seems unfair. * If we want to use such punishment, should we apply it to other privileges as well? e.g. administrators, leadership members (IMO very important for trust inside the community) * [Martin] If two members of the leadership voted to take action against a third member, that’s completely allowed. The leadership team can take action as needed. I’ll note that I myself had submit rights taken away for a year. Yes, I’m one of the handful of cases mentioned. * David - We're in between two extremes - instant banning when someone is determined to have violated the code of conduct, and anything goes with little or no enforcement of rules. Neither are great, we try to use our discretion to smooth out issues in the long-run without being too heavy handed. * ...but is the process too opaque and complicated? We aren't lawyers and don't want a complicated "legal" system for coreboot. Rules need to be simple, universally understandable, and enforceable. Maybe we need to enforce stiff penalties, at least for a temporary term, before returning things to normal. * Paul - Make sure we have good communication. The “sentence” should be limited, and communicated to the person. * Stefan: What’s a reasonable length of time? There are 2 main situations that we’ve dealt with in the past. * 1) something happens and people get a slap on the wrist. * 2) There’s an ongoing issue that happens over and over. * One person who had an action taken against him refused to take responsibility and could not change, even after repeated talks. * Nico: Make sure that everyone involved is in the discussion. ### [Martin] Remove ChromeEC as a submodule - reimplement like a payload * The ChromeEC can currently be built (for some platforms) as a part of the coreboot build. It’s being downloaded as a submodule right now, but this creates a number of issues. With the change to Zephyr, the build process and requirements have changed. To address this, I’d like to propose that we drop the ChromeEC as a submodule, which restricts us to a single version of the code which can be used across all mainboards. With an implementation similar to what’s done for the payloads, the ChromeEC can still be pulled down by platforms which want to build it, and each platform can select a different commit if needed. **Decision: Go ahead and remove as a submodule. The new implementation can be reviewed in gerrit.** ### [Martin] Drop Tioga-pass & Skylake-SP? * Marc gave these both +2, so I’m inclined to believe they should be removed, as he was one of the significant contributors, but I’d like to get everyone’s input. “The platform code depends on unreleased binary files and uses incomplete public header files.” * https://review.coreboot.org/c/coreboot/+/80171 * https://review.coreboot.org/c/coreboot/+/80172 Should they be removed immediately as incomplete and unlikely to be finished? * David: Only applies to skylake Xeon-SP * Intel never allowed the release of the FSP. * Servers are much longer lived - no issue with this living on in a branch. * SKX servers are being decommissioned en masse at this point, so it would be nice if someone can find pointers to SysPro and how to get it working. * Jay: Worked on this for a good bit of time for IT Renew - had internal build working. FSP was working. Ran out of funding to complete the project. * Label it so that we could pick it back up if needed. * The framework is useful - we don’t want it to just be killed. * Millions of nodes available, but no interest in coreboot. * Nico: Arthur should be asked - this shares a lot of code with the newer generation of xeon-sp. This should probably be kept if possible. * FelixH: Shouldn’t just throw it out - shouldn’t cause too much of a burden. * FelixS: Will intel release future FSPs for these platforms? * David: They should be available somewhere (other than skylake). * Skylake-SP: Not officially supported, but available from SysPro with some caveats. * Cooper Lake: Not officially supported, but available from OCP Delta Lake firmware images. * Sapphire Rapids / Eagle Stream: FSP is on Github now: https://github.com/intel/FSP/tree/master/EagleStreamFspBinPkg * Granite Rapids: Will be put up on the Github FSP repo eventually. ### [David] Meraki (Cisco) - Escalate compliance issue to SFC * Another year, another potential GPL violation from Meraki. Late 2022/early 2023 we were dealing with a complaint about MX84 and MX250 products (Rangely and Broadwell-DE). Cisco did release the code eventually (https://github.com/halmartin/coreboot-mx84 and https://dl.meraki.net/bootloader-mx250-20230105.tar.bz2), but it took a little over a year from the initial request. This time the request is concerning the MS350. * I sent an e-mail to [open-source(a)meraki.com] in October '23, but aside from what appears to be a canned response (weirdly sent weeks later) there has been no progress. Time to escalate with SFC again. * What can be done to get Meraki into compliance in a friendly way? It's great to have a large vendor using coreboot and the relationship between Meraki and the coreboot community can be mutually beneficial, but only if everyone's rights are respected. * Martin: I’ve got ideas on how to make it easier to release, but I probably need help to get these done. * Licensing: create a license package that can be built into the coreboot image. These can be displayed by the setup engine or in the OS. * Package the specific build. I’ve created a tool - util/scripts/rm_unused_code that removes all of the unused source files from the coreboot tree, then creates a patch to delete those files. I’ve got an update for this patch, but haven’t had time to work on it in a while. * David will send an email to the mailing list asking for anyone from Cisco to help us with this before the lawyers get involved. ### [DanielM] “What is coreboot” draft progress 📝📈 * Met with David and Max last week, ended up with a good bunch of notes (4 pages, thanks a lot both of you!), will tidy them up and then present as the “final draft” next time 🙂 \ ### 24.02 release The release tag was done on Monday the 19th. The announcement will be done on Monday 2024_02_26 Next release is 24.05. * Martin: There’s some confusion about freezes and how the releases are done at this point. We need to document that. A lot has changed since the last time we documented the process. # Next meeting * March 6, 2024. * [Meeting link](https://bbb.sfconservancy.org/b/mar-sfn-e22-axi). * [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-02-21](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1….

1 0

Leadership meeting -- BigBlueButton mobile support
by Julius Werner 21 Feb '24

21 Feb '24

Hi, After we just tried out BigBlueButton for the meeting, I have to say that I found its mobile support unfortunately lacking. It doesn't have an official Android app as far as I can tell, and the only unofficial one I found (https://play.google.com/store/apps/details?id=com.bigbluebuttonmobile) says "this item isn't available in your country" when I try to install it in the US. I can open the website from a mobile browser but then it doesn't have any mobile-specific UI or features (like using the "phone call" speaker instead of the big one), so it's pretty useless for that. I usually need to take part of the meeting on the go, and it seems that the only useable option for that is the POTS phone bridge which is obviously not a great experience (can't raise hands, can't see when other people have hands raised, etc.). I'm not sure for what reasons other people were asking to switch away from Google Meet, but I just wanted to add the data point that at least for my use case, it worked way better.

1 0

QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed
by Mike Banon 20 Feb '24

20 Feb '24

If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore: ... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

6 11

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 19 Feb '24

19 Feb '24

Dear community, Please note that the upcoming coreboot leadership meeting is scheduled for next Wednesday, February 21, 2024.[1] You are welcome to update the current agenda items with matters you wish to see addressed during the meeting.[2] ## Current Agenda Items ### We’ve switched to BigBlueButton for this meeting. * https://bbb.sfconservancy.org/b/mar-sfn-e22-axi * For phone access, call +1-718-247-9666, then enter 89421 as the conference PIN number. * It looks like there’s only a USA phone number. * I found some apps, but they seem to be to run the meeting, not to join it. * See the coreboot calendar for times and more information ### [FelixH] Look at the type that we should be using for readXX * Currently we’ve been using void*, but it’s been argued that using an uintptr_t would be preferable. * Should we use ‘_Generic’? * We’d like to have just a single type. ### [Nico] Revoking Gerrit privileges as punishment. I would like to discuss two matters about this. Not sure about the order. * My own case: I was removed from the core developers and reviewers groups 20 months ago. Without any charge nor chance to defend myself. There was Stefan's sentence, a discrediting rant about me with accusations that fit me not more than many other people, and an offer to reduce the sentence to a month if I were willing to come to the table. Which didn't make sense because I reached out to people long before Stefan's mail and it took Stefan, not me, over three months "to come to the table". And then he still couldn't tell me what I did worse than others. I asked again, Werner this time, what my charge is in 2023, again without results. And now I'm asking again. How can we make things better when we can't even say what was wrong? * [Martin] These issues are not discussed in a public forum where everyone with a pitchfork can get involved. That’s not useful. If you feel that the issues which led to this action being taken have changed, please email all the members of the leadership. Matt, Werner, and David. * Should we use Gerrit privileges as punishment at all? If so, shouldn't we have rules about it? * We will add this to the code of conduct page: ``` As a part of running the project, coreboot leadership has the right to revoke privileges as they see fit. This is not done lightly. Over the history of the coreboot project, there have been only a handful of times where an action needed to be taken. Discussions about these actions are not done publicly, for obvious reasons. If someone believes that the circumstances that led to an action have changed, please send an email to all the members of the leadership team for discussion. ``` * I will note that this text is already there: ``` If a community member engages in unacceptable behavior, the community organizers may take any action they deem appropriate, up to and including a temporary ban or permanent expulsion from the community without warning (and without refund in the case of a paid event). ``` * https://doc.coreboot.org/community/code_of_conduct.html * Doesn't it hurt the project more when it loses a reviewer? (who can still get their own patches merged anyway). * [Martin] I’d say yes, and that’s something that the leadership group has to weigh when they decide to take an action against an individual. * [David] Yes, it does hurt the project when it loses a reviewer (or any contributor, for that matter). That's why it's important to deal with "toxic developers" effectively - to prevent others from leaving the project. No one developer is worth several others who will refuse to work with them. * Should we maybe do the opposite? don't merge their patches unless they do review? * [Martin] When the issue is something other than the quality of a person’s code, it doesn’t make sense to punish them by refusing to allow their patches to be merged. As many people in the community have jobs where they’re required to push code to coreboot, that could be the equivalent to getting them fired, which seems unfair. * If we want to use such punishment, should we apply it to other privileges as well? e.g. administrators, leadership members (IMO very important for trust inside the community) * [Martin] If two members of the leadership voted to take action against a third member, that’s completely allowed. The leadership team can take action as needed. I’ll note that I myself had submit rights taken away for a year. Yes, I’m one of the handful of cases mentioned. ### [Martin] Remove ChromeEC as a submodule - reimplement like a payload * The ChromeEC can currently be built (for some platforms) as a part of the coreboot build. It’s being downloaded as a submodule right now, but this creates a number of issues. With the change to Zephyr, the build process and requirements have changed. To address this, I’d like to propose that we drop the ChromeEC as a submodule, which restricts us to a single version of the code which can be used across all mainboards. With an implementation similar to what’s done for the payloads, the ChromeEC can still be pulled down by platforms which want to build it, and each platform can select a different commit if needed. ### [Martin] Drop Tioga-pass & Xeon-sp? * Marc gave these both +2, so I’m inclined to believe they should be removed, as he was one of the significant contributors, but I’d like to get everyone’s input. “The platform code depends on unreleased binary files and uses incomplete public header files.” https://review.coreboot.org/c/coreboot/+/80171 https://review.coreboot.org/c/coreboot/+/80172 Should they be removed immediately as incomplete and unlikely to be finished? ### 24.02 release * The release tag was done on Monday the 19th. * The announcement will be done on Monday 2024_02_26. * Next release is 24.05. [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

4 3

[coreboot - Bug #524] (New) `CONFIG_X2APIC_ONLY=y`or `CONFIG_X2APIC_RUNTIME=y` cause Linux in emulation/qemu-i440fx to crash
by Paul Menzel 19 Feb '24

19 Feb '24

Issue #524 has been reported by Paul Menzel. ---------------------------------------- Bug #524: `CONFIG_X2APIC_ONLY=y`or `CONFIG_X2APIC_RUNTIME=y` cause Linux in emulation/qemu-i440fx to crash https://ticket.coreboot.org/issues/524 * Author: Paul Menzel * Status: New * Priority: Normal * Target version: none * Start date: 2024-02-04 * Affected versions: 4.21 ---------------------------------------- Build coreboot for `emulation/qemu-i440fx` with `CONFIG_X2APIC_ONLY=y`or `CONFIG_X2APIC_RUNTIME=y` causes Linux to crash: ### `CONFIG_X2APIC_ONLY=y` ``` $ qemu-system-x86_64 -bios /dev/shm/coreboot/build/coreboot.rom -L /dev/shm -enable-kvm -smp cpus=2 -m 1G -hda /dev/shm/debian-32.img -serial stdio -net nic -net user,hostfwd=tcp::22222-:22 WARNING: Image format was not specified for '/dev/shm/debian-32.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. [NOTE ] coreboot-4.22-671-g416cc665929e Fri Feb 02 20:40:20 UTC 2024 x86_64 bootblock starting (log level: 7)... [INFO ] Timestamp - end of bootblock: 18374588 [INFO ] Timestamp - start of romstage: 20847149 [INFO ] QEMU: firmware config interface detected [INFO ] Firmware config version id: 3 [INFO ] QEMU: firmware config: Found 'etc/e820' [DEBUG] CBMEM: [DEBUG] IMD: root @ 0x3ffff000 254 entries. [DEBUG] IMD: root @ 0x3fffec00 62 entries. [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x0. [DEBUG] FMAP: base = 0xffc00000 size = 0x400000 #areas = 3 [DEBUG] FMAP: area COREBOOT found @ 200 (4193792 bytes) [INFO ] CBFS: mcache @0x00014e00 built for 13 files, used 0x294 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/postcar' @0x1c140 size 0x91b0 in mcache @0x00014fe0 [DEBUG] Loading module at 0x3ffce000 with entry 0x3ffce042. filesize: 0x7d90 memsize: 0xe118 [DEBUG] Processing 636 relocs. Offset value of 0x3dfce000 [INFO ] Timestamp - end of romstage: 69275568 [DEBUG] BS: bootblock times (exec / console): total (unknown) / 12 ms [NOTE ] coreboot-4.22-671-g416cc665929e Fri Feb 02 20:40:20 UTC 2024 x86_64 postcar starting (log level: 7)... [INFO ] Timestamp - start of postcar: 113911520 [INFO ] Timestamp - end of postcar: 117105771 [INFO ] Timestamp - starting to load ramstage: 121657944 [DEBUG] FMAP: area COREBOOT found @ 200 (4193792 bytes) [INFO ] CBFS: Found 'fallback/ramstage' @0xd040 size 0xf072 in mcache @0x3fffeaec [INFO ] Timestamp - starting LZMA decompress (ignore for x86): 133785778 [INFO ] Timestamp - finished LZMA decompress (ignore for x86): 158178845 [DEBUG] Loading module at 0x3fe9d000 with entry 0x3fe9d000. filesize: 0x234e0 memsize: 0x12fe28 [DEBUG] Processing 3390 relocs. Offset value of 0x3be9d000 [INFO ] Timestamp - finished loading ramstage: 193391473 [DEBUG] BS: postcar times (exec / console): total (unknown) / 5 ms [NOTE ] coreboot-4.22-671-g416cc665929e Fri Feb 02 20:40:20 UTC 2024 x86_64 ramstage starting (log level: 7)... [INFO ] Timestamp - start of ramstage: 216358307 [INFO ] Timestamp - device enumeration: 219906562 [DEBUG] BS: BS_DEV_INIT_CHIPS run times (exec / console): 0 / 1 ms [INFO ] Enumerating buses... [DEBUG] Root Device scanning... [DEBUG] CPU_CLUSTER: 0 enabled [DEBUG] DOMAIN: 00000000 enabled [DEBUG] DOMAIN: 00000000 scanning... [DEBUG] PCI: pci_scan_bus for segment group 00 bus 00 [DEBUG] PCI: 00:00:00.0 [8086/1237] enabled [DEBUG] PCI: 00:00:01.0 [8086/7000] enabled [DEBUG] PCI: 00:00:01.1 [8086/7010] enabled [DEBUG] PCI: 00:00:01.3 [8086/7113] enabled [DEBUG] PCI: 00:00:02.0 [1234/1111] enabled [DEBUG] PCI: 00:00:03.0 [8086/100e] enabled [DEBUG] PCI: 00:00:01.0 scanning... [DEBUG] scan_bus: bus PCI: 00:00:01.0 finished in 0 msecs [DEBUG] PCI: 00:00:01.3 scanning... [DEBUG] scan_bus: bus PCI: 00:00:01.3 finished in 0 msecs [DEBUG] scan_bus: bus DOMAIN: 00000000 finished in 14 msecs [DEBUG] scan_bus: bus Root Device finished in 18 msecs [INFO ] done [DEBUG] BS: BS_DEV_ENUMERATE run times (exec / console): 1 / 21 ms [INFO ] Timestamp - device configuration: 298893234 [DEBUG] found VGA at PCI: 00:00:02.0 [DEBUG] Setting up VGA for PCI: 00:00:02.0 [DEBUG] Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 00000000 [DEBUG] Setting PCI_BRIDGE_CTL_VGA for bridge Root Device [INFO ] Allocating resources... [INFO ] Reading resources... [INFO ] QEMU: firmware config interface detected [INFO ] Firmware config version id: 3 [INFO ] QEMU: firmware config: Found 'etc/e820' [DEBUG] QEMU: e820/res: 0xfeffc000 +0x00004000 [DEBUG] QEMU: e820/ram: 0x00000000 + 0x40000000 [DEBUG] QEMU: reserve ioports 0x0510-0x0511 [firmware-config] [DEBUG] QEMU: reserve ioports 0x5658-0x5658 [vmware-port] [DEBUG] QEMU: reserve ioports 0xae00-0xae0f [pci-hotplug] [DEBUG] QEMU: reserve ioports 0xaf00-0xaf1f [cpu-hotplug] [DEBUG] QEMU: reserve ioports 0xafe0-0xafe3 [piix4-gpe0] [INFO ] Done reading resources. [INFO ] === Resource allocator: DOMAIN: 00000000 - Pass 1 (relative placement) === [INFO ] === Resource allocator: DOMAIN: 00000000 - Pass 2 (allocating resources) === [DEBUG] DOMAIN: 00000000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0d base 00000510 limit 00000511 io (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0e base 00005658 limit 00005658 io (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0f base 0000ae00 limit 0000ae0f io (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 10 base 0000af00 limit 0000af1f io (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 11 base 0000afe0 limit 0000afe3 io (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.0 01 base 00000000 limit 00000fff io (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.3 01 base 0000e400 limit 0000e43f io (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.3 02 base 00000f00 limit 00000f0f io (fixed) [INFO ] DOMAIN: 00000000: Resource ranges: [INFO ] * Base: 1000, Size: 4658, Tag: 100 [INFO ] * Base: 5659, Size: 57a7, Tag: 100 [INFO ] * Base: ae10, Size: f0, Tag: 100 [INFO ] * Base: af20, Size: c0, Tag: 100 [INFO ] * Base: afe4, Size: 341c, Tag: 100 [INFO ] * Base: e440, Size: 1bc0, Tag: 100 [DEBUG] PCI: 00:00:03.0 14 * [0xffc0 - 0xffff] limit: ffff io [DEBUG] PCI: 00:00:01.1 20 * [0xffb0 - 0xffbf] limit: ffbf io [DEBUG] DOMAIN: 00000000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done [DEBUG] DOMAIN: 00000000 mem: base: 40000000 size: 0 align: 0 gran: 0 limit: fdffffff [DEBUG] DOMAIN: 00000000 mem: base: 100000000 size: 0 align: 0 gran: 0 limit: ffffffffff [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0a base feffc000 limit feffffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0b base 00000000 limit 0009ffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0c base 000c0000 limit 3fffffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 12 base 000a0000 limit 000bffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 13 base 000c0000 limit 000fffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 02 base fec00000 limit fecfffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 03 base fee00000 limit fee0ffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 00 base 00008000 limit 0000dfff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.0 02 base ff800000 limit ffffffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.0 03 base fec00000 limit fec00fff mem (fixed) [INFO ] DOMAIN: 00000000: Resource ranges: [INFO ] * Base: 40000000, Size: be000000, Tag: 200 [INFO ] * Base: 100000000, Size: ff00000000, Tag: 200 [DEBUG] PCI: 00:00:02.0 10 * [0xfd000000 - 0xfdffffff] limit: fdffffff prefmem [DEBUG] PCI: 00:00:03.0 30 * [0xfcfc0000 - 0xfcffffff] limit: fcffffff mem [DEBUG] PCI: 00:00:03.0 10 * [0xfcfa0000 - 0xfcfbffff] limit: fcfbffff mem [DEBUG] PCI: 00:00:02.0 30 * [0xfcf90000 - 0xfcf9ffff] limit: fcf9ffff mem [DEBUG] PCI: 00:00:02.0 18 * [0xfcf8f000 - 0xfcf8ffff] limit: fcf8ffff mem [DEBUG] DOMAIN: 00000000 mem: base: 40000000 size: 0 align: 0 gran: 0 limit: fdffffff done [DEBUG] DOMAIN: 00000000 mem: base: 100000000 size: 0 align: 0 gran: 0 limit: ffffffffff done [INFO ] === Resource allocator: DOMAIN: 00000000 - resource allocation complete === [DEBUG] PCI: 00:00:01.1 20 <- [0x000000000000ffb0 - 0x000000000000ffbf] size 0x00000010 gran 0x04 io [DEBUG] PCI: 00:00:02.0 10 <- [0x00000000fd000000 - 0x00000000fdffffff] size 0x01000000 gran 0x18 prefmem [DEBUG] PCI: 00:00:02.0 18 <- [0x00000000fcf8f000 - 0x00000000fcf8ffff] size 0x00001000 gran 0x0c mem [DEBUG] PCI: 00:00:02.0 30 <- [0x00000000fcf90000 - 0x00000000fcf9ffff] size 0x00010000 gran 0x10 romem [DEBUG] PCI: 00:00:03.0 10 <- [0x00000000fcfa0000 - 0x00000000fcfbffff] size 0x00020000 gran 0x11 mem [DEBUG] PCI: 00:00:03.0 14 <- [0x000000000000ffc0 - 0x000000000000ffff] size 0x00000040 gran 0x06 io [DEBUG] PCI: 00:00:03.0 30 <- [0x00000000fcfc0000 - 0x00000000fcffffff] size 0x00040000 gran 0x12 romem [INFO ] Done setting resources. [INFO ] Done allocating resources. [DEBUG] BS: BS_DEV_RESOURCES run times (exec / console): 5 / 126 ms [INFO ] Timestamp - device enable: 684358641 [INFO ] Enabling resources... [DEBUG] PCI: 00:00:00.0 cmd <- 00 [DEBUG] PCI: 00:00:01.0 cmd <- 00 [DEBUG] PCI: 00:00:01.1 cmd <- 01 [DEBUG] PCI: 00:00:01.3 cmd <- 00 [DEBUG] PCI: 00:00:02.0 cmd <- 03 [DEBUG] PCI: 00:00:03.0 cmd <- 03 [INFO ] done. [DEBUG] BS: BS_DEV_ENABLE run times (exec / console): 2 / 7 ms [DEBUG] BS: BS_DEV_INIT entry times (exec / console): 2 / 0 ms [INFO ] Timestamp - device initialization: 727416775 [INFO ] Initializing devices... [DEBUG] CPU_CLUSTER: 0 init [INFO ] CPU: QEMU Virtual CPU version 2.5+. [INFO ] LAPIC 0x0 switched to X2APIC mode. [DEBUG] CPU: APIC: 00 enabled [DEBUG] CPU: APIC: 01 enabled [DEBUG] Loading module at 0x00030000 with entry 0x00030000. filesize: 0x1b8 memsize: 0x1b8 [DEBUG] Processing 17 relocs. Offset value of 0x00030000 [DEBUG] Attempting to start 1 APs [DEBUG] Waiting for 10ms after sending INIT. [DEBUG] Waiting for SIPI to complete... [INFO ] LAPIC 0x1 switched to X2APIC mode. [DEBUG] done. [INFO ] AP: slot 1 apic_id 1 [DEBUG] Waiting for SIPI to complete... [DEBUG] done. [INFO ] Initializing CPU #0 [DEBUG] CPU: vendor Intel device 60fb1 [DEBUG] CPU: family 0f, model 6b, stepping 01 [INFO ] CPU #0 initialized [INFO ] Initializing CPU #1 [DEBUG] CPU: vendor Intel device 60fb1 [DEBUG] CPU: family 0f, model 6b, stepping 01 [INFO ] CPU #1 initialized [INFO ] bsp_do_flight_plan done after 7 msecs. [DEBUG] CPU_CLUSTER: 0 init finished in 30 msecs [DEBUG] PCI: 00:00:00.0 init [DEBUG] Assigning IRQ 10 to PCI: 00:00:01.3 [DEBUG] Assigning IRQ 11 to PCI: 00:00:03.0 [DEBUG] PCI: 00:00:00.0 init finished in 7 msecs [DEBUG] PCI: 00:00:01.0 init [DEBUG] RTC Init [DEBUG] IOAPIC: Initializing IOAPIC at 0xfec00000 [DEBUG] IOAPIC: ID = 0x02 [DEBUG] IOAPIC: 24 interrupts [DEBUG] IOAPIC: Clearing IOAPIC at 0xfec00000 [DEBUG] IOAPIC: Bootstrap Processor Local APIC = 0x00 [DEBUG] PCI: 00:00:01.0 init finished in 5 msecs [DEBUG] PCI: 00:00:01.1 init [DEBUG] IDE: Primary interface: on [DEBUG] IDE: Secondary interface: on [DEBUG] IDE: Access to legacy IDE ports: off [DEBUG] PCI: 00:00:01.1 init finished in 3 msecs [DEBUG] PCI: 00:00:02.0 init [DEBUG] PCI: 00:00:02.0 init finished in 35 msecs [DEBUG] PCI: 00:00:03.0 init [DEBUG] PCI: 00:00:03.0 init finished in 0 msecs [INFO ] Devices initialized [DEBUG] BS: BS_DEV_INIT run times (exec / console): 57 / 43 ms [INFO ] Finalize devices... [INFO ] Devices finalized [INFO ] Timestamp - device setup done: 1027392332 [DEBUG] BS: BS_POST_DEVICE run times (exec / console): 0 / 3 ms [INFO ] Timestamp - cbmem post: 1037915018 [DEBUG] BS: BS_OS_RESUME_CHECK run times (exec / console): 0 / 1 ms [INFO ] Timestamp - write tables: 1046578108 [INFO ] Copying Interrupt Routing Table to 0x000f0000... done. [INFO ] Copying Interrupt Routing Table to 0x3fe93000... done. [DEBUG] PIRQ table: 128 bytes. [INFO ] QEMU: firmware config: Found 'etc/table-loader' [DEBUG] QEMU: found ACPI tables in fw_cfg. [INFO ] QEMU: firmware config: Found 'etc/acpi/rsdp' [DEBUG] QEMU: loading "etc/acpi/rsdp" to 0x3fe6f000 (len 20) [INFO ] QEMU: firmware config: Found 'etc/acpi/tables' [DEBUG] QEMU: loading "etc/acpi/tables" to 0x3fe6f040 (len 131072) [DEBUG] QEMU: loaded ACPI tables from fw_cfg. [DEBUG] Looking on 0x3fe6f000 for valid checksum [DEBUG] Checksum 1 passed [DEBUG] Checksum 2 passed all OK [DEBUG] ACPI: added table 1/32, length now 44 [DEBUG] ACPI: added table 2/32, length now 52 [DEBUG] ACPI: added table 3/32, length now 60 [DEBUG] ACPI: added table 4/32, length now 68 [DEBUG] ACPI: * SSDT [DEBUG] Found 2 CPU(s). [DEBUG] ACPI: added table 5/32, length now 76 [DEBUG] ACPI tables: 131136 bytes. [DEBUG] smbios_write_tables: 3fe67000 [DEBUG] SMBIOS firmware version is set to coreboot_version: '4.22-671-g416cc665929e' [DEBUG] SMBIOS: Unknown CPU or CPU doesn't support Deterministic Cache CPUID leaf [INFO ] DOMAIN: 00000000 (QEMU Northbridge i440fx) [INFO ] QEMU: firmware config: Found 'etc/smbios/smbios-tables' [DEBUG] QEMU: found smbios tables in fw_cfg (len 327). [DEBUG] QEMU: coreboot type0 table found at 0x3fe67040. [DEBUG] QEMU: loading smbios tables to 0x3fe67086 [DEBUG] SMBIOS tables: 461 bytes. [DEBUG] Writing table forward entry at 0x00000500 [DEBUG] Wrote coreboot table at: 0x00000500, 0x10 bytes, checksum 7ff5 [DEBUG] Writing coreboot table at 0x3fe94000 [DEBUG] 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES [DEBUG] 1. 0000000000001000-0000000000007fff: RAM [DEBUG] 2. 0000000000008000-000000000000dfff: RESERVED [DEBUG] 3. 000000000000e000-000000000009ffff: RAM [DEBUG] 4. 00000000000a0000-00000000000fffff: RESERVED [DEBUG] 5. 0000000000100000-000000003fe66fff: RAM [DEBUG] 6. 000000003fe67000-000000003fe9cfff: CONFIGURATION TABLES [DEBUG] 7. 000000003fe9d000-000000003ffccfff: RAMSTAGE [DEBUG] 8. 000000003ffcd000-000000003fffffff: CONFIGURATION TABLES [DEBUG] 9. 00000000fec00000-00000000fec00fff: RESERVED [DEBUG] 10. 00000000ff800000-00000000ffffffff: RESERVED [DEBUG] FMAP: area COREBOOT found @ 200 (4193792 bytes) [DEBUG] Wrote coreboot table at: 0x3fe94000, 0x310 bytes, checksum 85a4 [DEBUG] coreboot table: 808 bytes. [DEBUG] IMD ROOT 0. 0x3ffff000 0x00001000 [DEBUG] IMD SMALL 1. 0x3fffe000 0x00001000 [DEBUG] CONSOLE 2. 0x3ffde000 0x00020000 [DEBUG] TIME STAMP 3. 0x3ffdd000 0x00000910 [DEBUG] AFTER CAR 4. 0x3ffcd000 0x00010000 [DEBUG] RAMSTAGE 5. 0x3fe9c000 0x00131000 [DEBUG] COREBOOT 6. 0x3fe94000 0x00008000 [DEBUG] IRQ TABLE 7. 0x3fe93000 0x00001000 [DEBUG] ACPI 8. 0x3fe6f000 0x00024000 [DEBUG] SMBIOS 9. 0x3fe67000 0x00008000 [DEBUG] IMD small region: [DEBUG] IMD ROOT 0. 0x3fffec00 0x00000400 [DEBUG] RO MCACHE 1. 0x3fffe960 0x00000294 [DEBUG] FMAP 2. 0x3fffe8a0 0x000000b6 [DEBUG] ROMSTG STCK 3. 0x3fffe800 0x00000088 [INFO ] Timestamp - finalize chips: 1281447080 [DEBUG] BS: BS_WRITE_TABLES run times (exec / console): 4 / 77 ms [INFO ] Timestamp - starting to load payload: 1287927356 [INFO ] CBFS: Found 'fallback/payload' @0x25340 size 0x10049 in mcache @0x3fffeb84 [DEBUG] Checking segment from ROM address 0xffc2556c [DEBUG] Checking segment from ROM address 0xffc25588 [DEBUG] Loading segment from ROM address 0xffc2556c [DEBUG] code (compression=1) [DEBUG] New segment dstaddr 0x00100000 memsize 0x135a30 srcaddr 0xffc255a4 filesize 0x10011 [DEBUG] Loading Segment: addr: 0x00100000 memsz: 0x0000000000135a30 filesz: 0x0000000000010011 [DEBUG] using LZMA [INFO ] Timestamp - starting LZMA decompress (ignore for x86): 1321754094 [INFO ] Timestamp - finished LZMA decompress (ignore for x86): 1342389486 [DEBUG] Clearing Segment: addr: 0x000000000011eb68 memsz: 0x0000000000116ec8 [DEBUG] Loading segment from ROM address 0xffc25588 [DEBUG] Entry Point 0x00100000 [DEBUG] BS: BS_PAYLOAD_LOAD run times (exec / console): 6 / 19 ms [DEBUG] Jumping to boot code at 0x00100000(0x3fe94000) [INFO ] Timestamp - selfboot jump: 1370405009 coreboot: 4.22-671-g416cc665929e FILO version 0.6.0 (pmenzel@abreu) Sun Feb 4 13:23:12 UTC 2024 Press <Enter> for default boot, or <Esc> for boot prompt... timed out boot: hda1:/vmlinuz initrd=hda1:/initrd.img root=/dev/sda1 ro quiet console=ttyS0,115200 ATA-0: [io ports 0x1f0-0x1f7,0x3f6] * hda [ATA Disk]: QEMU HARDDISK Found Linux version 5.6.0-1-686-pae (debian-kernel(a)lists.debian.org) #1 SMP Debian 5.6.7-1 (2020-04-29) relocatable bzImage. Loading kernel... ok Loading initrd... ok Jumping to entry point... [ 0.051519] kernel BUG at arch/x86/kernel/apic/apic.c:1629! [ 0.052720] invalid opcode: 0000 [#1] SMP PTI [ 0.053664] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-1-686-pae #1 Debian 5.6.7-1 [ 0.055428] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 4.22-671-g416cc665929e 02/02/2024 [ 0.057435] EIP: setup_local_APIC+0x478/0x4b0 [ 0.058334] Code: fe ff ff 85 d2 0f 8f bd 11 00 00 a1 e0 06 93 df ba 00 07 01 00 8b 48 08 b8 50 03 00 00 e8 20 92 6f 00 e9 db fe ff ff 8d 76 00 <0f> 0b 8d b6 00 00 00 00 0f 0b e9 4b fc ff ff e8 d4 4b 02 00 a1 e0 [ 0.061881] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: ffffffff [ 0.063022] ESI: dfaac8cd EDI: 00000000 EBP: df993f64 ESP: df993f14 [ 0.064306] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246 [ 0.065936] CR0: 80050033 CR2: ff9ff000 CR3: 1fb48000 CR4: 000006b0 [ 0.066869] Call Trace: [ 0.067243] ? vprintk_default+0x17/0x20 [ 0.067871] ? kvm_arch_para_features+0x43/0x80 [ 0.068468] apic_intr_mode_init+0xf4/0x10a [ 0.069017] x86_late_time_init+0x1d/0x24 [ 0.069544] start_kernel+0x3f9/0x4ac [ 0.070027] i386_start_kernel+0x48/0x4a [ 0.070543] startup_32_smp+0x164/0x168 [ 0.071118] Modules linked in: [ 0.071619] ---[ end trace 61fac992e46bca1b ]--- [ 0.072257] EIP: setup_local_APIC+0x478/0x4b0 [ 0.072850] Code: fe ff ff 85 d2 0f 8f bd 11 00 00 a1 e0 06 93 df ba 00 07 01 00 8b 48 08 b8 50 03 00 00 e8 20 92 6f 00 e9 db fe ff ff 8d 76 00 <0f> 0b 8d b6 00 00 00 00 0f 0b e9 4b fc ff ff e8 d4 4b 02 00 a1 e0 [ 0.075365] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: ffffffff [ 0.076426] ESI: dfaac8cd EDI: 00000000 EBP: df993f64 ESP: df993f14 [ 0.077327] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246 [ 0.078485] CR0: 80050033 CR2: ff9ff000 CR3: 1fb48000 CR4: 000006b0 [ 0.079731] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.081327] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- ``` ### `CONFIG_X2APIC_RUNTIME=y` ``` $ qemu-system-x86_64 -bios /dev/shm/coreboot/build/coreboot.rom -L /dev/shm -enable-kvm -smp cpus=2 -m 1G -hda /dev/shm/debian-32.img -serial stdio -net nic -net user,hostfwd=tcp::22222-:22 WARNING: Image format was not specified for '/dev/shm/debian-32.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. [NOTE ] coreboot-4.22-671-g416cc665929e Fri Feb 02 20:40:20 UTC 2024 x86_64 bootblock starting (log level: 7)... [INFO ] Timestamp - end of bootblock: 16577474 [INFO ] Timestamp - start of romstage: 18671246 [INFO ] QEMU: firmware config interface detected [INFO ] Firmware config version id: 3 [INFO ] QEMU: firmware config: Found 'etc/e820' [DEBUG] CBMEM: [DEBUG] IMD: root @ 0x3ffff000 254 entries. [DEBUG] IMD: root @ 0x3fffec00 62 entries. [DEBUG] FMAP: Found "FLASH" version 1.1 at 0x0. [DEBUG] FMAP: base = 0xffc00000 size = 0x400000 #areas = 3 [DEBUG] FMAP: area COREBOOT found @ 200 (4193792 bytes) [INFO ] CBFS: mcache @0x00014e00 built for 13 files, used 0x294 of 0x4000 bytes [INFO ] CBFS: Found 'fallback/postcar' @0x1c280 size 0x91b0 in mcache @0x00014fe0 [DEBUG] Loading module at 0x3ffce000 with entry 0x3ffce042. filesize: 0x7d90 memsize: 0xe118 [DEBUG] Processing 636 relocs. Offset value of 0x3dfce000 [INFO ] Timestamp - end of romstage: 67022354 [DEBUG] BS: bootblock times (exec / console): total (unknown) / 21 ms [NOTE ] coreboot-4.22-671-g416cc665929e Fri Feb 02 20:40:20 UTC 2024 x86_64 postcar starting (log level: 7)... [INFO ] Timestamp - start of postcar: 90003960 [INFO ] Timestamp - end of postcar: 93116574 [INFO ] Timestamp - starting to load ramstage: 95752126 [DEBUG] FMAP: area COREBOOT found @ 200 (4193792 bytes) [INFO ] CBFS: Found 'fallback/ramstage' @0xd040 size 0xf1b6 in mcache @0x3fffeaec [INFO ] Timestamp - starting LZMA decompress (ignore for x86): 134002537 [INFO ] Timestamp - finished LZMA decompress (ignore for x86): 159465672 [DEBUG] Loading module at 0x3fe9c000 with entry 0x3fe9c000. filesize: 0x239e0 memsize: 0x130328 [DEBUG] Processing 3412 relocs. Offset value of 0x3be9c000 [INFO ] Timestamp - finished loading ramstage: 173672609 [DEBUG] BS: postcar times (exec / console): total (unknown) / 25 ms [NOTE ] coreboot-4.22-671-g416cc665929e Fri Feb 02 20:40:20 UTC 2024 x86_64 ramstage starting (log level: 7)... [INFO ] Timestamp - start of ramstage: 212046129 [INFO ] Timestamp - device enumeration: 215792182 [DEBUG] BS: BS_DEV_INIT_CHIPS run times (exec / console): 0 / 1 ms [INFO ] Enumerating buses... [DEBUG] Root Device scanning... [DEBUG] CPU_CLUSTER: 0 enabled [DEBUG] DOMAIN: 00000000 enabled [DEBUG] DOMAIN: 00000000 scanning... [DEBUG] PCI: pci_scan_bus for segment group 00 bus 00 [DEBUG] PCI: 00:00:00.0 [8086/1237] enabled [DEBUG] PCI: 00:00:01.0 [8086/7000] enabled [DEBUG] PCI: 00:00:01.1 [8086/7010] enabled [DEBUG] PCI: 00:00:01.3 [8086/7113] enabled [DEBUG] PCI: 00:00:02.0 [1234/1111] enabled [DEBUG] PCI: 00:00:03.0 [8086/100e] enabled [DEBUG] PCI: 00:00:01.0 scanning... [DEBUG] scan_bus: bus PCI: 00:00:01.0 finished in 0 msecs [DEBUG] PCI: 00:00:01.3 scanning... [DEBUG] scan_bus: bus PCI: 00:00:01.3 finished in 0 msecs [DEBUG] scan_bus: bus DOMAIN: 00000000 finished in 14 msecs [DEBUG] scan_bus: bus Root Device finished in 18 msecs [INFO ] done [DEBUG] BS: BS_DEV_ENUMERATE run times (exec / console): 1 / 21 ms [INFO ] Timestamp - device configuration: 293163829 [DEBUG] found VGA at PCI: 00:00:02.0 [DEBUG] Setting up VGA for PCI: 00:00:02.0 [DEBUG] Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 00000000 [DEBUG] Setting PCI_BRIDGE_CTL_VGA for bridge Root Device [INFO ] Allocating resources... [INFO ] Reading resources... [INFO ] QEMU: firmware config interface detected [INFO ] Firmware config version id: 3 [INFO ] QEMU: firmware config: Found 'etc/e820' [DEBUG] QEMU: e820/res: 0xfeffc000 +0x00004000 [DEBUG] QEMU: e820/ram: 0x00000000 + 0x40000000 [DEBUG] QEMU: reserve ioports 0x0510-0x0511 [firmware-config] [DEBUG] QEMU: reserve ioports 0x5658-0x5658 [vmware-port] [DEBUG] QEMU: reserve ioports 0xae00-0xae0f [pci-hotplug] [DEBUG] QEMU: reserve ioports 0xaf00-0xaf1f [cpu-hotplug] [DEBUG] QEMU: reserve ioports 0xafe0-0xafe3 [piix4-gpe0] [INFO ] Done reading resources. [INFO ] === Resource allocator: DOMAIN: 00000000 - Pass 1 (relative placement) === [INFO ] === Resource allocator: DOMAIN: 00000000 - Pass 2 (allocating resources) === [DEBUG] DOMAIN: 00000000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0d base 00000510 limit 00000511 io (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0e base 00005658 limit 00005658 io (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0f base 0000ae00 limit 0000ae0f io (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 10 base 0000af00 limit 0000af1f io (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 11 base 0000afe0 limit 0000afe3 io (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.0 01 base 00000000 limit 00000fff io (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.3 01 base 0000e400 limit 0000e43f io (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.3 02 base 00000f00 limit 00000f0f io (fixed) [INFO ] DOMAIN: 00000000: Resource ranges: [INFO ] * Base: 1000, Size: 4658, Tag: 100 [INFO ] * Base: 5659, Size: 57a7, Tag: 100 [INFO ] * Base: ae10, Size: f0, Tag: 100 [INFO ] * Base: af20, Size: c0, Tag: 100 [INFO ] * Base: afe4, Size: 341c, Tag: 100 [INFO ] * Base: e440, Size: 1bc0, Tag: 100 [DEBUG] PCI: 00:00:03.0 14 * [0xffc0 - 0xffff] limit: ffff io [DEBUG] PCI: 00:00:01.1 20 * [0xffb0 - 0xffbf] limit: ffbf io [DEBUG] DOMAIN: 00000000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done [DEBUG] DOMAIN: 00000000 mem: base: 40000000 size: 0 align: 0 gran: 0 limit: fdffffff [DEBUG] DOMAIN: 00000000 mem: base: 100000000 size: 0 align: 0 gran: 0 limit: ffffffffff [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0a base feffc000 limit feffffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0b base 00000000 limit 0009ffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 0c base 000c0000 limit 3fffffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 12 base 000a0000 limit 000bffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 13 base 000c0000 limit 000fffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 02 base fec00000 limit fecfffff mem (fixed) [DEBUG] avoid_fixed_resources: DOMAIN: 00000000 03 base fee00000 limit fee0ffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:00.0 00 base 00008000 limit 0000dfff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.0 02 base ff800000 limit ffffffff mem (fixed) [DEBUG] avoid_fixed_resources: PCI: 00:00:01.0 03 base fec00000 limit fec00fff mem (fixed) [INFO ] DOMAIN: 00000000: Resource ranges: [INFO ] * Base: 40000000, Size: be000000, Tag: 200 [INFO ] * Base: 100000000, Size: ff00000000, Tag: 200 [DEBUG] PCI: 00:00:02.0 10 * [0xfd000000 - 0xfdffffff] limit: fdffffff prefmem [DEBUG] PCI: 00:00:03.0 30 * [0xfcfc0000 - 0xfcffffff] limit: fcffffff mem [DEBUG] PCI: 00:00:03.0 10 * [0xfcfa0000 - 0xfcfbffff] limit: fcfbffff mem [DEBUG] PCI: 00:00:02.0 30 * [0xfcf90000 - 0xfcf9ffff] limit: fcf9ffff mem [DEBUG] PCI: 00:00:02.0 18 * [0xfcf8f000 - 0xfcf8ffff] limit: fcf8ffff mem [DEBUG] DOMAIN: 00000000 mem: base: 40000000 size: 0 align: 0 gran: 0 limit: fdffffff done [DEBUG] DOMAIN: 00000000 mem: base: 100000000 size: 0 align: 0 gran: 0 limit: ffffffffff done [INFO ] === Resource allocator: DOMAIN: 00000000 - resource allocation complete === [DEBUG] PCI: 00:00:01.1 20 <- [0x000000000000ffb0 - 0x000000000000ffbf] size 0x00000010 gran 0x04 io [DEBUG] PCI: 00:00:02.0 10 <- [0x00000000fd000000 - 0x00000000fdffffff] size 0x01000000 gran 0x18 prefmem [DEBUG] PCI: 00:00:02.0 18 <- [0x00000000fcf8f000 - 0x00000000fcf8ffff] size 0x00001000 gran 0x0c mem [DEBUG] PCI: 00:00:02.0 30 <- [0x00000000fcf90000 - 0x00000000fcf9ffff] size 0x00010000 gran 0x10 romem [DEBUG] PCI: 00:00:03.0 10 <- [0x00000000fcfa0000 - 0x00000000fcfbffff] size 0x00020000 gran 0x11 mem [DEBUG] PCI: 00:00:03.0 14 <- [0x000000000000ffc0 - 0x000000000000ffff] size 0x00000040 gran 0x06 io [DEBUG] PCI: 00:00:03.0 30 <- [0x00000000fcfc0000 - 0x00000000fcffffff] size 0x00040000 gran 0x12 romem [INFO ] Done setting resources. [INFO ] Done allocating resources. [DEBUG] BS: BS_DEV_RESOURCES run times (exec / console): 6 / 125 ms [INFO ] Timestamp - device enable: 679631328 [INFO ] Enabling resources... [DEBUG] PCI: 00:00:00.0 cmd <- 00 [DEBUG] PCI: 00:00:01.0 cmd <- 00 [DEBUG] PCI: 00:00:01.1 cmd <- 01 [DEBUG] PCI: 00:00:01.3 cmd <- 00 [DEBUG] PCI: 00:00:02.0 cmd <- 03 [DEBUG] PCI: 00:00:03.0 cmd <- 03 [INFO ] done. [DEBUG] BS: BS_DEV_ENABLE run times (exec / console): 5 / 8 ms [DEBUG] BS: BS_DEV_INIT entry times (exec / console): 3 / 0 ms [INFO ] Timestamp - device initialization: 735362458 [INFO ] Initializing devices... [DEBUG] CPU_CLUSTER: 0 init [INFO ] CPU: QEMU Virtual CPU version 2.5+. [INFO ] LAPIC 0x0 switched to X2APIC mode. [DEBUG] CPU: APIC: 00 enabled [DEBUG] CPU: APIC: 01 enabled [DEBUG] Loading module at 0x00030000 with entry 0x00030000. filesize: 0x1b8 memsize: 0x1b8 [DEBUG] Processing 17 relocs. Offset value of 0x00030000 [DEBUG] Attempting to start 1 APs [DEBUG] Waiting for 10ms after sending INIT. [DEBUG] Waiting for SIPI to complete... [INFO ] LAPIC 0x1 switched to X2APIC mode. [DEBUG] done. [INFO ] AP: slot 1 apic_id 1 [DEBUG] Waiting for SIPI to complete... [DEBUG] done. [INFO ] Initializing CPU #0 [DEBUG] CPU: vendor Intel device 60fb1 [DEBUG] CPU: family 0f, model 6b, stepping 01 [INFO ] CPU #0 initialized [INFO ] Initializing CPU #1 [DEBUG] CPU: vendor Intel device 60fb1 [DEBUG] CPU: family 0f, model 6b, stepping 01 [INFO ] CPU #1 initialized [INFO ] bsp_do_flight_plan done after 7 msecs. [DEBUG] CPU_CLUSTER: 0 init finished in 30 msecs [DEBUG] PCI: 00:00:00.0 init [DEBUG] Assigning IRQ 10 to PCI: 00:00:01.3 [DEBUG] Assigning IRQ 11 to PCI: 00:00:03.0 [DEBUG] PCI: 00:00:00.0 init finished in 5 msecs [DEBUG] PCI: 00:00:01.0 init [DEBUG] RTC Init [DEBUG] IOAPIC: Initializing IOAPIC at 0xfec00000 [DEBUG] IOAPIC: ID = 0x02 [DEBUG] IOAPIC: 24 interrupts [DEBUG] IOAPIC: Clearing IOAPIC at 0xfec00000 [DEBUG] IOAPIC: Bootstrap Processor Local APIC = 0x00 [DEBUG] PCI: 00:00:01.0 init finished in 5 msecs [DEBUG] PCI: 00:00:01.1 init [DEBUG] IDE: Primary interface: on [DEBUG] IDE: Secondary interface: on [DEBUG] IDE: Access to legacy IDE ports: off [DEBUG] PCI: 00:00:01.1 init finished in 2 msecs [DEBUG] PCI: 00:00:02.0 init [DEBUG] PCI: 00:00:02.0 init finished in 35 msecs [DEBUG] PCI: 00:00:03.0 init [DEBUG] PCI: 00:00:03.0 init finished in 0 msecs [INFO ] Devices initialized [DEBUG] BS: BS_DEV_INIT run times (exec / console): 57 / 36 ms [INFO ] Finalize devices... [INFO ] Devices finalized [INFO ] Timestamp - device setup done: 1012995431 [DEBUG] BS: BS_POST_DEVICE run times (exec / console): 0 / 3 ms [INFO ] Timestamp - cbmem post: 1023365228 [DEBUG] BS: BS_OS_RESUME_CHECK run times (exec / console): 0 / 1 ms [INFO ] Timestamp - write tables: 1050553506 [INFO ] Copying Interrupt Routing Table to 0x000f0000... done. [INFO ] Copying Interrupt Routing Table to 0x3fe92000... done. [DEBUG] PIRQ table: 128 bytes. [INFO ] QEMU: firmware config: Found 'etc/table-loader' [DEBUG] QEMU: found ACPI tables in fw_cfg. [INFO ] QEMU: firmware config: Found 'etc/acpi/rsdp' [DEBUG] QEMU: loading "etc/acpi/rsdp" to 0x3fe6e000 (len 20) [INFO ] QEMU: firmware config: Found 'etc/acpi/tables' [DEBUG] QEMU: loading "etc/acpi/tables" to 0x3fe6e040 (len 131072) [DEBUG] QEMU: loaded ACPI tables from fw_cfg. [DEBUG] Looking on 0x3fe6e000 for valid checksum [DEBUG] Checksum 1 passed [DEBUG] Checksum 2 passed all OK [DEBUG] ACPI: added table 1/32, length now 44 [DEBUG] ACPI: added table 2/32, length now 52 [DEBUG] ACPI: added table 3/32, length now 60 [DEBUG] ACPI: added table 4/32, length now 68 [DEBUG] ACPI: * SSDT [DEBUG] Found 2 CPU(s). [DEBUG] ACPI: added table 5/32, length now 76 [DEBUG] ACPI tables: 131136 bytes. [DEBUG] smbios_write_tables: 3fe66000 [DEBUG] SMBIOS firmware version is set to coreboot_version: '4.22-671-g416cc665929e' [DEBUG] SMBIOS: Unknown CPU or CPU doesn't support Deterministic Cache CPUID leaf [INFO ] DOMAIN: 00000000 (QEMU Northbridge i440fx) [INFO ] QEMU: firmware config: Found 'etc/smbios/smbios-tables' [DEBUG] QEMU: found smbios tables in fw_cfg (len 327). [DEBUG] QEMU: coreboot type0 table found at 0x3fe66040. [DEBUG] QEMU: loading smbios tables to 0x3fe66086 [DEBUG] SMBIOS tables: 461 bytes. [DEBUG] Writing table forward entry at 0x00000500 [DEBUG] Wrote coreboot table at: 0x00000500, 0x10 bytes, checksum 8ff5 [DEBUG] Writing coreboot table at 0x3fe93000 [DEBUG] 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES [DEBUG] 1. 0000000000001000-0000000000007fff: RAM [DEBUG] 2. 0000000000008000-000000000000dfff: RESERVED [DEBUG] 3. 000000000000e000-000000000009ffff: RAM [DEBUG] 4. 00000000000a0000-00000000000fffff: RESERVED [DEBUG] 5. 0000000000100000-000000003fe65fff: RAM [DEBUG] 6. 000000003fe66000-000000003fe9bfff: CONFIGURATION TABLES [DEBUG] 7. 000000003fe9c000-000000003ffccfff: RAMSTAGE [DEBUG] 8. 000000003ffcd000-000000003fffffff: CONFIGURATION TABLES [DEBUG] 9. 00000000fec00000-00000000fec00fff: RESERVED [DEBUG] 10. 00000000ff800000-00000000ffffffff: RESERVED [DEBUG] FMAP: area COREBOOT found @ 200 (4193792 bytes) [DEBUG] Wrote coreboot table at: 0x3fe93000, 0x310 bytes, checksum e5a4 [DEBUG] coreboot table: 808 bytes. [DEBUG] IMD ROOT 0. 0x3ffff000 0x00001000 [DEBUG] IMD SMALL 1. 0x3fffe000 0x00001000 [DEBUG] CONSOLE 2. 0x3ffde000 0x00020000 [DEBUG] TIME STAMP 3. 0x3ffdd000 0x00000910 [DEBUG] AFTER CAR 4. 0x3ffcd000 0x00010000 [DEBUG] RAMSTAGE 5. 0x3fe9b000 0x00132000 [DEBUG] COREBOOT 6. 0x3fe93000 0x00008000 [DEBUG] IRQ TABLE 7. 0x3fe92000 0x00001000 [DEBUG] ACPI 8. 0x3fe6e000 0x00024000 [DEBUG] SMBIOS 9. 0x3fe66000 0x00008000 [DEBUG] IMD small region: [DEBUG] IMD ROOT 0. 0x3fffec00 0x00000400 [DEBUG] RO MCACHE 1. 0x3fffe960 0x00000294 [DEBUG] FMAP 2. 0x3fffe8a0 0x000000b6 [DEBUG] ROMSTG STCK 3. 0x3fffe800 0x00000088 [INFO ] Timestamp - finalize chips: 1300590328 [DEBUG] BS: BS_WRITE_TABLES run times (exec / console): 5 / 82 ms [INFO ] Timestamp - starting to load payload: 1308405624 [INFO ] CBFS: Found 'fallback/payload' @0x25480 size 0x10049 in mcache @0x3fffeb84 [DEBUG] Checking segment from ROM address 0xffc256ac [DEBUG] Checking segment from ROM address 0xffc256c8 [DEBUG] Loading segment from ROM address 0xffc256ac [DEBUG] code (compression=1) [DEBUG] New segment dstaddr 0x00100000 memsize 0x135a30 srcaddr 0xffc256e4 filesize 0x10011 [DEBUG] Loading Segment: addr: 0x00100000 memsz: 0x0000000000135a30 filesz: 0x0000000000010011 [DEBUG] using LZMA [INFO ] Timestamp - starting LZMA decompress (ignore for x86): 1342618898 [INFO ] Timestamp - finished LZMA decompress (ignore for x86): 1362402424 [DEBUG] Clearing Segment: addr: 0x000000000011eb68 memsz: 0x0000000000116ec8 [DEBUG] Loading segment from ROM address 0xffc256c8 [DEBUG] Entry Point 0x00100000 [DEBUG] BS: BS_PAYLOAD_LOAD run times (exec / console): 6 / 17 ms [DEBUG] Jumping to boot code at 0x00100000(0x3fe93000) [INFO ] Timestamp - selfboot jump: 1382362947 coreboot: 4.22-671-g416cc665929e FILO version 0.6.0 (pmenzel@abreu) Sun Feb 4 13:23:12 UTC 2024 Press <Enter> for default boot, or <Esc> for boot prompt... timed out boot: hda1:/vmlinuz initrd=hda1:/initrd.img root=/dev/sda1 ro quiet console=ttyS0,115200 ATA-0: [io ports 0x1f0-0x1f7,0x3f6] * hda [ATA Disk]: QEMU HARDDISK Found Linux version 5.6.0-1-686-pae (debian-kernel(a)lists.debian.org) #1 SMP Debian 5.6.7-1 (2020-04-29) relocatable bzImage. Loading kernel... ok Loading initrd... ok Jumping to entry point... [ 0.051630] kernel BUG at arch/x86/kernel/apic/apic.c:1629! [ 0.052637] invalid opcode: 0000 [#1] SMP PTI [ 0.053267] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-1-686-pae #1 Debian 5.6.7-1 [ 0.054409] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 4.22-671-g416cc665929e 02/02/2024 [ 0.055811] EIP: setup_local_APIC+0x478/0x4b0 [ 0.056427] Code: fe ff ff 85 d2 0f 8f bd 11 00 00 a1 e0 06 93 c5 ba 00 07 01 00 8b 48 08 b8 50 03 00 00 e8 20 92 6f 00 e9 db fe ff ff 8d 76 00 <0f> 0b 8d b6 00 00 00 00 0f 0b e9 4b fc ff ff e8 d4 4b 02 00 a1 e0 [ 0.058843] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: ffffffff [ 0.059700] ESI: c5aac8cd EDI: 00000000 EBP: c5993f64 ESP: c5993f14 [ 0.060676] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246 [ 0.061610] CR0: 80050033 CR2: ff9ff000 CR3: 05b48000 CR4: 000006b0 [ 0.062494] Call Trace: [ 0.062876] ? vprintk_default+0x17/0x20 [ 0.063547] ? kvm_arch_para_features+0x43/0x80 [ 0.064399] apic_intr_mode_init+0xf4/0x10a [ 0.065197] x86_late_time_init+0x1d/0x24 [ 0.066421] start_kernel+0x3f9/0x4ac [ 0.066965] i386_start_kernel+0x48/0x4a [ 0.067506] startup_32_smp+0x164/0x168 [ 0.068167] Modules linked in: [ 0.068759] ---[ end trace 78220014fc8c5bde ]--- [ 0.069553] EIP: setup_local_APIC+0x478/0x4b0 [ 0.070297] Code: fe ff ff 85 d2 0f 8f bd 11 00 00 a1 e0 06 93 c5 ba 00 07 01 00 8b 48 08 b8 50 03 00 00 e8 20 92 6f 00 e9 db fe ff ff 8d 76 00 <0f> 0b 8d b6 00 00 00 00 0f 0b e9 4b fc ff ff e8 d4 4b 02 00 a1 e0 [ 0.073445] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: ffffffff [ 0.074518] ESI: c5aac8cd EDI: 00000000 EBP: c5993f64 ESP: c5993f14 [ 0.075590] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246 [ 0.076777] CR0: 80050033 CR2: ff9ff000 CR3: 05b48000 CR4: 000006b0 [ 0.077875] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.079101] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- ``` -- 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 2

src/soc/intel/xeon_sp/Kconfig:95:warning: config symbol defined without type
by Mike Banon 18 Feb '24

18 Feb '24

After this commit - https://review.coreboot.org/c/coreboot/+/79058 - now I always have this warning while doing a "make menuconfig" : src/soc/intel/xeon_sp/Kconfig:95:warning: config symbol defined without type To fix this, please add the "bool" line before "default y" to specify the config symbol type. P.S. wrote about this problem under the change about ~1 month ago, but maybe the notifications are not working for the merged changes - so posting it here just in case -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 1

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 16 Feb '24

16 Feb '24

Dear community, Kindly note that the upcoming coreboot leadership meeting is scheduled for Wednesday, February 21, 2024. [1] Please take a moment to update the current agenda items with matters you wish to see addressed during the meeting. [2] [1](https://bbb.sfconservancy.org/b/mar-sfn-e22-axi). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

Makefile classes-y vs subdirs-y
by Maximilian Brune 16 Feb '24

16 Feb '24

I am currently working a little bit on on makefile stuff and got a bit confused. Looking at the documentation it seems like `subdirs` is one of the possible `classes` that we have. But then I looked at payloads/libpayload/Makefile.mk file at this location: https://elixir.bootlin.com/coreboot/latest/source/payloads/libpayload/Makef… and it seems to add classes where I would have expected it to use subdirs-y instead. Can someone explain to me when to use classes-y and when to use subdirs-y?

2 1

coreboot 24.02 release tag on next Monday!
by Felix Singer 12 Feb '24

12 Feb '24

The next coreboot release tag is scheduled for next Monday, February 19th! With the upcoming release we are changing our release number format from a version number to a date format. So it will be versioned 24.02. As always, please test any mainboards, give feedback, and if possible submit a patch for review if you found an issue. We appreciate any help. Also, let us know if there are any patches which need to make it into the release. You can do that by responding to this email and by adding the following hashtag to the related patch on Gerrit. The hashtag field is shown after clicking on the "show all" button from the top left information block of a patch. coreboot_release_2402 [1] We are using another hashtag in order to track patches which are important or useful in some way, maybe even ready to be submitted, but might break something and thus the risk is too high right before the release. So we prefer to submit them after the release which gives enough time for testing until the next release. Examples are version updates to the toolchain or updates to the FSP submodule pointer. The hashtag is as follows: coreboot_post_release_2402 [2] Please don't hesitate and reach out to us if you have any question. Felix --- [1] https://review.coreboot.org/q/hashtag:coreboot_release_2402 [2] https://review.coreboot.org/q/hashtag:coreboot_post_release_2402

1 0

Termin mit Hinweis abgesagt: coreboot Leadership Meeting - Every 2 weeks from 11:00 to 12:00 on Wednesday (MST) (coreboot@coreboot.org)
by coreboot org 11 Feb '24

11 Feb '24

Dieser Termin wurde mit folgendem Hinweis abgesagt: "Updated with link to BigBlueButton meeting space." coreboot Leadership Meeting Every 2 weeks from 11:00 to 12:00 on Wednesday Mountain Time - Denver Standort US-BLD-PEARL2930-1-A-Nine-banded Armadillo (6) [GVC] https://www.google.com/maps/search/US-BLD-PEARL2930-1-A-Nine-banded+Armadil… Mit Google Meet teilnehmen https://meet.google.com/pyt-newq-rbb?hs=224 Per Telefon teilnehmen (US) +1 608-618-4744 PIN: 143813170 Weitere Telefonnummern https://tel.meet/pyt-newq-rbb?pin=6680344120895&hs=0 The meeting will be held via BigBlueButtonhttps://bbb.sfconservancy.org/b/mar-sfn-e22-axicoreboot leadership meeting minutesUse the number and pin below to join the meeting.United States (US): +1-718-247-9666PIN: 89421 Organisator pgeorgi(a)google.com pgeorgi(a)google.com ~~//~~ Einladung von Google Kalender: https://calendar.google.com/calendar/ Sie erhalten diese E-Mail, weil Sie ein Gast des Termins sind. Wenn Sie keine weiteren Informationen zu diesem Termin erhalten möchten, lehnen Sie die Einladung ab. Wenn Sie diese Einladung weiterleiten, kann jeder Empfänger eine Antwort an den Organisator senden und zur Gästeliste hinzugefügt werden. Außerdem könnte er weitere Nutzer einladen und Ihre Antwort ändern. Weitere Informationen https://support.google.com/calendar/answer/37135#forwarding

1 0

[coreboot - Bug #522] (New) `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function.
by Vadim Zaliva 10 Feb '24

10 Feb '24

Issue #522 has been reported by Vadim Zaliva. ---------------------------------------- Bug #522: `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function. https://ticket.coreboot.org/issues/522 * Author: Vadim Zaliva * Status: New * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2023-12-27 * Affected versions: master ---------------------------------------- `region_overlap()` function checks whether or not two memory regions overlap. Memory regions are represented as a region struct that contains the region's offset and size. This function then relies on `region_end()` function to compute the end of the region. `region_end()` function is susceptible to an integer overflow, which might result in the incorrect behaviour of `region_overlap()` function. An example of inputs that lead to wrong behaviour: ``` struct region r1 = {SIZE_MAX - 10, 20}; struct region r2 = {SIZE_MAX - 20, 15}; ``` It returns 0, but since the regions actually overlap, it should return 1. `region_overlap()` function is used in `smm_region_overlaps_handler()` function, which is itself used in SMI handlers to validate address values that come from an untrusted environment. This is necessary to prevent security vulnerabilities such as described in [BARing the System by Yuriy Bulygin, Oleksandr Bazhaniuk et al.](https://www.c7zero.info/stuff/REConBrussels2017_BARing_the_system.pdf) We do not have an example of an exploit based on this incorrect behaviour and are aware of the existence of one. However, theoretically, this could lead to security vulnerabilities. This bug was found during an ongoing [Coreboot Formal Verification Project](https://zaliva.org/UCSC-Twisted-Presentation-20231211.pdf), which aims to prove some important security properties of the coreboot’s SMI handler for the Gemini Lake/Octopus platform using Coq proof assistant and Verified Software Toolchain framework. -- 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

6 16

2024-02-07 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 08 Feb '24

08 Feb '24

# 2024-02-07 - coreboot Leadership Meeting Minutes ## Attendees Mina Asante, Martin Roth, Felix Singer, Jay Talbott, Werner Zeh, Matt Devillier, Patrick Georgi, Ahmed Elgogary, Jonathan Hall, Felix Held, Nicholas Chin, Simon Glass, Julius Werner, Varshit Panda, David Hendricks, Nico Huber, Lean Sheng Tan, Max Brune. ## Open Action Items * 2024-01-10 * [Open] Werner: Push patch based on https://ticket.coreboot.org/issues/522 * Nico: https://review.coreboot.org/q/topic:enforce_region_api * [Open] Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. * 2023-11-01 * [Started]Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * We can save over 900MB by using shallow submodules. * [Projects & RFCs](https://docs.google.com/document/d/15H2m4swdESSgGaIuINOePkyst8b39Y7Lu…. * Making progress - see email thread. * 2023-10-4 * Martin: Write a tutorial for gerrit - Feel free to help. [Started](https://docs.google.com/document/d/1Z8igNdgBG5_Qlr4kKRtlbpKaZo9RUg…. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. ## Minutes ### [Martin/Felix] Switching to BigBlueButton. * The upcoming meeting in two weeks (02/21/24) will take place on BigBlueButton instead of Google Chat. Further information will be published to the mailing list between Wednesday's meeting and the following one. * New meeting link to join the leadership meeting: * https://bbb.sfconservancy.org/b/mar-sfn-e22-axi * For phone access, call +1-718-247-9666, then enter 89421 as the conference PIN number. * It looks like there’s only a USA phone number. ### [FelixS] Building a community FSP for Intel based platforms * Initial coreboot support for Intel consumer platforms mostly comes with Google Chromebooks. * coreboot support for a wide range of mainboards is only possible if Intel releases FSP binaries. For some platforms Intel refuses to release a FSP binary and Intel also refuses to fix issues within FSP. * How to make coreboot more independent? People have tried convincing Intel to make FSP open source. It seems unlikely that anything in that regard happens any time soon. * As a compromise, I am proposing to build our own FSP from scratch that is built by the community, specifically companies. It's still meant to be closed-source, since Intel won't allow us to write open source code, but then we are able to extend and improve it whenever we want. * Will Intel allow us to distribute our own binaries if the code is completely written by ourselves? * Possible issues * Getting a multi-party NDA * [Werner] First of all we need an entity which could be the NDA partner (OSFF could probably be?) * Getting a license so that we are allowed to distribute it * [Werner]The license that comes with the FSP code that I am aware of explicitly inhibits code changes and productive use of self-built binaries. How would we ensure this? * [FelixS] AFAIK the standard license allows us to do code changes but it doesn’t allow us distributing the binary over let’s say a website. So I am wondering if it’s different with something we build ourselves. * [Sheng] Do you have connections with Intel folks to make this happen or initiate the discussion? Is there a solid plan for this, to outline the goals, process, and details with Intel? Or is this just a mere suggestion that is probably not very practical? Since this is not an Intel specific issue, how about AMD? This won't happen overnight - who is going to lead this initiative with Silicon vendors, initiate discussions and meetings (and it will be a difficult and consuming process), collect feedback from all parties, and craft out a solid plan to move ahead? * [Martin] In coreboot’s agreement with SFC, we agreed that any and all software and/or documentation developed and maintained by the Project and the Project’s participants will be distributed solely as Free Software. * Because of this agreement, while this proposed FSP could be interesting to the coreboot group, it’s not, and cannot be, a coreboot project. Since we wouldn’t be able to open source the proposed FSP, I’m not even convinced that it’s something that should be discussed in this meeting. * [Felix S.] Just wants to hear the opinion of the coreboot community and not try to add this project to coreboot’s projects * [Jonathan H] It would be hard to get manager support since it’s not open source. * [Jay T] A separate license is required for release. The FSP needs to be identified as non-intel. * [Nico] We can focus on FSP-S and publish everything that doesn’t have to be secret as open source. What does intel feel about this? * [Martin]: if we’re doing it as open source, why do it as FSP, why not just do it as coreboot? * David: Look at getting a consortium of companies to sit down with intel and try to work with them to make FSP better. This can’t be done privately, cutting intel out of the loop. * Werner: OSFF is ready to take over things like this instead of doing it as a consortium. Intel has typically even rejected the idea of joining the OSFF to do something like this. * David: Start with contacting intel. I can put Felix in touch with someone from intel. * Sheng: Try building on top of Subrata’s success: 75% of FSPS is getting moved to the platform firmware. * https://blog.osfw.foundation/breaking-the-boundary-a-way-to-create-your-own… * Incorporate Fiano tool as part of Intel coreboot build process to remove the unused FSP modules during build time. That will help to shrink the FSP-S binary by 75%. For the rest of the 25%, the community can start poking around it by trying to implement those as part of native coreboot code. * Resume the work on LibGFXinit. If LibGfx driver is production ready, then we could further shrink FSP-S by removing the graphic init module from it. ### [Arthur] Status update on ARM LBBR bootflow (was asked last meeting) * Nothing to discuss so not sure if this needs to be on the agenda. * Things are progressing along with the LBBR Engineering Change Request to include other bootflow recommendations where coreboot is BL1 * It’s an industry wide spec, so a wide range of partners were asked for input, which takes time * [Martin] We were told in a previous leadership meeting back in October or November that the decision of what to include in the spec would be made at a meeting in January, which is why we pushed so hard to get the decision about the ARM coreboot solutions to be wrapped up. * As far as it being on the agenda, I think even letting us know that things are just progressing but not resolved yet is information that should be shared instead of just leaving people wondering what’s going on. * When should we expect an actual update? June? December? 2025? * [Sheng] No idea..you know how big corporate’s meetings go.. People in the meeting keep asking more questions. As ARM has a wide range of ecosystem partners, and they want to be heard. We are also wondering and equally frustrated, but nothing within 9elements control, we already did our best as possible and keep putting in more resources to help resolve the questions from Arm partners.. Just want to be very cautious here that we did not promise fast approval, but the CB decision was crucial to kickstart the discussion and help to accelerate the process. Hopefully ARM SystemReady will finalize the decision in the coming months. Will share more when we have updates. * When are the patches in question expecting to be merged? * [Sheng] As per I got the confirmation and agreement from leadership in the meeting that with the conditional approval, the patches will be merged immediately after we got confirmation from ARM that the proposed coreboot->TFA is included in the LBBR spec. If the condition changes then will need to bring it up again. ### [Elyes] revert & get rid of write{8,16,32,64}p (readXXp? ). * See Julius’s comment here : https://review.coreboot.org/c/coreboot/+/80193. * Julius: There’s a reason we use void pointers - we want to practice good hygiene and use the correct types for variables. * FelixH: In some cases you have #defines for different MMIO addresses. You need additional typecasts in the code for this. * Werner: Adding the typecast indicates that the developer is doing this intentionally. * David: Something in linux coding guidelines about not hiding pointers as typedefs. This is in the same vein. * Felix & Nico - Agree that removing these will make the code more cluttered. * MaxB: No reason to have these functions - It just hides the typecast. So what if it adds just a bit of clutter. * David: I’d stick with the older format. * Werner: I’m with David - just cast the variable properly. * David: This could also create a bad precedent. * David: Fix the variables that are being passed in rather than casting them? * We’d like one implementation instead of two. Let’s make a decision about what we want to use. * Let’s figure out where the variables are created and see why they’re created with an incorrect type. * FelixH: Get stats of the usage of the different function types. Suspects that most values are actually uintptr_t. ### [Martin] coreboot 24.02 release in just under 2 weeks * Release planned for February 19, 2024. ### [SimonG] Coreboot Control Block again * [Link](https://review.coreboot.org/c/coreboot/+/77712). * Julius doesn’t feel that the benefit is not worth the maintenance cost. * CBFS is the main alternative. CCB should either have its own file or use one of the existing * Wener Zeh, Matt Deviller and David Hendricks generally approve to get this feature in. # Next meeting * February 21, 2024. * [Meeting link](https://bbb.sfconservancy.org/b/mar-sfn-e22-axi). * [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-02-07](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1….

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 05 Feb '24

05 Feb '24

Dear community, Please note that the upcoming coreboot leadership meeting is scheduled for Wednesday, February 7, 2024. [1] You are welcome to update the current agenda items with matters you wish to see addressed during the meeting. [2] ## Current Agenda Items ### [Martin/Felix] Switching to BigBlueButton. * The upcoming meeting in two weeks will take place on BigBlueButton instead of Google Chat. Further information will be published to the mailing list between this Wednesday's meeting and the following one. ### [FelixS] Building a community FSP for Intel based platforms * Initial coreboot support for Intel consumer platforms mostly comes with Google Chromebooks. * coreboot support for a wide range of mainboards is only possible if Intel releases FSP binaries. For some platforms Intel refuses to release a FSP binary and Intel also refuses to fix issues within FSP. * How to make coreboot more independent? People have tried convincing Intel to make FSP open source. It seems unlikely that anything in that regard happens any time soon. * As a compromise, I am proposing to build our own FSP from scratch that is built by the community, specifically companies. It's still meant to be closed-source, since Intel won't allow us to write open source code, but then we are able to extend and improve it whenever we want. * Will Intel allow us to distribute our own binaries if the code is completely written by ourselves? * Possible issues * Getting a multi-party NDA * Getting a license so that we are allowed to distribute it * [Werner]The license that comes with the FSP code that I am aware of explicitly inhibits code changes and productive use of self-built binaries. How would we ensure this? * [FelixS] AFAIK the standard license allows us to do code changes but it doesn’t allow us distributing the binary over let’s say a website. So I am wondering if it’s different with something we build ourselves. * [Sheng] Do you have connections with Intel folks to make this happen or initiate the discussion? Is there a solid plan for this, to outline the goals, process, and details with Intel? Or is this just a mere suggestion that is probably not very practical? Since this is not an Intel specific issue, how about AMD? This won't happen overnight - who is going to lead this initiative with Silicon vendors, initiate discussions and meetings (and it will be a difficult and consuming process), collect feedback from all parties, and craft out a solid plan to move ahead? * [Martin] In coreboot’s agreement with SFC, we agreed that any and all software and/or documentation developed and maintained by the Project and the Project’s participants will be distributed solely as Free Software. * Because of this agreement, while this proposed FSP could be interesting to the coreboot group, it’s not, and cannot be, coreboot project. Since we wouldn’t be able to open source the proposed FSP, I’m not even convinced that it’s something that should be discussed in this meeting. ### [Arthur] Status update on ARM LBBR bootflow (was asked last meeting) * Nothing to discuss so not sure if this needs to be on the agenda. * Things are progressing along with the LBBR Engineering Change Request to include other bootflow recommendations where coreboot is BL1 * It’s an industry wide spec, so a wide range of partners were asked for input, which takes time * [Martin] We were told in a previous leadership meeting back in October or November that the decision of what to include in the spec would be made at a meeting in January, which is why we pushed so hard to get the decision about the ARM coreboot solutions to be wrapped up. * As far as it being on the agenda, I think even letting us know that things are just progressing but not resolved yet is information that should be shared instead of just leaving people wondering what’s going on. * When should we expect an actual update? June? December? 2025? * When are the patches in question expecting to be merged? ### [Elyes] revert & get rid of write{8,16,32,64}p (readXXp? ). * See Julius’s comment here: (https://review.coreboot.org/c/coreboot/+/80193) ### [Martin] coreboot 24.02 release in just under 2 weeks * Release planned for Feb 19 [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

Reworking azalia verb tables
by Nicholas Sudsgaard 03 Feb '24

03 Feb '24

I was told this is a better place for discussion. This is a very experimental change and I would appreciate anyone's opinion on this. :) https://review.coreboot.org/c/coreboot/+/80333

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 02 Feb '24

02 Feb '24

Dear Community, We are pleased to announce that the upcoming coreboot leadership meeting is scheduled for Wednesday, February 7, 2024. [1] Please take a moment to review the current agenda items and update them with matters you wish to see addressed during the meeting. [2] [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 31 Jan '24

31 Jan '24

Issue #121 has been updated by Patrick Rudolph. It might be possible that testing on my side was a false positive and I was just lucky that the issue didn't appear within time. As it's unclear what the issue is about I'm just poking in the dark, comparing the reference code (MRC.bin) with coreboot's native code. Anything that could help narrowing it down as described here: https://ticket.coreboot.org/issues/121#note-80 would help to fix it. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1742 * 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

2 1

2024-01-24 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 25 Jan '24

25 Jan '24

# 2024-01-24 - coreboot Leadership Meeting ## Attendees Martin Roth, Felix Singer, Julius Werner, Arthur Heymans, David Hendricks, Jonathan Hall, Matt DeVillier, Felix Held, Patrick Georgi, Werner Zeh, Mina Asante, Nicholas Chin, Subrata Banik, Nico Huber, Marshall Dawson, Maximilian Brune. ## Open Action Items * 2024-01-10 * [Open] Werner: Push patch based on https://ticket.coreboot.org/issues/522 * Nico: https://review.coreboot.org/q/topic:enforce_region_api * [Open] Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. * 2023-11-01 * [Started] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * We can save over 900MB by using shallow submodules. * [Projects & RFCs](https://docs.google.com/document/d/15H2m4swdESSgGaIuINOePkyst8b39Y7Lu…. * Making progress - see email thread. * 2023-10-4 * Martin: Write a tutorial for gerrit - Feel free to help.[Started](https://docs.google.com/document/d/1Z8igNdgBG5_Qlr4kKRtlbpKa…. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. ## Minutes ### [Martin] [Review corebootprojects](https://docs.google.com/document/d/15H2m4swdESSgGaIuINOeP…. * See coreboot projects document ### [Martin] Review coreboot RFCs in gerrit * https://review.coreboot.org/c/coreboot/+/57861 * Abandon * https://review.coreboot.org/c/coreboot/+/62015 * Please review. ### [Martin & Felix]: coreboot infra discussion: - Is there any reason to consider moving to external services like gerrithub & github? - No? - coreboot.org hosts some private repos. Some cloud services claim ownership over everything. - Hidden costs? - Move Jenkins to a separate server - Can we use a build server, or is that too much of a security risk? - Some maintenance tasks are co-hosted. - What’s the problem if jenkins gets hacked? - Patches get marked as verified. - Can we reduce the saved logs that are no longer needed and only keep the ones that are important? - Unfortunately, there doesn’t seem to be a way to do that. Jenkins doesn’t have separate controls for even passed & failed builds, let alone builds that have been superseded by newer builds. * Decision: Rent a dedicated server with ECC memory and hard drives for storage. Start looking at moving jenkins over. We can look at moving the other services in the future. ## Hetzner servers “Ideal” machine for coreboot services * 8 cores with SMT * 64 GiB ECC Memory * 2x 512 GB NVMe drives RAID 1 * 2x 12 TB HDDs RAID1 * 12TB because 6TB drives are €17/month, 12 TB drives are €23. This can be used for backups & Jenkins logs/artifacts. * We could probably get away without a 2nd drive & RAID, but it seems more professional to have the redundancy. ### Hetzner AMD servers |[SX134] Mid-range Client CPU|[AX52] Mid-range Client CPU|[AX102] High-End Client CPU|[AX161] Server CPU| |:-------------------------- |:--------------------------|:--------------------------|:---------------- | | € 260.37 Germany | € 128.04 Germany | € 176.83 Germany | €240 Germany | | € 247.28 Finland | € 122.09 Finland | € 170.88 Finland | €227 Finland | | | | | | | AMD Ryzen 7 3700X | AMD Ryzen 7 7700 | AMD Ryzen 9 7950X3D | AMD EPYC7502P | | 8 Cores | 8 Cores | 16 Cores | 32 Cores | | | | | | | 128 GiB DDR4 ECC | 64 GiB DDR5 ECC | 128 GiB DDR5 ECC | 128 GiB DDR4 ECC | | | | | | | 2x 960 GB NVMe | 2x 1 TB NVMe | 2x 1.9 TB NVMe | 2x 1 TB NVMe | | | | | | | 10x 16 TB SATA HDD | 2x 12 TB SATA HDD | 2x 12 TB SATA HDD | 2x 12 TB SATAHDD | | | | | | * Here are relevant links to Hetzner AMD servers: - [SX134](https://www.hetzner.com/dedicated-rootserver/sx134/configurator#) - [AX52](https://www.hetzner.com/dedicated-rootserver/ax52/configurator#) - [AX102](https://www.hetzner.com/dedicated-rootserver/ax102/configurator#) - [AX161](https://www.hetzner.com/dedicated-rootserver/ax161/configurator#) ### Hetzner Intel Servers | [EX44] Mid-range Client CPU | [EX101] High-end Client CPU | [EX130-R] Server CPU | |:----------------------------|:----------------------------|:---------------------| | € 99.48 Germany | € 153.03 Germany | € 212.53 Germany | | € 93.53 Finland | € 147.08 Finland | € 206.58 Finland | | | | | | Intel® Core™ i5-13500 | Intel® Core™ i9-13900 | Intel Xeon Gold 5412U| | 6 P-cores 8 E-cores | 8 P-cores 16 E-cores | 24-cores | | | | | | 64 GiB DDR4 non-ECC | 64 GiB DDR5 ECC | 256 GiB DDR5 ECC | | | | | | 2 x 512 GB (Gen4) | 2 x 1.92 TB (Gen4) | 2 x 1.9 TB (Gen4) | | | | | | 2x 12 TB SATA HDD | 2x 12 TB SATA HDD | 2x 12 TB SATA HDD | | | | | * Here are relevant links to Hetzner Intel Servers: - [EX44](https://www.hetzner.com/dedicated-rootserver/ex44/configurator#) - [EX101](https://www.hetzner.com/dedicated-rootserver/ex101/configurator#) - [EX130-R](https://www.hetzner.com/dedicated-rootserver/ex130-r/configurator#) ### [SimonG] (cannot attend this week, so will skip Coreboot Control Block) # Next meeting * February 7, 2024. * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [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-01-24](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1….

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 22 Jan '24

22 Jan '24

Dear community, Please note that the upcoming coreboot leadership meeting is scheduled for Wednesday, January 24, 2024. [1] You are welcome to update the agenda items with matters you wish to see addressed during the meeting. [2] ## Current Agenda Items ### Felix and Martin want to talk servers again [1] (https://www.coreboot.org/calendar.html) [2] (https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… .4ddv57gdsocp)

1 0

Shallow submodules
by Martin Roth 21 Jan '24

21 Jan '24

One of the tasks I've had in my queue for a bit is to look into shallow submodules for coreboot. TLDR, we can decrease the submodule data size by over 900GB by using shallow submodules. The idea behind shallow submodules is that by default, we don't pull down as much data. For most submodules, most people typically only use the single commit pointed to by the submodule pointer. This means that people are spending time pulling down commits and then storing data that they don't typically need. The downside of shallow submodules (and shallow git repos in general) is that they don't contain the full data for the repository, so you can't immediately look at the full history or check out other versions. There are a couple of ways to limit the amount of data being fetched by a git repository. - You can fetch a single branch - You can fetch a limited amount of the git repo's history, either by date or by number of commits. This explores those possibilities. Currently if you download everything in the coreboot tree, along with the full submodules you get 1.4GB of data: 226MB of data after downloading the just coreboot repo, but before downloading submodules. Then another 1.2GB of data for all of the submodules. Changing the submodules to pull down a depth of 1 commit, we fetch just 208MB of data, a much more reasonable size than 1.2GB Pulling down the full branch used for each submodule increases the submodule size to 769MB. Here's a spreadsheet with the submodule size data, along for recommendations for each. https://docs.google.com/spreadsheets/d/1DAnFFnoLxdLE15CsUTE_AuCZeKG-UdrBndi… <https://docs.google.com/spreadsheets/d/1DAnFFnoLxdLE15CsUTE_AuCZeKG-UdrBndi…> Submodules recommended to use --depth=1 are: arm-trusted-firmware, intel-sec-tools, stm, chromeec, blobs, fsp, vboot All other submodules would fetch the current branch. My thought is that we set the default for each submodule to the recommended value in the sheet, then we can add a Make target or Kconfig option that pulls down the rest, for anyone who wants the full data. Once you've pulled down the entire history of a repo, it won't get removed, so the update (mostly) only needs to be done once for historic data. You'd need to do it again after any submodule update to get the full recent commit history though. Unrelated to the submodules or any proposed changes, to thin the coreboot repo out a bit, you can limit how far back the coreboot history goes, and ignore branches other than main by running a command like this: `git clone https://review.coreboot.org/coreboot.git coreboot-https --shallow-since=2020-01-01 --branch=main --single-branch` This pulls down 127MB of data instead of the full 226MB. Obviously you can change the date as desired to get more or less history. If at some point, you decide you want the rest of the data for that repo, you can run `git fetch --unshallow`. One note on pulling less history for the coreboot repo - Make sure you get the latest tag, or your coreboot version id will be wrong and confusing. Let me know what you think about updating the submodules as recommended. Martin

5 7

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 19 Jan '24

19 Jan '24

Dear community, We are pleased to announce that the upcoming cooreboot leadership meeting is scheduled for next Wednesday, January 24, 2024. [1] Please take a moment to update the agenda items with matters you wish to see addressed during the meeting. [2] [1](https://www.coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 17 Jan '24

17 Jan '24

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1533252: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1533252: Memory - corruptions (OVERRUN) /src/soc/intel/xeon_sp/chip_common.c: 124 in attach_iio_stacks() 118 continue; 119 } 120 121 struct device_path path; 122 path.type = DEVICE_PATH_DOMAIN; 123 path.domain.domain = s * MAX_LOGIC_IIO_STACK + x; >>> CID 1533252: Memory - corruptions (OVERRUN) >>> Overrunning struct type device_path of 32 bytes by passing it to a function which accesses it at byte offset 39. 124 struct device *iio_domain = alloc_dev(dev->bus, &path); 125 if (iio_domain == NULL) 126 die("%s: out of memory.\n", __func__); 127 iio_domain->ops = &iio_pcie_domain_ops; 128 } 129 } ** CID 1533251: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1533251: Memory - corruptions (OVERRUN) /src/soc/intel/xeon_sp/spr/ioat.c: 37 in create_ioat_domain() 31 struct device_path path = { 32 .type = DEVICE_PATH_DOMAIN, 33 .domain = { 34 .domain = domain_base + bus_base, 35 }, 36 }; >>> CID 1533251: Memory - corruptions (OVERRUN) >>> Overrunning struct type device_path of 32 bytes by passing it to a function which accesses it at byte offset 39. 37 struct device *const domain = alloc_dev(upstream, &path); 38 if (!domain) 39 die("%s: out of memory.\n", __func__); 40 41 domain->ops = &ioat_domain_ops; 42 ** CID 1533250: Insecure data handling (TAINTED_SCALAR) /src/soc/intel/xeon_sp/chip_common.c: 106 in attach_iio_stacks() ________________________________________________________________________________________________________ *** CID 1533250: Insecure data handling (TAINTED_SCALAR) /src/soc/intel/xeon_sp/chip_common.c: 106 in attach_iio_stacks() 100 void attach_iio_stacks(struct device *dev) 101 { 102 const IIO_UDS *hob = get_iio_uds(); 103 if (!hob) 104 return; 105 >>> CID 1533250: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "hob->PlatformData.numofIIO" as a loop boundary. 106 for (int s = 0; s < hob->PlatformData.numofIIO; ++s) { 107 for (int x = 0; x < MAX_LOGIC_IIO_STACK; ++x) { 108 if (s == 0 && x == 0) 109 continue; 110 111 const STACK_RES *ri = &hob->PlatformData.IIO_resource[s].StackRes[x]; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Cannot verify review.coreboot.org's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=R3’
by Mike Banon 16 Jan '24

16 Jan '24

Good day! I just found out that my wgets at http://dangerousprototypes.com/docs/Lenovo_G505S_hacking scripts (for restoring & configuring the AMD opensource AGESA boards at modern coreboot) - are failing because of this certificate error. To reproduce this easily you do not have to run the whole csb_patcher.sh or restore_agesa.sh - doing just a simple wget is more than enough, i.e.: wget "https://review.coreboot.org/changes/79838/revisions/2/patch?zip" --2024-01-16 **:**:**-- https://review.coreboot.org/changes/79838/revisions/2/patch?zip Resolving review.coreboot.org (review.coreboot.org)... **.**.***.*** Connecting to review.coreboot.org (review.coreboot.org)|**.**.***.***|:443... connected. ERROR: cannot verify review.coreboot.org's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=R3’: Issued certificate has expired. To connect to review.coreboot.org insecurely, use `--no-check-certificate'. Please resolve this error -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

3 3

[coreboot - Bug #121] T520: Hangs in OS
by Alex Gravitos 16 Jan '24

16 Jan '24

Issue #121 has been updated by Alex Gravitos. seems my assumptions about it being the first return were not entirely correct, the laptop just froze on me during a system update (its arch, so no harm was actually done), i would like to see more details on the `PDM_APD_PPD` stuff ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1741 * 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

1 0

Added "checks" integration to Gerrit
by Felix Singer 16 Jan '24

16 Jan '24

Hi coreboot fellows, You will find some new things in the Gerrit UI when you have a patch open. I've just added checks integration, which shows the executed CI jobs and tests in a much more convenient way rather than in the comment section. Ideally, it also gives a bit information on which tests failed, how many or why they failed. So more or less a summary about the build results you also get when you open the overview of a CI job. And also.. failed jobs shouldn't be listed as "warning". An example how it could look like: https://gerrit-review.googlesource.com/Documentation/pg-plugin-checks-api.h… However, it's still work in progress and I'm trying to figure out how to make it showing more information. Just wanted to make a little announcement in case of you are wondering or seeing some errors :) Felix

2 1

Support for ASUS F15
by �� 15 Jan '24

15 Jan '24

Dear Coreboot project team, I am a user of the Asus F15 TUF Gaming laptop. I have a laptop with an Intel 11th gen i5-11400H CPU (Broadwell) on a motherboard specific to the laptop (FX506HC). Could you please help me create a way to install Coreboot on my computer or consider supporting it in the future? Best Wishes, Audial Moon

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Alex Gravitos 15 Jan '24

15 Jan '24

Issue #121 has been updated by Alex Gravitos. Patrick Rudolph wrote in #note-82: > It looks like returning `PDM_APD_PPD` in get_power_down_mode() also fixes the issue. took me a while to figure out which return was supposed to be changed (its the first one). **however**, for some reason doing that also kills ethernet - both on-board and in the dock. like, to the point of them not being seen by the system. an android phone connected as usb modem is detected fine, so i'd say changing these returns somehow impacts the gigabit ethernet blob. sorry if i give not enough info, i am using coreboot for less than a week on my T520i, tell me if you need anything like logs or whatever ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1740 * 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

1 0

Is there a way to enable a PCI-PCI bridge on bus 3 early?
by Keith Hui 11 Jan '24

11 Jan '24

In my quest to get POST codes to show on my Asus P8Z77-M, and fixing sb/bd82x6x [1] along the way, I'm still not quite getting them. I have a ISA/PCI POST card, but it isn't giving me anything. I bought a little "Debug Card Expert" off Amazon that looks like a mini-PCI/mini-PCIe cross, but in today's testing I found out that it isn't wired properly (i.e. isn't going to work) for PCIe at all, but I did get it to show POST codes over LPC via the TPM header. I have another of this same little PoS that broke in half on arrival. Now that I know it only really works over LPC and only 9 signals, I'll attempt to repair the broken traces and glue it together. My board has a PCI-PCI bridge on bus:device.func 3:0.0 (so bus 3, this will be important) that services the PCI slot. After applying [1] to have the PCH send port 80 data to PCI as I specified in Kconfig, I still don't get any POST code... and not over LPC either, so I know my patch works. Now I think I may need to enable CONFIG_EARLY_PCI_BRIDGE. Problem is the bridge has to be a device on bus 0. How can I enable this PCI bridge on bus 3 early so a POST card sitting on it can get codes? Thanks Keith [1] https://review.coreboot.org/c/coreboot/+/79725

2 7

2024-01-10 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 11 Jan '24

11 Jan '24

# 2024-01-10 - coreboot Leadership Meeting Minutes ## Attendees Martin Roth, Mina Asante, David Hendricks, Werner Zeh, Felix Singer, Max Brune, Felix Held, Matt DeVillier, Ahmed Elgogary, Nico Huber, Nicholas Chin, Patrick Georgi, Jonathon Hall, Daniel Maslowski, Simon Glass, Jay Talbott. ## Open Action Items * 2024-01-10 * [Open] Werner: Push patch based on https://ticket.coreboot.org/issues/522 * [Open] Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. * 2023-12-13 * [Open] coreboot admins: Look at moving services off of stefan’s server. * [Moving coreboot services off of Stefan’s server] (https://docs.google.com/document/d/12aHuukgIRiS-9XlrqLFwVj1KqtYG_qih1yGX1E-…) * 2023-11-01 * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * No progress yet * 2023-10-18 * [Started] (https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/MMV2… JEE/)MattD and WernerZ: Work on compiling a list of website requirements from the mailing list. * No feedback yet - Matt will continue to gather feedback. * Probably have all of the community input - Need to capture the requirements as a starting point. * Move to next year. * [On hold] [pending requirements] MartinR & FelixS: Build a POC front page. * [Open] Arthur: Ask Philip about how to use company logos. * 2023-10-04 * [Started] (https://docs.google.com/document/d/1Z8igNdgBG5_Qlr4kKRtlbpKaZo9RUghRqZjHUNU…) Martin: Write a tutorial for gerrit - Feel free to help. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. * Not started ## Minutes: ### [Martin/others] Look at writing a doc stating what coreboot is * It’s been argued that this shouldn’t be called a “spec”, but Daniel Maslowski pointed out that coreboot is being defined by others as something that we aren’t, because we don’t have a good definition of what we are. Whatever we want to call it, it seems like a good plan to have *something* discussing what coreboot is. - Max: Is the target audience managers? - Daniel: The main idea is to give a definition, explain what coreboot is and does. Look at --- https://en.wikipedia.org/wiki/Coreboot (Not up to date) - It covers DRAM init in a larger paragraph - Which is what coreboot mainly means - plus e.g. some MSRs on x86 - We leave everything else up to the payload. - The way we look at the hardware ecosystem is different from others. We’re more platform (mainboard) oriented, whereas e.g. U-Boot is more SOC oriented. We should provide an entry point to understanding. - See also https://github.com/platform-system-interface/psi-spec - Felix Held: coreboot is now more SOC oriented. - David: U-Boot has a lot more mainboard specific code in the SOCs than coreboot does. - David: Having this document can be an advantage for coreboot. - Admins: Daniel, David - Martin will create a doc - [coreboot definition] (https://docs.google.com/document/d/1bMA19Cm5BMSVwZ1xFRn3pk_wSFIfSTaUY-94BLs…) - First draft in 6 weeks (Feb 21). ### [Martin] Localization of non-console strings for coreboot * With the addition of an early display, we’re looking at printing text to the screen directly from coreboot. Localization is being added for this, but the current patch uses the localization code from vboot. This isn’t a security related feature so shouldn’t depend on the rest of VBOOT being enabled. https://review.coreboot.org/c/coreboot/+/79054 * We also just had an RFC about storing setup engine strings. It seems like we’d want to make sure that whatever plan we have in place also supports localization for those strings as well. * How do we want to handle localization in coreboot? It seems like we’re going to be adding more strings that will be presented to the user. Werner: Do we want to concentrate on the current character set (Latin)? * Daniel: * Lots of dimensions here * Need translators, people understanding coreboot and/or connected to the community * E.g. openSUSE has a whole translation team. * Martin: * I don’t think we need to actually translate, just make sure we have the capability. This is for early display strings and the setup strings. Preparing for setup screen. * See also: https://archive.fosdem.org/2022/schedule/event/fw_settings_and_menus/ * Leader: Daniel ### [SimonG] Coreboot Control Block again * [Link] (https://review.coreboot.org/c/coreboot/+/77712) * Martin: Julius asked to put off discussion. * Simon: Julius seems to be against the proposal, I’m interested in what others think. * Martin: If people need it, it’s not intrusive, and it can be disabled I don’t see a problem. * MaxB: Issue with the patch and having moved things around. Julius’ other issue is that he doesn’t really see the use case, and I tend to agree. I haven’t seen this issue. I probably wouldn’t ever use this. * Matt: The main use case is troubleshooting a production image. CrOS images ship with console disabled, so there’s no way to debug the image. Sometimes you just want console enabled without all the other baggage of a console enabled build. * Nico: The current proposal is more invasive because it needs to be available before CBFS? (Simon: Yes) Is it too invasive for the minimal use case? CBFS should work too, just not on devices with early CBFS access. It increases complexity. * MaxB: Not against the idea, but the implementation is intrusive. Don’t do much in bootblock. * FelixS: Would it be possible to handle the option over chromeEC? Yes, though the EC isn’t available at the start of bootblock. * Martin: Let’s be inclusive and not block changes just because it’s not our use case. * Werner: This is a switch to enable/disable console very early, correct? Can we do that from a flashmap region instead of CBFS? Can we just use a hardcoded address in SPI? (Simon: Yes, on x86 - in a sense, that’s what we’re doing). * MaxB: move CBFS earlier? Currently we only need it at the end to load the next stage. * Patrick: Previous discussion about approaches to this: (https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/changes/85/5438… es/2021-05-selectable-serial-console.md) * Ahmed: Why isn’t the EC available at bootblock? (Simon, A message needs to be sent to the EC. It becomes available during bootblock. The issue isn’t whether the EC is running, just whether we can send a message). * David: Prefer to avoid EC dependencies since that will severely limit the usefulness of this feature. ### [Martin] Setup Option Table implementation in YAML * The initial plan was to use Kconfig syntax to generate the data for the tables, but even though Kconfig was designed to create a menu, there are significant differences between the Kconfig menus and what we’re trying to do here. The biggest difference is how we handle enabling menus. Kconfig is designed to include *ALL* values, and hide entries based on a current value. The SOT menu should completely exclude data that isn’t relevant to a system from the data structures. This can be handled, but this difference makes Kconfig less than ideal. ### [Martin] `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function * Bug 522 - https://ticket.coreboot.org/issues/522 * Looking for someone to take issue and push a patch. Issue gives an invalid result for an invalid input. Might be more useful to verify where the input is coming from? Max & Nico: Not sure this is an actual issue. * Werner - will push a patch based on their bug. ### Future of coreboot servers * We have an open action item on moving coreboot services off Stefan’s box. Other considerations have been to outsource some of the services we have so we can concentrate on doing a better job on everything else. Moving services off Stefan’s box makes it more feasible to build an admin team with full access, without putting Stefan’s other stuff on the service at risk. There has been some time to look for alternative hosting options, but given our priorities (e.g. to keep Gerrit as review system), no outsourced option looked like a good fit (while also actually offloading work) * [Jay] Did Martin ever get the server hardware from Marc Jones? * [Jay]: Marc says yes. * Yes, It’s in my garage, I need to finish getting it set up. * Martin: It was suggested that we could switch to Github for our CI. This *could* be free - * Felix: isn’t sure that it would be free for a big project like coreboot. * Matt: Ran into this issue when working on HEADS - Way too many limitations. * Nico: What’s the timeframe? (Martin - not decided yet). We can look at how much it takes in terms of resources, then look at running it at a cloud service. * Felix: Why run it on a cloud service instead of a dedicated hardware? That can be expensive * Nico: Just lets us get away from maintaining the server. It doesn’t need to be expensive. ### [Martin] Swag / Merch for FOSDEM * Ordered 24 beer glasses to take to FOSDEM. Will coreboot reimburse? Who should get these? coreboot can reimburse for the order Who gets them? Martin: Top devs day 1, any dev day 2? * Werner: Let’s see how this goes and change next year as needed. ## Completed Action Items * [Done] [Started](https://review.coreboot.org/c/coreboot/+/78832) Martin: Work on clang-format config update. * We can use the clang format version from the coreboot toolchain. * Some issues with clang format - martin will present. * See CB:78833 for what the current format’s changes will look like. * [David] #defines for bits in headers lose their indenting. Maybe we should have clang-format ignore headers for now. Smaller issues can be handled on a "use your best “judgement" basis. * [Done] Martin to add bitfield example to 78833 * Let’s look at running this just for .c files to start with. * [Done] PatrickG, FelixS, MartinR: Look at improving the responsiveness of gerrit. * This had a number of causes, mostly related to running out of storage, as well as both of the NVMe drives going bad. We’ve reduced the amount of data being saved by jenkins and replaced the NVMe drives. # Next meeting * January 24, 2024. * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [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 * https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 08 Jan '24

08 Jan '24

Dear community, Please note that the upcoming coreboot leadership meeting is scheduled for Wednesday, January 10, 2024. [1] You are welcome to update the agenda items with matters you wish to see addressed during the meeting . [2] ## Current Agenda Items ### [Martin/others] Look at writing a doc stating what coreboot is * It’s been argued that this shouldn’t be called a “spec”, but Daniel Maslowski pointed out that coreboot is being defined by others as something that we aren’t, because we don’t have a good definition of what we are. Whatever we want to call it, it seems like a good plan to have *something* discussing what coreboot is. ### [Martin] Localization of non-console strings for coreboot * With the addition of an early display, we’re looking at printing text to the screen directly from coreboot. Localization is being added for this, but the current patch uses the localization code from vboot. This isn’t a security related feature so shouldn’t depend on the rest of VBOOT being enabled. https://review.coreboot.org/c/coreboot/+/79054 * We also just had an RFC about storing setup engine strings. It seems like we’d want to make sure that whatever plan we have in place also supports localization for those strings as well. * How do we want to handle localization in coreboot? It seems like we’re going to be adding more strings that will be presented to the user. ### [SimonG] Coreboot Control Block again * [https://review.coreboot.org/c/coreboot/+/77712] ### [Martin] Review Setup Option Table implementation in YAML * The initial plan was to use Kconfig syntax to generate the data for the tables, but even though Kconfig was designed to create a menu, there are significant differences between the Kconfig menus and what we’re trying to do here. The biggest difference is how we handle enabling menus. Kconfig is designed to include *ALL* values, and hide entries based on a current value. The SOT menu should completely exclude data that isn’t relevant to a system from the data structures. This can be handled, but this difference makes Kconfig less than ideal. ### [Martin] `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function * Bug 522 - https://ticket.coreboot.org/issues/522 [1] https://www.coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 08 Jan '24

08 Jan '24

Dear community, We are pleased to announce that the upcoming coreboot leadership meeting is scheduled for next Wednesday, January 10, 2024. [1] Please take a moment to review the current agenda items and update them with matters you wish to see addressed during the meeting. [2] [1] https://www.coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… j6ljr2742djc

2 1

Re: Look at writing a doc stating what coreboot is
by James Feeney 05 Jan '24

05 Jan '24

1 0

How to build HOB
by Hamit Can Karaca 04 Jan '24

04 Jan '24

Hello I am new with coreboot and I am trying to understand base functionalities. Before coreboot I was using SBL and in SBL we could pass data to payload by building HOBs. I searched the coreboot code to see if there is a BuildHOB function but I couldn't find it. Is there a BuildHOB function in coreboot or does it have a different function which could pass data to payload. (I am using EDK2 as payload) Thanks for the answers.

2 1

Custom Coreboot
by Iu Che 03 Jan '24

03 Jan '24

Hello, I want to ask, is it possible to order coreboot porting from you to any of these laptop models? Lenovo ThinkPad X1 Carbon Gen 5, i7-7600U, Intel HD Graphics 620 Lenovo ThinkPad X1 Carbon Gen 6, i7-8650U, Intel HD Graphics 620 Lenovo ThinkPad X1 Carbon Gen 7, i5-8265U, Intel HD Graphics 620 Lenovo ThinkPad X1 Carbon Gen 8, i5-8350U, Intel HD Graphics 620 Lenovo ThinkPad X1 Carbon Gen 10, i7-1165G7, Iris Xe Graphics Lenovo ThinkPad X1 Carbon Gen 10, i5-1240P, Iris Xe Graphics Lenovo ThinkPad X1 Carbon Gen 11, i7-1360P, Iris Xe Graphics Lenovo ThinkPad T14p Gen 1, i9-13900H, Intel Iris Xe Lenovo ThinkPad T16 Gen 1, i7-1265U, Iris Xe Graphics Lenovo ThinkPad T16 Gen 2, i7-1360P, GeForce MX550 4G Lenovo Legion 5 Pro, i9-13900HX / RTX 4060 Lenovo Legion 7 Pro, i7-13700HX / RTX 4080 Lenovo Legion 7 Pro, i9-13900HX / RTX 4080 Lenovo Legion 7 Pro, i9-13900HX / RTX 4090 If this is possible, how much would such a service cost? The service of physical firmware is not needed, I can do it myself. Thank you!

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 01 Jan '24

01 Jan '24

Issue #121 has been updated by Patrick Rudolph. It looks like returning `PDM_APD_PPD` in get_power_down_mode() also fixes the issue. It matches the previous discoveries that the problem only appears when the package is in higher C-states. get_power_down_mode() seems to be only used when the DRAM is idle/ the package is in high C-states. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1726 * 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

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 31 Dec '23

31 Dec '23

Issue #121 has been updated by Patrick Rudolph. It looks like this issue doesn't appear any more when using the MRC.bin instead of native raminit. Thus it's likely that there's a difference between MRC and NRI that causes this issue. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1725 * 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

1 0

[PATCH] firmware: coreboot: framebuffer: Avoid invalid zero physical address
by Alper Nebi Yasak 27 Dec '23

27 Dec '23

On ARM64 systems coreboot defers framebuffer allocation to its payload, to be done by a libpayload function call. In this case, coreboot tables still include a framebuffer entry with display format details, but the physical address field is set to zero (as in [1], for example). Unfortunately, this field is not automatically updated when the framebuffer is initialized through libpayload, citing that doing so would invalidate checksums over the entire coreboot table [2]. This can be observed on ARM64 Chromebooks with stock firmware. On a Google Kevin (RK3399), trying to use coreboot framebuffer driver as built-in to the kernel results in a benign error. But on Google Hana (MT8173) and Google Cozmo (MT8183) it causes a hang. When the framebuffer physical address field in the coreboot table is zero, we have no idea where coreboot initialized a framebuffer, or even if it did. Instead of trying to set up a framebuffer located at zero, return ENODEV to indicate that there isn't one. [1] https://review.coreboot.org/c/coreboot/+/17109 [2] https://review.coreboot.org/c/coreboot/+/8797 Signed-off-by: Alper Nebi Yasak <alpernebiyasak(a)gmail.com> --- (I was previously told on #coreboot IRC that I could add coreboot mailing list to CC for kernel patches related to coreboot.) drivers/firmware/google/framebuffer-coreboot.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/firmware/google/framebuffer-coreboot.c b/drivers/firmware/google/framebuffer-coreboot.c index c323a818805c..5c84bbebfef8 100644 --- a/drivers/firmware/google/framebuffer-coreboot.c +++ b/drivers/firmware/google/framebuffer-coreboot.c @@ -36,6 +36,9 @@ static int framebuffer_probe(struct coreboot_device *dev) .format = NULL, }; + if (!fb->physical_address) + return -ENODEV; + for (i = 0; i < ARRAY_SIZE(formats); ++i) { if (fb->bits_per_pixel == formats[i].bits_per_pixel && fb->red_mask_pos == formats[i].red.offset && base-commit: 2220f68f4504aa1ccce0fac721ccdb301e9da32f -- 2.42.0

3 2

[coreboot - Bug #521] (New) gizmosphere/gizmo2 development board VGA support not working
by 8oDE 03 24 Dec '23

24 Dec '23

Issue #521 has been reported by 8oDE 03. ---------------------------------------- Bug #521: gizmosphere/gizmo2 development board VGA support not working https://ticket.coreboot.org/issues/521 * Author: 8oDE 03 * Status: New * Priority: High * Category: board support * Target version: none * Start date: 2023-12-24 * Affected versions: 4.18 * Needs backport to: none * Affected hardware: GizmoSphere Gizmo 2 ---------------------------------------- I got a gizmo2 development board. the official hardware and software support stopped a long time ago and no BIOS source code was released. I tried to compile coreboot firmware to support some new features. The latest supported coreboot version is 4.18. I flashed and booted the gizmo2 development board, there is no video output during the coreboot startup phase, but it boots the OS normally and the OS has video output, I purchased a FT232H board for printing logs, and it seems like there are a lot of problems. ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs_master_header 0x0 cbfs header 32 none config 0x80 raw 562 none revision 0x300 raw 720 none build_info 0x600 raw 103 none spd.bin 0x6c0 spd 128 none fallback/dsdt.aml 0x780 raw 6172 none cmos_layout.bin 0x2000 cmos_layout 616 none fallback/postcar 0x22c0 stage 22312 none payload_config 0x7a40 raw 1621 none payload_revision 0x80c0 raw 237 none (empty) 0x8200 null 31652 none apu/amdfw 0xfdc0 raw 135168 none fallback/romstage 0x30e00 stage 387544 none fallback/ramstage 0x8f880 stage 136240 LZMA (311716 decompressed) pci1002,9830.rom 0xb0d40 optionrom 59392 none fallback/payload 0xbf580 simple elf 72695 none (empty) 0xd11c0 null 3255268 none bootblock 0x3ebdc0 bootblock 16384 none ``` ---Files-------------------------------- coreboot-4.18-bootlog.txt (25.9 KB) .config (15.1 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

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 23 Dec '23

23 Dec '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 5 new defect(s) introduced to coreboot found with Coverity Scan. 442 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 1532881: (OVERRUN) ________________________________________________________________________________________________________ *** CID 1532881: (OVERRUN) /src/soc/intel/apollolake/mmap_boot.c: 73 in bios_mmap_init() 67 */ 68 bios_mapped_size = size - 256 * KiB; 69 70 rdev_chain_mem(&shadow_dev, (void *)base, bios_mapped_size); 71 72 xlate_window_init(&real_dev_window, &shadow_dev, start, bios_mapped_size); >>> CID 1532881: (OVERRUN) >>> Overrunning struct type xlate_region_device of 24 bytes by passing it to a function which accesses it at byte offset 47. 73 xlate_region_device_ro_init(&real_dev, 1, &real_dev_window, CONFIG_ROM_SIZE); 74 75 bios_size = size; 76 77 /* Check that the CBFS lies within the memory mapped area. It's too 78 easy to forget the SRAM mapping when crafting an FMAP file. */ /src/soc/intel/common/block/fast_spi/mmap_boot.c: 134 in bios_mmap_init() 128 ext_win_flash_base = fixed_win_flash_base - ext_win_size; 129 initialize_window(EXT_BIOS_DECODE_WINDOW, ext_win_host_base, 130 ext_win_flash_base, ext_win_size); 131 win_count++; 132 } 133 >>> CID 1532881: (OVERRUN) >>> Overrunning struct type xlate_region_device of 24 bytes by passing it to a function which accesses it at byte offset 47. 134 xlate_region_device_ro_init(&real_dev, win_count, real_dev_windows, CONFIG_ROM_SIZE); 135 136 init_done = true; 137 } 138 139 const struct region_device *boot_device_ro(void) ** CID 1532880: Integer handling issues (SIGN_EXTENSION) /src/lib/ramtest.c: 58 in test_pattern() ________________________________________________________________________________________________________ *** CID 1532880: Integer handling issues (SIGN_EXTENSION) /src/lib/ramtest.c: 58 in test_pattern() 52 { 53 uint8_t j, k; 54 55 k = (idx >> 8) + 1; 56 j = (idx >> 4) & 0x0f; 57 *addr = idx & 0x0f; >>> CID 1532880: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "j" with type "uint8_t" (8 bits, unsigned) is promoted in "j << 4 * k" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "j << 4 * k" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 58 *addr |= j << (4*k); 59 *value = 0x01010101 << (j & 7); 60 if (j & 8) 61 *value = ~(*value); 62 } 63 ** CID 1532879: Error handling issues (CHECKED_RETURN) /src/soc/intel/apollolake/cpu.c: 255 in post_mp_init() ________________________________________________________________________________________________________ *** CID 1532879: Error handling issues (CHECKED_RETURN) /src/soc/intel/apollolake/cpu.c: 255 in post_mp_init() 249 250 static void post_mp_init(void) 251 { 252 global_smi_enable(); 253 254 if (CONFIG(SOC_INTEL_COMMON_BLOCK_SGX_ENABLE)) >>> CID 1532879: Error handling issues (CHECKED_RETURN) >>> Calling "mp_run_on_all_cpus" without checking return value (as is done elsewhere 4 out of 5 times). 255 mp_run_on_all_cpus(sgx_configure, NULL); 256 } 257 258 static const struct mp_ops mp_ops = { 259 .pre_mp_init = pre_mp_init, 260 .get_cpu_count = get_cpu_count, ** CID 1532878: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1532878: Null pointer dereferences (FORWARD_NULL) /src/soc/qualcomm/common/qup_se_handler.c: 167 in qup_handle_transfer() 161 m_irq = qup_wait_for_m_irq(bus); 162 if ((m_irq & M_RX_FIFO_WATERMARK_EN) || 163 (m_irq & M_RX_FIFO_LAST_EN)) 164 rx_rem_bytes -= handle_rx(bus, din + size 165 - rx_rem_bytes, rx_rem_bytes); 166 if (m_irq & M_TX_FIFO_WATERMARK_EN) >>> CID 1532878: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "dout + size - tx_rem_bytes" to "handle_tx", which dereferences it. 167 tx_rem_bytes -= handle_tx(bus, dout + size 168 - tx_rem_bytes, tx_rem_bytes); 169 if (m_irq & M_CMD_DONE_EN) { 170 write32(&regs->geni_m_irq_clear, m_irq); 171 break; 172 } ** CID 1532877: Resource leaks (RESOURCE_LEAK) /src/soc/intel/common/block/crashlog/crashlog.c: 341 in malloc_cl_node() ________________________________________________________________________________________________________ *** CID 1532877: Resource leaks (RESOURCE_LEAK) /src/soc/intel/common/block/crashlog/crashlog.c: 341 in malloc_cl_node() 335 cl_node_t *node = malloc(sizeof(cl_node_t)); 336 if (!node) 337 return NULL; 338 339 node->data = malloc(len * sizeof(u32)); 340 if (!(node->data)) >>> CID 1532877: Resource leaks (RESOURCE_LEAK) >>> Variable "node" going out of scope leaks the storage it points to. 341 return NULL; 342 343 node->size = len * sizeof(u32); 344 node->next = NULL; 345 346 return node; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Installed memory in DIMM B of both channels. SNB native raminit reports memory in DIMM A?
by Keith Hui 23 Dec '23

23 Dec '23

I'm having more fun with my P8Z77-M. I put my two sticks of GSkill Ripjaws in slots A2 and B2 (aka C0S1, C1S1) following manual recommendations. Surprise 1: It actually worked at full speed now! It previously would totally croak, at least when I hook up serial to watch things go. Installing only one at C1S0 still didn't boot. And that's with me putting my max memory clock back to 800. Surprise 2: This is why I'm writing this email. I got this in the console: ... [DEBUG] memcfg DDR3 ref clock 133 MHz [DEBUG] memcfg DDR3 clock 1596 MHz [DEBUG] memcfg channel assignment: A: 0, B 1, C 2 [DEBUG] memcfg channel[0] config (00630020): [DEBUG] ECC inactive [DEBUG] enhanced interleave mode on [DEBUG] rank interleave on [DEBUG] DIMMA 8192 MB width x8 dual rank [DEBUG] DIMMB 0 MB width x8 single rank, selected [DEBUG] memcfg channel[1] config (00630020): [DEBUG] ECC inactive [DEBUG] enhanced interleave mode on [DEBUG] rank interleave on [DEBUG] DIMMA 8192 MB width x8 dual rank [DEBUG] DIMMB 0 MB width x8 single rank, selected ... Am I seeing things? Why did it report memory in DIMMA when I put my memory in slot 1 only? Regards Keith

1 0

Re: Planned maintenance on Thu Dec 21 8:00 - 10:00 UTC
by Martin Roth 21 Dec '23

21 Dec '23

All three drive exchanges were just putting in blank drives and letting the raid1 resync. Dec 21, 2023 at 08:21 by coreboot(a)coreboot.org: > On 20.12.23 23:50, Martin Roth via coreboot wrote: > >> It's trivial to them, and a pain in the ass for us. It's complete bullshit that they'd do this. The company should do better. This is crap customer service, and we both know it. They deserve to be called out for that. People should know that they're happy to screw their customers over when they screw up. >> > > So what did they do in the end? Did they take the disk and copy the data > to the new one, or just swap them and let you start over with an empty > disk? > > Nico > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

Planned maintenance on Thu Dec 21 8:00 - 10:00 UTC
by Felix Singer 21 Dec '23

21 Dec '23

Our hoster made a mistake during the last maintenance this week and it needs to be fixed. That requires another (but last!) downtime at the following time for two hours. Start of maintenance: Thursday, Dec 21 8:00 UTC Expected end of maintenance: Thursday, Dec 21 10:00 UTC We are sorry for the inconveniences. Felix

3 6

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 20 Dec '23

20 Dec '23

Issue #121 has been updated by Patrick Rudolph. It's still not clear why subsystem to look at. Even with access to Intel confidential documents it's hard to tell what happens when package C states are entered. Due to the nature that the CPU isn't running at deeper C-states, it doesn't make it easier to debug. What could help: - Compare MSRs against vendor firmware - Compare power/idle related registers against vendor firmware - Disable PCI devices and test if the problem persists - Test on desktops. So far only mobile users have reported problems. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1722 * Author: Julz Buckton * 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

1 0

[coreboot - Feature #185] (Resolved) x86_64 support on real hardware
by Patrick Rudolph 20 Dec '23

20 Dec '23

Issue #185 has been updated by Patrick Rudolph. Status changed from New to Resolved Coreboot has gained x86_64 support. Closing. ---------------------------------------- Feature #185: x86_64 support on real hardware https://ticket.coreboot.org/issues/185#change-1721 * Author: Patrick Rudolph * Status: Resolved * Priority: Normal * Start date: 2018-12-08 ---------------------------------------- * port a coreboot supported mainboard from x86 to x86_64 (ROMSTAGE / RAMSTAGE only) * Get familiar with protected mode and long mode * Learn about paging * Fix existing code to support x86_64 (struct packing, linker alignment, ...) * Might need to write assembler code * Write Documentation -- 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

1 0

[coreboot - Feature #197] (Resolved) QEMU x86_64 support
by Patrick Rudolph 20 Dec '23

20 Dec '23

Issue #197 has been updated by Patrick Rudolph. Status changed from New to Resolved x86_64 is working fine on QEMU and real hardware. Closing. ---------------------------------------- Feature #197: QEMU x86_64 support https://ticket.coreboot.org/issues/197#change-1720 * Author: Patrick Rudolph * Status: Resolved * Priority: Normal * Start date: 2019-02-14 ---------------------------------------- WIP: * https://review.coreboot.org/q/topic:%22x86_64_support%22+(status:open%20OR%… Currently broken: * Relocatable ramstage on x86_64 using GCC 8 -- 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

1 0

[coreboot - Bug #262] (Resolved) Sandy Bridge/IvyBridge: Only advertise supported MWAIT states as ACPI C states
by Patrick Rudolph 20 Dec '23

20 Dec '23

Issue #262 has been updated by Patrick Rudolph. Status changed from New to Resolved Implemented here: https://review.coreboot.org/c/coreboot/+/78194 ---------------------------------------- Bug #262: Sandy Bridge/IvyBridge: Only advertise supported MWAIT states as ACPI C states https://ticket.coreboot.org/issues/262#change-1719 * Author: Patrick Rudolph * Status: Resolved * Priority: Normal * Start date: 2020-06-18 ---------------------------------------- Some CPUs might not support MWAIT(C6)/MWAIT(C7). Don't advertise them as ACPI C3 as not supported. -- 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

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 20 Dec '23

20 Dec '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 55 new defect(s) introduced to coreboot found with Coverity Scan. 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 55 defect(s) ** CID 1531473: Error handling issues (CHECKED_RETURN) /src/vendorcode/amd/opensil/genoa_poc/opensil/xUSL/CCX/Common/AmdTable.c: 135 in SetSmnTableEntry() ________________________________________________________________________________________________________ *** CID 1531473: Error handling issues (CHECKED_RETURN) /src/vendorcode/amd/opensil/genoa_poc/opensil/xUSL/CCX/Common/AmdTable.c: 135 in SetSmnTableEntry() 129 130 Status = SilGetIp2IpApi (SilId_SmuClass, (void **)&SmuApi); 131 if (Status != SilPass) { 132 XUSL_TRACEPOINT (SIL_TRACE_ERROR, "SMU API not found!\n"); 133 return Status; 134 } >>> CID 1531473: Error handling issues (CHECKED_RETURN) >>> Calling "SilGetIp2IpApi" without checking return value (as is done elsewhere 28 out of 29 times). 135 SilGetIp2IpApi (SilId_DfClass, (void**) &DfApi); 136 if (Status != SilPass) { 137 XUSL_TRACEPOINT (SIL_TRACE_ERROR, "DF API not found!\n"); 138 return Status; 139 } 140 ** CID 1531471: Control flow issues (DEADCODE) /src/vendorcode/amd/opensil/genoa_poc/opensil/xUSL/FCH/Common/FchCore/FchHwAcpi/FchHwAcpi.c: 315 in ProgramCpuRstBTmr() ________________________________________________________________________________________________________ *** CID 1531471: Control flow issues (DEADCODE) /src/vendorcode/amd/opensil/genoa_poc/opensil/xUSL/FCH/Common/FchCore/FchHwAcpi/FchHwAcpi.c: 315 in ProgramCpuRstBTmr() 309 uint32_t RegEbx; 310 uint8_t PkgType; 311 312 RegEbx = 0; 313 PkgType = (uint8_t) (RegEbx >> 28); 314 if (PkgType == 0x4) { >>> CID 1531471: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "xUSLMemReadModifyWrite8((vo...". 315 xUSLMemReadModifyWrite8((void *)(size_t)(ACPI_MMIO_BASE + PMIO_BASE + FCH_PMIOA_REG20 + 2), 0, 0xFF); 316 xUSLMemReadModifyWrite8((void *)(size_t)(ACPI_MMIO_BASE + PMIO_BASE + FCH_PMIOA_REG20 + 3), 0xF8, 0x07); 317 } 318 } 319 320 static void FchInitEnableWdt (FCHCLASS_INPUT_BLK *FchDataPtr) ** CID 1531470: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/alecthomas/kong/options.go: 379 in github.com/alecthomas/kong.Configuration.anonymous%0(*github.com/alecthomas… ________________________________________________________________________________________________________ *** CID 1531470: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/alecthomas/kong/options.go: 379 in github.com/alecthomas/kong.Configuration.anonymous%0(*github.com/alecthomas… 373 if os.IsNotExist(err) || os.IsPermission(err) { 374 continue 375 } 376 377 return err 378 } >>> CID 1531470: Audit impact security (SUPPRESSED_ERROR) >>> The error returned by the function "f.Close()" is not explicitly checked. 379 f.Close() 380 381 resolver, err := k.LoadConfig(path) 382 if err != nil { 383 return errors.Wrap(err, path) 384 } ** CID 1531469: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 1121 in github.com/fxamacker/cbor/v2.encodeTime(*github.com/fxamacker/cbor/v2.encod…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() ________________________________________________________________________________________________________ *** CID 1531469: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 1121 in github.com/fxamacker/cbor/v2.encodeTime(*github.com/fxamacker/cbor/v2.encod…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 1115 return encode(e, em, v.Elem()) 1116 } 1117 1118 func encodeTime(e *encoderBuffer, em *encMode, v reflect.Value) error { 1119 t := v.Interface().(time.Time) 1120 if t.IsZero() { >>> CID 1531469: Audit impact security (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(cborNil)" is not explicitly checked. 1121 e.Write(cborNil) // Even if tag is required, encode as CBOR null. 1122 return nil 1123 } 1124 if em.timeTag == EncTagRequired { 1125 tagNumber := 1 1126 if em.time == TimeRFC3339 || em.time == TimeRFC3339Nano { ** CID 1531468: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 795 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 791 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 804 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 808 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() ________________________________________________________________________________________________________ *** CID 1531468: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 795 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 789 vk := v.Kind() 790 if vk == reflect.Slice && v.IsNil() { 791 e.Write(cborNil) 792 return nil 793 } 794 if b := em.encTagBytes(v.Type()); b != nil { >>> CID 1531468: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(b)" is not explicitly checked. 795 e.Write(b) 796 } 797 slen := v.Len() 798 if slen == 0 { 799 return e.WriteByte(byte(cborTypeByteString)) 800 } /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 791 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 785 return nil 786 } 787 788 func encodeByteString(e *encoderBuffer, em *encMode, v reflect.Value) error { 789 vk := v.Kind() 790 if vk == reflect.Slice && v.IsNil() { >>> CID 1531468: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(cborNil)" is not explicitly checked. 791 e.Write(cborNil) 792 return nil 793 } 794 if b := em.encTagBytes(v.Type()); b != nil { 795 e.Write(b) 796 } /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 804 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 798 if slen == 0 { 799 return e.WriteByte(byte(cborTypeByteString)) 800 } 801 encodeHead(e, byte(cborTypeByteString), uint64(slen)) 802 if vk == reflect.Array { 803 for i := 0; i < slen; i++ { >>> CID 1531468: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.WriteByte((uint8)v.Index(i).Uint())" is not explicitly checked. 804 e.WriteByte(byte(v.Index(i).Uint())) 805 } 806 return nil 807 } 808 e.Write(v.Bytes()) 809 return nil /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 808 in github.com/fxamacker/cbor/v2.encodeByteString(*github.com/fxamacker/cbor/v2…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 802 if vk == reflect.Array { 803 for i := 0; i < slen; i++ { 804 e.WriteByte(byte(v.Index(i).Uint())) 805 } 806 return nil 807 } >>> CID 1531468: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(v.Bytes())" is not explicitly checked. 808 e.Write(v.Bytes()) 809 return nil 810 } 811 812 func encodeString(e *encoderBuffer, em *encMode, v reflect.Value) error { 813 if b := em.encTagBytes(v.Type()); b != nil { ** CID 1531467: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 828 in github.com/fxamacker/cbor/v2.arrayEncodeFunc.encode(*github.com/fxamacker/c…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 832 in github.com/fxamacker/cbor/v2.arrayEncodeFunc.encode(*github.com/fxamacker/c…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() ________________________________________________________________________________________________________ *** CID 1531467: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 828 in github.com/fxamacker/cbor/v2.arrayEncodeFunc.encode(*github.com/fxamacker/c…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 822 type arrayEncodeFunc struct { 823 f encodeFunc 824 } 825 826 func (ae arrayEncodeFunc) encode(e *encoderBuffer, em *encMode, v reflect.Value) error { 827 if v.Kind() == reflect.Slice && v.IsNil() { >>> CID 1531467: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(cborNil)" is not explicitly checked. 828 e.Write(cborNil) 829 return nil 830 } 831 if b := em.encTagBytes(v.Type()); b != nil { 832 e.Write(b) 833 } /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 832 in github.com/fxamacker/cbor/v2.arrayEncodeFunc.encode(*github.com/fxamacker/c…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 826 func (ae arrayEncodeFunc) encode(e *encoderBuffer, em *encMode, v reflect.Value) error { 827 if v.Kind() == reflect.Slice && v.IsNil() { 828 e.Write(cborNil) 829 return nil 830 } 831 if b := em.encTagBytes(v.Type()); b != nil { >>> CID 1531467: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(b)" is not explicitly checked. 832 e.Write(b) 833 } 834 alen := v.Len() 835 if alen == 0 { 836 return e.WriteByte(byte(cborTypeArray)) 837 } ** CID 1531466: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 43118 in wuffs_jpeg__decoder__decode_sof() ________________________________________________________________________________________________________ *** CID 1531466: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 43118 in wuffs_jpeg__decoder__decode_sof() 43112 } 43113 if (self->private_impl.f_height == 0u) { 43114 status = wuffs_base__make_status(wuffs_jpeg__error__unsupported_implicit_height); 43115 goto exit; 43116 } 43117 { >>> CID 1531466: Control flow issues (MISSING_BREAK) >>> The case for value "4U" is not terminated by a "break" statement. 43118 WUFFS_BASE__COROUTINE_SUSPENSION_POINT(4); 43119 uint32_t t_2; 43120 if (WUFFS_BASE__LIKELY(io2_a_src - iop_a_src >= 2)) { 43121 t_2 = ((uint32_t)(wuffs_base__peek_u16be__no_bounds_check(iop_a_src))); 43122 iop_a_src += 2; 43123 } else { ** CID 1531465: Incorrect expression (NO_EFFECT) /src/vendorcode/wuffs/wuffs-v0.4.c: 42580 in wuffs_jpeg__decoder__do_decode_image_config() ________________________________________________________________________________________________________ *** CID 1531465: Incorrect expression (NO_EFFECT) /src/vendorcode/wuffs/wuffs-v0.4.c: 42580 in wuffs_jpeg__decoder__do_decode_image_config() 42574 status = wuffs_base__make_status(wuffs_base__suspension__short_read); 42575 goto suspend; 42576 } 42577 iop_a_src += self->private_data.s_do_decode_image_config[0].scratch; 42578 self->private_impl.f_payload_length = 0u; 42579 } >>> CID 1531465: Incorrect expression (NO_EFFECT) >>> Assigning "self->private_impl.choosy_decode_idct" to itself has no effect. 42580 self->private_impl.choosy_decode_idct = ( 42581 #if defined(WUFFS_BASE__CPU_ARCH__X86_64) 42582 wuffs_base__cpu_arch__have_x86_avx2() ? &wuffs_jpeg__decoder__decode_idct_x86_avx2 : 42583 #endif 42584 self->private_impl.choosy_decode_idct); 42585 self->private_impl.f_frame_config_io_position = wuffs_base__u64__sat_add((a_src ? a_src->meta.pos : 0), ((uint64_t)(iop_a_src - io0_a_src))); ** CID 1531464: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 19866 in wuffs_base__pixel_palette__closest_element() ________________________________________________________________________________________________________ *** CID 1531464: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 19866 in wuffs_base__pixel_palette__closest_element() 19860 // These deltas are conceptually int32_t (signed) but after squaring, 19861 // it's equivalent to work in uint32_t (unsigned). 19862 pb -= cb; 19863 pg -= cg; 19864 pr -= cr; 19865 pa -= ca; >>> CID 1531464: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "pg * pg" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 19866 uint64_t score = ((uint64_t)(pb * pb)) + ((uint64_t)(pg * pg)) + 19867 ((uint64_t)(pr * pr)) + ((uint64_t)(pa * pa)); 19868 if (best_score > score) { 19869 best_score = score; 19870 best_index = i; 19871 } ** CID 1531463: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 42377 in wuffs_jpeg__decoder__do_decode_image_config() ________________________________________________________________________________________________________ *** CID 1531463: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 42377 in wuffs_jpeg__decoder__do_decode_image_config() 42371 42372 if (self->private_impl.f_call_sequence != 0u) { 42373 status = wuffs_base__make_status(wuffs_base__error__bad_call_sequence); 42374 goto exit; 42375 } 42376 { >>> CID 1531463: Control flow issues (MISSING_BREAK) >>> The case for value "1U" is not terminated by a "break" statement. 42377 WUFFS_BASE__COROUTINE_SUSPENSION_POINT(1); 42378 if (WUFFS_BASE__UNLIKELY(iop_a_src == io2_a_src)) { 42379 status = wuffs_base__make_status(wuffs_base__suspension__short_read); 42380 goto suspend; 42381 } 42382 uint8_t t_0 = *iop_a_src++; ** CID 1531462: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 316 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 301 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 267 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 275 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 218 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 291 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 305 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 217 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 285 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 261 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 270 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 308 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 205 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 282 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 219 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() ________________________________________________________________________________________________________ *** CID 1531462: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 316 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 310 keys := v.MapKeys() 311 if f.cs.SortKeys { 312 sortValues(keys, f.cs) 313 } 314 for i, key := range keys { 315 if i > 0 { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(spaceBytes)" is not explicitly checked. 316 f.fs.Write(spaceBytes) 317 } 318 f.ignoreNextType = true 319 f.format(f.unpackValue(key)) 320 f.fs.Write(colonBytes) 321 f.ignoreNextType = true /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 301 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 295 // Do nothing. We should never get here since pointers have already 296 // been handled above. 297 298 case reflect.Map: 299 // nil maps should be indicated as different than empty maps 300 if v.IsNil() { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(nilAngleBytes)" is not explicitly checked. 301 f.fs.Write(nilAngleBytes) 302 break 303 } 304 305 f.fs.Write(openMapBytes) 306 f.depth++ /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 267 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 261 f.fs.Write(nilAngleBytes) 262 break 263 } 264 fallthrough 265 266 case reflect.Array: >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(openBracketBytes)" is not explicitly checked. 267 f.fs.Write(openBracketBytes) 268 f.depth++ 269 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { 270 f.fs.Write(maxShortBytes) 271 } else { 272 numEntries := v.Len() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 275 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 269 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { 270 f.fs.Write(maxShortBytes) 271 } else { 272 numEntries := v.Len() 273 for i := 0; i < numEntries; i++ { 274 if i > 0 { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(spaceBytes)" is not explicitly checked. 275 f.fs.Write(spaceBytes) 276 } 277 f.ignoreNextType = true 278 f.format(f.unpackValue(v.Index(i))) 279 } 280 } /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 218 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 212 return 213 } 214 215 // Print type information unless already handled elsewhere. 216 if !f.ignoreNextType && f.fs.Flag('#') { 217 f.fs.Write(openParenBytes) >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(([]byte)v.Type().String())" is not explicitly checked. 218 f.fs.Write([]byte(v.Type().String())) 219 f.fs.Write(closeParenBytes) 220 } 221 f.ignoreNextType = false 222 223 // Call Stringer/error interfaces if they exist and the handle methods /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 291 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 285 f.fs.Write([]byte(v.String())) 286 287 case reflect.Interface: 288 // The only time we should get here is for nil interfaces due to 289 // unpackValue calls. 290 if v.IsNil() { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(nilAngleBytes)" is not explicitly checked. 291 f.fs.Write(nilAngleBytes) 292 } 293 294 case reflect.Ptr: 295 // Do nothing. We should never get here since pointers have already 296 // been handled above. /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 305 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 299 // nil maps should be indicated as different than empty maps 300 if v.IsNil() { 301 f.fs.Write(nilAngleBytes) 302 break 303 } 304 >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(openMapBytes)" is not explicitly checked. 305 f.fs.Write(openMapBytes) 306 f.depth++ 307 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { 308 f.fs.Write(maxShortBytes) 309 } else { 310 keys := v.MapKeys() /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 217 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 211 f.formatPtr(v) 212 return 213 } 214 215 // Print type information unless already handled elsewhere. 216 if !f.ignoreNextType && f.fs.Flag('#') { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(openParenBytes)" is not explicitly checked. 217 f.fs.Write(openParenBytes) 218 f.fs.Write([]byte(v.Type().String())) 219 f.fs.Write(closeParenBytes) 220 } 221 f.ignoreNextType = false 222 /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 285 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 279 } 280 } 281 f.depth-- 282 f.fs.Write(closeBracketBytes) 283 284 case reflect.String: >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(([]byte)v.String())" is not explicitly checked. 285 f.fs.Write([]byte(v.String())) 286 287 case reflect.Interface: 288 // The only time we should get here is for nil interfaces due to 289 // unpackValue calls. 290 if v.IsNil() { /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 261 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 255 256 case reflect.Complex128: 257 printComplex(f.fs, v.Complex(), 64) 258 259 case reflect.Slice: 260 if v.IsNil() { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(nilAngleBytes)" is not explicitly checked. 261 f.fs.Write(nilAngleBytes) 262 break 263 } 264 fallthrough 265 266 case reflect.Array: /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 270 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 264 fallthrough 265 266 case reflect.Array: 267 f.fs.Write(openBracketBytes) 268 f.depth++ 269 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(maxShortBytes)" is not explicitly checked. 270 f.fs.Write(maxShortBytes) 271 } else { 272 numEntries := v.Len() 273 for i := 0; i < numEntries; i++ { 274 if i > 0 { 275 f.fs.Write(spaceBytes) /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 308 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 302 break 303 } 304 305 f.fs.Write(openMapBytes) 306 f.depth++ 307 if (f.cs.MaxDepth != 0) && (f.depth > f.cs.MaxDepth) { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(maxShortBytes)" is not explicitly checked. 308 f.fs.Write(maxShortBytes) 309 } else { 310 keys := v.MapKeys() 311 if f.cs.SortKeys { 312 sortValues(keys, f.cs) 313 } /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 205 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 199 // dealing with and formats it appropriately. It is a recursive function, 200 // however circular data structures are detected and handled properly. 201 func (f *formatState) format(v reflect.Value) { 202 // Handle invalid reflect values immediately. 203 kind := v.Kind() 204 if kind == reflect.Invalid { >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(invalidAngleBytes)" is not explicitly checked. 205 f.fs.Write(invalidAngleBytes) 206 return 207 } 208 209 // Handle pointers specially. 210 if kind == reflect.Ptr { /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 282 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 276 } 277 f.ignoreNextType = true 278 f.format(f.unpackValue(v.Index(i))) 279 } 280 } 281 f.depth-- >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(closeBracketBytes)" is not explicitly checked. 282 f.fs.Write(closeBracketBytes) 283 284 case reflect.String: 285 f.fs.Write([]byte(v.String())) 286 287 case reflect.Interface: /util/goswid/vendor/github.com/davecgh/go-spew/spew/format.go: 219 in github.com/davecgh/go-spew/spew.formatState.format(reflect.Value)() 213 } 214 215 // Print type information unless already handled elsewhere. 216 if !f.ignoreNextType && f.fs.Flag('#') { 217 f.fs.Write(openParenBytes) 218 f.fs.Write([]byte(v.Type().String())) >>> CID 1531462: (SUPPRESSED_ERROR) >>> The error returned by the function "f.fs.Write(closeParenBytes)" is not explicitly checked. 219 f.fs.Write(closeParenBytes) 220 } 221 f.ignoreNextType = false 222 223 // Call Stringer/error interfaces if they exist and the handle methods 224 // flag is enabled. ** CID 1531461: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/alecthomas/kong/tag.go: 206 in github.com/alecthomas/kong.hydrateTag(*github.com/alecthomas/kong.Tag, reflect.Type)error() /util/goswid/vendor/github.com/alecthomas/kong/tag.go: 205 in github.com/alecthomas/kong.hydrateTag(*github.com/alecthomas/kong.Tag, reflect.Type)error() ________________________________________________________________________________________________________ *** CID 1531461: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/alecthomas/kong/tag.go: 206 in github.com/alecthomas/kong.hydrateTag(*github.com/alecthomas/kong.Tag, reflect.Type)error() 200 if err != nil && t.Get("short") != "" { 201 return fmt.Errorf("invalid short flag name %q: %s", t.Get("short"), err) 202 } 203 t.Hidden = t.Has("hidden") 204 t.Format = t.Get("format") 205 t.Sep, _ = t.GetSep("sep", ',') >>> CID 1531461: (SUPPRESSED_ERROR) >>> The error returned by the function "t.GetSep("mapsep", 59)" is not explicitly checked. 206 t.MapSep, _ = t.GetSep("mapsep", ';') 207 t.Group = t.Get("group") 208 for _, xor := range t.GetAll("xor") { 209 t.Xor = append(t.Xor, strings.FieldsFunc(xor, tagSplitFn)...) 210 } 211 t.Prefix = t.Get("prefix") /util/goswid/vendor/github.com/alecthomas/kong/tag.go: 205 in github.com/alecthomas/kong.hydrateTag(*github.com/alecthomas/kong.Tag, reflect.Type)error() 199 t.Short, err = t.GetRune("short") 200 if err != nil && t.Get("short") != "" { 201 return fmt.Errorf("invalid short flag name %q: %s", t.Get("short"), err) 202 } 203 t.Hidden = t.Has("hidden") 204 t.Format = t.Get("format") >>> CID 1531461: (SUPPRESSED_ERROR) >>> The error returned by the function "t.GetSep("sep", 44)" is not explicitly checked. 205 t.Sep, _ = t.GetSep("sep", ',') 206 t.MapSep, _ = t.GetSep("mapsep", ';') 207 t.Group = t.Get("group") 208 for _, xor := range t.GetAll("xor") { 209 t.Xor = append(t.Xor, strings.FieldsFunc(xor, tagSplitFn)...) 210 } ** CID 1531460: Null pointer dereferences (FORWARD_NULL) /src/vendorcode/wuffs/wuffs-v0.4.c: 43686 in wuffs_jpeg__decoder__do_decode_frame() ________________________________________________________________________________________________________ *** CID 1531460: Null pointer dereferences (FORWARD_NULL) /src/vendorcode/wuffs/wuffs-v0.4.c: 43686 in wuffs_jpeg__decoder__do_decode_frame() 43680 { 43681 WUFFS_BASE__COROUTINE_SUSPENSION_POINT(2); 43682 if (WUFFS_BASE__UNLIKELY(iop_a_src == io2_a_src)) { 43683 status = wuffs_base__make_status(wuffs_base__suspension__short_read); 43684 goto suspend; 43685 } >>> CID 1531460: Null pointer dereferences (FORWARD_NULL) >>> Incrementing null pointer "iop_a_src". 43686 uint8_t t_0 = *iop_a_src++; 43687 v_c = t_0; 43688 } 43689 if (v_c == 255u) { 43690 break; 43691 } ** CID 1531459: Audit impact security (SUPPRESSED_ERROR) /util/goswid/pkg/uswid/uswid.go: 342 in github.com/9elements/goswid/pkg/uswid.UswidSoftwareIdentity.ToCBOR(bool)([]…, error)() ________________________________________________________________________________________________________ *** CID 1531459: Audit impact security (SUPPRESSED_ERROR) /util/goswid/pkg/uswid/uswid.go: 342 in github.com/9elements/goswid/pkg/uswid.UswidSoftwareIdentity.ToCBOR(bool)([]…, error)() 336 var buf bytes.Buffer 337 zlibWriter := zlib.NewWriter(&buf) 338 _, err := zlibWriter.Write(cborBuf) 339 if err != nil { 340 return nil, fmt.Errorf("cannot zlib compress CBOR data: %w", err) 341 } >>> CID 1531459: Audit impact security (SUPPRESSED_ERROR) >>> The error returned by the function "zlibWriter.Close()" is not explicitly checked. 342 zlibWriter.Close() 343 return buf.Bytes(), nil 344 } else { 345 return cborBuf, nil 346 } ** CID 1531458: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 689 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 657 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 680 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 642 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() ________________________________________________________________________________________________________ *** CID 1531458: (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 689 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 683 } 684 685 // Encode float32 686 // Don't use encodeFloat32() because it cannot be inlined. 687 e.scratch[0] = byte(cborTypePrimitives) | byte(26) 688 binary.BigEndian.PutUint32(e.scratch[1:], math.Float32bits(f32)) >>> CID 1531458: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(e.scratch[nil:5:nil])" is not explicitly checked. 689 e.Write(e.scratch[:5]) 690 return nil 691 } 692 693 func encodeInf(e *encoderBuffer, em *encMode, v reflect.Value) error { 694 f64 := v.Float() /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 657 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 651 fopt := em.shortestFloat 652 if v.Kind() == reflect.Float64 && (fopt == ShortestFloatNone || cannotFitFloat32(f64)) { 653 // Encode float64 654 // Don't use encodeFloat64() because it cannot be inlined. 655 e.scratch[0] = byte(cborTypePrimitives) | byte(27) 656 binary.BigEndian.PutUint64(e.scratch[1:], math.Float64bits(f64)) >>> CID 1531458: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(e.scratch[nil:9:nil])" is not explicitly checked. 657 e.Write(e.scratch[:9]) 658 return nil 659 } 660 661 f32 := float32(f64) 662 if fopt == ShortestFloat16 { /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 680 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 674 } 675 if p == float16.PrecisionExact { 676 // Encode float16 677 // Don't use encodeFloat16() because it cannot be inlined. 678 e.scratch[0] = byte(cborTypePrimitives) | byte(25) 679 binary.BigEndian.PutUint16(e.scratch[1:], uint16(f16)) >>> CID 1531458: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(e.scratch[nil:3:nil])" is not explicitly checked. 680 e.Write(e.scratch[:3]) 681 return nil 682 } 683 } 684 685 // Encode float32 /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 642 in github.com/fxamacker/cbor/v2.encodeFloat(*github.com/fxamacker/cbor/v2.enco…, *github.com/fxamacker/cbor/v2.encMode, reflect.Value)error() 636 encodeHead(e, byte(cborTypePositiveInt), v.Uint()) 637 return nil 638 } 639 640 func encodeFloat(e *encoderBuffer, em *encMode, v reflect.Value) error { 641 if b := em.encTagBytes(v.Type()); b != nil { >>> CID 1531458: (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(b)" is not explicitly checked. 642 e.Write(b) 643 } 644 f64 := v.Float() 645 if math.IsNaN(f64) { 646 return encodeNaN(e, em, v) 647 } ** CID 1531457: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 3939 in wuffs_base__color_u32_argb_premul__as__color_u64_argb_nonpremul() ________________________________________________________________________________________________________ *** CID 1531457: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 3939 in wuffs_base__color_u32_argb_premul__as__color_u64_argb_nonpremul() 3933 uint64_t g16 = 0x101 * (0xFF & (c >> 8)); 3934 uint64_t b16 = 0x101 * (0xFF & (c >> 0)); 3935 return 0xFFFF000000000000u | (r16 << 32) | (g16 << 16) | (b16 << 0); 3936 } else if (a == 0) { 3937 return 0; 3938 } >>> CID 1531457: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "a * 257U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 3939 uint64_t a16 = a * 0x101; 3940 3941 uint64_t r = 0xFF & (c >> 16); 3942 uint64_t r16 = (r * (0x101 * 0xFFFF)) / a16; 3943 uint64_t g = 0xFF & (c >> 8); 3944 uint64_t g16 = (g * (0x101 * 0xFFFF)) / a16; ** CID 1531456: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 777 in github.com/fxamacker/cbor/v2.encodeFloat32(*github.com/fxamacker/cbor/v2.en…, float32)error() ________________________________________________________________________________________________________ *** CID 1531456: Audit impact security (SUPPRESSED_ERROR) /util/goswid/vendor/github.com/fxamacker/cbor/v2/encode.go: 777 in github.com/fxamacker/cbor/v2.encodeFloat32(*github.com/fxamacker/cbor/v2.en…, float32)error() 771 return nil 772 } 773 774 func encodeFloat32(e *encoderBuffer, f32 float32) error { 775 e.scratch[0] = byte(cborTypePrimitives) | byte(26) 776 binary.BigEndian.PutUint32(e.scratch[1:], math.Float32bits(f32)) >>> CID 1531456: Audit impact security (SUPPRESSED_ERROR) >>> The error returned by the function "e.Buffer.Write(e.scratch[nil:5:nil])" is not explicitly checked. 777 e.Write(e.scratch[:5]) 778 return nil 779 } 780 781 func encodeFloat64(e *encoderBuffer, f64 float64) error { 782 e.scratch[0] = byte(cborTypePrimitives) | byte(27) ** CID 1531455: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 19866 in wuffs_base__pixel_palette__closest_element() ________________________________________________________________________________________________________ *** CID 1531455: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/vendorcode/wuffs/wuffs-v0.4.c: 19866 in wuffs_base__pixel_palette__closest_element() 19860 // These deltas are conceptually int32_t (signed) but after squaring, 19861 // it's equivalent to work in uint32_t (unsigned). 19862 pb -= cb; 19863 pg -= cg; 19864 pr -= cr; 19865 pa -= ca; >>> CID 1531455: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "pb * pb" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 19866 uint64_t score = ((uint64_t)(pb * pb)) + ((uint64_t)(pg * pg)) + 19867 ((uint64_t)(pr * pr)) + ((uint64_t)(pa * pa)); 19868 if (best_score > score) { 19869 best_score = score; 19870 best_index = i; 19871 } ** CID 1531454: Audit impact security (UNSAFE_FUNCTIONALITY) /util/goswid/vendor/github.com/davecgh/go-spew/spew/bypass.go: 36 in () ________________________________________________________________________________________________________ *** CID 1531454: Audit impact security (UNSAFE_FUNCTIONALITY) /util/goswid/vendor/github.com/davecgh/go-spew/spew/bypass.go: 36 in () 30 const ( 31 // UnsafeDisabled is a build-time constant which specifies whether or 32 // not access to the unsafe package is available. 33 UnsafeDisabled = false 34 35 // ptrSize is the size of a pointer on the current arch. >>> CID 1531454: Audit impact security (UNSAFE_FUNCTIONALITY) >>> Using unsafe function Sizeof. 36 ptrSize = unsafe.Sizeof((*byte)(nil)) 37 ) 38 39 type flag uintptr 40 41 var ( ** CID 1531453: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 42830 in wuffs_jpeg__decoder__decode_appn() ________________________________________________________________________________________________________ *** CID 1531453: Control flow issues (MISSING_BREAK) /src/vendorcode/wuffs/wuffs-v0.4.c: 42830 in wuffs_jpeg__decoder__decode_appn() 42824 iop_a_src = io1_a_src; 42825 io2_a_src = io0_a_src + a_src->meta.wi; 42826 } 42827 42828 uint32_t coro_susp_point = self->private_impl.p_decode_appn[0]; 42829 switch (coro_susp_point) { >>> CID 1531453: Control flow issues (MISSING_BREAK) >>> The case for value "0U" is not terminated by a "break" statement. 42830 WUFFS_BASE__COROUTINE_SUSPENSION_POINT_0; 42831 42832 do { 42833 if (a_marker == 224u) { 42834 if (self->private_impl.f_payload_length >= 5u) { 42835 self->private_impl.f_payload_length -= 5u; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian 20 Dec '23

20 Dec '23

Issue #121 has been updated by Anastasios Koutian. After upgrading to coreboot 4.22.01, the issue seems to have returned for me. Hardware is the same as above, however now there is no black screen and no graphical corruption. Instead the whole screen just freezes (along with the entire system). Also, it happens only after 1-2 days whereas before it would appear within 1-2 hours. I am now limiting package C-state to 2 using MSR_PKG_CST_CONFIG_CONTROL as you suggested. I can confirm ~0.7 - 1.0 W extra power usage when idle. If you would like me to test anything else, please let me know and I would be happy to help. If this issue could be eliminated, it would be great for these older laptops, since their battery life is already limited. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1718 * Author: Julz Buckton * 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

1 0

Re: ramstage video display on Chromebook?
by James Feeney 19 Dec '23

19 Dec '23

Down the rabbit hole... > Geminilake devices use the FSP PEI GOP driver for display init Hmm - "Pre-EFI Initialization Graphics Output Protocol"? Is this something completely different from the coreboot gfxinit? INTEL_GMA_ADD_VBT help says: The VBT describes the integrated GPU and connections, and is needed by the GOP driver integrated into FSP and the OS driver in order to initialize the display. https://wiki.osdev.org/GOP tells me: GOP is an EFI Boot Time Service, meaning you can't access it after you call ExitBootServices(). However, the framebuffer provided by GOP persists, so you can continue to use it for graphics output in your OS. How does the payload find this framebuffer? Is that info in the VBT? Or, the payload ignores this framebuffer, starts over and completely re-initializes the graphics? > so the display backlight will come on during ramstage (when FSP-S runs) That's very useful to know. > but the platform does not currently support any output / proof of life prior to the payload, other than maybe an early boot splash screen (you'd have to look if GLK supports that) Could be fun - eye candy. Martin says "Intel better than others thanks to libgfxinit", so if GOP is not GFX, then maybe a splash screen will not work? Or GFX also knows how to write to the GOP framebuffer? > simply connecting the debug cable and flashing a serial output enabled build will tell you the same thing Geminilake has serial output? This bluebird chromebook has one USB-C and one USB-A. Is the serial output going through the debug cable? It's not just some buried header on the circuit board? > coreboot saves the console output to memory and to any other output you have enabled in Kconfig. "console output to memory" meaning RAM? Or only to ROM? Or either? > The ROM does have a limited write capacity, but it's typically 100K erase/write cycles at this point, which should be enough for anyone. > Worth to mention that the flash console driver never erases. When it's full, it's full, the user needs to erase it manually. In my case, I don't like to be writing and erasing the system ROM. > Would a live Q/A session help? I'd be happy to host something. Thanks, but email is fine. It gives me time to digest, and hopefully it may leave a useful trail for someone else. Mostly, I'm being curious. Sometimes I have to stumble around before I can ask a meaningful question, and everyone's patience is much appreciated.

2 1

ramstage video display on Chromebook?
by James Feeney 19 Dec '23

19 Dec '23

On 12/18/2023 1:00 PM MST Matt DeVillier <matt.devillier(a)gmail.com> wrote: ... Thanks for all that, Matt. A little perspective helps me a lot! I'm wondering, with MrChrombox coreboot will anything normally show on a chromebook screen at ramstage, before payload? Or, if not, can anything be *made* to show on the screen, like status or debug info? I'm thinking, if a payload fails, at least something on the screen from coreboot ramstage would indicate that coreboot executed up through ramstage, without needing to connect a debug cable - and sort of geek eye-candy. Also, it looks like there is a way to save coreboot debug messages to a file. But, does that use CAR, or would messages be repeatedly written to the ROM with every boot? Maybe cache is too small to use for debug messages - geminilake? Or repeatedly writing to ROM reduces its life?

4 3

Re: Google Embedded Controller blob - how does that get to the EC?
by James Feeney 18 Dec '23

18 Dec '23

> Since my MrChromebox firmware does not use vboot, I have ported the EC-RW firmware update code from vboot to coreboot, and check if an EC-RW update is needed on each boot as part of EC init in ramstage. This code is in my tree on github for inspection. Well, there are over 100 files named "ramstage.c" in the github repository. Do I understand correctly that the MrChromebox firmware generated will have a custom ramstage, different from the stock coreboot ramstage, just to check if an EC-RW update is needed? Coreboot would not typically try to do that? > It's not necessary to build your own EC-RW firmware or even update it unless there's a specific issue you're trying to resolve. But still, to play-around with different payloads, using mostly stock coreboot, the EC firmware could just be completely left out of the coreboot ROM image? And, if I still needed to update the EC firmware, I could use the Google flashrom fork, as in the Google example, just: flashrom -p internal:bus=lpc -w ec.bin ?

2 3

coreboot services are back up
by coreboot org 18 Dec '23

18 Dec '23

This should have taken care of the issues we've been seeing recently with gerrit. If you see any issues with any of the services, other than the redmine service at ticket.coreboot.org, which is on a different server, please respond to this email and let us know what you're seeing. Martin

1 0

coreboot.org downtime for a couple of hours right *NOW*
by coreboot org 17 Dec '23

17 Dec '23

Hi All, We're taking down the coreboot servers for a couple of hours to do some emergency maintenance. Sorry for the short notice - everything should be back up in a couple of hours. Martin

1 0

Re: Google Embedded Controller blob - how does that get to the EC?
by James Feeney 17 Dec '23

17 Dec '23

> If you do need to update the EC firmware, just flash it manually. Don't bother with the automatic update. It doesn't make sense for you to build it into the firmware. Thanks. That makes more sense. Though still, I don't know where or when this "automatic update" happens. Maybe it happens when ChromeOS itself starts? If that is the case, then the EC update would *never* happen automatically if ChromeOS is replaced with something else. On the other hand, if the EC binary itself is somehow searching the CPU ROM for an EC ROM image, then it might get confused if there is no EC ROM image to find. Maybe Matt knows how this works? Matt? I also see that the Google flashrom fork seems to know how to do this update manually, if a filesystem exists, where http://goo.gl/i5sMq , "Flashrom @ Chromium.org", has: Similarly, to write the x86 and EC firmware ROMs (assume write-protection disabled): flashrom -p internal:bus=spi -w bios.bin # write x86 firmware flashrom -p internal:bus=lpc -w ec.bin # write EC firmware As far as I know, linux does not know how to directly mount a ROM coreboot filesystem.

2 1

Re: geminilake fsp on Google Chromebook?
by James Feeney 17 Dec '23

17 Dec '23

>> Then, how do I find whether a particular fspm/fsps set is using the coreboot 2.2.0.0 headers or the 2.2.3.1 headers? Those headers are very similar. > you can't, without knowing the exact build they came from. If they are Google built firmware images, they are using the Google FSP binaries/headers. Is that to say that the Google FSP headers may not match *any* version of the coreboot headers available? The FSP headers look to be setting some address offsets, which would not end well, if the wrong values were being used by coreboot. > For anything else, you'd need to know the tree/hash it was built from and which header values were selected by the build. Hmm - so in the end, "trial and error", if I really wanted to use the extracted Google FSP binaries. I'm hoping that other extracted Google blobs are not so finicky - the Embedded Controller blob, for instance? >> Where your config is for the edk2 payload, is there any reason that these same edk2 FSP files would not also work with the LinuxBoot payload? > I have no idea what you are asking here - edk2 FSP files? That phrase does not make sense to me. I'm also not familiar with the LinuxBoot payload or how it would relate to edk2 Ha! I'm expecting that the FSP files being used should have nothing at all to do with the eventual coreboot payload. I was just asking for confirmation. Though I'm not completely unfamiliar with firmware generally, with coreboot and Google firmware, sometimes my assumptions are correct, and sometimes they are completely off-base and wrong. As far as playing with LinuxBoot itself, yes, I know that I may be on my own for that.

3 2

Google Embedded Controller blob - how does that get to the EC?
by James Feeney 17 Dec '23

17 Dec '23

>> I'm hoping that other extracted Google blobs are not so finicky - the Embedded Controller blob, for instance? > As far as the EC, it's all open source, and in public repos at Google. You can rebuild it instead of using their binary. Thanks for that Martin. Still, I'm intimidated by the EC blob. On my board, Google's forked flashrom says: Found Nuvoton flash chip "NPCX796F". Some Nuvoton ECs, and probably this one, are ARM chips. 3rdparty/chromeec/README.md says: If you want instant gratification, you can fetch the source code directly. However, you will need the tool-chain provided by the Chromium OS development environment to build a binary. And then, at http://goo.gl/i5sMq, "Flashrom @ Chromium.org" says: For these examples, we assume the x86 firmware ROM is connected directly to the host via SPI and the EC ROM is connected via the EC to LPC. And then, no matter how this EC blob is acquired, that Google page does not seem to disclose exactly *how* this EC ROM image is suppose to get from the coreboot ROM image, and into the separate EC ROM. But, for instance, I see u-boot/cmd/Kconfig actually has: menu "Firmware commands" config CMD_CROS_EC bool "Enable crosec command" depends on CROS_EC default y help Enable command-line access to the Chrome OS EC (Embedded Controller). This provides the 'crosec' command which has a number of sub-commands for performing EC tasks such as updating its flash, accessing a small saved context area and talking to the I2C bus behind the EC (if there is one). So, even after going to the trouble of getting an EC ROM image into coreboot, how does this get into the EC ROM? Does coreboot have some "magic" that checks the EC ROM version, and then automatically flash the EC ROM? Or, does this have to be done manually? And, if manually, and if u-boot is not being used, does this "crosec" command have to be found or built, to run in an x86 linux for instance, and used to actually flash the EC ROM?

3 2

Re: geminilake fsp on Google Chromebook?
by Martin Roth 17 Dec '23

17 Dec '23

Actually, Intel doesn't have much to do with this. I can look at adding the feature, but the chromeos team would need to evaluate the size differences and decide to whether to enable it. Dec 17, 2023 at 12:09 by coreboot(a)coreboot.org: > Dec 16, 2023 at 20:16 by coreboot(a)coreboot.org: > >> Just a thought, the FSP headers are pretty small. Maybe they can be compressed and added to the firmware image to make this easier, the way we do for the config file. >> > > Considering that coreboot needs to know these FSP address offsets, that would seem an excellent idea. Or, at least a reference to the actual version of the headers used could be added to the firmware image, if a unique header version number exists. > > I notice that in the documentation, referenced at 3rdparty/fsp/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf, Intel mentions Coreboot specifically by name. So maybe the coreboot developers would hold some sway with this idea. > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

Re: geminilake fsp on Google Chromebook?
by James Feeney 17 Dec '23

17 Dec '23

Dec 16, 2023 at 20:16 by coreboot(a)coreboot.org: > Just a thought, the FSP headers are pretty small. Maybe they can be compressed and added to the firmware image to make this easier, the way we do for the config file. Considering that coreboot needs to know these FSP address offsets, that would seem an excellent idea. Or, at least a reference to the actual version of the headers used could be added to the firmware image, if a unique header version number exists. I notice that in the documentation, referenced at 3rdparty/fsp/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf, Intel mentions Coreboot specifically by name. So maybe the coreboot developers would hold some sway with this idea.

1 0

COM Express type 7 / 6 board?
by ron minnich 15 Dec '23

15 Dec '23

I'm looking for a COM Express board, type 6 or 7, that runs coreboot, thought I would start here.

4 5

Re: geminilake fsp on Google Chromebook?
by James Feeney 15 Dec '23

15 Dec '23

>> … I expect that that refers to an even newer "release 9" versus a "release 8". And, this "-r9" should also work with the setting: CONFIG_FSP_HEADER_PATH= "src/vendorcode/intel/fsp/fsp2 _0/geminilake/ 2.2.3.1 " Is that correct? > NO! those strings are simply build paths, they have no correlation to the version of headers which need to be used with a given binary/binaries. Google binaries use Google's headers. Intel's binaries use Intel's headers. Then, how do I find whether a particular fspm/fsps set is using the coreboot 2.2.0.0 headers or the 2.2.3.1 headers? Those headers are very similar. > Also, the binaries in my repo would not have anything resembling that build path as it's specific to a Google ChromeOS build system, and my binaries are not from a ChromeOS device. Oops! I was looking at your binaries in 3rdparty/blobs/mainboard/google/octopus/casta/ instead of your binaries from the site-local/Kconfig, 3rdparty/blobs/soc/intel/glk/fsp/release/. $ strings 3rdparty/blobs/soc/intel/glk/fsp/release/Fsp_M.fd |grep -i gemini|head -1 c:\tcwork\bxt_ap7829\Build\GeminilakeFspPkg\RELEASE_VS2013x86\IA32\GeminilakeSiliconPkg\NorthCluster\MemoryInitGlk\MemoryInitFsp\DEBUG\AutoGen.c Where your config is for the edk2 payload, is there any reason that these same edk2 FSP files would not also work with the LinuxBoot payload?

2 1

Re: geminilake fsp on Google Chromebook?
by Matt DeVillier 14 Dec '23

14 Dec '23

On Thu, Dec 14, 2023 at 6:07 PM James Feeney <james(a)nurealm.net> wrote: > > To get it to update values to new default settings, run: > > make savedefconfig && make defconfig KBUILD_DEFCONFIG=${PWD}/defconfig > > The Kconfig in coreboot document is written with developers writing > Kconfig files in mind, but it's got a lot of useful information about how > Kconfig works. > > That helps. It's sort of a "process", building a ".config", rather than a > single "make nconfig" and done. > since you're starting with my defconfigs, you don't need to change anything. They are the exact configs I use to build my release firmware and are known/tested working. > > > all this mess is because you're trying to use an existing config rather > than start from my defconfig, which is designed to work with my repo. The > selections are currently guarded appropriately. ADD_FSP_BINARIES only needs > to be selected if not using the 3rdparty/fsp repo (as it's selected by > default there). > > Ah! Ok, I see that now. I'm stumbling-around, trying to understand config > options. It's overwhelming at first. And it requires learning to "trust > the defaults". > you're not trusting the defaults, you're trusting my configs which are used to build working firmware. The defaults are not sane or there wouldn't be a dozen lines in the defconfigs and a handful more in my site-local/Kconfig > > Some config options for a board are "required - don't touch!", and others > really are "optional". I'm getting a sense of which is which, but there > doesn't seem to really be a "config overview" or centralized guidance. And > it's probably different for every different cpu architecture. > indeed, knowing what can/should be changed in many cases requires being a firmware developer with reasonable familiarity with coreboot, the platform, and the board in question > > >> … Hmm - so, if the blob files referenced in site-local/Kconfig are not > extracted from the stock ChromeOS firmware images for GLK boards, and they > are not built from source by coreboot, then where are they from? > > > they're extracted from another coreboot device which uses newer FSP > blobs than the Google ones. Which is why I use the newer headers. > > Aha! Thanks for that. > > Comparing the latest "bluebird" update, > bios-casta.ro-11297-222-0.rw-11297-411-0.bin, from > chromeos_15604.57.0_octopus_recovery_stable-channel_mp-v32.bin, and your > newer FSP blobs, I see: > > $ strings 2023Dec01/fsps.bin |grep octopus|head -n1 > > /build/octopus/tmp/portage/sys-boot/intel-glkfsp-0.0.1-r9/work/intel-glkfsp-0.0.1/Build/GeminilakeFspPkg/RELEASE_COREBOOT/IA32/GeminilakeFspPkg/FspHeader/FspHeader/OUTPUT/./FspHeader.dll > > $ strings 3rdparty/blobs/mainboard/google/octopus/casta/fsps.bin | grep > octopus | head -n1 > > /build/octopus/tmp/portage/sys-boot/intel-glkfsp-0.0.1-r8/work/intel-glkfsp-0.0.1/Build/GeminilakeFspPkg/RELEASE_COREBOOT/IA32/GeminilakeFspPkg/FspHeader/FspHeader/OUTPUT/./FspHeader.dll > > The most recent bios has that "-r9", versus the "-r8". I expect that that > refers to an even newer "release 9" versus a "release 8". And, this "-r9" > should also work with the setting: > CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/ > 2.2.3.1" > NO! those strings are simply build paths, they have no correlation to the version of headers which need to be used with a given binary/binaries. Google binaries use Google's headers. Intel's binaries use Intel's headers. Also, the binaries in my repo would not have anything resembling that build path as it's specific to a Google ChromeOS build system, and my binaries are not from a ChromeOS device. TBF, this is unnecessarily confusing because Intel chose to not publicly release FSP headers/binaries for Geminilake (or Jasperlake). Everything is set correctly in my repo so that a user who clones my repo/submodules and uses my build script will end up with a functional firmware image for a given board. > Is that correct? > > >

1 0

2023-12-13 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 14 Dec '23

14 Dec '23

# 2023-12-13 - coreboot Leadership Meeting Minutes ## Attendees Martin R, Werner Zeh, Christian Walter, Matt DeVillier, Felix Singer, Felix Held, Jay Talbott, Marshall Dawson, Simon Glass, David Hendricks, Maximilian Brune, Jeremy Compostella, Jonathan Hall, Karthik R, Nico H, Mina A, Lean Sheng Tan. ## Open Action Items * 2023-12-13 * Patrick? FelixS?: Look at improving the responsiveness of gerrit. * Swapping issues? * Jenkins taking resources * 504 error code - 500 error code * Same patch pushed twice, same change-ID two different gerrit ids. * Patches showing up as open even after they’re merged * Move coreboot resources off of stefan’s server? * 2023-11-29 * [Open] FelixS: Draft a proof-of-concept proposal to switch to meson. * 2023-11-15 * [Done] Martin: Publish coreboot FAQ https://review.coreboot.org/c/coreboot/+/79441 * 2023-11-01 * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * No progress yet * 2023-10-18 * [Started](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/th… XKVCP3YIFJEE/) MattD and WernerZ: Work on compiling a list of website requirements from the mailing list. * No feedback yet - Matt will continue to gather feedback. * Probably have all of the community input - Need to capture the requirements as a starting point. * Move to next year. * [On hold] [pending requirements] MartinR & FelixS: Build a POC front page. * [Open] Arthur: Ask Philip about how to use company logos. * 2023-10-4 * [Started](https://docs.google.com/document/d/1Z8igNdgBG5_Qlr4kKRtlbpKaZo9RUg… Martin: Write a tutorial for gerrit - Feel free to help. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. * Not started * 2023-09-20 * [Started](https://review.coreboot.org/c/coreboot/+/78832) Martin: Work on [clang-format config update](https://review.coreboot.org/c/coreboot/+/78832). * We can use the clang format version from the coreboot toolchain! * Some issues with clang format - martin will present. * See [CB:78833](https://review.coreboot.org/c/coreboot/+/78833) for what the current format’s changes will look like. * [David] #defines for bits in headers lose their indenting. Maybe we should have clang-format ignore headers for now. Smaller issues can be handled on a "use your best “judgement" basis. * [Done] Martin to add [bitfield](https://review.coreboot.org/c/coreboot/+/78833/4/src/drivers/inte… example to 78833 * Let’s look at running this just for .c files to start with. ## Minutes ### [Martin] Covered open action items ### [Martin] Present Projects & RFCs list ### [Sheng] Decision for Bootflow on Arm64 Server * As mentioned in previous leadership meeting and a special meeting on 05 Dec 2023, the leadership team will make decision on going forward with the proposal here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BRW3… WM/ * We’re proposing that there are two additional boot flows added to Arm’s document. https://docs.google.com/document/d/1z3fLdUmbOBKvHJfub8ki9YWjuqpK_1PY0H4BWwm… ### Decision * We’re agreeing to change the coreboot codebase to support the modified bootflow, based on the understanding that the standard coreboot arm bootflow will also be included. If that isn’t accepted, we’ll need to revisit this. If Arm agrees to include both boot flows in their document, we will get the patches merged, but we’d like an agreement from them before that’s done. * Nico: The secure monitor is still an issue. That’s not open source. * [Martin] But the secure boot monitor is not part of coreboot or even called by coreboot in the new boot flow. Let’s have a discussion about it, but there are other topics we want to cover in this meeting. ### [Martin/MaxB] Look at improving the readability of our build system * See https://review.coreboot.org/c/coreboot/+/79230 - this combines a number of changes into a single patch just to see what things would look like. * Please take a look and voice opinions. * Some problems: * Makefiles at the directory tips frequently have `ifeq` blocks surrounding the entire contents. https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/src/… * We probably shouldn’t indent the entire file. * To indent ifeq/ifneq/endif statements inside a target, we need to use spaces instead of tabs. This leads to an ugly mix of spaces and tabs, which can be confusing, and will break the build if it’s done incorrectly. ### [Martin] Cancel the December 27th meeting? * Cancel this! ### [PatrickG, Martin] How to present design proposals? * There’s some tension in the project between “folks write a whole new thingamabob and submit it whole to the project, then get indignant when the project doesn’t adopt it wholesale. To avoid that from happening, we discourage working like that” and “you want to do something? Build a prototype” * Should we document what we think is a good way to approach such situations? * With the example of “make a coreboot build system based on meson”, Patrick mused: “While we discourage folks from dumping a full solution on us, having a partial solution (and that should be more than a userland tool, because those are easy in meson) to offer a glimpse in how it should look is worthwhile. The problems arise when there's so much work sunk into it that rejecting it means rejecting a developer's work of months, which is why that's not a good approach to "dump code on us". * There aren't any hard & fast rules, but - "I got qemu to compile (typically the easiest target) and this is how it looks" seems like a good step in between. - If it takes months to get to that stage, it's probably not worth it, because whatever has been built in that time is as complex as what we have. - "I got qemu to compile, but don't mind the mess in most of the tree. I have a plan how it should look (see src/cpu which is more like it) but I wanted to prove the concept first" already offers something that can be discussed properly without costing too much effort. * Stefan offered that code can be published on Gerrit even when it’s not ready yet (and/or just a prototype). Gerrit does have a “Work In Progress” flag for CLs, after all, so there’s not necessarily a need to set up a branch for such work. * Flow: * Propose the idea to the mailing list * Present a draft * Do a small implementation (Qemu or similar) * Present an RFC * Review on mailing list & in leadership meeting. * ??? * Profit??? * Felixs: Start a forum? Replace the mailing list with a forum? * Felixh: We already have the bugtracker - it uses a different login than gerrit, so it’s already problematic to use. Let’s not create another. * Nico: The mailing list is the most accessible method. Everyone can participate well. * Felixs: Just looking at how other open source projects done today open projects on gitlab or github, and people discuss things there. People today are used to that. People don’t like writing emails. Modern solutions look nicer and are more accessible. * SJG: Mailing list is searchable and everything can be seen later. Other things are more of a walled garden. Replacing the mailing list would be a bad decision. * Nico: Forums are accessible only to people able to use a web browser. * This can at least be an example process, if not the only process. ### [Martin] review of “Setup Option Table” (placeholder name for what was CFR) * We’re more aligned with a build-time approach, with customization of the data structures in mainboard code. If this customization becomes commonplace, we can move functions into lib/sot or something. * Kconfig-based / data-serialization-language (like yaml, ~~cbor or protobuf~~)? * [Setup Option Table requirements](https://docs.google.com/document/d/1WAc6k8k4hUhcUJl-hl9jUfEWh… for *any* solution * Kconfig [Setup Option Tables](https://docs.google.com/document/d/1TWbxKRhsTpid7xyK-yMdsxhfZxZtTTN… h.astha87lu249) * Kconfig [Setup Option Table DSL](https://docs.google.com/document/d/18uApZbuvou9unlL8SdTZ4dTblHD2OGs_Sg… ### [Simon]: Serial RFC * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 Now updated to allow use of a CBFS file. * Does the -2 indicate that this is being killed? * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. * I’ve already stated numerous times that I don’t think that an option method based solely on including the configuration directly into bootblock is the right way to go about things. If we do pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, which will be far more useful in the long-run, in my opinion. # Next meeting * January 10, 2024. * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [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 * https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

Re: coreboot Meetings Announcement And Agenda Call
by Julius Werner 11 Dec '23

11 Dec '23

[edit: that was meant to go to the list, too] On Mon, Dec 11, 2023 at 3:12 PM Julius Werner <jwerner(a)chromium.org> wrote: >> >> ### [Simon]: Serial RFC >> * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 >> * Does the -2 indicate that this is being killed? >> * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without >> agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. >> * I’ve already stated numerous times that I don’t think that an option method based solely on >> including the configuration directly into bootblock is the right way to go about things. If we do >> pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, >> which will be far more useful in the long-run, in my opinion. > > > Unfortunately I'll be on a plane this Wednesday and won't be able to join this discussion. Would you mind if we move this to next meeting?

2 2

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 11 Dec '23

11 Dec '23

Dear community, Kindly note that the upcoming coreboot leadership meeting is scheduled for Wednesday, December 13, 2023.[1] You are welcome to add things you wish to see addressed during the meeting to the current agenda items. [2] ## Current Agenda Items ### [Martin] Cover open action items ### [Martin/MaxB] Look at improving the readability of our build system * See https://review.coreboot.org/c/coreboot/+/79230 - this combines a number of changes into a single patch just to see what things would look like. ### [Martin] Cancel the December 27th meeting? ### [PatrickG, Martin] How to present design proposals? * There’s some tension in the project between “folks write a whole new thingamabob and submit it whole to the project, then get indignant when the project doesn’t adopt it wholesale. To avoid that from happening, we discourage working like that” and “you want to do something? Build a prototype” * Should we document what we think is a good way to approach such situations? * with the example of “make a coreboot build system based on meson”, Patrick mused: “While we discourage folks from dumping a full solution on us, having a partial solution (and that should be more than a userland tool, because those are easy in meson) to offer a glimpse in how it should look is worthwhile. The problems arise when there's so much work sunk into it that rejecting it means rejecting a developer's work of months, which is why that's not a good approach to "dump code on us". * There aren't any hard & fast rules, but - "I got qemu to compile (typically the easiest target) and this is how it looks" seems like a good step in between. - If it takes months to get to that stage, it's probably not worth it, because whatever has been built in that time is as complex as what we have. - "I got qemu to compile, but don't mind the mess in most of the tree. I have a plan how it should look (see src/cpu which is more like it) but I wanted to prove the concept first" already offers something that can be discussed properly without costing too much effort. * Stefan offered that code can be published on Gerrit even when it’s not ready yet (and/or just a prototype). Gerrit does have a “Work In Progress” flag for CLs, after all, so there’s not necessarily a need to set up a branch for such work. ### [Martin] Localization of non-console strings for coreboot * With the addition of an early display, we’re looking at printing text to the screen directly from coreboot. Localization is being added for this, but the current patch uses the localization code from vboot. This isn’t a security related feature so shouldn’t depend on the rest of VBOOT being enabled. https://review.coreboot.org/c/coreboot/+/79054 * We also just had an RFC about storing setup engine strings. It seems like we’d want to make sure that whatever plan we have in place also supports localization for those strings as well. * How do we want to handle localization in coreboot? It seems like we’re going to be adding more strings that will be presented to the user. ### [Martin] review of “Setup Option Table” (placeholder name for what was CFR) * We’re more aligned with a build-time approach, with customization of the data structures in mainboard code. If this customization becomes commonplace, we can move functions into lib/sot or something. * Kconfig-based / data-serialization-language (like yaml, cbor or protobuf)? * [Setup Option Table requirements](https://docs.google.com/document/d/1WAc6k8k4hUhcUJl-hl9jUfEWh… * [Setup Option Tables](https://docs.google.com/document/d/1TWbxKRhsTpid7xyK-yMdsxhfZxZtTTN… h.astha87lu249) * [Setup Option Table DSL](https://docs.google.com/document/d/18uApZbuvou9unlL8SdTZ4dTblHD2OGs_Sg… ### [Martin/others] Look at writing a doc stating what coreboot is * It’s been argued that this shouldn’t be called a “spec”, but Daniel Maslowski pointed out that coreboot is being defined by others as something that we aren’t, because we don’t have a good definition of what we are. Whatever we want to call it, it seems like a good plan to have *something* discussing what coreboot is. ### [Simon]: Serial RFC * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 * Does the -2 indicate that this is being killed? * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. * I’ve already stated numerous times that I don’t think that an option method based solely on including the configuration directly into bootblock is the right way to go about things. If we do pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, which will be far more useful in the long-run, in my opinion. [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

geminilake fsp on Google Chromebook?
by James Feeney 10 Dec '23

10 Dec '23

Comparing the git trees for the current stock coreboot and for your MrChromebox-4.21, I'm wondering about the .config differences generated by nconfig at CONFIG_FSP_HEADER_PATH=. ./src/soc/intel/apollolake/Kconfig has: config FSP_HEADER_PATH default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0" if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1" if SOC_INTEL_GEMINILAKE default "3rdparty/fsp/ApolloLakeFspBinPkg/Include/" But, "make nconfig" in the MrChromebox tree, nonetheless, produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1"' in the .config, somehow, despite the above, while the stock coreboot "make nconfig" instead produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0"', as might be expected. Can someone explain why there is the "if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE" consraint for the fsp? Is fsp 2.2.3.1 actually still the correct configuration when using the fsp.bin files extracted from the stock Google ChromeOS? Thanks James

3 4

Need help with porting coreboot.
by bud 08 Dec '23

08 Dec '23

Hello, I would like some help with porting coreboot using autoport. I do not understand most of the instructions given in the documentation, for example: "Grab coreboot tree" Which coreboot tree? This one?: git clone ssh://review.coreboot.org:29418/coreboot or this one?: git clone https://review.coreboot.org/coreboot.git Apart from this, I have many other issues with understanding the documentation I would really appreciate it if you could provide step by step instructions with the commands to execute, without any vague instructions from the documentation. Thank you, bud (NOTE: I apologize if my tone of writing sounded rude.)

2 1

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 08 Dec '23

08 Dec '23

Dear community, We are happy to announce that the upcoming coreboot leadership meeting is scheduled for Wednesday, December 13, 2023. [1] Please take a moment to update the current agenda items with matters you wish to see addressed during the meeting. [2] [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

How to add additional LPC decode ranges to Baytrail.
by Jose Trujillo 08 Dec '23

08 Dec '23

Hello Dear Community: I am trying to enable UART port addresses 3e8 and 2e8 to one of my 2 superios I have attached to the same LPC port. I need 4 UART ports. Both superio chips work if I set 3f8 and 2f8 but one at the time (i need to disable the other SIO). Today I was looking at baytrail code but I got lost; I did not even find how the code add 3f8/2f8 in order to do the same to 3e8/2e8. i found the function "lpc_open_pmio_window()" but this didn't build for me on Baytrail. Do somebody know to to add LPC decode ranges for 3e8 and 2e8 on Baytrail? Please let me know. Jose Trujillo.

1 0

[coreboot - Bug #519] (New) make gconfig - could not find glade file
by James Feeney 07 Dec '23

07 Dec '23

Issue #519 has been reported by James Feeney. ---------------------------------------- Bug #519: make gconfig - could not find glade file https://ticket.coreboot.org/issues/519 * Author: James Feeney * Status: New * Priority: Normal * Target version: none * Start date: 2023-12-07 * Affected versions: 4.21 ---------------------------------------- $ git rev-parse HEAD 62c25351c101a3d5c7104aa6fc34e71990478dde Arch Linux make 4.4.1-2 $ make gconfig ... (gconf:825619): libglade-WARNING **: 09:26:11.670: could not find glade file '/sdb/coreboot.main/build/util/kconfig/gconf.glade' ** (gconf:825619): ERROR **: 09:26:11.673: GUI loading failed ! make: *** [build/util/kconfig/Makefile.real:47: gconfig] Trace/breakpoint trap (core dumped) $ find -name gconf.glade ./util/kconfig/gconf.glade $ ll /sdb/coreboot.main/build/util/kconfig/gconf.glade /bin/ls: cannot access '/sdb/coreboot.main/build/util/kconfig/gconf.glade': No such file or directory -- 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

1 1

[coreboot - Bug #518] (New) make xconfig - g++: fatal error: no input files
by James Feeney 07 Dec '23

07 Dec '23

Issue #518 has been reported by James Feeney. ---------------------------------------- Bug #518: make xconfig - g++: fatal error: no input files https://ticket.coreboot.org/issues/518 * Author: James Feeney * Status: New * Priority: Normal * Category: build system * Target version: none * Start date: 2023-12-07 * Affected versions: 4.21 ---------------------------------------- $ git rev-parse HEAD 62c25351c101a3d5c7104aa6fc34e71990478dde Arch Linux make 4.4.1-2 $ make -d xconfig ... Found '/sdb/coreboot.main/util/kconfig/qconf.cc'. ... No implicit rule found for '/sdb/coreboot.main/util/kconfig/qconf.cc'. ... Finished prerequisites of target file 'build/util/kconfig/qconf.o'. Must remake target 'build/util/kconfig/qconf.o'. /sdb/coreboot.main/util/kconfig/Makefile.inc:63: update target 'build/util/kconfig/qconf.o' due to: target does not exist ... g++: fatal error: no input files compilation terminated. ... -- 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

1 0

Baytrail issue to communicate with superios.
by Jose Trujillo 06 Dec '23

06 Dec '23

Hello All: I hope you are doing great. The system: Baytrail E3845, 4GB DDR3, fintek (f81803a) @0x4e and Winbond (w83627dhg) @0x2e, etc... I just built coreboot (master) the last few days, everything works wonderfully except 2 things: - Libgfxinit probably because this board is using the AUX channel instead DDI to communicate with the monitors; seems to me libgfxinit cannot find monitors thru DP ports but I could be wrong because neither VGA gets initialized; and eventually Linux always initialize the video correctly. - SuperIOs not working; "cat /proc/interrupts" shows not activity from any serial port to any processor, but, I set accordingly (konfig, devicetree and superio.asl) I will check on Monday if the route definitions of "irqroute.h" are ok. Using "superiotool" to scan for SIO devices finds Winbond W83627DHG and dumped all its registries but doesn't show Fintek f81803 because of lack of support, so, data exchange between the processor and the SIO chips via LPC port seems to be fine, maybe just need to fix the interrupt issues. Any help will be highly appreciated, Thank you, JT

2 7

Announcement: flashrom-stable continues as flashprog
by Nico Huber 06 Dec '23

06 Dec '23

Hi everybody! as you may know already, flashrom-stable was removed from review.coreboot.org a while ago. flashrom-stable was a short- lived semi-fork, based on flashrom v1.2 [1]. The effort to keep developing a stable flash programming tool for everyone, however, shall continue. I have hence renamed flashrom-stable to *flashprog*. Now it's definitely a fork. The main reason for the fork is that I saw the flashrom master (now main) branch to become unmaintainable. Probably because we merged too much code together, without actually managing to work together on a product. Beside names, I tried to keep everything as usual. There's a wiki (slowly filled with contents from the old one) https://flashprog.org/ an IRC channel #flashprog on libera.chat and a mailing list, of course flashprog(a)flashprog.org managed at https://mail.sourcearcade.org/postorius/lists/flashprog.flashprog.org/ Review continues on a Gerrit instance, albeit on https://review.sourcearcade.org/ And you can clone the repository from a GitHub mirror https://github.com/SourceArcade/flashprog.git Now that all this is done, I hope to return to work on the source code again. There are still many patches open that were pending for flashrom-stable. And it looks like the next release candidate is only one commit away :) So stay tuned! Nico [1] https://mail.coreboot.org/hyperkitty/list/flashrom-stable@flashrom.org/thre…

1 0

Bootflow on ARM64 Server Discussion
by mina＠coreboot.org 05 Dec '23

05 Dec '23

Thank you to all who were able to join the discussion pertaining to Bootflow on ARM64 server. Please access the overview of the meeting using the link below: https://docs.google.com/document/d/1z3fLdUmbOBKvHJfub8ki9YWjuqpK_1PY0H4BWwm… .

1 0

Linux boot delayed by value of generic.reset_off_delay_ms (touchscreen reset)?
by Paul Menzel 05 Dec '23

05 Dec '23

Dear coreboot folks, On the Dell Latitude 5430 Chromebook (google/brya/var/crota) there is a delay of 160 ms during startup in the Linux kernel [1]: [ 0.000000] microcode: microcode updated early to revision 0x430, date = 2023-06-07 [ 0.000000] Linux version 5.15.124-20281-g306376f9e9db (chrome-bot@chromeos-release-builder-us-central1-c-x32-9-oel9) (Chromium OS 17.0_pre496208_p20230501-r16 clang version 17.0.0 (/mnt/host/source/src/third_party/llvm-project 98f5a340975bc00197c57e39eb4ca26e2da0e8a2), LLD 17.0.0) #1 SMP PREEMPT Mon Oct 2 18:31:36 PDT 2023 […] [ 0.150271] ACPI: PM: Power Resource [PR00] [ 0.313289] ACPI: PM: Power Resource [PR01] A @google.com person commented, that this *could* be caused by the reset delay of the ELAN touchscreen. From `src/third_party/coreboot/src/mainboard/google/brya/variants/crota/overridetree.cb`: device ref i2c3 on chip drivers/i2c/hid register "generic.hid" = ""ELAN900C"" register "generic.desc" = ""ELAN Touchscreen"" register "generic.irq" = "ACPI_IRQ_LEVEL_LOW(GPP_C7_IRQ)" register "generic.detect" = "1" register "generic.reset_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C1)" register "generic.reset_delay_ms" = "150" register "generic.reset_off_delay_ms" = "1" register "generic.enable_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPP_C0)" register "generic.enable_delay_ms" = "6" register "generic.stop_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C6)" register "generic.stop_off_delay_ms" = "1" register "generic.has_power_resource" = "1" register "hid_desc_reg_offset" = "0x01" device i2c 0x16 on end end end As I have been bitten the last time, I tried to flash a Dell Chromebook, I am weary to test, so I am asking here. > The delay is unavoidable, although I suppose there's room for > improvement on making ACPI power sequencing parallelizable or > otherwise deferring it until the device is actually getting probed > (preferably using asynchronous probe, since this is a slow device -- > ChromeOS tends to configure touchscreen drivers for async probe > already, or else loaded as modules). > > Perhaps you can take this problem upstream if you'd like to work on > something, but from a ChromeOS perspective this is either Intended > Behavior or a Feature Request. I don't think we're interested in > tracking this as a Feature Request here. During startup this reset delay should not hold up the boot, should it? Could the firmware reset the touchscreen, and somehow message the OS, that it’s not needed anymore? Kind regards, Paul [1]: https://issuetracker.google.com/issues/303565666 PS: I was unable to change the issue title to correct PR01 to PR00.

2 1

48 hours before DUG #4 & vPub 0x9 opensource online party!
by Mike Banon 05 Dec '23

05 Dec '23

Dear friends, I invite you to a joint DUG #4 & vPub 0x9 event that starts this Thursday at 5 PM UTC - in exactly 48 hours since this e-mail. Would you like to learn & discuss about: * coreboot-based Dasharo firmware distribution and its unique features? * cool hardware devices supporting the opensource firmwares, like NovaCustom new laptop? * opensource firmware world and its current events in general, i.e. AMD OpenSIL news? Then this upcoming event - is an excellent opportunity for you to have a great time in a friendly company of firmware enthusiasts. The 1st part of our event - DUG #4 - is dedicated to Dasharo distribution of coreboot opensource firmware with advanced features like GUI & FLASHBIOS and the ecosystem around it. DUG will take place between 5-7 PM UTC - and then around 7 PM UTC will switch to vPub opensource online party! The past joint events have been highly successful and I'm sure you will find this one interesting as well ;-) Both sound/video and text chats will be available for your convenience More details and Join links are available here - [*] https://vpub.dasharo.com/e/11/dasharo-user-group-4 P.S. to avoid missing out future events, join our Matrix or tiny-volume event notification newsletter: [*] https://matrix.to/#/#dasharo-osf-vpub:matrix.org [*] https://newsletter.3mdeb.com/subscription/0_K65I7ro (just ~4 e-mails per year) -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

[coreboot - Bug #516] (New) brya/var/crota: `ACPI BIOS Error (bug): Failure creating named object [\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327)`
by Paul Menzel 04 Dec '23

04 Dec '23

Issue #516 has been reported by Paul Menzel. ---------------------------------------- Bug #516: brya/var/crota: `ACPI BIOS Error (bug): Failure creating named object [\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327)` https://ticket.coreboot.org/issues/516 * Author: Paul Menzel * Status: New * Priority: Normal * Target version: none * Start date: 2023-12-02 ---------------------------------------- On the Dell Latitude 5430 Chromebook (brya/var/crota) with ChromeOS, Linux 5.15.133 reports an ACPI error: [ 0.000000] Linux version 5.15.133-20573-g839a3133d611 (chrome-bot@chromeos-release-builder-us-central1-a-x32-6-ibti) (Chromium OS 17.0_pre498229-r6 clang version 17.0.0 (/mnt/host/source/src/third_party/llvm-project 14f0776550b5a49e1c42f49a00213f7f3fa047bf), LLD 17.0.0) #1 SMP PREEMPT Sun Nov 26 18:55:03 PST 2023 2023-12-01T11:43:58.591525Z INFO kernel: [ 0.000000] Command line: cros_secure console= loglevel=7 init=/sbin/init cros_secure drm.trace=0x106 root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 6348800 verity payload=PARTUUID=12e8cf21-bcc0-49b5-85bb-56fb8102f7d4/PARTNROFF=1 hashtree=PARTUUID=12e8cf21-bcc0-49b5-85bb-56fb8102f7d4/PARTNROFF=1 hashstart=6348800 alg=sha256 root_hexdigest=4ad313ce4c441485f2be87533efe22a0d8b61bffb78260d17ccd2672e7edb538 salt=8051d68355ccfca99de821939b957ff34d38b866a2951a595e4c0613a1c51f97" noinitrd vt.global_cursor_default=0 kern_guid=12e8cf21-bcc0-49b5-85bb-56fb8102f7d4 add_efi_memmap noresume i915.modeset=1 ramoops.ecc=1 tpm_tis.force=0 intel_pmc_core.warn_on_s0ix_failures=1 i915.enable_guc=3 i915.enable_dc=4 xdomain=0 swiotlb=65536 intel_iommu=on i915.enable_psr=1 […] [ 0.000000] DMI: Google Crota/Crota, BIOS Google_Crota.14505.456.0 04/21/2023 […] [ 0.146114] ACPI BIOS Error (bug): Failure creating named object [\_SB.MPTS], AE_ALREADY_EXISTS (20210730/dswload2-327) [ 0.146117] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20210730/psobject-220) […] -- 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

Bootflow on ARM64 Server Discussion
by mina＠coreboot.org 04 Dec '23

04 Dec '23

Dear community, You are invited to the upcoming meeting on Tuesday, December 5, 2023, from 7:00 PM to 8:00 PM GMT, to continue the discussion of issues pertaining to the ARM64 server.[1] Here are links to some relevant documents to be considered: * ARM Server Base Boot Security Requirements PDF Download * ARM Base Boot Requirements * Background doc on ARM servers using ACPI & SMBIOS [1]meet.google.com/sxc-vcax-xwg

1 0

[coreboot - Bug #517] (New) lenovo x230 boot stuck with connected external monitor
by Vasily Evseenko 04 Dec '23

04 Dec '23

Issue #517 has been reported by Vasily Evseenko. ---------------------------------------- Bug #517: lenovo x230 boot stuck with connected external monitor https://ticket.coreboot.org/issues/517 * Author: Vasily Evseenko * Status: New * Priority: High * Target version: none * Start date: 2023-12-04 * Affected versions: 4.21 * Affected hardware: Lenovo x230 * Affected OS: any ---------------------------------------- Coreboot releases 4.21 and 4.22.01 have a bug. If lenovo x230 laptop has connected external monitor then boot stuck on Seabios greeting. Boot without external monitor always succeeded. Last release without bug is 4.20.1 Coreboot config attached. ---Files-------------------------------- .config (19.4 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

2 4

[RFH] board-status: Please upload your logs
by Paul Menzel 03 Dec '23

03 Dec '23

Dear coreboot folks, especially users, Uploads to the board status repository [1] have ceased quite a bit this year. As most community members only have access to a few devices, these logs are tremendously useful to support users, and to analyze bugs and regressions. So, just a quick shout-out to you all to quickly take the time to upload the log files [2]. Kind regards, Paul [1]: https://review.coreboot.org/plugins/gitiles/board-status/ [2]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/ut…

1 0

Build server maintenance on Saturday, Dec 2
by Felix Singer 02 Dec '23

02 Dec '23

I will do a maintenance on some build servers this Saturday, Dec 2. You might experience long waiting times for builds. The maintenance is scheduled for 12pm UTC+1 and it's expected to be finished at 4pm UTC+1. Felix

1 3

2023-11-29 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 30 Nov '23

30 Nov '23

# 2023-11-29 - coreboot Leadership Meeting Minutes ## Attendees: Christian Walter, Daniel Maslowski, David Hendricks, Felix Held, Felix Singer, Jay Talbott, Jeremy Compostella, Jonathan Hall, Julius Werner, Lean Sheng Tan, Marshall Dawson, Martin Roth, Matt DeVillier, Matt Papageorge, Maximilian Brune, Nico, Patrick Georgi, Simon Glass, Tim Crawford, Werner Zeh, Mina Asante. ### Open Action Items * 2023-11-29 * [Open]FelixS: Draft a proof-of-concept proposal to switch to meson. * 2023-11-15 * [Started] Martin: Publish coreboot FAQ * 2023-11-01 * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. - Additionally look at whether the .branch option helps. * 2023-10-18 * [Started] MattD and WernerZ: Work on compiling a list of website requirements from the mailing list. * No feedback yet - Matt will continue to gather feedback. * Probably have all of the community input - Need to capture the requirements as a starting point. * Move to next year. * [On hold pending requirements] MartinR & FelixS: Build a POC front page. * [Open] Arthur: Ask Philip about how to use company logos. * 2023-10-4 * [Started] Martin: Write a tutorial for gerrit - Feel free to help. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. * 2023-09-20 * [Started] Martin: Work on clang-format config update. * We can use the clang format version from the coreboot toolchain! * Some issues with clang format - martin will present. * See CB:78833 for what the current format’s changes will look like. * [David] #defines for bits in headers lose their indenting. Maybe we should have clang-format ignore headers for now. Smaller issues can be handled on a "use your best “judgement" basis. * [Done] Martin to add bitfield example to 78833 * Let’s look at running this just for .c files to start with. ## Minutes ### [Martin] Cover open action items - Clang format - Can we merge the format update at https://review.coreboot.org/c/coreboot/+/78832, then start converting .c files? - Header files can be put off until later. -Requested that patches be reviewed & merged. - Website requirement status? - Delay until next year. ### [Arthur] A new bootflow on ARM64 server using more of TF-A - Motivation: More ARM-Server support in coreboot - ARM wants to put coreboot in the ARM Base Boot Requirements: https://developer.arm.com/documentation/den0044/latest - Vendors are more inclined to consider coreboot if it is in a spec written and supported by ARM - It is currently planned to put the TFA on ARM -> coreboot -> Linuxboot bootflow in there as an alternative to the EDK2 variants. TFA can be open source as well as closed source so it is not entirely the same as letting FSP start at Reset - The Idea is that coreboot is considered by big Vendors when they formulate their specs (so that coreboot doesn’t have to hack around to make stuff work for it) - Reuse working solutions (TF-A) can be a good idea: easier porting. - The scope of the coreboot side of things is small and very reusable: generating SMBIOS and ACPI is quite portable between platforms. - patches necessary to accomplish this mainly are the following: - https://review.coreboot.org/c/coreboot/+/74798/9 - https://review.coreboot.org/c/coreboot/+/78284/8 - patch missing that grabs FDT in bootblock (like done in RISC-V bootblock) - Using only ramstage can be minimally invasive. A similar thing was done to optionally build romstage sources inside the bootblock: https://review.coreboot.org/c/coreboot/+/55068 - coreboot's security model often relies on it being the first code that executes. This might need some changes. - Handoff data from TF-A is often in FDT format for which ramstage has support. - TF-A is BSD3 licensed. You may not always have access to the source code for your platform. * Currently use bootblock & romstage, but they basically do nothing more than setting up cbmem. Only generating SMBIOS & ACPI tables. - This really depends on the platform though. Other platforms than the initial vendor would be able to implement more setup in coreboot if desired. * Another concern is that this could set a precedent for other platforms taking over the reset vector and wrapping coreboot. - We definitely don’t want to do this on X86 - ARM is different? - Intel wanted to do this before - https://universalscalablefirmware.github.io/documentation/1_terminology.htm…. - Can we accept this case and consider accepting other use cases when they come up? All we can really do is prevent the name ‘coreboot’ being used - anyone can take and use the code as long as they follow licensing restrictions. * This is just a discussion about doing the minimum needed to support inclusion into ARM’s Base Boot Requirements. We’d still be able to refuse any particular additions to the codebase (though vendors can fork this). * [Felix H.] If we put the TF-A bootflow with coreboot code into the spec, we should also put in a coreboot-native bootflow next to it into the same spec. * [simon] The way that TFA operates is unfortunate - arm wants to produce blobs out of TFA instead of supporting other open source projects. Beware. * [Martin] Is there a deadline? Spec review is in January. - Maybe the ease of use and quality of coreboot convinces a more full adoption on server (use only BL31 like other platforms)? Maybe I'm naive on this? * [Martin] 1) This is taking a piece of coreboot and using it in a different way than normal. I recommended on the mailing list that we call this flow something other than just "coreboot' so as not to confuse things or dilute the meaning of what coreboot is. Maybe "ATF with coreboot technology" or something. 2) This allows us to expose coreboot to people who would otherwise be using a completely different solution. That's a *really* good thing in my opinion. 3) We should try to be a good player in the open source firmware space and work with other projects to create solutions. If this means using pieces of coreboot, I'm all for it, similar to wanting to be able to take pieces of other projects and use them to extend coreboot's functionality. Sure, we could block it here and force it to be forked, but that doesn't really help anyone. 4) Maybe to differentiate this, we can go further than just making it a Kconfig option and actually add a new makefile target. That would make it even more plain that this isn't the full coreboot build. - No decision was made at this meeting, but the leadership is leaning towards accepting the proposal. **Leadership viewpoint: * [David] Maybe the situation here is not as good as we’d hoped. We’d like to have coreboot allowed for inclusion than have ARM push everything to coreboot. * [Matt] - Agree with David, but it’s better to allow coreboot to be used. Hope is that by providing an alternative to EDK2, we’ll help push open source firmware. * [Werner] - See both ways. This discussion is about the spec - Document the bootflow for the spec and the regular bootflow, and this would probably be enough for now. ### [Martin/MaxB] Look at improving the readability of our build system * Our current build system uses make, but stretches it way beyond most makefile-based build systems. This was done to add abstractions which, for example, make it much easier to add files to the various stages. Because of this complexity at the heart of the build, it can be very difficult to understand what’s going on in any given section. One way that is being looked at to improve this is indentation of the if clauses, but this is problematic without rewriting some sections. See CB:79230 PatrickG encourages folks to consider Burning the Diskpack because he feels that people are too reverent about old work. The build system is 14 years old (and replaced a build system that was 10 years old at the time): if there’s an opportunity to achieve a significant improvement in that area by replacing what we have with something else, go for it! (That doesn’t mean that it must be done. But consider it besides the various fixes that could be applied) * [Martin] I agree with Patrick, but have some qualifications i. We’re replacing an existing system that works. Is this the best place to spend our resources? ii. Because it would be replacing a working system, there should be relatively substantial benefits to be gained by updating before it’s considered. iii. While Patrick doesn’t want to discourage change just because the build process is old, we also shouldn’t look to throw it away just because it’s old. - (Patrick agrees with all of that) * There was a proposal to switch to meson. FelixS will do a proof of concept. * Switch to .mak or .mk - not .am or .in (used by autoconf/automake) ### [FelixH] Announcements for non-regular meetings * A non-regular coreboot meeting should be announced at least on the previous work day before the time the meeting starts, so that everyone has a chance for preparing for the meeting. [Martin] And - check your damned links. ## Closed action items * [Done] Martin: Make announcement about changing release numbers in the release notes of the final 4.xx release. Following releases will use year.month.sub release format. 24.02 (24.02.00 implied) would go to 24.02.01 if a release update is needed. The next release, 3 months later, would be 24.05. * [Done] Martin: Create coreboot governance page * https://review.coreboot.org/c/homepage/+/79312 # Next meeting * December 13, 2023 * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [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 * https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

Monochrome coreboot logo as BMP?
by Simon Glass 29 Nov '23

29 Nov '23

Hi, I am looking for a 160x160 BMP coreboot logo to use when booting U-Boot on top of coreboot, so that it is obvious to people that coreboot is being used. Typically it is used with a blank background. I have looked at the available logo but it is quite large. I am looking for something small, perhaps <10KB, so it needs to be BMP compressed (U-Boot does not support PNG at present). I have spent a bit of time trying to do this with inkscape and 'convert' but I cannot get one with anti-aliased edges. Can anyone help, please? Thanks! Simon

3 6

commit 0eab62b makes menuconfig more strict regarding the old configs
by Mike Banon 29 Nov '23

29 Nov '23

In my case, a csb_patcher.sh script [1] - among other things - delivers the example config files for the opensource AGESA boards. Although these configs haven't been updated for a while (i.e. a last update of AMD Lenovo G505S config [2] is 1 year ago), I got away with this: they are still working, just get refreshed when a user does "menuconfig" & "make" and result in a working coreboot build. However, with a commit 0eab62b [3] they are rejected [see 4]. Of course I'm going to manually "refresh" the configs to temporarily fix this problem, but I see this could increase the maintenance burden and reduce the usefulness of coreboot config files shared online... Are there any advantages of KCONFIG_STRICT / KCONFIG_WERROR that outweigh these potential issues? [1] https://review.coreboot.org/c/coreboot/+/64873 [2] https://review.coreboot.org/c/coreboot/+/64829 [3] https://review.coreboot.org/c/coreboot/+/79259 [4] ./coreboot/$ make menuconfig src/soc/intel/meteorlake/Kconfig:457:warning: config symbol defined without type ./coreboot/.config:26:warning: unknown symbol: COMPRESS_RAMSTAGE ./coreboot/.config:230:warning: unknown symbol: ARCH_ALL_STAGES_X86 ./coreboot/.config:249:warning: unknown symbol: VBT_DATA_SIZE_KB ./coreboot/.config:256:warning: unknown symbol: UART_PCI_ADDR ./coreboot/.config:264:warning: unknown symbol: S3_DATA_POS ./coreboot/.config:265:warning: unknown symbol: S3_DATA_SIZE ./coreboot/.config:274:warning: unknown symbol: LOGICAL_CPUS ./coreboot/.config:459:warning: unknown symbol: INTEL_GMA_OPREGION_2_0 ./coreboot/.config:572:warning: unknown symbol: PAYLOAD_YABITS ./coreboot/.config:574:warning: unknown symbol: PAYLOAD_TIANOCORE ERROR: 10 warnings encountered, and warnings are errors. make: *** [build/util/kconfig/Makefile.real:47: menuconfig] Error 1 -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

5 7

coreboot's role in the boot process -- is it time for a coreboot spec?
by Nico Huber 29 Nov '23

29 Nov '23

Hi folks, something I've been thinking back and forth about since the hackathon a week ago: Should we give people who promote coreboot something to refer to, something that more clearly states, what coreboot is? I know, some of you who know me might feel the urge to check if it isn't April the 1st. Nico suggesting a spec? What's happening here? I've always neglected the idea. Probably because I was too focused on fellow developers. But coreboot is not only discussed by develo- pers anymore. And we all know too well, developers don't make all the decisions. I believe having a document that basically says "that's coreboot, that's what people ask for" might help in, well, higher-level discussions. So what do I suggest? To have some high-level description of what coreboot does, where it starts, where it ends. And also, to be com- prehensive, the things that are set in stone: cb-tables, SELF for the payload. It's in C header files. But I guess the information could be imported for the last chapters. Overall, the spec should not be long. I imagine something like 2~4 pages plus the cb-tables. About the high-level part: Generally, I don't want to rush this. But I'll draft some things below that I already have on my mind. My current thoughts are mostly motivated by the "new bootflow for ARM64" thread[1] and Martin's excellent idea to rather call that "with coreboot technology" than "coreboot". Many people seem to agree. I guess, because it's not what we usually do. But what do we usually do? Shouldn't we write that down? coreboot boot process --------------------- coreboot's bootstrapping usually happens in two phases: 1. When a DRAM controller is part of the platform, it will be configured by coreboot to allow access to the main memory. 2. When the main memory is available, the platform is further initialized into an abstract state that allows generic opera- ting systems to run. (some simple picture here; it's too late in the evening for ascii-art on my end) coreboot starts with the first instruction on the main application processor (AP), or earlier when another processor runs platform initialization code from writable memory before the AP starts. Exceptions are made, when * the first instructions run from a boot ROM, or * the first instructions are pre-defined by the silicon vendor and the hardware doesn't allow execution of other code, i.e. due to cryptographic signature checks. In this case, coreboot starts with the first instruction from writable memory that can be controlled by the platform owner. Future hardware iterations should strive to allow coreboot to run earlier. After the hardware initialization, coreboot will write tables (cbtables, ACPI, SMBIOS and alike) with chip- and board-specific information. With this information, a generic operating system should be able to run without any further, board-specific know- ledge. Finally, coreboot loads and executes an embedded payload program from the same memory that holds coreboot. If possible, coreboot will cease all other execution at this point. It is the payload program's responsibility to continue the boot strapping on its own, without relying on any services provided by coreboot but the in-memory tables. Cheers, Nico [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BRW3…

2 4

RFC: Behavior of make *config
by Patrick Georgi 28 Nov '23

28 Nov '23

Hi everybody, I updated Kconfig to track latest Linux last week and that brought some behavioral change with it. While these changes are appreciated in some respect, they also complicate work in others. I now proposed https://review.coreboot.org/79298, a change that exempts _all_ *config targets from strict symbol checking under the assumption that any attempt to edit a config should work even if the old configuration is unclean. It will save a clean copy if it saves on exit. A regular build will still fail with an error like this: /home/pgeorgi/coreboot/.config:152:warning: unknown symbol: VBT_DATA_SIZE_KB ERROR: 1 warnings encountered, and warnings are errors. make[1]: *** [build/util/kconfig/Makefile.real:76: olddefconfig] Error 1 make: *** [Makefile:219: build/config.h] Error 2 Running `make olddefconfig` manually (that is, explicitly stating that you want to run the command) would clean it up. Now, given that this is a rather big semantic change, I wanted to make sure that the wider community can provide their input on how to approach this issue properly. Before last week, only `make oldconfig` was exempt from checking, and the checks made by the other *config targets were much more lenient. With this approach, all *config targets clean up the config (and will do so silently, which might be a concern!) but when the config isn't right, the build will fail, and loudly. Thoughts? Regards, Patrick

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 27 Nov '23

27 Nov '23

Dear community, Kindly note that the upcoming coreboot leadership meeting is scheduled for Wednesday, November 29, 2023. [1] You are welcome to add things you wish to see addressed during the meeting to the current agenda items.[2] ## Current Agenda Items ### [Arthur] A new bootflow on ARM64 server using more of TF-A - Motivation: More ARM-Server support in coreboot. - ARM wants to put coreboot in the ARM Base Boot. Requirements: https://developer.arm.com/documentation/den0044/latest - Vendors are more inclined to consider coreboot if it is in a spec written and supported by ARM. - It is currently planned to put the TFA -> coreboot -> Linuxboot bootflow in there as an alternative to the EDK2 variants. TFA can be open source as well as closed source so it is not entirely the same as letting FSP start at Reset. - The Idea is that coreboot is considered by big Vendors when they formulate their specs (so that coreboot doesn’t have to hack around to make stuff work for it). - Reuse working solutions (TF-A) can be a good idea: easier porting. - The scope of the coreboot side of things is small and very reusable: generating SMBIOS and ACPI is quite portable between platforms. - patches necessary to accomplish this mainly are the following: - https://review.coreboot.org/c/coreboot/+/74798/9 - https://review.coreboot.org/c/coreboot/+/78284/8 - patch missing that grabs FDT in bootblock (like done in RISC-V bootblock) - Using only ramstage can be minimally invasive. A similar thing was done to optionally build romstage sources inside the bootblock: https://review.coreboot.org/c/coreboot/+/55068 - coreboot's security model often relies on it being the first code that executes. This might need some changes. - Handoff data from TF-A is often in FDT format for which ramstage has support. - TF-A is BSD3 licensed. You may not always have access to the source code for your platform. - Maybe the ease of use and quality of coreboot convinces a more full adoption on server (use only BL31 like other platforms)? Maybe I'm naive on this? * [Martin] 1) This is taking a piece of coreboot and using it in a different way than normal. I recommended on the mailing list that we call this flow something other than just "coreboot' so as not to confuse things or dilute the meaning of what coreboot is. Maybe "ATF with coreboot technology" or something. 2) This allows us to expose coreboot to people who would otherwise be using a completely different solution. That's a *really* good thing in my opinion. 3) We should try to be a good player in the open source firmware space and work with other projects to create solutions. If this means using pieces of coreboot, I'm all for it, similar to wanting to be able to take pieces of other projects and use them to extend coreboot's functionality. Sure, we could block it here and force it to be forked, but that doesn't really help anyone. 4) Maybe to differentiate this, we can go further than just making it a Kconfig option and actually add a new makefile target. That would make it even more plain that this isn't the full coreboot build. ### [Martin/MaxB] Look at improving the readability of our build system * Our current build system uses make, but stretches it way beyond most makefile-based build systems. This was done to add abstractions which, for example, make it much easier to add files to the various stages. Because of this complexity at the heart of the build, it can be very difficult to understand what’s going on in any given section. One way that is being looked at to improve this is indentation of the if clauses, but this is problematic without rewriting some sections. See CB:79230 * PatrickG encourages folks to consider Burning the Diskpack because he feels that people are too reverent about old work. The build system is 14 years old (and replaced a build system that was 10 years old at the time): if there’s an opportunity to achieve a significant improvement in that area by replacing what we have with something else, go for it! (That doesn’t mean that it must be done. But consider it besides the various fixes that could be applied) * [Martin] I agree with Patrick, but have some qualifications. 1) We’re replacing an existing system that works. Is this the best place to spend our resources? 2) Because it would be replacing a working system, there should be relatively substantial benefits to be gained by updating before it’s considered. 3) As Patrick doesn’t want to discourage change just because the build process is old, we also shouldn’t look to throw it away just because it’s old. (Patrick agrees with all of that) ### [Patrick, Martin] How to present design proposals? * There’s some tension in the project between “folks write a whole new thingamabob and dump it on the project, and get indignant when the project doesn’t adopt it wholesale, and to avoid that from happening, we discourage working like that” and “you want to do something? Build a prototype” * Should we document what we think is a good way to approach such situations? With the example of “make a coreboot build system based on meson”, Patrick mused: “While we discourage folks from dumping a full solution on us, having a partial solution (and that should be more than a userland tool, because those are easy in meson) to offer a glimpse in how it should look is worthwhile. The problems arise when there's so much work sunk into it that rejecting it means rejecting a developer's work of months, which is why that's not a good approach to "dump code on us". There aren't any hard & fast rules, but "I got qemu to compile (typically the easiest target) and this is how it looks" seems like a good step in between. If it takes months to get to that stage, it's probably not worth it, because whatever has been built in that time is as complex as what we have. "I got qemu to compile, but don't mind the mess in most of the tree. I have a plan how it should look (see src/cpu which is more like it) but I wanted to prove the concept first" already offers something that can be discussed properly without costing too much effort.” Stefan offered that code can be published on Gerrit even when it’s not ready yet (and/or just a prototype). Gerrit does have a “Work In Progress” flag for CLs, after all, so there’s not necessarily a need to set up a branch for such work. ### [Martin] Localization of non-console strings for coreboot * With the addition of an early display, we’re looking at printing text to the screen directly from coreboot. Localization is being added for this, but the current patch uses the localization code from vboot. This isn’t a security related feature so shouldn’t depend on the rest of VBOOT being enabled. We also just had an RFC about storing setup engine strings. It seems like we’d want to make sure that whatever plan we have in place also supports localization for those strings as well. * How do we want to handle localization in coreboot? ### [FelixH] Announcements for non-regular meetings * A non-regular coreboot meeting should be announced at least on the previous work day before the time the meeting starts, so that everyone has a chance for preparing for the meeting. [1]https://coreboot.org/calendar.html [2]https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKr…

1 0

Meeting to discuss setup engine data at 5pm UTC today
by coreboot org 27 Nov '23

27 Nov '23

Hi all, sorry for the short notice here. We're having a meeting in just over an hour from when I send this to discuss the formatting and generation of the data needed for a setup engine. See the discussion on the mailing list here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/RO5W… Call-in phone numbers are in the meeting notification on the coreboot calendar. https://coreboot.org/calendar.html Link to the Meeting: https://meet.google.com/hsr-exba-ojf Martin

1 0

'make menuconfig' broken by commit 7eab8ef8b720e8744eea3c6c771bccc217fbe5ed
by Keith Hui 26 Nov '23

26 Nov '23

Hi all, We have a problem. After commit 7eab8ef8b720e8744eea3c6c771bccc217fbe5ed (util/kconfig: Uprev to Linux 6.2's kconfig) [1], make menuconfig is completely borked. I found out using git bisect. After the gerrit link is the output I get when I run 'make menuconfig' instead of the configuration menu. Can we get this looked at ASAP? Thanks Keith [1]https://review.coreboot.org/c/coreboot/+/79179 -------- output ------- $ make menuconfig /usr/bin/ld: build/util/kconfig/mconf.o: in function `show_help': mconf.c:(.text+0x1545): undefined reference to `stdscr' /usr/bin/ld: mconf.c:(.text+0x1551): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function `print_item': checklist.c:(.text+0x82): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x98): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0xb2): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0xd8): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0xfe): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x13c): undefined reference to `wprintw' /usr/bin/ld: checklist.c:(.text+0x162): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x179): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0x196): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x1bc): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x1d8): undefined reference to `waddnstr' /usr/bin/ld: checklist.c:(.text+0x1f8): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0x204): undefined reference to `wrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function `print_arrows': checklist.c:(.text+0x248): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0x264): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x26a): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x278): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x28e): undefined reference to `waddnstr' /usr/bin/ld: checklist.c:(.text+0x2a6): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x2ac): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x2ba): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x2c0): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x2ce): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x2d4): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x2e2): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x2e8): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x2f6): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x318): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0x348): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x34e): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x35c): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x372): undefined reference to `waddnstr' /usr/bin/ld: checklist.c:(.text+0x38a): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x390): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x39e): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x3a4): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x3b2): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x3b8): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x3c6): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x3cc): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x3da): undefined reference to `waddch' /usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function `print_buttons': checklist.c:(.text+0x478): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0x484): undefined reference to `wrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function `dialog_checklist': checklist.c:(.text+0x54a): undefined reference to `stdscr' /usr/bin/ld: checklist.c:(.text+0x556): undefined reference to `stdscr' /usr/bin/ld: checklist.c:(.text+0x580): undefined reference to `stdscr' /usr/bin/ld: checklist.c:(.text+0x58c): undefined reference to `stdscr' /usr/bin/ld: checklist.c:(.text+0x5c7): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/checklist.o:checklist.c:(.text+0x5d3): more undefined references to `stdscr' follow /usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function `dialog_checklist': checklist.c:(.text+0x653): undefined reference to `newwin' /usr/bin/ld: checklist.c:(.text+0x668): undefined reference to `keypad' /usr/bin/ld: checklist.c:(.text+0x6b7): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x6d0): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0x6db): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x6e9): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x6f8): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x706): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x72b): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x731): undefined reference to `acs_map' /usr/bin/ld: checklist.c:(.text+0x73f): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0x76b): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x7ec): undefined reference to `subwin' /usr/bin/ld: checklist.c:(.text+0x801): undefined reference to `keypad' /usr/bin/ld: checklist.c:(.text+0x9da): undefined reference to `wnoutrefresh' /usr/bin/ld: checklist.c:(.text+0x9e6): undefined reference to `wnoutrefresh' /usr/bin/ld: checklist.c:(.text+0x9eb): undefined reference to `doupdate' /usr/bin/ld: checklist.c:(.text+0x9fc): undefined reference to `wgetch' /usr/bin/ld: checklist.c:(.text+0xad1): undefined reference to `scrollok' /usr/bin/ld: checklist.c:(.text+0xae2): undefined reference to `wscrl' /usr/bin/ld: checklist.c:(.text+0xaf3): undefined reference to `scrollok' /usr/bin/ld: checklist.c:(.text+0xb61): undefined reference to `wnoutrefresh' /usr/bin/ld: checklist.c:(.text+0xb6d): undefined reference to `wrefresh' /usr/bin/ld: checklist.c:(.text+0xbfe): undefined reference to `scrollok' /usr/bin/ld: checklist.c:(.text+0xc0f): undefined reference to `wscrl' /usr/bin/ld: checklist.c:(.text+0xc20): undefined reference to `scrollok' /usr/bin/ld: checklist.c:(.text+0xc99): undefined reference to `wnoutrefresh' /usr/bin/ld: checklist.c:(.text+0xca5): undefined reference to `wrefresh' /usr/bin/ld: checklist.c:(.text+0xd1b): undefined reference to `wnoutrefresh' /usr/bin/ld: checklist.c:(.text+0xd27): undefined reference to `wrefresh' /usr/bin/ld: checklist.c:(.text+0xe99): undefined reference to `delwin' /usr/bin/ld: checklist.c:(.text+0xea5): undefined reference to `delwin' /usr/bin/ld: checklist.c:(.text+0xf0b): undefined reference to `wrefresh' /usr/bin/ld: checklist.c:(.text+0xf33): undefined reference to `delwin' /usr/bin/ld: checklist.c:(.text+0xf3f): undefined reference to `delwin' /usr/bin/ld: checklist.c:(.text+0xf4e): undefined reference to `doupdate' /usr/bin/ld: checklist.c:(.text+0xf64): undefined reference to `delwin' /usr/bin/ld: checklist.c:(.text+0xf70): undefined reference to `delwin' /usr/bin/ld: build/util/kconfig/lxdialog/inputbox.o: in function `print_buttons': inputbox.c:(.text+0x96): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0xa2): undefined reference to `wrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/inputbox.o: in function `dialog_inputbox': inputbox.c:(.text+0x10c): undefined reference to `stdscr' /usr/bin/ld: inputbox.c:(.text+0x118): undefined reference to `stdscr' /usr/bin/ld: inputbox.c:(.text+0x142): undefined reference to `stdscr' /usr/bin/ld: inputbox.c:(.text+0x14e): undefined reference to `stdscr' /usr/bin/ld: inputbox.c:(.text+0x172): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/inputbox.o:inputbox.c:(.text+0x17e): more undefined references to `stdscr' follow /usr/bin/ld: build/util/kconfig/lxdialog/inputbox.o: in function `dialog_inputbox': inputbox.c:(.text+0x1fe): undefined reference to `newwin' /usr/bin/ld: inputbox.c:(.text+0x213): undefined reference to `keypad' /usr/bin/ld: inputbox.c:(.text+0x262): undefined reference to `wattrset' /usr/bin/ld: inputbox.c:(.text+0x27b): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x286): undefined reference to `acs_map' /usr/bin/ld: inputbox.c:(.text+0x294): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x2a3): undefined reference to `acs_map' /usr/bin/ld: inputbox.c:(.text+0x2b1): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x2d6): undefined reference to `wattrset' /usr/bin/ld: inputbox.c:(.text+0x2dc): undefined reference to `acs_map' /usr/bin/ld: inputbox.c:(.text+0x2ea): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x316): undefined reference to `wattrset' /usr/bin/ld: inputbox.c:(.text+0x3f5): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x40b): undefined reference to `wattrset' /usr/bin/ld: inputbox.c:(.text+0x46c): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x4a2): undefined reference to `waddnstr' /usr/bin/ld: inputbox.c:(.text+0x4bb): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x4c7): undefined reference to `wrefresh' /usr/bin/ld: inputbox.c:(.text+0x4d8): undefined reference to `wgetch' /usr/bin/ld: inputbox.c:(.text+0x592): undefined reference to `wattrset' /usr/bin/ld: inputbox.c:(.text+0x60f): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x642): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x66a): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x68f): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x69b): undefined reference to `wrefresh' /usr/bin/ld: inputbox.c:(.text+0x6cd): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x6f4): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x727): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x74f): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x76f): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x7ac): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x7d8): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x80b): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x833): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x858): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x8b8): undefined reference to `wattrset' /usr/bin/ld: inputbox.c:(.text+0x95d): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x990): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x9b8): undefined reference to `waddch' /usr/bin/ld: inputbox.c:(.text+0x9dd): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0x9e9): undefined reference to `wrefresh' /usr/bin/ld: inputbox.c:(.text+0x9f3): undefined reference to `flash' /usr/bin/ld: inputbox.c:(.text+0xb1e): undefined reference to `delwin' /usr/bin/ld: inputbox.c:(.text+0xb34): undefined reference to `delwin' /usr/bin/ld: inputbox.c:(.text+0xbba): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0xbc6): undefined reference to `wrefresh' /usr/bin/ld: inputbox.c:(.text+0xc84): undefined reference to `wmove' /usr/bin/ld: inputbox.c:(.text+0xc90): undefined reference to `wrefresh' /usr/bin/ld: inputbox.c:(.text+0xc9f): undefined reference to `delwin' /usr/bin/ld: inputbox.c:(.text+0xcd7): undefined reference to `delwin' /usr/bin/ld: inputbox.c:(.text+0xcf7): undefined reference to `delwin' /usr/bin/ld: build/util/kconfig/lxdialog/menubox.o: in function `do_print_item': menubox.c:(.text+0x96): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0xac): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0xb8): undefined reference to `wclrtoeol' /usr/bin/ld: menubox.c:(.text+0xde): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0xf5): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0x112): undefined reference to `waddnstr' /usr/bin/ld: menubox.c:(.text+0x13e): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0x15a): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0x180): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x1a0): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0x1b8): undefined reference to `wrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/menubox.o: in function `print_arrows': menubox.c:(.text+0x21f): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0x23b): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0x241): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x24f): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x265): undefined reference to `waddnstr' /usr/bin/ld: menubox.c:(.text+0x27d): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0x283): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x291): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x297): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x2a5): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x2ab): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x2b9): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x2bf): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x2cd): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x2ef): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0x2fb): undefined reference to `wrefresh' /usr/bin/ld: menubox.c:(.text+0x326): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0x32c): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x33a): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x350): undefined reference to `waddnstr' /usr/bin/ld: menubox.c:(.text+0x368): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0x36e): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x37c): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x382): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x390): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x396): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x3a4): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x3aa): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x3b8): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x3cc): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0x3d8): undefined reference to `wrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/menubox.o: in function `print_buttons': menubox.c:(.text+0x4f1): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0x4fd): undefined reference to `wrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/menubox.o: in function `do_scroll': menubox.c:(.text+0x524): undefined reference to `scrollok' /usr/bin/ld: menubox.c:(.text+0x535): undefined reference to `wscrl' /usr/bin/ld: menubox.c:(.text+0x546): undefined reference to `scrollok' /usr/bin/ld: menubox.c:(.text+0x563): undefined reference to `wrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/menubox.o: in function `dialog_menu': menubox.c:(.text+0x5ab): undefined reference to `stdscr' /usr/bin/ld: menubox.c:(.text+0x5b7): undefined reference to `stdscr' /usr/bin/ld: menubox.c:(.text+0x5d0): undefined reference to `stdscr' /usr/bin/ld: menubox.c:(.text+0x5dc): undefined reference to `stdscr' /usr/bin/ld: menubox.c:(.text+0x633): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/menubox.o:menubox.c:(.text+0x63f): more undefined references to `stdscr' follow /usr/bin/ld: build/util/kconfig/lxdialog/menubox.o: in function `dialog_menu': menubox.c:(.text+0x6bf): undefined reference to `newwin' /usr/bin/ld: menubox.c:(.text+0x6d4): undefined reference to `keypad' /usr/bin/ld: menubox.c:(.text+0x723): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0x73c): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0x747): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x755): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x764): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x772): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x797): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0x7b2): undefined reference to `wbkgdset' /usr/bin/ld: menubox.c:(.text+0x7b8): undefined reference to `acs_map' /usr/bin/ld: menubox.c:(.text+0x7c6): undefined reference to `waddch' /usr/bin/ld: menubox.c:(.text+0x7f2): undefined reference to `wattrset' /usr/bin/ld: menubox.c:(.text+0x873): undefined reference to `subwin' /usr/bin/ld: menubox.c:(.text+0x888): undefined reference to `keypad' /usr/bin/ld: menubox.c:(.text+0xa76): undefined reference to `wnoutrefresh' /usr/bin/ld: menubox.c:(.text+0xadc): undefined reference to `wmove' /usr/bin/ld: menubox.c:(.text+0xae8): undefined reference to `wrefresh' /usr/bin/ld: menubox.c:(.text+0xaf9): undefined reference to `wgetch' /usr/bin/ld: menubox.c:(.text+0xe3a): undefined reference to `scrollok' /usr/bin/ld: menubox.c:(.text+0xff2): undefined reference to `wnoutrefresh' /usr/bin/ld: menubox.c:(.text+0xffe): undefined reference to `wrefresh' /usr/bin/ld: menubox.c:(.text+0x1121): undefined reference to `wrefresh' /usr/bin/ld: menubox.c:(.text+0x113b): undefined reference to `delwin' /usr/bin/ld: menubox.c:(.text+0x1147): undefined reference to `delwin' /usr/bin/ld: menubox.c:(.text+0x1221): undefined reference to `delwin' /usr/bin/ld: menubox.c:(.text+0x122d): undefined reference to `delwin' /usr/bin/ld: menubox.c:(.text+0x1248): undefined reference to `delwin' /usr/bin/ld: build/util/kconfig/lxdialog/menubox.o:menubox.c:(.text+0x1254): more undefined references to `delwin' follow /usr/bin/ld: build/util/kconfig/lxdialog/textbox.o: in function `refresh_text_box': textbox.c:(.text+0x57): undefined reference to `wmove' /usr/bin/ld: textbox.c:(.text+0x63): undefined reference to `wrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/textbox.o: in function `dialog_textbox': textbox.c:(.text+0x135): undefined reference to `stdscr' /usr/bin/ld: textbox.c:(.text+0x141): undefined reference to `stdscr' /usr/bin/ld: textbox.c:(.text+0x15a): undefined reference to `stdscr' /usr/bin/ld: textbox.c:(.text+0x166): undefined reference to `stdscr' /usr/bin/ld: textbox.c:(.text+0x1d7): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/textbox.o:textbox.c:(.text+0x1e3): more undefined references to `stdscr' follow /usr/bin/ld: build/util/kconfig/lxdialog/textbox.o: in function `dialog_textbox': textbox.c:(.text+0x263): undefined reference to `newwin' /usr/bin/ld: textbox.c:(.text+0x278): undefined reference to `keypad' /usr/bin/ld: textbox.c:(.text+0x2ab): undefined reference to `subwin' /usr/bin/ld: textbox.c:(.text+0x2c5): undefined reference to `wattrset' /usr/bin/ld: textbox.c:(.text+0x2e0): undefined reference to `wbkgdset' /usr/bin/ld: textbox.c:(.text+0x2f1): undefined reference to `keypad' /usr/bin/ld: textbox.c:(.text+0x340): undefined reference to `wattrset' /usr/bin/ld: textbox.c:(.text+0x359): undefined reference to `wmove' /usr/bin/ld: textbox.c:(.text+0x364): undefined reference to `acs_map' /usr/bin/ld: textbox.c:(.text+0x372): undefined reference to `waddch' /usr/bin/ld: textbox.c:(.text+0x381): undefined reference to `acs_map' /usr/bin/ld: textbox.c:(.text+0x38f): undefined reference to `waddch' /usr/bin/ld: textbox.c:(.text+0x3b4): undefined reference to `wattrset' /usr/bin/ld: textbox.c:(.text+0x3cf): undefined reference to `wbkgdset' /usr/bin/ld: textbox.c:(.text+0x3d5): undefined reference to `acs_map' /usr/bin/ld: textbox.c:(.text+0x3e3): undefined reference to `waddch' /usr/bin/ld: textbox.c:(.text+0x431): undefined reference to `wnoutrefresh' /usr/bin/ld: textbox.c:(.text+0x4ba): undefined reference to `wgetch' /usr/bin/ld: textbox.c:(.text+0x88c): undefined reference to `delwin' /usr/bin/ld: textbox.c:(.text+0x898): undefined reference to `delwin' /usr/bin/ld: textbox.c:(.text+0x905): undefined reference to `delwin' /usr/bin/ld: textbox.c:(.text+0x911): undefined reference to `delwin' /usr/bin/ld: build/util/kconfig/lxdialog/textbox.o: in function `print_page': textbox.c:(.text+0xb7b): undefined reference to `wnoutrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/textbox.o: in function `print_line': textbox.c:(.text+0xbe5): undefined reference to `wmove' /usr/bin/ld: textbox.c:(.text+0xbf6): undefined reference to `waddch' /usr/bin/ld: textbox.c:(.text+0xc3b): undefined reference to `waddnstr' /usr/bin/ld: textbox.c:(.text+0xc47): undefined reference to `wclrtoeol' /usr/bin/ld: build/util/kconfig/lxdialog/textbox.o: in function `print_position': textbox.c:(.text+0xd47): undefined reference to `wattrset' /usr/bin/ld: textbox.c:(.text+0xd62): undefined reference to `wbkgdset' /usr/bin/ld: textbox.c:(.text+0xdf1): undefined reference to `wmove' /usr/bin/ld: textbox.c:(.text+0xe0a): undefined reference to `wprintw' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `init_one_color': util.c:(.text+0x9b2): undefined reference to `init_pair' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `color_setup': util.c:(.text+0xb3c): undefined reference to `has_colors' /usr/bin/ld: util.c:(.text+0xb45): undefined reference to `start_color' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `attr_clear': util.c:(.text+0xb7b): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0xb9a): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0xbb4): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0xbfc): undefined reference to `wtouchln' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `dialog_clear': util.c:(.text+0xc0f): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xc1b): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xc34): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xc40): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xc5f): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/util.o:util.c:(.text+0xc9a): more undefined references to `stdscr' follow /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `dialog_clear': util.c:(.text+0xca4): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0xcab): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xcbd): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0xcd0): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xce0): undefined reference to `waddnstr' /usr/bin/ld: util.c:(.text+0xd23): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xd35): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0xd4f): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xd63): undefined reference to `waddnstr' /usr/bin/ld: util.c:(.text+0xd9d): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0xda4): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xdae): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0xdc1): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xdce): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0xe07): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xe17): undefined reference to `waddnstr' /usr/bin/ld: util.c:(.text+0xe49): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xe56): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0xe83): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0xe8a): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xe94): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0xeaa): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xeb2): undefined reference to `wnoutrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `init_dialog': util.c:(.text+0xeca): undefined reference to `initscr' /usr/bin/ld: util.c:(.text+0xed1): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xedd): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xef5): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xf01): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xf1a): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/util.o:util.c:(.text+0xf26): more undefined references to `stdscr' follow /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `init_dialog': util.c:(.text+0xf6e): undefined reference to `endwin' /usr/bin/ld: util.c:(.text+0xf99): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0xfa6): undefined reference to `keypad' /usr/bin/ld: util.c:(.text+0xfab): undefined reference to `cbreak' /usr/bin/ld: util.c:(.text+0xfb0): undefined reference to `noecho' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `end_dialog': util.c:(.text+0xffd): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0x100d): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0x1014): undefined reference to `stdscr' /usr/bin/ld: util.c:(.text+0x101c): undefined reference to `wrefresh' /usr/bin/ld: util.c:(.text+0x1021): undefined reference to `endwin' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `print_title': util.c:(.text+0x108a): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0x10ad): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0x10c3): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x10e5): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0x1100): undefined reference to `waddnstr' /usr/bin/ld: util.c:(.text+0x1111): undefined reference to `waddch' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `print_autowrap': util.c:(.text+0x11b9): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0x11d7): undefined reference to `waddnstr' /usr/bin/ld: util.c:(.text+0x1301): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0x131c): undefined reference to `waddnstr' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `print_button': util.c:(.text+0x1407): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0x142d): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0x1443): undefined reference to `waddnstr' /usr/bin/ld: util.c:(.text+0x1486): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0x14a0): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x14d2): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0x14ea): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x1510): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0x152c): undefined reference to `waddnstr' /usr/bin/ld: util.c:(.text+0x1552): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0x1568): undefined reference to `waddnstr' /usr/bin/ld: util.c:(.text+0x1584): undefined reference to `wmove' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `draw_box': util.c:(.text+0x15b5): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0x15db): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0x15f9): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0x160c): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x1628): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0x163b): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x1657): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0x166a): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x168b): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0x169e): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x16af): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0x16c2): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x16d8): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0x16eb): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x16f9): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0x170c): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x171f): undefined reference to `acs_map' /usr/bin/ld: util.c:(.text+0x1732): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x174a): undefined reference to `waddch' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `draw_shadow': util.c:(.text+0x178c): undefined reference to `has_colors' /usr/bin/ld: util.c:(.text+0x17aa): undefined reference to `wattrset' /usr/bin/ld: util.c:(.text+0x17c6): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0x17db): undefined reference to `winch' /usr/bin/ld: util.c:(.text+0x17ec): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x181c): undefined reference to `wmove' /usr/bin/ld: util.c:(.text+0x1828): undefined reference to `winch' /usr/bin/ld: util.c:(.text+0x1839): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x1845): undefined reference to `winch' /usr/bin/ld: util.c:(.text+0x1856): undefined reference to `waddch' /usr/bin/ld: util.c:(.text+0x1873): undefined reference to `wnoutrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/util.o: in function `on_key_esc': util.c:(.text+0x1978): undefined reference to `nodelay' /usr/bin/ld: util.c:(.text+0x1989): undefined reference to `keypad' /usr/bin/ld: util.c:(.text+0x1995): undefined reference to `wgetch' /usr/bin/ld: util.c:(.text+0x19a4): undefined reference to `wgetch' /usr/bin/ld: util.c:(.text+0x19b3): undefined reference to `wgetch' /usr/bin/ld: util.c:(.text+0x19cd): undefined reference to `nodelay' /usr/bin/ld: util.c:(.text+0x19de): undefined reference to `keypad' /usr/bin/ld: util.c:(.text+0x1a0d): undefined reference to `ungetch' /usr/bin/ld: build/util/kconfig/lxdialog/yesno.o: in function `print_buttons': yesno.c:(.text+0x9f): undefined reference to `wmove' /usr/bin/ld: yesno.c:(.text+0xab): undefined reference to `wrefresh' /usr/bin/ld: build/util/kconfig/lxdialog/yesno.o: in function `dialog_yesno': yesno.c:(.text+0xdf): undefined reference to `stdscr' /usr/bin/ld: yesno.c:(.text+0xeb): undefined reference to `stdscr' /usr/bin/ld: yesno.c:(.text+0x115): undefined reference to `stdscr' /usr/bin/ld: yesno.c:(.text+0x121): undefined reference to `stdscr' /usr/bin/ld: yesno.c:(.text+0x145): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/yesno.o:yesno.c:(.text+0x151): more undefined references to `stdscr' follow /usr/bin/ld: build/util/kconfig/lxdialog/yesno.o: in function `dialog_yesno': yesno.c:(.text+0x1d1): undefined reference to `newwin' /usr/bin/ld: yesno.c:(.text+0x1e6): undefined reference to `keypad' /usr/bin/ld: yesno.c:(.text+0x235): undefined reference to `wattrset' /usr/bin/ld: yesno.c:(.text+0x24e): undefined reference to `wmove' /usr/bin/ld: yesno.c:(.text+0x259): undefined reference to `acs_map' /usr/bin/ld: yesno.c:(.text+0x267): undefined reference to `waddch' /usr/bin/ld: yesno.c:(.text+0x276): undefined reference to `acs_map' /usr/bin/ld: yesno.c:(.text+0x284): undefined reference to `waddch' /usr/bin/ld: yesno.c:(.text+0x2a9): undefined reference to `wattrset' /usr/bin/ld: yesno.c:(.text+0x2af): undefined reference to `acs_map' /usr/bin/ld: yesno.c:(.text+0x2bd): undefined reference to `waddch' /usr/bin/ld: yesno.c:(.text+0x2e9): undefined reference to `wattrset' /usr/bin/ld: yesno.c:(.text+0x332): undefined reference to `wgetch' /usr/bin/ld: yesno.c:(.text+0x3f2): undefined reference to `delwin' /usr/bin/ld: yesno.c:(.text+0x408): undefined reference to `delwin' /usr/bin/ld: yesno.c:(.text+0x470): undefined reference to `wrefresh' /usr/bin/ld: yesno.c:(.text+0x47e): undefined reference to `delwin' /usr/bin/ld: yesno.c:(.text+0x4a0): undefined reference to `delwin' /usr/bin/ld: yesno.c:(.text+0x4c0): undefined reference to `delwin' collect2: error: ld returned 1 exit status make: *** [/usr/src/coreboot/util/kconfig/Makefile.inc:76: build/util/kconfig/mconf] Error 1 $

2 1

Intel Alderlake N100 support
by Javier 26 Nov '23

26 Nov '23

Hello ! I noticed on 4.16 release notes [1], Intel Alderlake-N RVP was added as a new supported board. I don't know if that means Intel Alderlake N100 and other "N*" like N200 intel processors are also supported or only a particular one. If N100 would be included into the processors supported, is ME disabling supported, or at least mitigating its privacy risks supported? On the same release notes, as part of the significant changes, it's mentioned ME is now disabled from skylake to alderlake. So I'm hoping disabling ME on alderlake n100 is actually possible. I don't know if more boards besides the RVP one (which I don't know which one it is) can be supported. I acquired a Trycoo WI-6 Mini PC [2] with tho hope I could use coreboot on it and more importantly, disable ME on its intel processor. Have there been news about this mini-pc booting with coreboot? Is there hope? BTW, I executed some commands, like dmidecode, lspci on it, though an external usb disk with linux, and most of the outputs indicate unknown unfortunately, :( Any hopes for this mini-pc? Any success story reported? Are there instructions on how to further test to know for sure about the possibilities, and also to try, even from similar mini-pcs or boards? Any command outputs you'd like me to share? Thanks a lot ! -- Javier [1] https://doc.coreboot.org/releases/coreboot-4.16-relnotes.html [2] https://www.amazon.com/gp/product/B0CBTF4J7X

1 1

Restoring the opensource AGESA boards takes just 1% of git reverts since their removal
by Mike Banon 26 Nov '23

26 Nov '23

Dear friends, please take a look at this change: https://review.coreboot.org/c/coreboot/+/76832 This script reverts the opensource AGESA AMD boards removal that happened after 5e8e911b7caee021faff96c4e82a77a42544ea62 (0 point of history, or 0 PoH) - by git-reverting: 1) the "bad commits" (marked as "CBF" = coreboot build failure) - that either remove or break a code needed for our boards 2) the "unlucky commits" (marked as "GRF" = git revert failure) - that are a roadblock for git-reverting the "bad commits" Right now at 3bd83b27afbc840f184b652a1dd8ed539623a258 (3765 PoH), it takes 38 CBF git reverts - just 1% of 3765 commits since the OSS AGESA removal! - - making this removal look questionable and the idea of restoration viable. Btw plenty of these git reverts could be avoided if the changes to the "dropped code" are allowed: i.e. instead of git reverting the four patches numbered 497-500 at the script above, one could simply add a single " #define SPEEDSTEP_APIC_MAGIC 0xACAC " somewhere. Therefore the real number of "bad commits" (which either remove our boards or break the things for us) isn't that great and the opensource AGESA boards really can be brought back to coreboot with a bunch of ifdef's etc. Please let me know if you're interested in such a quest... SUCCESSFUL TESTS for the opensource AGESA boards which I own (Lenovo G505S - - fam15 laptop, ASUS A88XM-E - fam15 desktop, ASUS AM1I-A - fam16 desktop) : 1) only build: 69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for AM1I-A, most likely boot works too but I didn't have the time to test 2) build & boot: 69ffebf5ccf123bc0b3fb28b485985af0597761d (3698 PoH) for G505S and A88XM-E 11ba8ebbcc662ebd1dc8e14372a020eb32f26561 (3741 PoH) for G505S test only -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 3

make menuconfig - is broken after commit 7eab8ef (Linux 6.2's kconfig) and follow-ups
by Mike Banon 26 Nov '23

26 Nov '23

Dear friends, I just encountered a menuconfig problem on a fresh coreboot. Steps to reproduce: 1) Testing environment - fully updated Artix Linux (arch w/o systemd): 6.5.11 linux kernel etc. 2) At the freshly cloned coreboot directory (+ submodules checkout'ed), git reset --hard 7eab8ef and then make menuconfig - will cause these errors: /usr/bin/ld: build/util/kconfig/lxdialog/yesno.o: warning: relocation against `acs_map' in read-only section `.text' /usr/bin/ld: build/util/kconfig/mconf.o: in function `show_help': mconf.c:(.text+0x1770): undefined reference to `stdscr' /usr/bin/ld: mconf.c:(.text+0x177c): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function `print_item': checklist.c:(.text+0x82): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x98): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0xb2): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0xd8): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0xfe): undefined reference to `wattrset' 3) One commit before - 7f93aa4 - the things worked OK Curious, if anyone else has the same error? Please take a look at this -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

3 3

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 24 Nov '23

24 Nov '23

Dear Community, We are happy to announce that the upcoming coreboot leadership meeting is scheduled for November 29, 2023. [1] Kindly update the current agenda items with things you wish to see addressed during the meeting.[2] [1] https://coreboot.org/calendar.html (https://coreboot.org/calendar.html) [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… (https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…) j6ljr2742djc

1 0

Fwd: Re: Makefile indentation for conditionals
by Maximilian Brune 23 Nov '23

23 Nov '23

---------- Forwarded message --------- Von: Maximilian Brune <maximilian.brune(a)9elements.com> Date: Do., 23. Nov. 2023 um 23:13 Uhr Subject: Re: [coreboot] Re: Makefile indentation for conditionals To: Felix Held <felix-coreboot(a)felixheld.de> Could you please show the world a simple example of what you mean? It > would certainly help everyone understand your proposal. > https://review.coreboot.org/c/coreboot/+/79230 Am Do., 23. Nov. 2023 um 21:29 Uhr schrieb Felix Held < felix-coreboot(a)felixheld.de>: > On 23/11/2023 20:50, Martin Roth via coreboot wrote: > > If we do go this route for indentation, could we standardize on either > > 2-space 4-space indentation per level? The Makefile lines are long > > enough without indentation. > > I was initially thinking of 4 or 8 spaces vs tabs which isn't > necessarily easy to visually differentiate, so I didn't like the idea > too much. A 2 spaces indentation might be much better and something to > look into; at least that's sufficiently visually different from the tabs > for any usual tab size to not mix those up. > > Regards, > Felix > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot