coreboot

coreboot@coreboot.org

1 participants
39762 discussions

Sane length for the first commit message line in documentation
by Zeh, Werner 09 Jan '25

09 Jan '25

Hi all. Recently it was brought to my attention that there is a dead link [1] in our documentation (commit message guidelines [2]). After having a look and asking around it turned out that it currently points to the old wiki which is finally offline, hence the dead link. I have created a patch to re-write the old content from the wiki in [3]. So far this is more or less a rewrite of what has been there in the old wiki with some additions from me. One review comment is that the mentioned limits for the line length of the first commit message might not be sufficient anymore. There it stated that the first line should be less than 65 characters or absolute maximum 75. Shall we adjust this length now that we are having this commit message guideline available again in our docs? Limiting to a too low number might lead to struggles when writing a meaningful description with the prefixed file path. Having too big numbers here might make it hard to read on consoles and even in Gerrit. Any thoughts on the new limits? Or are the ones mentioned there still fine? Your input is valuable. Thanks Werner [1] https://www.coreboot.org/Git#Commit_messages [2] https://doc.coreboot.org/contributing/gerrit_guidelines.html#recommendations -for-gerrit-activity [3] https://review.coreboot.org/c/coreboot/+/85915

2 2

Q: Can I modify PCH soft straps from bootblock?
by Keith Hui 09 Jan '25

09 Jan '25

All, A use case for the title is beginning to emerge for a number of Asus P8x7x boards. For example: https://review.coreboot.org/c/coreboot/+/85413 and https://review.coreboot.org/c/coreboot/+/85768 Many standard ATX boards in the family have more peripherals than the 8 PCIe lanes available out of the PCH, so some are structured to share 3 of the 4 PCIe lanes originally earmarked for an x4 slot. They do this with a number of 2-way PCIe switches (specifically ASM1440 - no datasheet, but I figured out the pinout, only thing I don't know is the polarity of the control signal) controlled by GPIOs either on the super I/O or the PCH. With vendor firmware this is an option that can be configured from UEFI setup itself. I can handle GPIOs fine, but stealing lanes from an x4 slot requires changing a soft strap to reconfigure lanes 1-4 from one x4 port to four x1 ports. The only strategy I can see work is flash a modified soft strap to the descriptor, during bootblock before PCI bus scan happens and before SPI is locked down, trigger a full platform reset (eg. outb(0xe, 0xcf9)) , then program the GPIOs to match the updated soft strap. Has this been done before in coreboot so there is code I can lift? Thanks Keith

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 06 Jan '25

06 Jan '25

Dear coreboot Community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, January 8, 2025. [1] Kindly update the agenda with matters you wish to see addressed during the meeting. [2] ## Current Agenda Items ### [Sheng/Chris] Promote Liu Shuo to be core developer * He has shown great progress in leading and helping coreboot Xeon patches together with the community * Stats for the past 2 years: Commits: 96 (10th most commits overall) Reviews: 139 Comments: 118 * Worked together with community to upstream GNR patches and cleaned up many Eagle Stream coreboot mess * Able to address most of reviewers feedback and make the code better, understand coreboot practices, and also produces patches with good code quality. * Author of (https://community.intel.com/t5/Blogs/Tech-Innovation/Data-Center/Advancing-…) * Will have bigger responsibility to maintain and drive the Xeon coreboot works. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 03 Jan '25

03 Jan '25

Dear coreboot Community, We are pleased to announce that we have an upcoming leadership meeting scheduled for January 8, 2025. [1] Please update the agenda with matters you wish to see addressed during the meeting. [2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Two devicetree questions and two use cases
by Keith Hui 27 Dec '24

27 Dec '24

My question is pretty much as title. I'll explain my use cases below. 1. https://review.coreboot.org/c/coreboot/+/82633 With this patch, I'm still getting leftover devices messages in the log for devices 0:1.1 and 0:1.2. This is with no card plugged into the PCIe x16 slot. As far as I can tell those devices are for when the Ivy Bridge CPU's PCIe lanes have to run in x8 or x4 mode. I don't know what device 0:4.0 is for. 0:6.0 is for the extra 4 PCIe lanes for Xeon CPUs. None of the Asus P8x7x series boards have them wired up. So is there a way for me to "remove" the latter two devices from chipset.cb with the mainboard devicetree.cb, or do I have to hide them like I did in the patch? How do I completely get rid of leftover devices? 2. https://review.coreboot.org/c/coreboot/+/85413 and https://review.coreboot.org/c/coreboot/+/85768 These boards, as well as p8z77-m_pro (likely any standard ATX board in this family), have one x16 slot and one x8 slot that are both serviced by the 16 PCIe lanes out of the CPU. The card presence pin on the x8 slot activates a CPU hard strap and enables bifurcation, as well as configures a bunch of PCIe mux/switches to send the bifurcated lanes to the x8 slot. Together they reconfigure the CPU's PCIe lanes into two x8 slots. But wait, there's more. p8z77-v and sabertooth_z77 have a third PCIe x4 slot serviced by the PCH, but the 4 lanes are shared with some other x1 slots and devices. They can configure the PCIe x4 slot to really be x4, or the 4 lanes can be configured as 4 x1 ports for various x1 slots or onboard devices. This requires changing a soft strap as well as manipulating some GPIOs in the SIO chip, and the devicetree changed to match. I have the SIO GPIO part figured out, the soft strap I can only come to one possible explanation: reflash SPI descriptor with the changed soft strap and force a platform reset. To verify I'll need to get a board and actually check the flash chip for changes. But how do I manage the devicetree dynamically? Say for sabertooth I'll want to turn on PCH PCIe root port 1 only if it is set for x4, otherwise I'll need all ports 1-4 on so its three PCIe x1 slots can work along with the x4 slot now being x1 only. Thanks Keith

2 1

Calling all Asus P8x7x board owners, and Q about NCT5535D
by Keith Hui 24 Dec '24

24 Dec '24

Hello, I recently got my hands on boardviews of many Asus P8x7x series mainboards, and some offshoots such as Z77-A and Sabertooth Z77, and have also found a way to extract VBT data and the USB port config out of the vendor firmware image (which isn't really a straight image, but what looks like an update capsule), allowing me to attempt something quite ambitious given I only have the P8Z77-M on hand: Bring coreboot to the entire family. Again because I only have the vendor firmware image and boardview to go by, I will only be able to put out an untested new board patch, hence I am calling for anyone with these boards, that aren't already in the tree, to help me test them, and to get things I can't get out of firmware image, such as HDA verbs and GPIO setup, by running autoport on your board. Additionally, if you have a P8Z77-V (Hello Bill!), please test this patch: https://review.coreboot.org/c/coreboot/+/85413 And if you have a P8Z77-M PRO, please test your serial port, and if changing it to use serial port A like P8Z77-M does, make the serial port work. Now, during my survey of the board family, I found that: 1. They link their power LEDs to only one of two GPIOs on the PCH: 8 or 27. That's easily determined from the boardview. 2. Except for P8C WS which I can't get a boardview for, this family only uses one of two Nuvoton super I/Os: NCT5535D or NCT6779D. 6779 is well known, but I cannot find the datasheet for 5535, and the pinout for the closest thing I can find, NCT5532D, have the pins shifted by approximately 3 pins, and there may be more differences. Does anyone know anything about NCT5535D or can hook me up with a datasheet? Thanks Keith

2 2

2024-12-25 - coreboot Leadership Meeting Canceled
by mina＠coreboot.org 23 Dec '24

23 Dec '24

Hello coreboot, Please note that the leadership meeting scheduled for Wednesday, December 25, 2024, has been canceled as it falls on Christmas Day. Thank you for your understanding, and I wish you a joyous and merry Christmas. Best regards, Mina.

1 0

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

18 Dec '24

Issue #121 has been updated by Anastasios Koutian. Anastasios Koutian wrote in #note-100: > Have been using this change: https://review.coreboot.org/c/coreboot/+/78609 since it was merged (May 23) and haven't seen any freezes. > It's possible that this solves the issue. Can others confirm? Still no freezes since. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1995 * 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 #574] (New) Stack corruption in romstage on Intel platform (ADL-N) with recent builds
by Alicja Michalska 17 Dec '24

17 Dec '24

Issue #574 has been reported by Alicja Michalska. ---------------------------------------- Bug #574: Stack corruption in romstage on Intel platform (ADL-N) with recent builds https://ticket.coreboot.org/issues/574 * Author: Alicja Michalska * Status: New * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2024-12-17 * Affected versions: master ---------------------------------------- While building from master (testing CB:85609), I've noticed CBMEM complaining about stack corruption. Older build made a ~month ago did not experience the same issue. Maybe caused by Xeon-SP refactoring? `[INFO ] CBFS: Found 'fallback/romstage' @0x21d40 size 0x11c28 in mcache @0xfef8c28c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 465 ms [NOTE ] coreboot-24.08-922-gf9b4c5a996dc-dirty Mon Dec 16 23:28:48 UTC 2024 x86_32 romstage starting (log level: 8)... [ERROR] Stack corruption detected at eip: 0xffc74870 [DEBUG] pm1_sts: 0000 pm1_en: 0000 pm1_cnt: 00001c00 [DEBUG] gpe0_sts[0]: 00000000 gpe0_en[0]: 00000000 [DEBUG] gpe0_sts[1]: 00000000 gpe0_en[1]: 00000000 [DEBUG] gpe0_sts[2]: 00000000 gpe0_en[2]: 00000000 [DEBUG] gpe0_sts[3]: 00000000 gpe0_en[3]: 00000000 [DEBUG] TCO_STS: 0000 0000 [DEBUG] GEN_PMCON: d8a01a78 00002200 [DEBUG] GBLRST_CAUSE: 00000002 00000000 [DEBUG] HPR_CAUSE0: 00000002 [DEBUG] prev_sleep_state 0 (S0) [INFO ] OC Watchdog: disabling watchdog timer [DEBUG] Abort disabling TXT, as CPU is not TXT capable. [SPEW ] CBFS DEBUG: _cbfs_alloc(name='fspm.bin', alloc=0x00000000(0xfef87e98), force_ro=false, type=-1) [DEBUG] FMAP: area COREBOOT found @ c50200 (3866112 bytes) [INFO ] Fixed Decode Window: SPI flash base=0x600000, Host base=0xff600000, Size=0xa00000 [INFO ] CBFS: Found 'fspm.bin' @0x58dc0 size 0xc0000 in mcache @0xfef8c414 [DEBUG] FMAP: area RW_MRC_CACHE found @ c00000 (65536 bytes) [SPEW ] MRC cache found, size 63176 bytes [SPEW ] bootmode is set to: 2 (boot assuming no config change)` -- 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_12_18 coreboot Group Review Sesssion
by mina＠coreboot.org 16 Dec '24

16 Dec '24

Hello coreboot! We are pleased to announce that our upcoming review session is scheduled for Wednesday, December 18, 2024: https://meet.google.com/kpu-yozw-gtt As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here is the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…). Kindly add any specific patches you'd like the group to review to the top of the sheet. Thank you. Best regards, Mina.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
3977
Older →

Jump to page:

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