coreboot

coreboot@coreboot.org

3 participants
39562 discussions

[coreboot - Bug #327] MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR
by Patrick Rudolph 16 Mar '24

16 Mar '24

Issue #327 has been updated by Patrick Rudolph. Please test https://review.coreboot.org/c/coreboot/+/81295 In case this doesn't fix the problem please attach to windows kernel using windbg and provide more details about the failing code. ---------------------------------------- Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR https://ticket.coreboot.org/issues/327#change-1792 * Author: xinhua wang * Status: New * Priority: Normal * Start date: 2021-12-30 ---------------------------------------- https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi… this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc When set to 0x1000 windows UEFI tianocore mode boots fine ---Files-------------------------------- dmesg.txt (76.9 KB) results.log (204 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

[coreboot - Bug #327] MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR
by Patrick Rudolph 16 Mar '24

16 Mar '24

Issue #327 has been updated by Patrick Rudolph. It looks like 0x2000 is the correct size for the total opregion (MBOX1-MBOX5). Since ACPI only uses MBOX3, the size should be reduced to 0x400. ---------------------------------------- Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR https://ticket.coreboot.org/issues/327#change-1791 * Author: xinhua wang * Status: New * Priority: Normal * Start date: 2021-12-30 ---------------------------------------- https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi… this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc When set to 0x1000 windows UEFI tianocore mode boots fine ---Files-------------------------------- dmesg.txt (76.9 KB) results.log (204 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

[coreboot - Bug #327] MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR
by Joel Linn 16 Mar '24

16 Mar '24

Issue #327 has been updated by Joel Linn. I can also confirm this, I get *ACPI_BIOS_ERROR 0x1000 0x0 0x0 0x2000* and applying the mentioned change does the trick for me. Sandy Bridge H61 Express i3-3220, no secondary GPU, libgfxinit ---------------------------------------- Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR https://ticket.coreboot.org/issues/327#change-1790 * Author: xinhua wang * Status: New * Priority: Normal * Start date: 2021-12-30 ---------------------------------------- https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi… this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc When set to 0x1000 windows UEFI tianocore mode boots fine ---Files-------------------------------- dmesg.txt (76.9 KB) results.log (204 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

The coreboot master branch has been deleted
by Martin Roth 13 Mar '24

13 Mar '24

Hello All, It's been mentioned a few times previously that we were going to delete the master branch after switching the default branch to 'main'. This process is now completed - the master branch is gone. One positive of this is that people can no longer push patches to the master branch in confusion, however anyone who hasn't updated scripts or git pointers in the past 6 months is now going to see failures. This could absolutely include the coreboot project as well. We've recently found settings that were still pointing at the master branch. If you see any oddness or issues that could be related to the master branch, please let the admins or leadership know. Thanks much. Martin

1 0

GRUB2_SECONDARY_PAYLOAD: max possible module set + unavailable modules
by Mike Banon 10 Mar '24

10 Mar '24

Good day! I am trying to ensure the best feature set for a GRUB2 secondary payload of SeaBIOS. First of all, I checked what GRUB2 modules I have in a fully-updated Artix (arch without systemd) installation: ls -al /boot/grub/i386-pc/ | cut -c44- | awk '{ print substr( $0, 1, length($0)-4 ) }' | tr '\n' ' ' Then I tried using this list as a value for CONFIG_GRUB2_EXTRA_MODULES (could not set it with 'make menuconfig' because it was way too long, so had to edit a ./coreboot/.config manually) - but for some reason not all GRUB2 modules are available: while trying to build, I constantly got the errors like: ... config.status: creating grub ./grub-mkstandalone: error: cannot open `grub-core//pxechain.mod': No such file or directory. make[2]: *** [Makefile:15040: default_payload.elf] Error 1 make[1]: *** [Makefile:45: grub2] Error 2 make: *** [payloads/external/Makefile.mk:276: grub2] Error 2 - and had to remove the "missing modules" from this variable one-by-one. Eventually I got the max possible GRUB2 module set - please see attachments (without any modules at all, img/grub2 occupies 472 KB at CBFS; with all these modules - 710 KB). However, what worries me is why these modules are unavailable at coreboot+SeaBIOS version of GRUB2 : biosdisk bufio cacheinfo cbtable command core drivemap font freedos fs gfxterm legacycfg legacy_password_test load lsapm moddep modinf ntldr partmap plan9 pxechain pxe sendkey truecrypt vbe vga vga_text video_fb video Some of those missing ones could be valuable - like a truecrypt module... Do you know why they are missing and how to debug this? -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

looking for someone to help on coreboot port to visionfive2 board
by ron minnich 07 Mar '24

07 Mar '24

during a recent RISE meeting, I conveyed the good news that Max and 9elements had released the SiFive unmatched port and it was upstreamed! That was great. People seemed interested. Next request: Starfive visionfive2. Now, we do have an oreboot port, so there is a code base to reference. If somebody would like to look at getting this board ported, it would be a big help.

1 0

2024-03-06 - coreboot Leadership Meeting minutes
by mina＠coreboot.org 07 Mar '24

07 Mar '24

# 2024-03-06 - coreboot Leadership Meeting minutes ## Announcement: OSFF ByteTalks - [https://osfw.foundation/events/bytetalks-vol.-1/]. OSFC will be in Bochum Germany - September 3-5 - [https://www.osfc.io/]. ## Attendees: Martin Roth, Mina Asante, Julius Werner, Daniel Maslowski, Jonathan Hall, Matt Devillier, Nicholas Chin, Nico Huber, Jay Talbott, Felix Singer, Werner Zeh, Marshall Dawson, Felix Held, David Hendricks, Jules Irenge, Max Brune. ## Open Action Items * 2024-03-06 * [Open] Martin: To update documentation on gerrit contributing guidelines. * https://doc.coreboot.org/contributing/index.html * 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 ### [Martin] -1 should be a privilege for coreboot reviewers along with +2 rights. * Since 2016, all registered users have had -1 rights. Back then, we didn’t block on unresolved comments, so giving a -1 was the only good way to get attention for an issue. This is no longer the case, and I feel that we should go back to having -1 rights be one of the privileges given to contributors. * There’s no incident - We just don’t need to give -1 to every registered user anymore. This has been superseded by making people address all open patches. * Current status: * Registered users: -1 to +1 * Developers: -1 to +2 * Core developers: -2 to +2 * Proposed: * Registered users: 0 to +1 * Developers: -1 to +2 * Core developers: -2 to +2 * FelixS: If people can give +1, they should be allowed to give -1. * Martin: So should we give -2 privileges to everyone with +2 privileges as well? * FelixS: The -1 allows me to see attitudes about things without needing to read come * Martin: I feel like the -1 rights should go to people who have actually submitted patches - it’s not hard. * Max, David, Daniel: Agreed * FelixS: Disagree * Documentation needs to be updated. * We can change it back if there are issues. ### [Martin] Implementing fuzzing testing at coreboot. * First test at [https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util…] * Any APIs & anything loaded out of SPI should be fuzzed when possible. * Add to ongoing projects. ### [Martin] Gtiles is currently down * FelixS added some firewallish rules to the web server to block some bots. Still not very efficient - each Bot needs to be blocked individually. * We don’t get IP addresses of requests. * Daniel: Search engines also index GitHub on which we have mirrored out repos, so when it’s about code visibility/discoverability, we can block crawlers completely to lower the impact on our own infra. People can use the GitHub viewer and Gitiles alike, giving just a different view on the same data. ### [FelixS] Revisit register naming for I2c device registers: * See (https://review.coreboot.org/c/coreboot/+/77098) - This only changes the *coreboot* structures, not device #defines and device specific structures. * After discussion about this patch, there’s more support for keeping internal naming consistent, even if it doesn’t match the names from the specs. * Werner: Keep the names consistent with the datasheets even if they don’t match the coreboot structures. Max: Agreed * Martin & FelixS would prefer to change. ### [Martin] Renaming SPI master/slave * There’s no specific SPI spec, but there are a number of major companies who have changed the names in their specifications. Most notably, Intel has changed the names in the eSPI specification to controller/target. \ Unfortunately, there’s no real agreement on what to change the names to: \ [https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Alternative_termi…] * Martin’s proposal would be to go with the eSPI names of controller/target as eSPI. \ * Matt and Werner agree. * Julius points out "main" and "sub" preserves MISO/MOSI and is currently used on Wikipedia. * Max likes this. David +1 * Nico: This seems a bit forced * SPI: main/sub and eSPI: controller/target (Devices use whatever their datasheet says) * FelixS: Let’s look at what the linux kernel does. ### [Martin] Designing a coreboot Poster & Brochure for conferences * We’d like to design a poster & brochure to have at conferences and other places where coreboot information is desired. * [https://docs.google.com/document/d/1l-dSWram1vpq6-fYYqecYmOXCpj_7YXSnBx-kaK…] * Please comment or contribute * Marvin has a flyer * Add a payload section - Most used payloads - add logos * Adding a bunch of qr codes pointing to the website for the vendors & consultants * Shortened links as well or instead * Make part of the domain instead - gsoc.coreboot.org instead of https://doc.coreboot.org/contributing/gsoc.html ### [Martin] Info only: The 24.02 release is complete and announced. * Next release will be Mid-May. ### [FelixS] Not applying to GSOC this year - deadline is passed. * Not many people interested in mentoring - This is a big time investment. # Next meeting * March 20, 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-03-06](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1… 1).

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 06 Mar '24

06 Mar '24

Dear community, Please note that the upcoming coreboot leadership meeting is scheduled for next Wednesday, March 6, 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] -1 should be a privilege for coreboot reviewers along with +2 rights. * Since 2016, all registered users have had -1 rights. Back then, we didn’t block on unresolved comments, so giving a -1 was the only good way to get attention for an issue. This is no longer the case, and I feel that we should go back to having -1 rights be one of the privileges given to contributors. ### [Martin] Implementing fuzzing testing at coreboot. * First test at https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util… ### [FelixS] Revisit register naming for I2c device registers: * See https://review.coreboot.org/c/coreboot/+/77098 * After discussion about this patch, there’s more support for keeping internal naming consistent, even if it doesn’t match the names from the specs. ### [Martin] Renaming SPI master/slave * There’s no specific SPI spec, but there are a number of major companies who have changed the names in their specifications. Most notably, Intel has changed the names in the eSPI specification to controller/target. Unfortunately, there’s no real agreement on what to change the names to: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Alternative_termi… ### [Martin] Designing a coreboot Poster & Brochure for conferences * We’d like to design a poster & brochure to have at conferences and other places where coreboot information is desired. ### [Martin] Info only: The 24.02 release is complete and announced. [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

2 1

EM100Pro-G3 sporadically stops working
by Corvin Köhne 06 Mar '24

06 Mar '24

Hi, I'm currently having some issues using the new EM100Pro-G3 and would like to know if someone has seen such issues before and may have a solution. The EM100Pro-G3 sporadically stops working properly. I can reproduce the issue within a few minutes by running the following steps in a loop: 1. power off the board 2. em100 \ --device EMxxxxxx \ --stop \ --set <chip> \ --download <rom> \ --verify \ --start 3. power on the board * the board is configured to netboot a linux 4. wait until linux is reachable by ssh 5. goto 1 After some iterations, the board isn't able to boot any more. Even if I power cycle the board, it doesn't boot. It doesn't even reach it's first POST. Reloading the ROM into the EM100 (repeating step 2), solves the issue. I'm currently trying to gather more information about the issue. What I do know right now: 1. Reloading the ROM without physically touching anything solves the issue. 2. It doesn't matter if I connect the USB connector + power adapter or only the USB connector to the EM100Pro-G3. 3. I've recently exchanged the EM100Pro-G3 with the older EM100Pro-G2. The board is running fine for several hours right now without any issues. 4. If the board is unable to boot, `em100 --device EMxxxxxx --trace` does return some data. I don't think it's a physical issue, e.g. signal integrity issue, as I'm not touching the whole system (see 1 + 2). I also don't think that it's a sporadic issue of my ROM file as it's working with the old G2 (see 3). Maybe the ROM isn't loaded correctly into the EM100 which causes it to return wrong data (see 1 + 4)? As said, the board is currently connected to a G2. I'm going to keep this test running for a while. If I can't reproduce the issue on the G2, I'm going to switch back to the G3 and try to gather some more information. What I'm going to check next is if the ROM returned by `em100 --device EMxxxxxx --upload <rom>` matches the desired ROM. Any help how to debug or solve this issue is highly appreciated! -- Many thanks in advance, Corvin

1 1

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

05 Mar '24

Hi Julius, I've fixed the issue you were seeing. Thanks for bringing it to our attention. There were 2 things that were contributing to jenkins not seeing the libpayload files: 1) They were deeper in the tree than we were looking for junit*.xml files. These were only getting picked up two levels deep into the payloads directory: payloads/*/*/junit*.xml 2) We were also looking for junit.xml files anywhere in the tree, but the output files only match junit*.xml files. Here's the list of files we needed to find: ./payloads/libpayload/build/coverage/junit-libpayload-tests-build.xml ./payloads/libpayload/build/coverage/junit-libpayload-tests_libcbfs_cbfs-no-verification-has-sha512-test(tests).xml ./payloads/libpayload/build/coverage/junit-libpayload-tests_libcbfs_cbfs-no-verification-no-sha512-test(tests).xml ./payloads/libpayload/build/coverage/junit-libpayload-tests_libcbfs_cbfs-verification-has-sha512-test(tests).xml ./payloads/libpayload/build/coverage/junit-libpayload-tests_libcbfs_cbfs-verification-no-sha512-test(tests).xml ./payloads/libpayload/build/coverage/junit-libpayload-tests_libcbfs_cbfs-lookup-has-fallback-test(tests).xml ./payloads/libpayload/build/coverage/junit-libpayload-tests_libcbfs_cbfs-lookup-no-fallback-test(tests).xml ./payloads/libpayload/build/coverage/junit-libpayload-tests_libc_fmap_locate_area-test(tests).xml ./payloads/libpayload/build/coverage/junit-libpayload-tests_drivers_speaker-test(tests).xml I've updated the general pattern to find junit*.xml files anywhere in the tree, and now they're seen by the jenkins log collector. In the output of https://qa.coreboot.org/job/coreboot-gerrit/253059/ you can see that we now get 4 errors: Test Result (4 failures / +4) tests_libcbfs_cbfs-lookup-has-fallback-test(tests).test_cbfs_unverified_area_map, RW, aligned tests_libcbfs_cbfs-lookup-has-fallback-test(tests).test_cbfs_unverified_area_map, RW, unaligned tests_libcbfs_cbfs-lookup-no-fallback-test(tests).test_cbfs_unverified_area_map, RW, aligned tests_libcbfs_cbfs-lookup-no-fallback-test(tests).test_cbfs_unverified_area_map, RW, unaligned Thanks again for helping to fix this problem. Martin Feb 28, 2024, 16:22 by jwerner(a)chromium.org: > Hmm... well, I just uploaded a CL that clearly breaks one of the > tests, and Jenkins still gave me a Verified+1: > https://review.coreboot.org/80788 > > I also don't see any info about the tests running on the test report > (https://qa.coreboot.org/job/coreboot-gerrit/252941/testReport/(root)/). > So if the tests are running (and the code you pointed out strongly > looks like they should be), it's probably a problem with reading back > the test results? How does Jenkins collect those XML files? > > On Tue, Feb 27, 2024 at 7:04 PM Martin Roth <gaumless(a)tutanota.com> wrote: > >> >> Hey Julius, >> Here's what we running: >> https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util… >> >> Martin >> Feb 27, 2024 at 18:31 by jwerner(a)chromium.org: >> >> > Hi, >> > >> > We've had unit test support in libpayload for over two years now, but >> > I just noticed that it doesn't look like we're actually running them >> > in the CI? E.g. if I look through a test run like this >> > https://qa.coreboot.org/job/coreboot-gerrit/252761/testReport/(root)/ >> > I can't find them anywhere (most of them have confusingly similar >> > names with coreboot unit tests, but "fmap_locate_area-test" is a >> > unique one). >> > >> > Is that intended or an oversight? Would it be easy to fix? (I'm not >> > super familiar with how the tests are integrated into Jenkins, but the >> > libpayload framework is pretty much a direct copy of the coreboot >> > framework, so if we can run the coreboot ones hopefully it should be >> > easy to run the libpayload ones as well?) >> > _______________________________________________ >> > coreboot mailing list -- coreboot(a)coreboot.org >> > To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > >> > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
3957
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot