coreboot October 2024

coreboot@coreboot.org

17 participants
18 discussions

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 14 Oct '24

14 Oct '24

Dear coreboot community, Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, October 16, 2024.[1] Kindly take a moment to review the current agenda and share your thoughts or suggest any additional items you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda Items ### [dhendrix] Should we add something in the code of conduct about autism or other conditions that may warrant limited exceptions? * This is something Angel brought up in the e-mail thread regarding a recent disciplinary action. A reasonable accommodation may be good to carve out. That leaves some open questions, however, like how do we know that somebody is really having this condition (e.g. doctor's note?) and not using it as an excuse? Also, what would such accommodations look like? SFC has offered to get us in touch with their director of DEI who can help craft policy for this sort of thing ### [Sheng] Coreboot documentation automation build has been broken for ages. What has to be done to fix it? ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #455] superiotool detects Aspeed AST2400 instead of Nuvoton NCT6779D
by Walter Sonius 13 Oct '24

13 Oct '24

Issue #455 has been updated by Walter Sonius. Quick and dirty fix! The same issue on MSI H87-G43 (ms7816 rev1.2) appears, although NCT6779D is supported however not the specific model with ID`0xc563`. In the "nuvoton.c" source file from the "superiotool" alter the ID on line number 551 from `0xc562` to `0xc563`. Since I don't know how to add an extra ID/condition to the source file, this will break detection for someone with the `0xc562` chip. Can someone please do pull request for superiotool? https://github.com/coreboot/coreboot/blob/main/util/superiotool/nuvoton.c ` {0xc562, "NCT6779D", {` replace with ` {0xc563, "NCT6779D", {` The first time using `superiotool` without this fix, it will detect wrongly the Aspeed chipset just like the Original Poster reports but returns `chip_id=0xc563` hinted multiple times. Subsequent runs of the `superiotool` won't find any chipset anymore but will end with `No Super I/O found`... ``` uname -a Linux ubuntu-mate 6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 2 20:41:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux sudo dmesg | grep H87 [ 0.000000] DMI: MSI MS-7816/H87-G43 (MS-7816), BIOS V2.9 07/16/2014 sudo superiotool -l | grep 6779 Nuvoton NCT6775F (A) (dump available) Nuvoton NCT6775F (B) / NCT5572D (B) (not all LDNs supported) (dump available) Nuvoton NCT6776F (B) (dump available) Nuvoton NCT6776F/D (C) (dump available) Nuvoton NCT6779D (dump available) <---------------Partly supported sudo superiotool -aV superiotool r Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Aspeed Super I/O at 0x2e... Failed. Returned data: scratch registers all read as 0xff Probing for Aspeed Super I/O at 0x4e... Found Aspeed AST2400 (id=0x00) at 0x4e <----------------Wrong Probing for Exar Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Exar Super I/O at 0x4e... ... truncated output... Probing for Nuvoton Super I/O at 0x164e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x2e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Failed. Returned data: chip_id=0xc563 <------------------------Hint Probing for Nuvoton Super I/O (sid=0xfc) at 0x4e... ...truncated... ``` Fixed superiotool output, replaced line 551 ID c562 > c563 and it will dump/report registers: ``` sudo ./superiotool -dV superiotool r Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Aspeed Super I/O at 0x2e... Failed. Returned data: scratch registers all read as 0xff Probing for Aspeed Super I/O at 0x4e... Failed. Returned data: scratch registers all read as 0xff ...truncated... Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Found Nuvoton NCT6779D (id=0xc563) at 0x4e Register dump: idx 10 11 13 14 1a 1b 1c 1d 20 21 22 24 25 26 27 28 2a 2b 2c 2f val ff ff ff ff 30 70 08 00 c5 63 ff 04 00 40 00 00 40 00 00 0b def ff ff 00 00 30 70 10 00 c5 62 ff 04 00 MM 00 00 c0 00 01 MM LDN 0x01 (Parallel Port) idx 30 60 61 70 74 f0 val 01 03 78 05 04 3c def 01 03 78 07 04 3f LDN 0x02 (UART A) idx 30 60 61 70 f0 f2 val 01 03 f8 04 00 00 def 01 03 f8 04 00 00 LDN 0x03 (UART B, IR) idx 30 60 61 70 f0 f1 f2 val 00 02 f8 03 00 00 00 def 01 02 f8 03 00 00 00 LDN 0x05 (Keyboard Controller) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 83 def 00 00 00 00 00 00 00 83 LDN 0x06 (CIR) idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 08 09 32 00 def 00 00 00 00 08 09 32 00 LDN 0x07 (GPIO6, GPIO7, GPIO8) idx e0 e1 e2 e3 e4 e5 e6 e7 ec ed f4 f5 f6 f7 f8 val 73 0f 00 0f ff ff ff ff 00 ff ff ff ff ff ff def 0f 00 00 00 ff 00 00 00 00 00 ff 00 00 00 00 LDN 0x08 (WDT1, GPIO0, GPIO1) idx 30 60 61 e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 val 00 00 00 ff ff ff ff ff ff d8 00 00 00 ff 00 ff def 00 00 00 ff 00 00 00 00 ff 00 00 00 00 00 00 00 LDN 0x09 (GPIO1, GPIO2, GPIO3, GPIO4, GPIO5, GPIO6, GPIO7, GPIO8) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ee f0 f1 f2 f4 f5 f6 f7 fe val be df 60 00 60 7f 06 00 06 00 00 00 c0 00 ff 00 00 3f 00 00 c0 00 def 00 ff 00 00 00 7f 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 00 00 LDN 0x0a (ACPI) idx e0 e1 e2 e3 e4 e5 e6 e7 e9 ee f0 f2 f3 f4 f6 f7 fe val 01 00 00 15 08 02 5c 00 00 00 10 5c 00 00 00 c0 00 def 01 00 00 00 00 02 1c 00 00 00 10 5c 00 00 00 c0 00 LDN 0x0b (Hardware Monitor, Front Panel LED) idx 30 60 61 62 63 70 e0 e1 e2 e4 f0 f1 f2 f5 f6 f7 f8 f9 fa val 01 0a 00 0a 10 00 7f 7f ff 7f 00 00 00 00 00 87 47 00 00 def 00 00 00 00 00 00 7f 7f ff ff 00 00 00 10 00 87 47 00 00 LDN 0x0d (WDT1) idx f0 val 00 def 00 LDN 0x0e (CIR WAKE-UP) idx 30 60 61 70 val 00 00 00 00 def 00 00 00 00 LDN 0x0f (GPIO Push-Pull or Open-drain) idx e0 e1 e2 e3 e4 e5 e6 e7 e9 f0 f1 f2 val ff df 7f ff ff ff 7b ff ff 9d 00 00 def ff ff 7f ff ff ff 0f ff ff 9d 00 00 LDN 0x14 (Port 80 UART) idx e0 e1 e2 e3 e4 val 80 00 00 10 00 def 80 00 00 10 00 LDN 0x16 (Deep Sleep) idx 30 e0 e1 e2 val 20 20 04 05 def 20 20 04 05 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff ...truncated... ``` Other debug info related to lm_sensors and this specific chipset. ``` sudo sensors-detect #truncated output Found `Nuvoton NCT5532D/NCT6779D Super IO Sensors' Success! (address 0xa00, driver `nct6775') Driver `nct6775': * ISA bus, address 0xa00 Chip `Nuvoton NCT5532D/NCT6779D Super IO Sensors' (confidence: 9) sudo modprobe nct6775 sudo dmesg | tail -n 1 [ 506.259692] nct6775: Found NCT6779D or compatible chip at 0x4e:0xa00 sensors radeon-pci-0100 Adapter: PCI adapter temp1: +35.0 C (crit = +120.0 C, hyst = +90.0 C) acpitz-acpi-0 Adapter: ACPI interface temp1: +27.8 C temp2: +29.8 C nct6779-isa-0a00 Adapter: ISA adapter Vcore: 872.00 mV (min = +0.00 V, max = +1.74 V) in1: 1.04 V (min = +0.00 V, max = +0.00 V) ALARM AVCC: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM +3.3V: 3.39 V (min = +0.00 V, max = +0.00 V) ALARM in4: 1.10 V (min = +0.00 V, max = +0.00 V) ALARM in5: 848.00 mV (min = +0.00 V, max = +0.00 V) ALARM in6: 1.06 V (min = +0.00 V, max = +0.00 V) ALARM 3VSB: 3.44 V (min = +0.00 V, max = +0.00 V) ALARM Vbat: 3.31 V (min = +0.00 V, max = +0.00 V) ALARM in9: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in10: 24.00 mV (min = +0.00 V, max = +0.00 V) ALARM in11: 0.00 V (min = +0.00 V, max = +0.00 V) in12: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in13: 752.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 784.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 0 RPM (min = 0 RPM) fan2: 1010 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) SYSTIN: +27.0 C (high = +0.0 C, hyst = +0.0 C) ALARM sensor = CPU diode CPUTIN: +127.5 C (high = +80.0 C, hyst = +75.0 C) ALARM sensor = CPU diode AUXTIN0: +22.0 C sensor = thermistor AUXTIN1: +127.0 C sensor = thermistor AUXTIN2: -128.0 C sensor = thermistor AUXTIN3: -52.0 C sensor = thermal diode PECI Agent 0: +31.0 C PCH_CHIP_CPU_MAX_TEMP: +0.0 C PCH_CHIP_TEMP: +0.0 C PCH_CPU_TEMP: +0.0 C PCH_MCH_TEMP: +0.0 C PCH_DIM0_TEMP: +0.0 C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled coretemp-isa-0000 Adapter: ISA adapter Package id 0: +32.0 C (high = +80.0 C, crit = +100.0 C) Core 0: +30.0 C (high = +80.0 C, crit = +100.0 C) Core 1: +32.0 C (high = +80.0 C, crit = +100.0 C) ``` ---------------------------------------- Bug #455: superiotool detects Aspeed AST2400 instead of Nuvoton NCT6779D https://ticket.coreboot.org/issues/455#change-1941 * Author: shen Liu * Status: New * Priority: Normal * Category: userspace utilities * Target version: master * Start date: 2023-02-07 * Affected versions: master * Needs backport to: none * Related links: More discussion： https://www.reddit.com/r/coreboot/comments/10ud7tk/is_b85me45_ms7817_suppor… https://wiki.archlinux.org/title/Debuginfod * Affected hardware: MSI B85M-E45 * Affected OS: Manjaro Linux 22.0.2 (Kernel ver:6.1.9-1) ---------------------------------------- ``` shell sudo ./superiotool Found Aspeed AST2400 (id=0x00) at 0x4e sudo ./superiotool superiotool r4.19-306-g12ec7901b7 No Super I/O found ``` Does superiotool provide debug symbols? Without debug symbols I can't use gdb to provide more useful information. -- 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 Meetings Announcement And Agenda Call
by mina＠coreboot.org 11 Oct '24

