[coreboot] Supported Motherboards

[Mike Banon]

> There might be neither ME nor PSP, but that just means the controllers that are known and researched are absent (it doesn't tell you anything about less researched ones).

There is no evidence that AMD processors contained any "remote
management" controllers before late 16h family (Puma). Even the early
16h (Jaguar) is okay in this relation, and G505S CPU is 15h (Richland)
- so, unlike the recent Intels, it does not contain any "remote
management" controllers that might be exploited as a hardware backdoor
via some vulnerability.

> AMD graphics driver developers force you to put a usually proprietary AtomBIOS into your firmware.

1) You can move AtomBIOS from the firmware to GRUB/Linux kernel stage.
Putting it into your firmware is more convenient - but it's not the
only solution and could be avoided (e.g. by following some of these
instructions - https://bugs.freedesktop.org/show_bug.cgi?id=26891 )

2) AtomDis of AtomBIOS is clear enough to make sure there aren't any
backdoors ( https://pastebin.com/xKW9FV58 ), perhaps that's why the
efforts like OpenAtom (
https://github.com/alterapraxisptyltd/openatom/ +
https://github.com/mrnuke/radeon ) and OpenRadeonBIOS (
https://sourceforge.net/p/openradeonbios/ ) have been suspended.

> The G505s still uses AGESA (a hard to maintain AMD reference code). This (and actually the native coreboot AMD code too) might get moved away from our master branch after any release.

You are correct, it could be that one day coreboot will go full Intel.
But that is more likely to happen simply because the corporations
participating in the development of coreboot aren't interested at any
AMD boards. So the future coreboot indeed might support only some
Google/Purism computers together with Intel/Facebook/etc. in-house
proprietary boards, and there will not be any coreboot-supported
boards without Intel ME + full complex set of their blobs (FSP etc.)

> The last time I worked on a bigger patch set in my spare time, I nearly gave up after some nights of work because of the unmaintainable mess around {cpu,nb,sb}/amd/

If its difficult to write the crossplatform code in some cases or if
you aren't interested at AMD boards (understandable if you don't have
any), you could use something like "ifdef INTEL_BOARD then
Enable_Feature_X else Dont_Enable". Better to live without some
not-essential features than removing the boards, especially since
there really aren't a lot of coreboot-supported motherboards.

> I believe it's only a question of time until coreboot maintainers are finally fed up with it.

The majority of platform-specific problems discussed at the mailing
lists are directly related to Intel. Sometimes I'm seeing so many of
them flooding my inbox, I'm wondering how the coreboot maintainers
aren't fed up with Intel mess. Here are some long thread examples:

*) "How to get correct memory params for FSP"
*) "[skylake] Can not turn monitor on"
*) "Kabylake unable to boot with post code 0x71"
+ could dig out much more if required.

Even from a bystander's point of view it is quite obvious that many of
these Intel-specific problems have been caused by the improper
software design and insufficient source code quality. Luckily you seem
to recognize these problems, as I could see from some of your messages
like this one -
https://mail.coreboot.org/pipermail/coreboot/2018-November/087722.html
. Whether this has been caused by Intel outsourcing to developing
countries, or "quantity-over-quality" approach, I don't know. However:
despite the Intel source code being as messy as AMD (if not more
messy) you don't see any serious discussions regarding the
removal/rewrite of Intel, and we all know why.

> A good solution would be to write native coreboot code for this platform from scratch. Something at least of the quality of intel/x4x (and the compatible southbridges) would be much appreciated and would likely maintain itself for some years.

But that will not protect AMD code from removal. When someone will
want to remove it, in any case they will find a reason: either "EOL
and old" (could happen to intel/x4x regardless of its' source code
quality) or "no feature/property X we've introduced and absolutely
require" (something like "late vs early init") or simply "why should
we care about AMD boards if we work with/at Intel". Maybe then the
coreboot project will be forked and there will be two coreboots: one
for the people, and another for corporations.

Sorry, but it seemed more like "Please avoid AMD if possible, its'
going to be removed". Problem that its hard to avoid AMD without going
Intel, and there are a lot more reasons to avoid Intel than AMD: in
addition to the earlier introduction of remote management controllers
and being a monopoly, there are serious Intel-only security
vulnerabilities like Meltdown which requires a 5%-30% performance
degrading patch and Intel hyperthreading will be disabled soon (
https://www.theregister.co.uk/2018/11/02/portsmash_intel_security_attack/
). Perhaps it makes more sense to say

" Please avoid Intel if possible "

but I don't want to start "Intel vs AMD" holy war there, especially
since it seems we are greatly outnumbered by
Intel-employed/partnered/sympathetic folks (how could one be sincerely
sympathetic to Intel is a big question though).

Best regards,
Mike Banon
On Thu, Nov 8, 2018 at 11:18 PM Nico Huber <nico.h at gmx.de> wrote:
>
> On 11/8/18 3:29 PM, Mike Banon wrote:
> > Please consider AMD Lenovo G505S laptop: all the hardware
> > virtualizations AMD-V / SLAT / IOMMU are fully supported there
> > (although you have to install a microcode update to avoid the possible
> > glitches), no Intel ME / AMD PSP, quad-core CPU, 16GB DDR3 RAM
> > possible, recent build_status report,
>
> Please avoid the G505s if possible. There might be neither ME nor PSP,
> but that just means the controllers that are known and researched are
> absent (it doesn't tell you anything about less researched ones). Also,
> if you want to use its integrated graphics, you can't run fully free
> software (not even on the main CPU) because AMD graphics driver develo-
> pers force you to put a usually proprietary AtomBIOS into your firmware.
> The Linux radeon/amdgpu drivers are only open source because they hide
> the proprietary parts in the host firmware (BIOS/coreboot, not some
> firmware that runs on the gfx processor).
>
> > and there's a cosy community
> > around it and we intend to support it for a looong time - as long as
> > all our G505S last
>
> That's good to hear. But here comes a warning: The G505s still uses
> AGESA (a hard to maintain AMD reference code). This (and actually the
> native coreboot AMD code too) might get moved away from our master
> branch after any release. I believe it's only a question of time until
> coreboot maintainers are finally fed up with it*.
>
> A good solution would be to write native coreboot code for this platform
> from scratch. Something at least of the quality of intel/x4x (and the
> compatible southbridges) would be much appreciated and would likely
> maintain itself for some years.
>
> Nico
>
> * The last time I worked on a bigger patch set in my spare time, I
>   nearly gave up after some nights of work because of the unmain-
>   tainable mess around {cpu,nb,sb}/amd/. It's dragging the whole
>   project down, IMHO.