Hi Keith
Thanks a lot for testing! It looks like the newer parallel mp code uses
"mfence" which is probably not supported by your CPU.
I updated the code to reflect that.
I'd appreciate if you can test the latest version of
https://review.coreboot.org/c/coreboot/+/59693/
Kind regards
On Tue, Nov
Hi everyone,
Thanks for your efforts to keep a computing legend alive. :)
I suffered an unexpected exception after applying the patch train.
Serial log at the end of this email. I probably could leave out
bootblock/romstage/postcar, but it's here for completeness. Next:
bisect.
I do still have a
Hi Branden,
On Mon, Nov 29, 2021 at 9:18 PM Branden Waldner wrote:
>
> I wasn't really sure that I wanted to comment on this, but seeing as
> how I have some of the affected boards I guess I should.
Thank you very much.
> Angel Pons wrote:
> > Besides AMD AGESA boards, the other boards that ne
I wasn't really sure that I wanted to comment on this, but seeing as
how I have some of the affected boards I guess I should.
Angel Pons wrote:
> Besides AMD AGESA boards, the other boards that need to be updated are AOpen
> DXPL
> Plus-U (a dual-socket server board that uses Netburst Xeons, no
>
> On a side note is there any kind of crowd sourcing platform / escrow
> service for GPL projects? I know it's been talked about, and there have
> been attempts made. But as far as I can tell, nothing has ever prospered.
If someone wanted to work with one of the approved coreboot contractors
having read this discussion, and with all respect for all the opinions
so clearly expressed, I still support Arthur's original proposal.
On Sun, Nov 28, 2021 at 2:20 PM David Hendricks
wrote:
>
>
>
>> 1. These boards will be gone for the people who check the "mainboards
>> supported by coreboot"
1. These boards will be gone for the people who check the "mainboards
> supported by coreboot" and see only the "new Intel stuff". This
> hinders the coreboot community growth around the "gone boards", and
> also of the coreboot community in general: the fewer boards are
> supported by coreboot, th
Hi Peter,
On 28.11.21 02:44, Peter Stuge wrote:
> TL;DR: If someone wants to deprecate older code then *they* have to
> first balance any compatibility debt introduced by the newer code.
sounds fair. However I have to ask, do you see things are unbalanced?
And in what direction?
Taking the alloc
Am 28.11.2021 um 02:44 schrieb Peter Stuge:
Patrick Georgi via coreboot wrote:
With all due respect, dropping support for the majority of AMD boards
Dropping support for hardware has never been the primary purpose of
deprecation plans,
I think the difference is unimportantly subtle; deprecat
TL;DR: If someone wants to deprecate older code then *they* have to
first balance any compatibility debt introduced by the newer code.
Anything else incentivises a race to the bottom; to move fast and
break things. coreboot IMO neither wants nor needs that.
Patrick Georgi via coreboot wrote:
> >
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
24. November 2021 21:16, "Mike Banon" schrieb:
> With all due respect, dropping support for the majority of AMD boards
Dropping support for hardware has never been the primary purpose of
deprecation plans, but since deprecations have been interpreted like that too
often, I propose using clearer
I'm happy to contribute financially. It just comes with the caveat that
I need to know with some surety that I can finally have a working board
at the end of it.
On a side note is there any kind of crowd sourcing platform / escrow
service for GPL projects? I know it's been talked about, and th
On Thu, Nov 25, 2021 at 9:50 PM Angel Pons wrote:
>
> TL;DR: The deprecation notice is a call for action. Please stop
> complaining about it, let's work on a solution instead. Especially
> when https://review.coreboot.org/q/topic:amd_resource_allocator_v4
> already exists, which implements some of
Hi Mike,
I typically don't indulge in mailing list drama, but I'm sick and
tired of seeing people waste their time and energy along with others'.
This is not the first time I've seen something like this: something
similar happened about two years ago when other AMD boards (KGPE-D16
and KCMA-D8, am
> Do you remember from where you got these magic values? Suspect I'm going
> to need similar. Will investigate soc/amd/¨* too.
> /* QEMU-specific register */
> #define EXT_TSEG_MBYTES 0x50
> +#define SMRAMC 0x9d
> +#define C_BASE_SEG ((0 << 2) | (1 << 1) | (0 << 0))
> +#define G_SMRAME (
Arthur Heymans:
https://review.coreboot.org/c/coreboot/+/48210 and
https://review.coreboot.org/c/coreboot/+/48262/ provided the implementation
for PARALLEL_MP on qemu.
Notice that modern AMD CPUs (soc/amd/¨*) also use PARALLEL_MP and can be
used as an example for AMD AGESA platforms too.
Good l
> To address the OP, it seems like there is some activity on getting an
> AGESA RESOURCE_ALLOCATOR_V4 working, but is an AGESA PARALLEL_MP init
> also needed (and is there any activity or something I can do to help?)
> Realize resources may not exist to spoon feed problem definitions to a
> level m
Am 25.11.2021 um 18:06 schrieb AreYouLoco? via coreboot:
In my opinion coreboot is more developer friendly than user friendly.
Kinda obvious: We don't even ship binaries...
Given the trouble these deprecation announcements always are, I can tell
you an even more developer friendly strategy:
Patrick Georgi via coreboot:
On 25.11.21 17:04, Mike Banon wrote:
2. It's not just the loss of boards - it's also the loss of coreboot
users/contributors who only have these boards and don't want to switch
These users didn't contribute fixes to their boards (or even just
feedback that things n
It's definitely preferable to have platforms working in-tree rather than
out of tree. This is a *significant* portion of coreboot's supported
platforms and sends a strong signal to anyone using or considering them
that they can just forget about the coreboot project because the rug may be
pulled ou
> 1. These boards will be gone for the people who check the "mainboards
> supported by coreboot" and see only the "new Intel stuff". This
> hinders the coreboot community growth around the "gone boards", and
> also of the coreboot community in general: the fewer boards are
> supported by coreboot,
Dear coreboot folks,
Am 25.11.21 um 17:43 schrieb Patrick Georgi:
On 25.11.21 17:04, Mike Banon wrote:
[…]
[ forking threat, and follow-up comment ]
Please let’s not escalate this. (Type your answer, save it in the draft
folder, sleep over it, and then think if you want to send it.)
I th
On November 25, 2021 4:43:35 PM UTC, Patrick Georgi via coreboot
wrote:
>On 25.11.21 17:04, Mike Banon wrote:
>These users didn't contribute fixes to their boards (or even just feedback
>that things needs to be done and testing when others provide patches) - are
>they even contributors?
>
>
On 25.11.21 17:04, Mike Banon wrote:
2. It's not just the loss of boards - it's also the loss of coreboot
users/contributors who only have these boards and don't want to switch
These users didn't contribute fixes to their boards (or even just feedback that
things needs to be done and testing w
> The word 'drop' has ominous connotations, but it's not a deletion. A board is
> never really gone.
"Dropping" 50 boards may be ominous in relation to the future of the
coreboot project:
1. These boards will be gone for the people who check the "mainboards
supported by coreboot" and see only th
The word 'drop' has ominous connotations, but it's not a deletion. A
board is never really gone. It's git. I can still find the Alpha
boards in there if I go back far enough. It's just that active
development ends, as no one is working to keep them up to date.
Would it be ok with you to drop the b
> With all due respect, dropping support for the majority of AMD boards
> - with a quite significant community around them! - doesn't seem like
> a wise decision, if we still care about the coreboot marketshare on
> the worldwide-available consumer PCs. Small improvement in the common
> source, but
With all due respect, dropping support for the majority of AMD boards
- with a quite significant community around them! - doesn't seem like
a wise decision, if we still care about the coreboot marketshare on
the worldwide-available consumer PCs. Small improvement in the common
source, but a huge lo
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
> We could announce this deprecation in the 4.16 release notes, then
deprecate after 4.18 (8.5 months from now). At that point, we'd create a
branch and set up a verification builder so that any deprecated platforms
could be continued in the 4.18 branch.
That timeline of 8.5 months does sound fai
I think, given how good a job you've all done with the release tags
and so on, it's easy for people to get to a working build for a board;
therefore, deprecating non conforming platforms make sense, as does
your suggestion for six months.
On Wed, Nov 24, 2021 at 4:51 AM Arthur Heymans wrote:
>
>
32 matches
Mail list logo