11 Oct '24

Dear coreboot community, Please note that our upcoming leadership meeting is scheduled for Wednesday, October 16, 2024.[1] Kindly take a moment to update the current agenda with matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante.

1 0

2024_10_09 coreboot Group Review Session
by mina＠coreboot.org 07 Oct '24

07 Oct '24

Hello coreboot! Our next group review session is scheduled for Wednesday, October 9, 2024: https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html 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’s 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. Given the limited time for our session, any reviews completed beforehand would be greatly appreciated. Thank you. Best regards, Mina.

1 0

Recent disciplinary action taken
by David Hendricks 05 Oct '24

05 Oct '24

Dear coreboot community members, Recently there was some unpleasant activity on Gerrit which violated our community’s guidelines regarding respectful conduct. In this case the coreboot leadership team determined that the behavior in question fit a long pattern about which the individual had been previously warned. As a result we have decided to remove Nico from our community for a period of 1 year. We hope this will be a sufficient cooling off period and that we will not need to take more drastic steps in the future. As we've said in the past, we trust that developers in our community are acting in good faith and can generally resolve issues on their own. In cases where two sides cannot reach an agreement, for example in a code review, we expect all engagement to be respectful and to help drive toward a solution. For technical matters this often means starting a mailing list discussion, bringing an issue up during the coreboot leadership meeting, starting a task force to tackle a large problem, or other means of gathering input and collaborating. Personal matters should be brought to the leadership team directly. We'll listen to any complaints or frustrations, but cannot tolerate personal attacks made on Gerrit, the mailing list, or other forums. It is always required that we treat others in a professional manner and communicate with respect, regardless of how strongly we may feel about a particular issue. If anybody feels that a discussion has become too heated, or that somebody is not being treated respectfully, or are simply unsure of how to proceed in a difficult situation, please reach out to the coreboot leadership and we will chart a path forward together.

11 16

Project departure announcement: Arthur Heymans
by Arthur Heymans 04 Oct '24

04 Oct '24

Hi In light of a recent decision by the coreboot leadership, I would like to announce my departure from the project. I believe the one-year ban of Nico Huber is unjust and a poor decision for the community. Unless professional reasons compel me otherwise, I will be leaving the project for at least the same amount of time. Most of what I did this year was done in my free time. Out of the 104 patches I submitted to main since January, Nico reviewed 49. From a practical standpoint, this is a disaster. I do want to end this chapter on a positive note. I learned so much from this community and have had an incredible experience to be part of it, so thank you a million times! Interacting with this community has been a blast! Learning from people and giving back to others is one of the most rewarding things one can do in life. That's why I believe the future of firmware must be open source. The communities that form around such software align so well with our deep human nature. I think open-source firmware has a really bright future ahead, and I hope to be part of it somehow. I have a cool firmware project in the pipeline that I look forward to sharing one day. Thanks a lot and good luck! Arthur

1 0

Re: Recent disciplinary action taken
by AreYouLoco? 03 Oct '24

03 Oct '24

Hi, I am following project since few years. Happy coreboot user here. And I was hesitating but finally I decided to post to the list. Banning core developer for 1 year because of some disagreements sounds a bit harsh to me. Especially that I used to post questions on the IRC channel and mailing list and Nico was the only that actually took my personal struggles building coreboot as well as helped fixing one issue. If not that I would probabbly pass and walk away from actually using coreboot. And now I recommend it to others. Its not defending. I just would like to express my personal experience here. That we are people. We make mistakes. If someone is not behaving maybe the person has some bad-bad day. Some kind of consecuence should be taken. Because without that we wont learn. Am I wrong? Bit still one year ban seems harsh to me. Thats it. Just my 2 cents. Orest, aka AreYouLoco? On October 3, 2024 2:05:12 PM UTC, coreboot-request(a)coreboot.org wrote: >Send coreboot mailing list submissions to > coreboot(a)coreboot.org > >To subscribe or unsubscribe via email, send a message with subject or >body 'help' to > coreboot-request(a)coreboot.org > >You can reach the person managing the list at > coreboot-owner(a)coreboot.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of coreboot digest..." > >Today's Topics: > > 1. Re: Recent disciplinary action taken (Sergii Dmytruk) > 2. Re: Recent disciplinary action taken (Angel Pons) > 3. 2024-10-02 - coreboot Leadership Meeting Minutes > (mina(a)coreboot.org) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 2 Oct 2024 15:03:42 +0300 >From: Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com> >Subject: [coreboot] Re: Recent disciplinary action taken >To: Arthur Heymans <arthur(a)aheymans.xyz> >Cc: coreboot(a)coreboot.org >Message-ID: <Zv02njwrZB-HiR0K@MjU3Nj> >Content-Type: text/plain; charset=utf-8 > >Hi > >I second that. First Nico was banned from flashrom, now from coreboot. >I saw no real basis for the previous decision and see none for this one. >I even thought of him being overly nice in our recent interactions. > >In general, he seems to care much more about the projects than many >others and actually put in the effort. This can result in having strong >opinions and disagreements, but that's not a bad thing. > >Regards, >Sergii > >On Wed, Oct 02, 2024 at 11:55:55AM +0200, Arthur Heymans wrote: >> Hi >> >> I am not happy with this decision. >> We are a community with a lot of passionate individuals that differ in >> their communication style. >> Differences in communication styles cause friction, there is no way around >> it. >> Commenting beyond the mere technical on how we treat each other in a >> community is appropriate and not a violation of respectful conduct. >> To the contrary, sometimes a more heated discussion is to be preferred to >> be being "nice" all the time. >> >> I remember on one of my first patches in 2016, that Nico commented that the >> code looked so bad he wanted to cry. >> It's not "nice" but it was really bad code and I learned a lot since then, >> thanks to the honest and truthful communication of the community. >> More direct communication is preferred by lot of people, including myself. >> >> I believe Nico is a good actor in our community and a 1 year ban does more >> harm than good. >> I personally thoroughly enjoy having him as a reviewer. >> >> I ask the leadership to revisit this decision. Coreboot is a hard project >> to get into and driving the most competent people away is not a smart move. >> >> Arthur >> >> On Wed, Oct 2, 2024 at 9:40 AM David Hendricks via coreboot < >> coreboot(a)coreboot.org> wrote: >> >> > Dear coreboot community members, >> > >> > Recently there was some unpleasant activity on Gerrit which violated our >> > community’s guidelines regarding respectful conduct. In this case the >> > coreboot leadership team determined that the behavior in question fit a >> > long pattern about which the individual had been previously warned. As a >> > result we have decided to remove Nico from our community for a period of 1 >> > year. We hope this will be a sufficient cooling off period and that we will >> > not need to take more drastic steps in the future. >> > >> > As we've said in the past, we trust that developers in our community are >> > acting in good faith and can generally resolve issues on their own. In >> > cases where two sides cannot reach an agreement, for example in a code >> > review, we expect all engagement to be respectful and to help drive toward >> > a solution. For technical matters this often means starting a mailing list >> > discussion, bringing an issue up during the coreboot leadership meeting, >> > starting a task force to tackle a large problem, or other means of >> > gathering input and collaborating. >> > >> > Personal matters should be brought to the leadership team directly. We'll >> > listen to any complaints or frustrations, but cannot tolerate personal >> > attacks made on Gerrit, the mailing list, or other forums. It is always >> > required that we treat others in a professional manner and communicate with >> > respect, regardless of how strongly we may feel about a particular issue. >> > >> > If anybody feels that a discussion has become too heated, or that somebody >> > is not being treated respectfully, or are simply unsure of how to proceed >> > in a difficult situation, please reach out to the coreboot leadership and >> > we will chart a path forward together. >> > _______________________________________________ >> > coreboot mailing list -- coreboot(a)coreboot.org >> > To unsubscribe send an email to coreboot-leave(a)coreboot.org > >------------------------------ > >Message: 2 >Date: Wed, 2 Oct 2024 14:27:00 +0000 >From: Angel Pons <th3fanbus(a)gmail.com> >Subject: [coreboot] Re: Recent disciplinary action taken >To: David Hendricks <dhendrix(a)coreboot.org> >Cc: coreboot(a)coreboot.org >Message-ID: > <CABqd-o1X8o+V9WGvQ34SajWRkwS1ONQpRNhxkB06rA29v8rwVA(a)mail.gmail.com> >Content-Type: multipart/alternative; > boundary="0000000000001580ce06237f3ca0" > >Hello list, > >On Wed, Oct 2, 2024 at 7:40 AM David Hendricks via coreboot < >coreboot(a)coreboot.org> wrote: > >> Dear coreboot community members, >> >> Recently there was some unpleasant activity on Gerrit which violated our >> community’s guidelines regarding respectful conduct. In this case the >> coreboot leadership team determined that the behavior in question fit a >> long pattern about which the individual had been previously warned. As a >> result we have decided to remove Nico from our community for a period of 1 >> year. We hope this will be a sufficient cooling off period and that we will >> not need to take more drastic steps in the future. >> >David, I see you are one of the three members of the leadership team [1]. >Could you please provide the following, privately if necessary? > > - the minutes for the meeting in which the decision was made (which might >contain references to the documents below; if the meeting minutes are not >available, I would like to know why) > - links to the aforementioned "unpleasant activity on Gerrit" > - the guidelines from [2] or [3] (I could not find a document called >"community guidelines") that were violated > >Not knowing what happened nor why makes me afraid to contribute, lest the >same fate befall me as well. Especially considering that Nico has been a >role model for me as I was learning the ropes of firmware development, so >most of the things about coreboot as well as authoring and reviewing >changes I have learned from him. > >> As we've said in the past, we trust that developers in our community are >> acting in good faith and can generally resolve issues on their own. In >> cases where two sides cannot reach an agreement, for example in a code >> review, we expect all engagement to be respectful and to help drive toward >> a solution. For technical matters this often means starting a mailing list >> discussion, bringing an issue up during the coreboot leadership meeting, >> starting a task force to tackle a large problem, or other means of >> gathering input and collaborating. >> >> Personal matters should be brought to the leadership team directly. We'll >> listen to any complaints or frustrations, but cannot tolerate personal >> attacks made on Gerrit, the mailing list, or other forums. It is always >> required that we treat others in a professional manner and communicate with >> respect, regardless of how strongly we may feel about a particular issue. >> >A tiny remark about professional manner: when interacting with others I >know, I like sprinkling a bit of humour in my messages, but without being >disrespectful towards anyone (no dark humour and no making fun of others) >or compromising my knowledge/abilities (do not overdo it and consider that >not everyone might get it). I believe this does not make me unprofessional, >but I am happy to listen in case anyone disagrees. > >Other than that, I agree with the above, but I also believe it is important >to be aware that misunderstandings can and will happen, especially >considering that people from all over the world can contribute, each with >their own culture and tradition. Not everyone is a native English speaker >(even if it does not seem like it, I am not). Not everyone is capable of >noticing when a discussion is getting too heated/tense, let alone do >something to end it before it is too late (I am trying to get better at >this). Not everyone communicates the same way, e.g. autistic people tend to >communicate in direct and literal ways that can be misinterpreted by >non-autistic people [4] (I am autistic, I have had this happen before), >whereas other autistic people have no issues with this communication style. > >I believe that the information in [4] (especially the list of 12 rules) is >valuable and I would appreciate having them integrated into our own >guidelines, although I agree they should be guidelines rather than >strictly-enforced rules: misunderstandings are *still* inevitable and will >happen. In case of a misunderstanding, I think the most sensible way to >proceed is for someone (preferably one of the participants) to notice that >"something feels wrong" and remain calm, disengaging from the discussion if >needed (e.g. wait before replying to an email or review comment). If >possible, try to bring it up without pointing fingers, e.g. "I feel this >discussion is heating up: is there anything I can do to help, or am I >reading into things?" or (quoting a response) "This sounded quite rude to >me, was it intentional?". This requires being able to recognise that >tension is building up and restraining one's impulses; I understand this is >not trivial to accomplish, especially if one is susceptible to getting >angry (e.g. me). > >> If anybody feels that a discussion has become too heated, or that somebody >> is not being treated respectfully, or are simply unsure of how to proceed >> in a difficult situation, please reach out to the coreboot leadership and >> we will chart a path forward together. >> _______________________________________________ >> coreboot mailing list -- coreboot(a)coreboot.org >> To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > >Best regards, >Angel > >[1]: https://www.coreboot.org/leadership.html >[2]: https://doc.coreboot.org/community/code_of_conduct.html >[3]: https://doc.coreboot.org/contributing/gerrit_guidelines.html >[4]: >https://warwick.ac.uk/services/socialinclusion/projects/letstalkaboutdisabi… >

