Hi Paul,
My responses are inline.
Feb 19, 2024, 15:26 by pmen...@molgen.mpg.de:
> Dear coreboot folks,
>
>
> Am 19.02.24 um 22:24 schrieb mina--- via coreboot:
>
> […]
>
>> ### [Nico] Revoking Gerrit privileges as punishment.
>> I would like to discuss two matters about this. Not sure about the
Hey Mike,
I think you should be able to just append change the kconfig values when you
run make to override the current settings.
something like
`make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0`
if we update where they're set in the makefile from := to ?=, you could even
just
Hey Simon, I think this is a good summary of the current situation, though the
table doesn't come through in the text version of the email at all. Maybe
upload an RFC to the documentation directory so it can be commented on in
gerrit?
As I mentioned in the leadership meeting, I have concerns
I'll work on running things through jenkins again, but it's going to take a
while to get all of the patches done. If anyone has a specific patch they need
to get verified, rebasing it on top of the main branch is a good way to get
jenkins to pick it up again.
*Please* do not rebase huge patch
Hey Jeremy, I retriggered the build. I thought that at one point we had it set
up so that anyone could retrigger the builds, but that doesn't seem to be the
case anymore. Let me see if I can fix that.
Martin
Sep 6, 2023, 16:38 by jeremy.composte...@intel.com:
> Hi,
>
> It happened to me a
Hi Hannah, Thanks for the update.
Presumably the HDMI source isn't required in the uGOP driver for chromebooks,
so that shouldn't be a problem. With chromebooks, only the eDP should need to
be initialized to show signs-of-life.
I guess the only thing I really see happening at this point is for
Hi Jeremy,
I've added it to the agenda for today's leadership meeting.
Martin
Sep 5, 2023, 15:30 by jeremy.composte...@intel.com:
> Hi,
>
> Any feedback on this topic ?
>
> I made some significant changes and made sure to cover all the cases
> we identified including non-XIP stages. Cf.
>
Hi Jeremy and all the rest of the Intel folk who took the time to come to the
coreboot meeting today. I wasn't thrilled with the message you were there to
present, but I was happy to see all who attended.
I may be incorrect, but I assume that Google has been talking with Intel about
Hi Jeremy,
Thanks for posting this. I know that you're planning on doing a presentation
about this in this week's leadership meeting and look forward to that.
https://coreboot.org/calendar.html
A few questions:
1) How does the uGOP driver work with libgfxinit? Does using uGOP mean that the
Issue #496 has been updated by Martin Roth.
Category set to Payloads
Bug #496: Missing malloc check in libpayload
https://ticket.coreboot.org/issues/496#change-1629
* Author: Keith Makan
* Status: New
* Priority: Normal
* Category: Payloads
* Target
Issue #495 has been updated by Martin Roth.
Subject changed from Stoney not booting PSPSecureOS -- Graphics driver takes 30
minutes to start to Stoney chromebooks not booting PSPSecureOS -- Graphics
driver takes 30 minutes to start
Status changed from Response Needed to Resolved
Patch
Hi Keith, Sorry about the late reply here. Responses inline:
Jul 25, 2023, 22:25 by buu...@gmail.com:
> After 34 patches converting all sandybridge boards to Haswell-style
> SPD info, I now need to run abuild to see if I missed any, To save
> time, space, and possibly wear on my SSD I only want
Issue #500 has been updated by Martin Roth.
Tracker changed from Bug to Feature
Assignee deleted (Patrick Georgi)
Changing to a feature request and unassigning from Patrick.
I believe this is currently working as designed. It could definitely be
extended, but I don't believe that the lack
Duplicated code between mainboards isn't a big issue in my opinion. It allows
the boards to be customized without worrying about other companies' mainboards.
We've tried to make mainboards as small as we can, and we can keep refactoring
things out where it makes sense.
If some common code fits
Issue #462 has been updated by Martin Roth.
Are you sure the 2nd DIMM is working? Since one of the two DIMMs works and the
other doesn't, it seems suspicious.
You might also want to try clearing the MRC Cache area. Your first boot log
said that it was trying stored timings, and those
Issue #455 has been updated by Martin Roth.
Subject changed from superiotool recognizes the wrong chip and doesn't work. to
superiotool detects Aspeed AST2400 instead of Nuvoton NCT6779D
Bug #455: superiotool detects Aspeed AST2400 instead
Issue #456 has been updated by Martin Roth.
Hashes for all of the tarballs, old and new have been added to the bottom of
the release notes.
Hashes for tarballs & signatures
Old tarballs:
- a1f9ec1252a3cc19f0b4ba1a2b9d66ea9327499cbeecebd85377db7d5c68
Issue #456 has been updated by Martin Roth.
Status changed from New to Feedback
New 4.19 tarballs have been pushed, but they use the same name. I updated the
release notes stating that they had been updated.
I looked at changing the name, but to do that, the actual release number needs
Issue #456 has been updated by Martin Roth.
I'll re-create the archive. I'd fixed the bug with the timestamps, but it must
not have been included in the script that generated these tarballs.
For naming, I'd rather not go with -2 unless we create a new tag. I think
something like coreboot
Issue #456 has been updated by Martin Roth.
Subject changed from coreboot 4.19 tarballs are unusable to coreboot 4.19
tarballs have bad timestamps
Bug #456: coreboot 4.19 tarballs have bad timestamps
https://ticket.coreboot.org/issues/456#change-1401
Have you tested with a battery installed? I'm imagining a hardware glitch on
shutdown that causes an EC failure. Many older desktop platforms wouldn't even
power on if there wasn't a CMOS battery installed.
Martin
Jan 16, 2023, 11:08 by flyingfishfin...@gmail.com:
> Morning,
> Just checking
Issue #314 has been updated by Martin Roth.
Status changed from New to Rejected
Not a coreboot bug. closing
Bug #314: Please disable 'administrator approval' on ticket.coreboot.org
https://ticket.coreboot.org/issues/314#change-1373
* Author: akjuxr3
Issue #326 has been updated by Martin Roth.
Status changed from New to Closed
No response to questions in the past year.
Closing.
Bug #326: raminit fails after 58188 review.coreboot.org
https://ticket.coreboot.org/issues/326#change-1372
* Author
Issue #335 has been updated by Martin Roth.
Status changed from New to Closed
No response to comments asking for clarification in over a year. Closing.
Bug #335: High prority bug causes bricking when tianocore and flash log console
used together
Issue #392 has been updated by Martin Roth.
Status changed from New to Response Needed
Is this fixed now? There was a revert of the patch that caused the problem,
but that was abandoned with a comment saying that another pair of patches fixed
the issue. Unfortunately, one of those two
Issue #436 has been updated by Martin Roth.
Status changed from New to Resolved
This is actually a much bigger question than just berknip. Many of the
coreboot "default" configs are not bootable, either due to requiring binaries
that are not redistributable.
I've added tha
Issue #440 has been updated by Martin Roth.
Status changed from New to Response Needed
I'm not able to reproduce it on a genuine linux system. I don't think it's
surprising that it wouldn't work on WSL as windows probably doesn't let the WSL
linux kernel get close to real hardware.
Can
Issue #445 has been updated by Martin Roth.
It's entirely possible that coreboot is violating some of the power-on timings
of that wifi module. This could cause it to work some of the time, but fail at
other times.
To fix this, or determine if this actually is a problem, someone would have
Issue #447 has been updated by Martin Roth.
Status changed from New to Closed
Subject changed from X9SAE-V No Post to X9SAE-V No Post - Need help recovering
board.
Tracker changed from Bug to Other
Hey, sorry about your board. Unfortunately, bad flashes and bad images happen.
We always
Issue #386 has been updated by Martin Roth.
Status changed from New to Closed
No update since Kyösti pointed out the issue in the boot log to indicate that
this is anything beyond incompatible dimms. Closing.
Bug #386: ASUS P8Z77-V LX2 - Raminit
Issue #343 has been updated by Martin Roth.
Status changed from New to Resolved
The patch https://review.coreboot.org/c/coreboot/+/64235 which was said to fix
the issue was merged on 2022-11-02.
Please reopen if the issue is still seen.
Bug
Issue #443 has been updated by Martin Roth.
Status changed from New to Resolved
Fixed in the latest toolchain.
Bug #443: acpica distfile changed
https://ticket.coreboot.org/issues/443#change-1358
* Author: Fabian Groffen
* Status: Resolved
* Priority
Issue #441 has been updated by Martin Roth.
Status changed from New to Closed
Closing as resolved.
Bug #441: [resolved]
https://ticket.coreboot.org/issues/441#change-1357
* Author: U dent
* Status: Closed
* Priority: Low
* Start date: 2022-11-27
Issue #432 has been updated by Martin Roth.
Status changed from Response Needed to Closed
Closing as not an issue in coreboot.
Bug #432: t440p reboots on suspend
https://ticket.coreboot.org/issues/432#change-1356
* Author: Josh R
* Status: Closed
Issue #19 has been updated by Martin Roth.
Some utilities and payload code still uses bare unsigned, but this is
completely fixed in the coreboot src/ directory.
There are unfortunately some false positives within names and comments, so the
lint test should be updated in addition to fixing
Issue #36 has been updated by Martin Roth.
Status changed from New to Closed
No updates in 7 years. Closing.
Please reopen if this is still an issue.
Bug #36: x201: stuck ec event
https://ticket.coreboot.org/issues/36#change-1354
* Author: Alexander
Issue #33 has been updated by Martin Roth.
Status changed from New to Closed
Closing as fixed.
Bug #33: cbmem utility fails on newer linux kernels "Failed to mmap /dev/mem:
Resource temporarily unavailable"
https://ticket.coreboot.org/issues
Issue #27 has been updated by Martin Roth.
Status changed from New to Closed
Marking as closed due to the last update being 7 years old. Please reopen if
we have a new update.
Bug #27: Windows doesn't like references in ACPI to objects that are only
Issue #20 has been updated by Martin Roth.
Affected versions 4.18 added
This was completed, but seems like it may now be broken again.
The command 'make test-toolchain' should tell you if the toolchain version you
are using is current, but currently reports that the toolchain is up-to-date
Issue #12 has been updated by Martin Roth.
Status changed from New to Closed
Closing as fixed.
Bug #12: Use of CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL is a mess
https://ticket.coreboot.org/issues/12#change-1349
* Author: Martin Roth
* Status: Closed
Issue #14 has been updated by Martin Roth.
Status changed from New to Closed
Closing due to No updates in 7 years. Please reopen if needed.
Feature #14: printout lenovo ec power cause register
https://ticket.coreboot.org/issues/14#change-1348
* Author
Issue #7 has been updated by Martin Roth.
Status changed from In Progress to Closed
No updates in 7 years. Closing.
Feature #7: gnawty support based on acer cb3-111
https://ticket.coreboot.org/issues/7#change-1347
* Author: Alexander Couzens
* Status
Issue #4 has been updated by Martin Roth.
Status changed from New to Closed
We've done a significant amount of work on coreboot's documentation over the
past 7 years.
Closing this as completed. If there is any additional documentation needed,
please file a new bug stating exactly what needs
Issue #387 has been updated by Martin Roth.
Status changed from New to Closed
Closing this issue. The framework chromebook will be supported in tree as
typical for chromebooks.
If other versions of the framework laptops are to be supported, someone can add
them to the tree, and we welcome
I wanted to see what people think about changing the indentation for
devicetree.cb files (including overridetree.cb and chipset.cb files)
We currently use tabs to indent, which my editor has set to 8 spaces across all
of coreboot, but these aren't C files, and maybe shouldn't be treated the
If it would help, we could supply a VM with each release that had the coreboot
toolchain pre-built. It's also possible to use the released docker images to
rebuild coreboot - those already contain the toolchain.
The advantages to both of these is that you'd be building in the environment
that
e that time too long, chip vendors aren't
going to want to add their chips to the tree. I'm not sure how to balance that.
Jan 3, 2023, 17:17 by gnu...@cyberdimension.org:
> On Tue, 3 Jan 2023 18:38:02 +0100 (CET)
> Martin Roth wrote:
>
>> Hi Denis,
>> - Responses i
Hi Denis,
- Responses inline
Jan 2, 2023, 17:16 by gnu...@cyberdimension.org:
> Hi,
>
> The MAINTAINERS file has the following:
>
>> PC ENGINES ALL MAINBOARDS
>> M: Piotr Król
>> M: Michał Żygowski
>> S: Supported
>> F: src/mainboard/pcengines/
>>
>
> But the commit
Issue #431 has been reported by Martin Roth.
Bug #431: fix src/arch/x86/smbios issues
https://ticket.coreboot.org/issues/431
* Author: Martin Roth
* Status: New
* Priority: Normal
* Assignee: Solomon Alan-Dei
* Category: coreboot common code
* Target
Issue #430 has been updated by Martin Roth.
Assignee set to Solomon Alan-Dei
Bug #430: Fix util/cbfstool coverity issues
https://ticket.coreboot.org/issues/430#change-1202
* Author: Martin Roth
* Status: New
* Priority: Normal
* Assignee: Solomon Alan
Issue #430 has been reported by Martin Roth.
Bug #430: Fix util/cbfstool coverity issues
https://ticket.coreboot.org/issues/430
* Author: Martin Roth
* Status: New
* Priority: Normal
* Category: userspace utilities
* Target version: none
* Start date
Felix,
If you've formed an opinion, maybe you want to take a break from submitting
for a bit to let others test out the new submission strategy?
For everyone else, I'd like to note that over the past year, Felix has hit
submit on more than 45% of all of the coreboot patches that have been
Issue #387 has been updated by Martin Roth.
Hey Jun, Please don't misunderstand any of this as hostility - it's definitely
not meant that way.
I think we all would like a framework coreboot port, and would be excited to
see it happen, but it takes quite a bit of work to get an initial port
Issue #387 has been updated by Martin Roth.
Can we find out who the framework laptops were supplied to? It's great that
these individuals have agreed to work on the port, but the coreboot community
as a whole hasn't signed up to support the framework laptop.
There are a number
Unfortunately, yabits hasn't really seen any updates since it was added as a
payload, so I think it's time to remove it.
If there's no objection, we can remove it as a payload after today's 4.17
release.
I don't believe this counts as deprecation, but if others feel otherwise, we
can announce
Hi He Chen,
You are absolutely welcome to use coreboot on your devices if your CPU is
supported. What processor are you using?
There's no specific requirement to become a coreboot vendor except to sell
devices with coreboot on them, and to email us to let us know so we can add
your company to
This didn't get any discussion when it was initially posted, so I want to make
sure there are no objections.
I'll post the notice of the removal in the 4.17 release notes unless there's a
reason to keep Ice Lake code around. This will be removed from the master
branch after the 4.19 release.
hat AMD does not care about the AGESA platforms supported in
> coreboot, since they don't produce that hardware anymore?
> Just making assumptions here. Anyway, improving that code is my intention
> given that I write patches for it ;-)
>
> Arthur
>
> On Tue, May 17, 2022 at 7:40 PM
May 17, 2022, 11:40 by coreboot@coreboot.org:
> Just my opinion, and I'm intentionally replying off list.
>
Oops. Or not. :-/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
Arthur, you are not making an argument that any vendor should release their
source code as opensource. I agree that all of this code should be reviewed,
but if we complain about code quality and lack of testing for open sourced
code, but don't for closed source, that's an argument against any
After reading what I've included below, I'm going to have to vote to keep the
guards.
Martin
May 16, 2022, 10:59 by david.hendri...@gmail.com:
> On Mon, May 16, 2022 at 8:59 AM ron minnich wrote:
>
>>
>> btw, sometimes this has gone the other direction ..
>>
The next quarterly release, 4.17 is targeted for May 30, 2022.
Additionally, at that time, we plan to update the release packages and version
numbers any of the coreboot branches which have been modified since they were
released. Going forward, this should happen anytime there's a new release.
Thanks Andy, I think that's totally reasonable.
Martin
Apr 26, 2022, 06:56 by andy.p...@sdcsystems.com:
> Felix wrote...
>
> >So, will you also step up as a maintainer for it?
> I’m going to reserve judgement on that until I see how things go with
> trying to get the existing coreboot code
Here's a list for coreboot.
https://review.coreboot.org/c/coreboot/+/63797
Martin
Apr 22, 2022, 18:46 by rminn...@gmail.com:
> oh oops the person doing that misunderstood me, we'll have to fix it
>
> On Fri, Apr 22, 2022 at 5:41 PM Martin Roth wrote:
>
>>
>&
gt;
>> (I'm not a Coreboot dev/maintainer, so apologies for commenting from the
>> peanut gallery...)
>>
>>
>> On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote:
>> > [...]
>> > 2) Decide on a set of criteria that we can use to evaluate whe
Apr 20, 2022, 14:49 by coreboot@gmail.com:
> # 2022-04-20 - coreboot Leadership
>
> ## Decisions
> * Martin will do an example of Kconfig where the platforms have been removed
> keep the mainboard names in the tree. When selected, it will show the branch
> where the platform is
Apr 16, 2022, 08:03 by nic...@gmx.de:
> It's always a trade-off. Is the Quark code really that bad that it
> is hard to keep it along?
>
I'm not particularly looking at removing the Quark code right now. I lobbied
early on to keep it in the tree. Really, I want 2 things out of this discussion.
Apr 16, 2022, 08:32 by nic...@gmx.de:
> Hi Sheng,
>
> On 16.04.22 11:01, Sheng Lean Tan wrote:
>
>> Personally I think moving Galileo soc to stable branch is a win-win
>> situation for all of us.
>>
>
> it looks like nobody is maintaining such a stable branch yet. Would you
> volunteer to
Hey Jack, no problem, let's start a new thread.
Apr 14, 2022, 14:56 by jrose...@chromium.org:
> Hoping I'm not derailing too far here: Could we consider modeling this based
> on > http://appdb.winehq.org> ? I.e., people can contribute test results per
> board, and upload things like "which
Apr 14, 2022, 14:06 by 0xl...@gmail.com:
> Hi Martin,
>
>> I think we all agree that it'd be good to have test racks that have all of
>> the boards in the coreboot repository for verification, however that's
>> currently not practical with the resources we have. The whole thing just
>> isn't
Apr 14, 2022, 14:18 by 0xl...@gmail.com:
> I'm sending an email directly to the board committer since nobody has
> mentioned the history and is responding to my idea a lot.
> Lee, do you still have your quark galileo board? Are you at all able to test
> a new build or package equipment to
Apr 12, 2022, 10:25 by insu...@riseup.net:
>
> On 4/12/22 10:17, Nico Huber wrote:
>
>> Hello Insurgo,
>>
>> On 12.04.22 16:01, Insurgo Technologies Libres / Open Technologies wrote:
>>
>>> On April 12, 2022 8:55:56 AM UTC, Arthur Heymans
>>> wrote:
>>>
> Would it make sense to backport
Apr 13, 2022, 06:10 by 0xl...@gmail.com:
> On Wed, Apr 13, 2022, 6:26 AM Patrick Georgi <> patr...@coreboot.org> > wrote:
>
>> Am 12.04.2022 um 23:54 schrieb Karl Semich:
>> > Obviously a way to sidestep all this would be to simply test the board
>> > in question, which is a small investment
Apr 12, 2022, 12:14 by f...@mniewoehner.de:
> On Mon, 2022-04-11 at 22:23 +, Peter Stuge wrote:
>
>> Martin Roth via coreboot wrote:
>> > 1) Please don't use the term deprecate - use "moved to a branch"
>>
>> I don't think the wording matters,
Hey Mike, Sameer,
Sorry, I'd missed this thread until now.
I've got a patch train that rebases all of of the coreboot patches onto the
latest official memtest86+ version. I can upload that as a branch.
I'm currently working on doing the reverse, and making patches to push into the
TLDR:
1) Please don't use the term deprecate - use "moved to a branch"
2) Lets set up some rules about moving platforms/chips to a branch.
3) How do we find out what platforms are actually in use?
4) Please don't take this as an argument.We
---
First, we are not going to "Deprecate"
Apr 1, 2022, 05:43 by pe...@stuge.se:
> Arthur Heymans wrote:
>
>> The context here, was that I voiced some practical concerns about
>>
>> using CBOR as a handoff structure. LinuxBIOS or coreboot tables were
>> carefully designed to be very easy to parse.
>>
>
> Your concern is valid and I think
I spoke with Phcoder (the original author) about this ages ago, and he
recommended not actually playing sound with it, but using it with an audio
cable between the output device and input device. I assume you'd be able to
use it at a much higher speed that way.
Martin
Dec 7, 2021, 10:37 by
If someone wanted to work with one of the approved coreboot contractors or
individual contributor to set up a fundraiser of some sort to raise money to do
things like this, that'd be great.
We've had a requests for things like this in the past, but it's not something
that the coreboot project
Hey Arthur,
Nov 24, 2021, 05:50 by art...@aheymans.xyz:
> Hi
> I would like to suggest to deprecate some legacy codepaths inside the
> coreboot tree and therefore make some newer ones mandatory.
> ... snip ...> About the timeline of deprecations. Is deprecating non
> conforming platforms from
# 9 November 2021 - coreboot EFI working group
Attendees: Martin Roth, Felix Held, Michael Niewöhner, Matt DeVillier, Nate
DeSimone, Patrick Georgi, Tim Crawford, Werner Zeh
## Agenda:
* [Edward] Supporting some UEFI interfaces continues to be a hot topic, one
such area is ESRT table ASL
Nov 7, 2021, 04:13 by nic...@gmx.de:
> On 07.11.21 00:11, Martin Roth wrote:
>
>> CB:55367 was pushed on June 9th. It's 5 months later. Intel hasn't been
>> able to get it merged yet. Sure, we're not outright saying they can't get
>> it in, but in effect, that's wh
Nov 7, 2021, 04:29 by nic...@gmx.de:
> On 07.11.21 00:15, Martin Roth wrote:
>
>>
>> Nov 6, 2021, 05:49 by nic...@gmx.de:
>>
>>> It also seems that you underestimate the individuals in the
>>> community.
>>>
>> I don't
Nov 6, 2021, 05:49 by nic...@gmx.de:
> On 05.11.21 19:39, Patrick Georgi via coreboot wrote:
>
>> It [coreboot] would be dead: while there are still a few folks carefully
>> maintaining
>> i945 and GM45 in this reality, I'm not sure they would have done so in that
>> other reality where there
Nov 6, 2021, 05:49 by nic...@gmx.de:
> On 05.11.21 19:39, Patrick Georgi via coreboot wrote:
>
>> It [coreboot] would be dead: while there are still a few folks carefully
>> maintaining
>> i945 and GM45 in this reality, I'm not sure they would have done so in that
>> other reality where there
Nov 6, 2021, 05:21 by nic...@gmx.de:
> On 05.11.21 18:15, Martin Roth via coreboot wrote:
>
>> Nov 4, 2021, 05:24 by pmen...@molgen.mpg.de:
>>
>>> On 20.10.21 14:24, Nico Huber wrote:
>>>
>>>> My proposal:
>>>> How about we set up some
Nov 5, 2021, 14:10 by nic...@gmx.de:
> On 05.11.21 18:58, Martin Roth wrote:
>
>> This binary is also mandatory for the elkhart lake platform, so to support
>> this platform, loading this is required, whether it's built from source as a
>> part of the coreboot bui
# 03 November 2021 - coreboot Leadership meeting minutes
Edited for clarity and formatting.
* Attendees: Christian Walter, David Hendricks, Felix Held, Felix Singer, Jason
Glenesk, Jay Talbott, Martin Roth, Matt DeVillier, Patrick Georgi, Piotr Król,
Ron Minnich, Sean Rhodes, Stefan Reinauer
Oct 31, 2021, 15:03 by nic...@gmx.de:
> Hi Sheng,
>
> On 27.10.21 06:29, Tan, Lean Sheng wrote:
>
>> As mentioned earlier the Firmware of the PSE needs to be loaded at boot time
>> of the host CPU, this is mandatory for Elkhart Lake.
>>
> ...
>
> so as far as I understand it this is not
Nov 4, 2021, 05:24 by pmen...@molgen.mpg.de:
> On 20.10.21 14:24, Nico Huber wrote:
>
>> My proposal:
>> How about we set up some guidelines how to proceed when adding support
>> for a new platform that requires any blobs? My vague idea is as follows:
>> Before the very first commit for such a
# 20 October 2021 - coreboot Leadership
##Attendees:
Felix Singer, David Hendricks, Arthur, Werner, Piotr, Lean Sheng Tan,
Marshall, Jason Glenesk, Jay Talbott, Matt DeVillier, Patrick Georgi, Tim
Crawford, Martin, Stefan, Felix Held
## Agenda:
* [patrick g] “Verified+1” permissions on
Accidentally responded off the mailing list initally. :-/
Oct 20, 2021, 08:07 by matt.devill...@gmail.com:
> On Wed, Oct 20, 2021 at 8:53 AM Andy Pont wrote:
>
>>
>> Nico wrote...
>> >> How about we set up some guidelines how to proceed when adding support
>> >> for a new platform that
# 12 October 2021 - coreboot EFI working group
## Objective:
Linux is expecting more and more to use EFI supplied interfaces (UEFI
Boot Services in particular, even if many are stubbed out) so like it or
not, we’re going to need to support these interfaces. How do we approach
this without
at coreboot.org when we just get complaints and
grief?
Personally, I'm tired of dealing with it. It's become too toxic, so
I'm retiring from the project.
Martin
On Sun, Jan 26, 2020 at 1:09 PM Nico Huber wrote:
>
> Hi Martin,
>
> On 26.01.20 20:36, Martin Roth wrote:
> > While it's not
While it's not my preference, I'm fine with pulling picasso out of the
tree and doing the development in private if that's the community
desire. When we're done, it can go in, or not, as the coreboot
community chooses. Because we can't boot what's in coreboot
currently, we're being forced to
My proposal is to drop platforms that aren't being tested, aren't
being maintained, or are causing serious problems with general
coreboot development.
For example
- ASUS KGPE-d16 is still being used and tested, so I wouldn't suggest
dropping that code, even though it apparently doesn't support
at 8:39 AM Martin Roth wrote:
>
> It's patch cleanup time again. This cleanup was last done almost 2
> years ago, so there are a lot of old patches that haven't been touched
> in a while.
> Next week I'm going to abandon all of the open patches that haven't
> been touched
It's patch cleanup time again. This cleanup was last done almost 2
years ago, so there are a lot of old patches that haven't been touched
in a while.
Next week I'm going to abandon all of the open patches that haven't
been touched in over 18 months.
The list of roughly 250 patches to be
For anyone who doesn't understand what Patrick is referring to, any
comments made in for a file need to be marked as resolved before the
patches can be submitted now. Top level comments made with the
"Reply" button and saying something nice, do not need to be resolved
To see what comments need
I'd check the smbus base address right before the FSP starts with and
without your change. If it's only set with your change, then try
clearing it before calling the FSP.
See what the BAR is after the FSP runs, and make sure that the address
coreboot is using is the same. The early FSPs had a
1 - 100 of 315 matches
Mail list logo
