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 other board 
> in the tree uses
> the same chipset code) and various Asus P2B boards (which support Pentium 2/3 
> CPUs, these
> boards are older than me). Even though I only know two people who still have 
> some of these
> boards (and they don't have the same boards), they're still supported because 
> the code has
> been maintained so far.

I am one of the two with Asus P2B boards, with Keith Hui being the
other. I've got a P2B and a P2-99 and I believe Keith Hui has a
P2B-LS.
So far there have not been very many changes and Keith Hui and others
have worked on them, all I've done is test master and relevant patch
sets every once in a while.
I know I have not been uploading board_status results and I have not
gotten around to fixing the variant set up for the P2-99 so I'm not
uploading results that are uncertain about which board they are for.
Not really relevant, but I think it is pretty neat to be running
coreboot on boards older then some of the contributors.

 Mike Banon wrote:
> I am often build-testing my boards (didn't notice a
> https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only 
> because I've been
> re-using the previously built toolchains to save time). Also, I am actively 
> tech-supporting all the
> people who would like to build coreboot for AMD boards from this list, even 
> right now I am in an
> active message exchange with >10 people who are switching to these boards to 
> run coreboot
> on them - and any user may give back to the project one day.

I actually have a few AMD boards and laptops that might be viable for
porting to, but I've never looked in to it much because of the state
support is in coreboot and the fact most of the hardware was actively
being used.

 Arthur Heymans wrote:
> The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes 
> the codepath for
> SMM_ASEG. This code is used to start APs and do some feature programming on 
> each AP, but
> also set up SMM. This has largely been superseded by PARALLEL_MP, which 
> should be able
> to cover all use cases of LEGACY_SMP_INIT, with little code changes. The 
> reason for
> deprecation is that having 2 codepaths to do the virtually the same increases 
> maintenance
> burden on the community a lot, while also being rather confusing.
>
> A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on 
> single core
> systems. It's likely easy to extend PARALLEL_MP or write some code that just 
> does CPU
> detection on the BSP CPU. - Support smm in the legacy ASEG (0xa0000 - 
> 0xb0000) region. A
> POC showed that it's not that hard to do with PARALLEL_MP
> https://review.coreboot.org/c/coreboot/+/58700

I didn't even know that was a problem until now. I doubt there is much
I can do about it myself at this point in time, though I can try to
look through it I guess.


Branden Waldner
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Reply via email to