[coreboot] Supported Motherboards

Sun Nov 11 04:09:31 CET 2018

I strongly agree to what Mike said.
thats maybe the "i want a cheap but yet powerfull and as Free as possible" point of view.

Also with the recent AMDGPU driver for linux. amd hardware is a good option to have a somewhat powerful and free graphics solution.
And i am personaly much less worried about some vgabios or gpu microcode than an backdoor processor on my main cpu.

If i will hopeful  get mad C-skillz and better unterstanding about lowlevel hardware processes in the future, i really would like to contribute to those amd 15th gen Ports of coreboot.

Am 11. November 2018 00:41:37 MEZ schrieb Mike Banon <mikebdp2 at gmail.com>:
>> There is no evidence that there is such a thing for Intel systems
>with AMT disabled, either.
>
>But it is easier not to have any AMT/ME/PSP at all: no need to clean
>anything and nothing to worry about.
>
>> I could secure it with a hyper-visor, I guess, but what if I just
>want to run Linux?
>
>Possible to run Linux under a hypervisor as well, by using something
>like QubesOS (which contains Xen).
>
>> >
>> > 2) 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
>
>I could be a car mechanic without being able to build a new car from
>scratch. When I looked under this car's hood (AtomDis) I saw just a
>bunch of command tables like SetMemoryClock / AdjustDisplayPll /
>EnableVGA_Render and data tables like LVDS_Info /
>VRAM_UsageByFirmware. Haven't seen anything suspicious that could have
>indicated some potential backdoors there. But if you don't want to run
>this blob even under a hypervisor like Xen in QubesOS, there's always
>an option to avoid this blob entirely by running your PC in a headless
>mode. Meanwhile you can't avoid the closed source Intel FSP the same
>way.
>
>In addition, there is YABEL option in coreboot to prevent the
>undocumented access of OptionROMs to other PCI devices - which also
>helps to reduce the concerns regarding this AtomBIOS blob. I'm not
>sure there is any equivalent for FSP.
>
>> The support for pre-ME/FSP Intel boards shows that maintaining
>> 10y+ old platforms can be fun and works out very well.
>
>But they could still be removed from coreboot just because of "EOL and
>old"/"no-one is using them". From coreboot 4.3 release notes: " 20
>mainboards were removed that aren't on the market for years (and even
>hard to get on Ebay) ". Stuff like this could happen to any board that
>is old, or am I wrong here?
>
>> The (AMD) platforms are not the problem. Maybe the problem is that
>their fans got lazy and rested on AGESA, idk.
>
>Its understandable that it could look like we are lazy and resting on
>AGESA. But maybe we are busy using our coreboot'ed AMD computers for
>various freedom-related projects - as the tools to create something
>great? And having to rewrite AGESA would mean we're suddenly working
>much more on the tools than on the stuff we're creating with them -
>without any obvious benefit to the
>not-hardcore-programmers-but-security-conscious people who see that
>AGESA is open source already
>
>Best regards,
>Mike Banon
>
>
>
>On Fri, Nov 9, 2018 at 9:27 PM Nico Huber <nico.h at gmx.de> wrote:
>>
>> On 11/9/18 2:22 PM, Mike Banon wrote:
>> >> 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.
>>
>> There is no evidence that there is such a thing for Intel systems
>with
>> AMT disabled, either.
>> >> 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 )
>>
>> 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?
>>
>> >
>> > 2) 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.
>>
>> >> 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.
>>
>> That's not what I said. Actually, there is actively maintained AMD
>code
>> in our repo. I was talking about unmaintained code.
>>
>> > But 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.
>>
>> > 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.)
>>
>> 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.
>>
>> >> 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.
>>
>> 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.
>>
>> >> 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.
>>
>> 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.
>>
>> > 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.
>>
>> Nope, as said above, the unmaintained AMD is a hell a lot messier.
>>
>> >> 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.
>>
>> 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?
>>
>> > 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).
>>
>> 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 at coreboot.org
>https://mail.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181111/b1c19fd7/attachment.html>