1 0

2024-10-02 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 03 Oct '24

03 Oct '24

# 2024-10-02 - coreboot Leadership Meeting ## Attendees Felix Held, Alicja Michalska, David Hendricks, Matt DeVillier, Maximilian Brune, Werner Zeh, Mina Asante, Martin Roth, Jonathon Murphy, Felix Singer, Julius Werner, Karthik Ramasubramanian, Jeremy Compostella. ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out invitations for this meeting. * Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico:(https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [jpmurphy] Have we solicited or received feedback on why organizations choose not to use coreboot? * Have we solicited or performed technical analysis of how we compare to other solutions or what features may be missing? * David: Were we supposed to set up a meeting to discuss ideas? * Intel was pushing slimboot - BSD licensed. * Do we know how much slimboot is used? * Werner: 2 years ago it was being used because of the license reason. More than 90% of contributions were made by intel employees. The main intel contributor has left the project. It doesn’t look like there’s a community there at all. No guarantee that the project will persist if intel decides to drop it. Based on the BSD license there’s not much of a chance that a healthy community will evolve. With intel’s current financial issues, it’s even less likely. * Max: I’m not hearing anything about slimboot anymore. * Martin: Inertia * Martin: UEFI is more expected, has larger IBVs. * The silicon vendors push the IBVs - AMI, Insyde, Phoenix. * ODMs just go with their relationships with the IBVs. * Developing on your own is hard * Complexity/inflexibility of FSP. It's hard to justify coreboot + FSP when FSP requires its own set of custom patches and hacks to change its default behavior. * Alicja: I believe we need something that can configure the platform options at runtime (writing to CMOS/SMMSTORE) instead of setting options at build time, many people using Chromebooks with Matt's builds complain about "lack of features". * Can anyone look further into this? ### [Werner] Present the workflow for Feature Request and Implementation which is an outcome of one of the OSFF’s workstreams. * There are tasks around streamlining feature implementation requests to make it more plannable for business use cases. Werner took it as an AI. Website: (https://opensourcefirmware.foundation/workstreams/feature-request-flow/) Specification: (https://drive.google.com/file/d/1su3s93xNgqy9AixDfHEWGrB_1nxYbQoz/view) * This process has been reviewed by a number of coreboot and OSFF community members from a number of companies. * This would not be required to add a feature, but is intended simply to help the project and feature implementers work through the process. * The point of this is to provide a timeline and a better guarantee that the feature would be accepted by the community. * Felixh: Who is doing the work to implement the feature? * This is not restricted by the process. Most of the time it would be the requester. * Felixh: The “guarantee” of acceptance is very concerning. I’m worried that companies will demand that their patches get rubber stamped. * That’s absolutely not guaranteed by this process. The idea is that a specification would be agreed upon, to facilitate the merging of features. The time to reject a feature is early in this * Max: Who decides when to transition between phases? * Werner: It differs between phases. One way is when the community and requester are in sync. In the implementation phase if the feature complies with the design document (this is decided by the implementation team). There are also suggested timelines. * Max: There are a number of feature patches where the idea is good, but the implementation doesn’t fit coreboot well. How do we avoid merging poor patches? * Werner: That’s why the community needs to be involved in the implementation phase. Full features shouldn’t just be dropped into the tree. * David: Agreed, even if an implementation isn’t perfect, it may be better to get it in then fix it rather than just letting it bitrot. * FelixH: If things are being done behind closed doors, this process may not work. * Martin: Behind closed doors should be a big exception. Let’s see how this goes. * Werner: I can look at creating a feature design template from the OSFF. We can also have a dashboard of features that are ongoing and what phase they’re in. There are a lot of things to improve in the ecosystem. * Martin: How to give feedback: * Werner: Send an email or review on the google [doc](https://docs.google.com/document/d/1zZvnoJwAKX7bm80UxPwnHMfelvoqoYbxR1…. Feedback is welcome. ### [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach. * 2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id. * Jon: We’re going to try to make the bugs public and update gerrit. Can we add a rule to link to the bug? * Martin will work with the other admins to make this work. * CrosBug? * BUG=b:? * CB-Bug - For coreboot bugs? * Werner: Please respond to the poll about how to respond to coverity issues. * (https://rallly.co/invite/1c8J3azXAcje) ### David: We had to take an action with a community member’s behavior. Details are on the mailing list. David will respond to various questions on the mailing list. * If anyone is feeling anxiety about dealing with other people in the community, *please* reach out. You can email anyone on the leadership team or the arbitration team. These issues will be kept confidential. (https://coreboot.org/leadership.html) ### Granite rapids patches are out! Great job getting these out before the chip is out. * FelixH: These are great and very appreciated. It’s obvious that a lot of work went into trying to improve things. # Next Leadership Meeting * October 16, 2024. * [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.

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 October 2024