Post by Mike BanonThere 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.
There is no evidence that there is such a thing for Intel systems with
AMT disabled, either.
Post by Mike BanonAMD 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 )
So you can shift the problem? Point is? I could secure it with a
hyper-visor, I guess, but what if I just want to run Linux?
Post by Mike Banon2) AtomDis of AtomBIOS is clear enough to make sure there aren't any
backdoors ( https://pastebin.com/xKW9FV58 ),
You have made (up?) that claim before. If it is clear to you and you
have the knowledge to implement a free graphics driver for the G505s,
please do it! If not, I suppose you lie deliberately.
This list is about open-source firmware, if you want to make random
claims about proprietary firmware, please do it somewhere else.
Post by Mike BanonThe 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.
That's not what I said. Actually, there is actively maintained AMD code
in our repo. I was talking about unmaintained code.
Post by Mike BanonBut that is more likely to happen simply because the corporations
participating in the development of coreboot aren't interested at any
AMD boards.
Nope, it's because the unmaintained code is no fun at all to work with.
If I (as a non-corporate contributor) want to clean something up across
the whole tree, there are sub-trees where I instantly see what I have
to do, see how beautiful things turn out... there are also sub-trees
that give me a bad time, delay a few hour job for days and as such
lower the potential of non-corporate contributors. The code that runs
on G505s lives in the latter sub-trees.
Post by Mike BanonSo 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.)
That's unlikely. The support for pre-ME/FSP Intel boards shows that
maintaining 10y+ old platforms can be fun and works out very well. The
(AMD) platforms are not the problem. Maybe the problem is that their
fans got lazy and rested on AGESA, idk.
Post by Mike BanonThe 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.
That makes no sense at all. Either you want to have new features, up to
date support etc., then we have to maintain it on the master branch. If
we "ifdef" things out, it's the same as having it on a separate branch.
Post by Mike BanonI 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.
Your statistics are biased by the fact that almost nobody uses coreboot
for AMD (in production) compared to Intel. But to be honest, Intel does
a mess indeed, but it's not half as bad as the unmaintained (even the
native) AMD code.
Post by Mike Banon*) "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
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.
Nope, as said above, the unmaintained AMD is a hell a lot messier.
Post by Mike BanonA 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.
Well, I'm with the people. And if I would fork coreboot for the people,
the unmaintained AMD code would be high up on the list of what to drop
to be able to support the rest better. You seem to be absolutely con-
fused about coreboot development. There are a lot active non-corporate
developers in the community. You are asking them to maintain the crappy
code too, for less fun and no money. How should that ever work out?
Post by Mike BanonSorry, 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).
Yeah, it's weird. I'm absolutely not on the Intel side. I just can't
stand your biased bullshit. So I'm looking for arguments against AMD
when I see your unfounded arguments against Intel. Not because I don't
like AMD but because I don't like this list to look dubious, i.e. that
we would accept biased arguments without correcting them.
Nico
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot