Discussion:
Supported Motherboards
(too old to reply)
kinky_nekoboi
2018-11-07 16:07:36 UTC
Permalink
Hi J.Clamp,
what kind of usecase to u have for your mainboard?
I use the G41m-es2l for my homeserver.
It supports core 2 quad CPUs and has 2 DDR2 slots.
Also it is usable without any nonfree blobs.
if u need something more powerful look for the ivy bridge boards or one that does support the 15th gen Amd cpus
Hi all,
I am new to coreboot and was looking for a motherboard that would
support coreboot. I have checked and looked at this page but I don't
know if coreboot is supported on all of these motherboards or if only
certain motherboards support coreboot? Any help would be greatly
appreciated.
Here is the link to the page that I found -
https://coreboot.org/status/board-status.html
--
https://mail.coreboot.org/mailman/listinfo/coreboot
kinky_nekoboi
2018-11-07 16:38:23 UTC
Permalink
as far as i know it uses xen? so you need AMD-V or Intel VT-x + VT-d
i think and sandy/ivy bridge platform with fsp blob would fit this needs best
there is the asus maximus ... and there is the T520 with a vpro cpu with feeds this needs best i guess
I am thinking of installing QubesOS on the mainboard. One of the
requirements for QubesOS 4.0 is that it has to run coreboot.
Post by kinky_nekoboi
Hi J.Clamp,
what kind of usecase to u have for your mainboard?
I use the G41m-es2l for my homeserver.
It supports core 2 quad CPUs and has 2 DDR2 slots.
Also it is usable without any nonfree blobs.
if u need something more powerful look for the ivy bridge boards or
one that does support the 15th gen Amd cpus
Am 7. November 2018 16:56:57 MEZ schrieb J Clamp via coreboot
Hi all,
I am new to coreboot and was looking for a motherboard that would
support coreboot. I have checked and looked at this page but I
don't
Post by kinky_nekoboi
know if coreboot is supported on all of these motherboards or if
only
Post by kinky_nekoboi
certain motherboards support coreboot? Any help would be greatly
appreciated.
Here is the link to the page that I found -
https://coreboot.org/status/board-status.html
Kinky Nekoboi
2018-11-07 18:10:05 UTC
Permalink
kinda... the wiki and the supported board lists are maintained by devs
in their freetime i guess so it is not always 100% up to date.

u can see all target board currently supported (more or less ) in the
nconfig build menu while compieling coreboot.
I also was curious to know if the website that I found lists all of
the motherboards that coreboot currently supports?
Post by kinky_nekoboi
Hi J.Clamp,
what kind of usecase to u have for your mainboard?
I use the G41m-es2l for my homeserver.
It supports core 2 quad CPUs and has 2 DDR2 slots.
Also it is usable without any nonfree blobs.
if u need something more powerful look for the ivy bridge boards or
one that does support the 15th gen Amd cpus
Am 7. November 2018 16:56:57 MEZ schrieb J Clamp via coreboot
Hi all,
I am new to coreboot and was looking for a motherboard that would
support coreboot. I have checked and looked at this page but I don't
know if coreboot is supported on all of these motherboards or if only
certain motherboards support coreboot? Any help would be greatly
appreciated.
Here is the link to the page that I found -
https://coreboot.org/status/board-status.html
Angel Pons
2018-11-07 18:41:35 UTC
Permalink
Hello,

Currently board_status only lists the main variant for each board,
which means boards with variants (which may be somewhat different) are
not listed there.

On Wed, Nov 7, 2018 at 5:39 PM kinky_nekoboi
Post by kinky_nekoboi
as far as i know it uses xen? so you need AMD-V or Intel VT-x + VT-d
i think and sandy/ivy bridge platform with fsp blob would fit this needs best
there is the asus maximus ... and there is the T520 with a vpro cpu with feeds this needs best i guess
Sandybridge (SNB) and Ivybridge (IVB) have blob-free coreboot. It is
working well enough to replace the FSP version. (see [1])

There are some more SNB/IVB boards: I have a Gigabyte GA-H61M-S2PV and
an Asus P8H61-M PRO, I ported coreboot to both. There is also
autoport, which means porting SNB/IVB boards to coreboot is much
easier.

On Wed, Nov 7, 2018 at 7:11 PM Kinky Nekoboi
Post by kinky_nekoboi
kinda... the wiki and the supported board lists are maintained by devs in their freetime i guess so it is not always 100% up to date.
u can see all target board currently supported (more or less ) in the nconfig build menu while compieling coreboot.
The board_status page is updated automatically. The wiki, however, is
not. It is read-only as well since documentation is being moved to
[2].

Best regards,

Angel Pons Pons

[1]: https://review.coreboot.org/c/coreboot/+/29402
[2]: https://doc.coreboot.org
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Kinky Nekoboi
2018-11-07 18:53:18 UTC
Permalink
Did not know it that there is a replacement for FSP.

Was it Reserve-engineered? i just recently build a working rom for my
W520 with the afford to reduce as much blobs as possible. shined me and
stuff.

is there any way to find out if my rom was build without FSP ? with
cbfstool or something?

greetings

the kinky nekoboi
Post by Angel Pons
Hello,
Currently board_status only lists the main variant for each board,
which means boards with variants (which may be somewhat different) are
not listed there.
On Wed, Nov 7, 2018 at 5:39 PM kinky_nekoboi
Post by kinky_nekoboi
as far as i know it uses xen? so you need AMD-V or Intel VT-x + VT-d
i think and sandy/ivy bridge platform with fsp blob would fit this needs best
there is the asus maximus ... and there is the T520 with a vpro cpu with feeds this needs best i guess
Sandybridge (SNB) and Ivybridge (IVB) have blob-free coreboot. It is
working well enough to replace the FSP version. (see [1])
There are some more SNB/IVB boards: I have a Gigabyte GA-H61M-S2PV and
an Asus P8H61-M PRO, I ported coreboot to both. There is also
autoport, which means porting SNB/IVB boards to coreboot is much
easier.
On Wed, Nov 7, 2018 at 7:11 PM Kinky Nekoboi
Post by kinky_nekoboi
kinda... the wiki and the supported board lists are maintained by devs in their freetime i guess so it is not always 100% up to date.
u can see all target board currently supported (more or less ) in the nconfig build menu while compieling coreboot.
The board_status page is updated automatically. The wiki, however, is
not. It is read-only as well since documentation is being moved to
[2].
Best regards,
Angel Pons Pons
[1]: https://review.coreboot.org/c/coreboot/+/29402
[2]: https://doc.coreboot.org
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Angel Pons
2018-11-07 19:10:58 UTC
Permalink
Hello nekoboi,

On Wed, Nov 7, 2018 at 7:53 PM Kinky Nekoboi
Post by Kinky Nekoboi
Did not know it that there is a replacement for FSP.
Was it Reserve-engineered? i just recently build a working rom for my
W520 with the afford to reduce as much blobs as possible. shined me and
stuff.
is there any way to find out if my rom was build without FSP ? with
cbfstool or something?
Well, it has been there for a while (longer than me AFAIK, I started
corebooting stuff around April 2018). If I am not mistaken, it was
reverse-engineered.

Nearly every SNB/IVB board in coreboot uses open-source code, so I
guess you're not using FSP. If you did, you would also have to include
it.
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
kinky_nekoboi
2018-11-07 19:56:55 UTC
Permalink
sounds promissing i will give it a deeper look later.
this makes the SNB/IVY platform much more attractive to me.
thx for the information.
Post by Angel Pons
Hello nekoboi,
On Wed, Nov 7, 2018 at 7:53 PM Kinky Nekoboi
Post by Kinky Nekoboi
Did not know it that there is a replacement for FSP.
Was it Reserve-engineered? i just recently build a working rom for my
W520 with the afford to reduce as much blobs as possible. shined me
and
Post by Kinky Nekoboi
stuff.
is there any way to find out if my rom was build without FSP ? with
cbfstool or something?
Well, it has been there for a while (longer than me AFAIK, I started
corebooting stuff around April 2018). If I am not mistaken, it was
reverse-engineered.
Nearly every SNB/IVB board in coreboot uses open-source code, so I
guess you're not using FSP. If you did, you would also have to include
it.
Timothy Pearson
2018-11-07 22:36:26 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by kinky_nekoboi
sounds promissing i will give it a deeper look later.
this makes the SNB/IVY platform much more attractive to me.
thx for the information.
Be aware there's still an Intel ME requirement for those platforms;
while they are old enough that the ME can be significantly reduced, it
cannot be completely eliminated.

- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJb42jqAAoJEK+E3vEXDOFb6PIH/0EvBPqEK3hm8wEK/qr21f9K
gNXz5L2vWysfOR4CpAr+dAiB2FGDCa3uBJziQtQi4XRqrnzWerD1lOoQJb+API+G
gS7k88h7f9l8WVr1zug7GS34CnE+hxsCb4q2gZVnuo5B8fdmhywi8/DDOrMfnikM
EvPuYtFnlIOQ+BF523TEqH7CjkjoYxrjQc/pmA0SxZvcwoTZU4YxYTcdF77LPhyk
qcnSI+3mZ6M+Sh64CZ7x8ko2Ap5rKnv3CoPZIAwoqn+4fme22GJKL8p6g/8W1Zwg
o4slXN2G2hkjRpeLvNj0rmODe0ztGEaR5tzauo8WERWTBGpdVcE+qxB9jXq3JWI=
=M28c
-----END PGP SIGNATURE-----
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Mike Banon
2018-11-08 14:29:05 UTC
Permalink
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, 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

Best regards,
Mike Banon
On Thu, Nov 8, 2018 at 1:37 AM Timothy Pearson
Post by Timothy Pearson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by kinky_nekoboi
sounds promissing i will give it a deeper look later.
this makes the SNB/IVY platform much more attractive to me.
thx for the information.
Be aware there's still an Intel ME requirement for those platforms;
while they are old enough that the ME can be significantly reduced, it
cannot be completely eliminated.
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJb42jqAAoJEK+E3vEXDOFb6PIH/0EvBPqEK3hm8wEK/qr21f9K
gNXz5L2vWysfOR4CpAr+dAiB2FGDCa3uBJziQtQi4XRqrnzWerD1lOoQJb+API+G
gS7k88h7f9l8WVr1zug7GS34CnE+hxsCb4q2gZVnuo5B8fdmhywi8/DDOrMfnikM
EvPuYtFnlIOQ+BF523TEqH7CjkjoYxrjQc/pmA0SxZvcwoTZU4YxYTcdF77LPhyk
qcnSI+3mZ6M+Sh64CZ7x8ko2Ap5rKnv3CoPZIAwoqn+4fme22GJKL8p6g/8W1Zwg
o4slXN2G2hkjRpeLvNj0rmODe0ztGEaR5tzauo8WERWTBGpdVcE+qxB9jXq3JWI=
=M28c
-----END PGP SIGNATURE-----
--
https://mail.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
kinky_nekoboi
2018-11-08 14:33:41 UTC
Permalink
hello mike that are great news!
it would be nice if this success would benefit the hudson boards (f2a85m-*) too.
IOMMU and Raminit(no dual channel)
even with microcode are still buggy as hell. But at least this port makes my home workstation as fast and blobfree as possible.

greetings
the nekoboi
Post by Mike Banon
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, 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
Best regards,
Mike Banon
On Thu, Nov 8, 2018 at 1:37 AM Timothy Pearson
Post by Timothy Pearson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by kinky_nekoboi
sounds promissing i will give it a deeper look later.
this makes the SNB/IVY platform much more attractive to me.
thx for the information.
Be aware there's still an Intel ME requirement for those platforms;
while they are old enough that the ME can be significantly reduced,
it
Post by Timothy Pearson
cannot be completely eliminated.
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJb42jqAAoJEK+E3vEXDOFb6PIH/0EvBPqEK3hm8wEK/qr21f9K
gNXz5L2vWysfOR4CpAr+dAiB2FGDCa3uBJziQtQi4XRqrnzWerD1lOoQJb+API+G
gS7k88h7f9l8WVr1zug7GS34CnE+hxsCb4q2gZVnuo5B8fdmhywi8/DDOrMfnikM
EvPuYtFnlIOQ+BF523TEqH7CjkjoYxrjQc/pmA0SxZvcwoTZU4YxYTcdF77LPhyk
qcnSI+3mZ6M+Sh64CZ7x8ko2Ap5rKnv3CoPZIAwoqn+4fme22GJKL8p6g/8W1Zwg
o4slXN2G2hkjRpeLvNj0rmODe0ztGEaR5tzauo8WERWTBGpdVcE+qxB9jXq3JWI=
=M28c
-----END PGP SIGNATURE-----
--
https://mail.coreboot.org/mailman/listinfo/coreboot
Mike Banon
2018-11-08 14:48:22 UTC
Permalink
A10-5750M CPU of AMD Lenovo G505S laptop is from the same Richland 15h
family as your F2A85M-* , and its' southbridge A76M should be also
very similar to what you have: its' Bolton-M3 but there's a relatively
small difference between these Bolton and Hudson since they are from
the same family of FCH (
https://en.wikipedia.org/wiki/List_of_AMD_chipsets#Fusion_controller_hubs_(FCH)
) . Although I don't know why your IOMMU isn't working and why these
Raminit problems are happening, its definitely possible to fix them,
maybe even by wisely borrowing some of G505S specific source code
(comparing the sources and trying to borrow some sources your board
might be lacking). In addition, try looking through the mailing lists
/ board_status reports to find the people who have the same
motherboard as you and CC them your e-mails in case they aren't
subscribed to coreboot mailing list; maybe they could tell you some
useful info: e.g. what if IOMMU and Raminit were working before but
got broken by some bad commit; if you'd know that some of this has
been working before together with an approximate date, it'd be
possible to triangulate the "things-breaking" commit by doing the
dichotomy (e.g. it should take just 10 tries to go through 1024
commits and find which one broke it)

Best regards,
Mike Banon
On Thu, Nov 8, 2018 at 5:33 PM kinky_nekoboi
Post by kinky_nekoboi
hello mike that are great news!
it would be nice if this success would benefit the hudson boards (f2a85m-*) too.
IOMMU and Raminit(no dual channel)
even with microcode are still buggy as hell. But at least this port makes my home workstation as fast and blobfree as possible.
greetings
the nekoboi
Post by Mike Banon
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, 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
Best regards,
Mike Banon
On Thu, Nov 8, 2018 at 1:37 AM Timothy Pearson
Post by Timothy Pearson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Post by kinky_nekoboi
sounds promissing i will give it a deeper look later.
this makes the SNB/IVY platform much more attractive to me.
thx for the information.
Be aware there's still an Intel ME requirement for those platforms;
while they are old enough that the ME can be significantly reduced, it
cannot be completely eliminated.
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJb42jqAAoJEK+E3vEXDOFb6PIH/0EvBPqEK3hm8wEK/qr21f9K
gNXz5L2vWysfOR4CpAr+dAiB2FGDCa3uBJziQtQi4XRqrnzWerD1lOoQJb+API+G
gS7k88h7f9l8WVr1zug7GS34CnE+hxsCb4q2gZVnuo5B8fdmhywi8/DDOrMfnikM
EvPuYtFnlIOQ+BF523TEqH7CjkjoYxrjQc/pmA0SxZvcwoTZU4YxYTcdF77LPhyk
qcnSI+3mZ6M+Sh64CZ7x8ko2Ap5rKnv3CoPZIAwoqn+4fme22GJKL8p6g/8W1Zwg
o4slXN2G2hkjRpeLvNj0rmODe0ztGEaR5tzauo8WERWTBGpdVcE+qxB9jXq3JWI=
=M28c
-----END PGP SIGNATURE-----
--
https://mail.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Kinky Nekoboi
2018-11-08 15:24:27 UTC
Permalink
seems like it was quite silent around these board in the mailing list
except my emails.

the first rom i test was send me by ***@gmail.com it was labeled
coreboot_asus_f2a85-m_1532513585.rom .. i dont know if this is the
commit code of it.

this one was working it think also with IOMMU but it was not able to
drive a radeon addon card.

Does someone no who was working on this boards first .. in the past the
original developer of a port could help me with some problems.
A10-5750M CPU of AMD Lenovo G505S laptop is from the same Richland 15h > family as your F2A85M-* , and its' southbridge A76M should be also >
very similar to what you have: its' Bolton-M3 but there's a relatively >
small difference between these Bolton and Hudson since they are from >
the same family of FCH ( >
https://en.wikipedia.org/wiki/List_of_AMD_chipsets#Fusion_controller_hubs_(FCH)
) . Although I don't know why your IOMMU isn't working and why these >
Raminit problems are happening, its definitely possible to fix them, >
maybe even by wisely borrowing some of G505S specific source code >
(comparing the sources and trying to borrow some sources your board >
might be lacking). In addition, try looking through the mailing lists >
/ board_status reports to find the people who have the same >
motherboard as you and CC them your e-mails in case they aren't >
subscribed to coreboot mailing list; maybe they could tell you some >
useful info: e.g. what if IOMMU and Raminit were working before but >
got broken by some bad commit; if you'd know that some of this has >
been working before together with an approximate date, it'd be >
possible to triangulate the "things-breaking" commit by doing the >
dichotomy (e.g. it should take just 10 tries to go through 1024 >
commits and find which one broke it) > > Best regards, > Mike Banon > On
Thu, Nov 8, 2018 at 5:33 PM kinky_nekoboi >
<***@bluetardis.de> wrote: >> >> hello mike that are great
news! >> it would be nice if this success would benefit the hudson
boards (f2a85m-*) too. >> IOMMU and Raminit(no dual channel) >> even
with microcode are still buggy as hell. But at least this port makes my
home workstation as fast and blobfree as possible. >> >> greetings >>
the nekoboi >> >> Am 8. November 2018 15:29:05 MEZ schrieb Mike Banon
<***@gmail.com>: >>> >>> 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, 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 >>> >>> Best regards, >>> Mike
Banon >>> On Thu, Nov 8, 2018 at 1:37 AM Timothy Pearson >>>
Post by kinky_nekoboi
sounds promissing i will give it a deeper look later.
this makes the SNB/IVY platform much more attractive to me.
thx for the information.
Be aware there's still an Intel ME requirement for those platforms;
while they are old enough that the ME can be significantly reduced, it
cannot be completely eliminated.
https://mail.coreboot.org/mailman/listinfo/coreboot >
Mike Banon
2018-11-08 16:15:12 UTC
Permalink
Maybe not during this month (or even not during this year), but in any
case there should be at least some messages related to your board. I
am suggesting a search request like this one:
https://www.google.com/search?q=%22f2a85m%22+%22coreboot%22+site:mail.coreboot.org
( "f2a85m" "coreboot" site:mail.coreboot.org ), its giving me 60-80
results. Also, you can look through the commit history for this
board's specific code:
https://review.coreboot.org/cgit/coreboot.git/log/src/mainboard/asus/f2a85-m
- although you'd have to separate the commits which are about some
formatting/minor fixes universal to many boards (e.g. src/mainboard:
Capitalize ROM, RAM, CPU and APIC) from those who really
added/removed/changed the features of this board, and focus on the
committers of latter ones

Best regards,
Mike Banon
On Thu, Nov 8, 2018 at 6:24 PM Kinky Nekoboi
seems like it was quite silent around these board in the mailing list except my emails.
this one was working it think also with IOMMU but it was not able to drive a radeon addon card.
Does someone no who was working on this boards first .. in the past the original developer of a port could help me with some problems.
Post by kinky_nekoboi
sounds promissing i will give it a deeper look later.
this makes the SNB/IVY platform much more attractive to me.
thx for the information.
Be aware there's still an Intel ME requirement for those platforms;
while they are old enough that the ME can be significantly reduced, it
cannot be completely eliminated.
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Nico Huber
2018-11-08 20:18:52 UTC
Permalink
Post by Mike Banon
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).
Post by Mike Banon
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.
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Mike Banon
2018-11-09 13:22:24 UTC
Permalink
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
Post by Mike Banon
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).
Post by Mike Banon
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.
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Nico Huber
2018-11-09 18:27:31 UTC
Permalink
Post by 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.
There is no evidence that there is such a thing for Intel systems with
AMT disabled, either.
Post by Mike Banon
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?
Post by Mike Banon
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.
Post by Mike Banon
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.
Post by Mike Banon
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.
Post by Mike Banon
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.
Post by Mike Banon
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.
Post by Mike Banon
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.
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 Banon
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?
Post by Mike Banon
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.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Mike Banon
2018-11-10 23:41:37 UTC
Permalink
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).
Post by Mike Banon
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
Post by 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.
There is no evidence that there is such a thing for Intel systems with
AMT disabled, either.
Post by Mike Banon
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?
Post by Mike Banon
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.
Post by Mike Banon
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.
Post by Mike Banon
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.
Post by Mike Banon
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.
Post by Mike Banon
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.
Post by Mike Banon
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.
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 Banon
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?
Post by Mike Banon
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.org
https://mail.coreboot.org/mailman/listinfo/coreboot
kinky_nekoboi
2018-11-11 03:09:31 UTC
Permalink
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.
Post by Nico Huber
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.
Post by Nico Huber
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).
Post by Nico Huber
Post by Mike Banon
2) AtomDis of AtomBIOS is clear enough to make sure there aren't
any
Post by Nico Huber
Post by Mike Banon
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.
Post by Nico Huber
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?
Post by Nico Huber
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
Post by Nico Huber
Post by Mike Banon
There might be neither ME nor PSP, but that just means the
controllers
Post by Nico Huber
Post by Mike Banon
that are known and researched are absent (it doesn't tell you
anything
Post by Nico Huber
Post by Mike Banon
about less researched ones).
There is no evidence that AMD processors contained any "remote
management" controllers before late 16h family (Puma). Even the
early
Post by Nico Huber
Post by Mike Banon
16h (Jaguar) is okay in this relation, and G505S CPU is 15h
(Richland) -
Post by Nico Huber
Post by Mike Banon
so, unlike the recent Intels, it does not contain any "remote
management" controllers that might be exploited as a hardware
backdoor> via some vulnerability.
Post by Nico Huber
There is no evidence that there is such a thing for Intel systems
with
Post by Nico Huber
AMT disabled, either.
Post by Mike Banon
AMD graphics driver developers force you to put a usually
proprietary
Post by Nico Huber
Post by Mike Banon
AtomBIOS into your firmware.
1) You can move AtomBIOS from the firmware to GRUB/Linux kernel
stage.
Post by Nico Huber
Post by Mike Banon
Putting it into your firmware is more convenient - but it's not the
only
Post by Nico Huber
Post by Mike Banon
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 Banon
2) AtomDis of AtomBIOS is clear enough to make sure there aren't
any
Post by Nico Huber
Post by Mike Banon
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 Banon
The G505s still uses AGESA (a hard to maintain AMD reference
code).
Post by Nico Huber
Post by Mike Banon
This (and actually the native coreboot AMD code too) might get
moved
Post by Nico Huber
Post by Mike Banon
away from our master branch after any release.
You are correct, it could be that one day coreboot will go full
Intel.
Post by Nico Huber
That's not what I said. Actually, there is actively maintained AMD
code
Post by Nico Huber
in our repo. I was talking about unmaintained code.
Post by Mike Banon
But that is more likely to happen simply because the corporations
participating in the development of coreboot aren't interested at
any
Post by Nico Huber
Post by Mike Banon
AMD boards.
Nope, it's because the unmaintained code is no fun at all to work
with.
Post by Nico Huber
If I (as a non-corporate contributor) want to clean something up
across
Post by Nico Huber
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 Banon
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
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
(AMD) platforms are not the problem. Maybe the problem is that their
fans got lazy and rested on AGESA, idk.
Post by Mike Banon
The last time I worked on a bigger patch set in my spare time, I
nearly
Post by Nico Huber
Post by Mike Banon
gave up after some nights of work because of the unmaintainable
mess
Post by Nico Huber
Post by Mike Banon
around {cpu,nb,sb}/amd/
If its difficult to write the crossplatform code in some cases or
if you
Post by Nico Huber
Post by Mike Banon
aren't interested at AMD boards (understandable if you don't have
any),
Post by Nico Huber
Post by Mike Banon
you could use something like "ifdef INTEL_BOARD then
Enable_Feature_X
Post by Nico Huber
Post by Mike Banon
else Dont_Enable". Better to live without some not-essential
features
Post by Nico Huber
Post by Mike Banon
than removing the boards, especially since there really aren't a
lot of
Post by Nico Huber
Post by Mike Banon
coreboot-supported motherboards.
That makes no sense at all. Either you want to have new features, up
to
Post by Nico Huber
date support etc., then we have to maintain it on the master branch.
If
Post by Nico Huber
we "ifdef" things out, it's the same as having it on a separate
branch.
Post by Nico Huber
Post by Mike Banon
I believe it's only a question of time until coreboot maintainers
are
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
for AMD (in production) compared to Intel. But to be honest, Intel
does
Post by Nico Huber
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
Post by Nico Huber
Post by Mike Banon
monitor on" *) "Kabylake unable to boot with post code 0x71" +
could dig
Post by Nico Huber
Post by Mike Banon
out much more if required.
Even from a bystander's point of view it is quite obvious that many
of
Post by Nico Huber
Post by Mike Banon
these Intel-specific problems have been caused by the improper
software
Post by Nico Huber
Post by Mike Banon
design and insufficient source code quality. Luckily you seem to
recognize these problems, as I could see from some of your messages
like
Post by Nico Huber
Post by Mike Banon
this one -
https://mail.coreboot.org/pipermail/coreboot/2018-November/087722.html .
Post by Nico Huber
Post by Mike Banon
Whether this has been caused by Intel outsourcing to developing
countries, or "quantity-over-quality" approach, I don't know.
despite the Intel source code being as messy as AMD (if not more
messy)
Post by Nico Huber
Post by Mike Banon
you don't see any serious discussions regarding the removal/rewrite
of
Post by Nico Huber
Post by Mike Banon
Intel, and we all know why.
Nope, as said above, the unmaintained AMD is a hell a lot messier.
Post by Mike Banon
A good solution would be to write native coreboot code for this
platform from scratch. Something at least of the quality of
intel/x4x
Post by Nico Huber
Post by Mike Banon
(and the compatible southbridges) would be much appreciated and
would
Post by Nico Huber
Post by Mike Banon
likely maintain itself for some years.
But that will not protect AMD code from removal. When someone will
want
Post by Nico Huber
Post by Mike Banon
to remove it, in any case they will find a reason: either "EOL and
old"
Post by Nico Huber
Post by Mike Banon
(could happen to intel/x4x regardless of its' source code quality)
or
Post by Nico Huber
Post by Mike Banon
"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,
Post by Nico Huber
the unmaintained AMD code would be high up on the list of what to
drop
Post by Nico Huber
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
Post by Nico Huber
developers in the community. You are asking them to maintain the
crappy
Post by Nico Huber
code too, for less fun and no money. How should that ever work out?
Post by Mike Banon
Sorry, but it seemed more like "Please avoid AMD if possible, its'
going
Post by Nico Huber
Post by Mike Banon
to be removed". Problem that its hard to avoid AMD without going
Intel,
Post by Nico Huber
Post by Mike Banon
and there are a lot more reasons to avoid Intel than AMD: in
addition to
Post by Nico Huber
Post by Mike Banon
the earlier introduction of remote management controllers and being
a
Post by Nico Huber
Post by Mike Banon
monopoly, there are serious Intel-only security vulnerabilities
like
Post by Nico Huber
Post by Mike Banon
Meltdown which requires a 5%-30% performance degrading patch and
Intel
Post by Nico Huber
Post by Mike Banon
hyperthreading will be disabled soon (
https://www.theregister.co.uk/2018/11/02/portsmash_intel_security_attack/).
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
like AMD but because I don't like this list to look dubious, i.e.
that
Post by Nico Huber
we would accept biased arguments without correcting them.
Nico
--
https://mail.coreboot.org/mailman/listinfo/coreboot
Nico Huber
2018-11-11 23:27:05 UTC
Permalink
Post by kinky_nekoboi
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.
With the "free" parts of amdgpu you have no modesetting, AFAICT. I don't
see how that is a good option. They don't document their display engine,
AFAIK. That plus that AMD graphics driver developers make the impression
that they wouldn't accept open-source modesetting into the Linux kernel
is why I never started to look into writing native gfx init for AMD.
Which works fine for Intel btw., they are very open in that area.
Post by kinky_nekoboi
And i am personaly much less worried about some vgabios or gpu microcode
than an backdoor processor on my main cpu.
Why? If you don't even know what runs on your main CPU, why care about
other processors? (let's ignore that you said "backdoor processor" which
could also apply to the AMD platforms this discussion was earlier about)
Integrated graphics processors usually have full RAM access btw.
Post by kinky_nekoboi
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.
That would be much appreciated.

Nico
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Nico Huber
2018-11-11 23:16:25 UTC
Permalink
Post by Mike Banon
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).
When I said `just want to run Linux` I meant exactly the opposite of
what you propose: just/only Linux. Doesn't matter.
Post by Mike Banon
Post by Mike Banon
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.
Well, I wouldn't expect AtomDis to output something like EvilFunction.
What would you expect is suspicious? For me, VRAM_UsageByFirmware is
definitely something I'd look into before I could tell. VRAM in the
integrated graphics case, might be your system RAM. Maybe this could be
used to give accidental access to some RAM that isn't supposed to be
used as VRAM?
Post by Mike Banon
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.
We were talking about the G505s, right?
Post by Mike Banon
Meanwhile you can't avoid the closed source Intel FSP the same
way.
There's no board in coreboot that uses FSP and would compare to the
G505s.
Post by Mike Banon
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?
I don't think so. Maybe nobody even asked to keep these boards.
Post by Mike Banon
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
I'm not sure what to say. Do you imply that open source makes anything
more secure? There are some benefits in open-source development that
seem to result in rather secure code. For instance, reviewing processes,
that you get more people look at the code etc. But I don't see that for
AGESA (maybe because I didn't try to read it). I don't know if it has
ever been audited with security in mind or even reviewed. Most of the
AGESA related work in coreboot is about wrapping it, so nobody has to
look into it. For me, using open-source AGESA is no more secure than
using FSP (until I read its code).

That's also why I never ask silicon vendors for code but for documen-
tation instead. If the code isn't written/reviewed/maintained by an
open-source community, what's the point of open source? (I know I know,
freedom to adapt it, but that doesn't make it secure per se.)

Nico
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
T***@gmx.com
2018-11-10 18:08:48 UTC
Permalink
If you want an owner controlled coreboot-libre firmware (coreboot isn't
always foss) available board get a kcma-d8, kgpe-d16, etc. or one of the
raptor computing systems OpenPOWER boards which have foss firmware (not
coreboot) from the factory, documentation and are owner controlled.

You can score a D16 new on fleabay for $150 ATM plus a 6328 cpu for $30
resulting in (with ram and a good amd gfx card) being able to play games
in a vm at max settings - there are a lot of good native linux and or
drm free games right now. It seems those new D16's sold there also have
the ASMB4 chip you need for OpenBMC.

the G34/C32 opterons are much faster than the G41's C2Q's and the
OpenPOWER9 stuff is much faster than intel/amd's proprietary blobbed x86
offerings of comparable price

I have wrote longer posts about that in the past so look 'em up :D and
welcome to the community.

I concur the g505s is a superior choice to a me'ed device as me can't be
disabled...unlike with workstations you can't have perfect with a laptop
right now here's hoping for a openpower laptop.
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
e***@free.fr
2018-11-11 13:52:28 UTC
Permalink
+1
Me too, I strongly support the point of view of Mike. Freedom, be it in software or hardware is not negotiable!..
But on the other hand the point of view of Nico is also very legitimate. Having had to deal in my professional life with legacy code which was badly written and unmaintained (or unsupported) by the original issuer, I know what a nightmare can arise in this situation!..
So by force of circumstances, unfortunately, we can expect that the g505s (of other agesa based boards) will indeed be dropped from the coreboot master in the near future..
We (the owners of agesa based boards) need to prepare for this eventuality, and maybe if we want to keep coreboot alive (and evolving) on our platforms we should consider a fork... Please don't insult me for this for this reasoning (it is not even a proposal..), but we must face the reality..
One problem I notice is that almost all the experts in the coreboot comunity are focusing on Intel platforms nowadays (for professional reasons I suppose..). So when "the push come to shove", it will be hard for us newbs (yes Im an eternal newb in coreboot.. ;-)) to get advice and support in our maintaining efforts..
Anyway I think that it is stupid to get offensive and confrontational with the coreboot comunity even if it gets more and more Intel oriented..

My 2 satoshis,
Florentin

----- Mail d'origine -----
De: kinky_nekoboi <***@bluetardis.de>
À: ***@coreboot.org, Mike Banon <***@gmail.com>, Nico Huber <***@gmx.de>, coreboot <***@coreboot.org>
Envoyé: Sun, 11 Nov 2018 04:09:31 +0100 (CET)
Objet: Re: [coreboot] Supported Motherboards

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.
Post by Nico Huber
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.
Post by Nico Huber
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).
Post by Nico Huber
Post by Mike Banon
2) AtomDis of AtomBIOS is clear enough to make sure there aren't
any
Post by Nico Huber
Post by Mike Banon
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.
Post by Nico Huber
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?
Post by Nico Huber
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
Post by Nico Huber
Post by Mike Banon
There might be neither ME nor PSP, but that just means the
controllers
Post by Nico Huber
Post by Mike Banon
that are known and researched are absent (it doesn't tell you
anything
Post by Nico Huber
Post by Mike Banon
about less researched ones).
There is no evidence that AMD processors contained any "remote
management" controllers before late 16h family (Puma). Even the
early
Post by Nico Huber
Post by Mike Banon
16h (Jaguar) is okay in this relation, and G505S CPU is 15h
(Richland) -
Post by Nico Huber
Post by Mike Banon
so, unlike the recent Intels, it does not contain any "remote
management" controllers that might be exploited as a hardware
backdoor> via some vulnerability.
Post by Nico Huber
There is no evidence that there is such a thing for Intel systems
with
Post by Nico Huber
AMT disabled, either.
Post by Mike Banon
AMD graphics driver developers force you to put a usually
proprietary
Post by Nico Huber
Post by Mike Banon
AtomBIOS into your firmware.
1) You can move AtomBIOS from the firmware to GRUB/Linux kernel
stage.
Post by Nico Huber
Post by Mike Banon
Putting it into your firmware is more convenient - but it's not the
only
Post by Nico Huber
Post by Mike Banon
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 Banon
2) AtomDis of AtomBIOS is clear enough to make sure there aren't
any
Post by Nico Huber
Post by Mike Banon
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 Banon
The G505s still uses AGESA (a hard to maintain AMD reference
code).
Post by Nico Huber
Post by Mike Banon
This (and actually the native coreboot AMD code too) might get
moved
Post by Nico Huber
Post by Mike Banon
away from our master branch after any release.
You are correct, it could be that one day coreboot will go full
Intel.
Post by Nico Huber
That's not what I said. Actually, there is actively maintained AMD
code
Post by Nico Huber
in our repo. I was talking about unmaintained code.
Post by Mike Banon
But that is more likely to happen simply because the corporations
participating in the development of coreboot aren't interested at
any
Post by Nico Huber
Post by Mike Banon
AMD boards.
Nope, it's because the unmaintained code is no fun at all to work
with.
Post by Nico Huber
If I (as a non-corporate contributor) want to clean something up
across
Post by Nico Huber
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 Banon
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
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
(AMD) platforms are not the problem. Maybe the problem is that their
fans got lazy and rested on AGESA, idk.
Post by Mike Banon
The last time I worked on a bigger patch set in my spare time, I
nearly
Post by Nico Huber
Post by Mike Banon
gave up after some nights of work because of the unmaintainable
mess
Post by Nico Huber
Post by Mike Banon
around {cpu,nb,sb}/amd/
If its difficult to write the crossplatform code in some cases or
if you
Post by Nico Huber
Post by Mike Banon
aren't interested at AMD boards (understandable if you don't have
any),
Post by Nico Huber
Post by Mike Banon
you could use something like "ifdef INTEL_BOARD then
Enable_Feature_X
Post by Nico Huber
Post by Mike Banon
else Dont_Enable". Better to live without some not-essential
features
Post by Nico Huber
Post by Mike Banon
than removing the boards, especially since there really aren't a
lot of
Post by Nico Huber
Post by Mike Banon
coreboot-supported motherboards.
That makes no sense at all. Either you want to have new features, up
to
Post by Nico Huber
date support etc., then we have to maintain it on the master branch.
If
Post by Nico Huber
we "ifdef" things out, it's the same as having it on a separate
branch.
Post by Nico Huber
Post by Mike Banon
I believe it's only a question of time until coreboot maintainers
are
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
for AMD (in production) compared to Intel. But to be honest, Intel
does
Post by Nico Huber
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
Post by Nico Huber
Post by Mike Banon
monitor on" *) "Kabylake unable to boot with post code 0x71" +
could dig
Post by Nico Huber
Post by Mike Banon
out much more if required.
Even from a bystander's point of view it is quite obvious that many
of
Post by Nico Huber
Post by Mike Banon
these Intel-specific problems have been caused by the improper
software
Post by Nico Huber
Post by Mike Banon
design and insufficient source code quality. Luckily you seem to
recognize these problems, as I could see from some of your messages
like
Post by Nico Huber
Post by Mike Banon
this one -
https://mail.coreboot.org/pipermail/coreboot/2018-November/087722.html
.
Post by Nico Huber
Post by Mike Banon
Whether this has been caused by Intel outsourcing to developing
countries, or "quantity-over-quality" approach, I don't know.
despite the Intel source code being as messy as AMD (if not more
messy)
Post by Nico Huber
Post by Mike Banon
you don't see any serious discussions regarding the removal/rewrite
of
Post by Nico Huber
Post by Mike Banon
Intel, and we all know why.
Nope, as said above, the unmaintained AMD is a hell a lot messier.
Post by Mike Banon
A good solution would be to write native coreboot code for this
platform from scratch. Something at least of the quality of
intel/x4x
Post by Nico Huber
Post by Mike Banon
(and the compatible southbridges) would be much appreciated and
would
Post by Nico Huber
Post by Mike Banon
likely maintain itself for some years.
But that will not protect AMD code from removal. When someone will
want
Post by Nico Huber
Post by Mike Banon
to remove it, in any case they will find a reason: either "EOL and
old"
Post by Nico Huber
Post by Mike Banon
(could happen to intel/x4x regardless of its' source code quality)
or
Post by Nico Huber
Post by Mike Banon
"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,
Post by Nico Huber
the unmaintained AMD code would be high up on the list of what to
drop
Post by Nico Huber
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
Post by Nico Huber
developers in the community. You are asking them to maintain the
crappy
Post by Nico Huber
code too, for less fun and no money. How should that ever work out?
Post by Mike Banon
Sorry, but it seemed more like "Please avoid AMD if possible, its'
going
Post by Nico Huber
Post by Mike Banon
to be removed". Problem that its hard to avoid AMD without going
Intel,
Post by Nico Huber
Post by Mike Banon
and there are a lot more reasons to avoid Intel than AMD: in
addition to
Post by Nico Huber
Post by Mike Banon
the earlier introduction of remote management controllers and being
a
Post by Nico Huber
Post by Mike Banon
monopoly, there are serious Intel-only security vulnerabilities
like
Post by Nico Huber
Post by Mike Banon
Meltdown which requires a 5%-30% performance degrading patch and
Intel
Post by Nico Huber
Post by Mike Banon
hyperthreading will be disabled soon (
https://www.theregister.co.uk/2018/11/02/portsmash_intel_security_attack/).
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
Post by Mike Banon
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
Post by Nico Huber
like AMD but because I don't like this list to look dubious, i.e.
that
Post by Nico Huber
we would accept biased arguments without correcting them.
Nico
--
https://mail.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listi
Nico Huber
2018-11-11 23:46:26 UTC
Permalink
Post by e***@free.fr
So by force of circumstances, unfortunately, we can expect that the
g505s (of other agesa based boards) will indeed be dropped from the
coreboot master in the near future..
That's not what I said or intended to say (we might know if ppl.
wouldn't top post). I meant things may always be removed if not pro-
perly maintained, and that the AGESA code is one of these areas. It
wouldn't even be the first thing I'd drop, if I ever start to drop
things.
Post by e***@free.fr
We (the owners of agesa based boards) need to prepare for this
eventuality, and maybe if we want to keep coreboot alive (and evolving)
on our platforms we should consider a fork... Please don't insult me
for this for this reasoning (it is not even a proposal..), but we must
face the reality..
Hmmm... I remember when these discussions around "board removals" from
the master branch started, we tried to make clear that development of
these boards could continue on other branches. These boards wouldn't get
the latest and greatest features any more but instead would not be
broken trying to add the latest features ;) That seems much better and
easier to handle than a port but was mostly rejected.
Post by e***@free.fr
One problem I notice is that almost all the experts in the coreboot
comunity are focusing on Intel platforms nowadays (for professional
reasons I suppose..).
That's not what I see. There are a lot of young non-professionals (or
at least not employed for coreboot work) who start to work on coreboot.
They mostly end up working with Intel hardware too. Code quality might
be an issue. Compared to the better maintained open-source Intel code,
AGESA is much harder to read, some AMD code barely readable. The diver-
gence of AMD code might also be an issue. The Intel code all looks the
same and is easy to get into; if you read and understood one platform,
you understand the half of all Intel platforms in coreboot. For AMD
there are sometimes different implementations even for a single chip.
Post by e***@free.fr
So when "the push come to shove", it will be hard
for us newbs (yes Im an eternal newb in coreboot.. ;-)) to get advice
and support in our maintaining efforts..
AMD might be harder to configure than Intel, I'm not sure. But! there is
public documentation for a lot of the older platforms. It's likely not
complete but should be good enough to design the code. With some luck
you'd only need to look into AGESA to fill the gaps.

Nico
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
kinky_nekoboi
2018-11-11 23:54:44 UTC
Permalink
BTW does anybody now if IOMMU ever has worked on F2A85M.
Its kinda frustrating that there is nobody who seems to use this board.
is it maybe only broken on the richland core since i use a A8-6600K
Post by Nico Huber
Post by e***@free.fr
So by force of circumstances, unfortunately, we can expect that the
g505s (of other agesa based boards) will indeed be dropped from the
coreboot master in the near future..
That's not what I said or intended to say (we might know if ppl.
wouldn't top post). I meant things may always be removed if not pro-
perly maintained, and that the AGESA code is one of these areas. It
wouldn't even be the first thing I'd drop, if I ever start to drop
things.
Post by e***@free.fr
We (the owners of agesa based boards) need to prepare for this
eventuality, and maybe if we want to keep coreboot alive (and
evolving)
Post by e***@free.fr
on our platforms we should consider a fork... Please don't insult me
for this for this reasoning (it is not even a proposal..), but we
must
Post by e***@free.fr
face the reality..
Hmmm... I remember when these discussions around "board removals" from
the master branch started, we tried to make clear that development of
these boards could continue on other branches. These boards wouldn't get
the latest and greatest features any more but instead would not be
broken trying to add the latest features ;) That seems much better and
easier to handle than a port but was mostly rejected.
Post by e***@free.fr
One problem I notice is that almost all the experts in the coreboot
comunity are focusing on Intel platforms nowadays (for professional
reasons I suppose..).
That's not what I see. There are a lot of young non-professionals (or
at least not employed for coreboot work) who start to work on coreboot.
They mostly end up working with Intel hardware too. Code quality might
be an issue. Compared to the better maintained open-source Intel code,
AGESA is much harder to read, some AMD code barely readable. The diver-
gence of AMD code might also be an issue. The Intel code all looks the
same and is easy to get into; if you read and understood one platform,
you understand the half of all Intel platforms in coreboot. For AMD
there are sometimes different implementations even for a single chip.
Post by e***@free.fr
So when "the push come to shove", it will be hard
for us newbs (yes Im an eternal newb in coreboot.. ;-)) to get
advice
Post by e***@free.fr
and support in our maintaining efforts..
AMD might be harder to configure than Intel, I'm not sure. But! there is
public documentation for a lot of the older platforms. It's likely not
complete but should be good enough to design the code. With some luck
you'd only need to look into AGESA to fill the gaps.
Nico
--
https://mail.coreboot.org/mailman/listinfo/coreboot
ron minnich
2018-11-12 14:05:32 UTC
Permalink
Post by e***@free.fr
Anyway I think that it is stupid to get offensive and confrontational with the coreboot comunity even if it gets more and more Intel oriented..
so is this statement based on a measurement or just your impression?

I count 181 mainboard devicetree.cb files in the tree. Of these 73
have the string cpu.*intel in them. So less than half. Next we'd have
to see how this changes over time.

In 2012 there were 179 boards in the tree, 57 with that string in them.

Not a giant change.

If someone would like to correct my numbers or methodology that would
be interesting but I think the claim fails. I'd also point out that
starting in 2013 we re-introduced multiple architecture to the tree
with arm and that has continued to grow (we had alpha, ppc and arm ca.
2005 but it got lost).

as always, code wins. I think if you want truly open architecture,
this is the year to stop working on obsolete hardware and get on riscv
or power or even arm. We need your help!

ron
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Nico Huber
2018-11-11 23:58:05 UTC
Permalink
The size of AGESA is currently about 10% of coreboot. Nico, do you
think a single person working in spare time can reimplement 10% of
coreboot?
I don't care how much it looks like. It's likely bloated vendor code.
For instance, look at the numbers for this:

$ tokei src/cpu/amd/family_10h-family_15h/
src/northbridge/amd/{amdfam10/,amdht/,amdmct/}

I wouldn't be surprised if this non-agesa code even covers more than
a single AGESA platform (like agesa/f15tn). So that might also be 1%
instead of 10%, it's hard to compare.

That's still a lot of code. I don't know how hard it is to configure
AMD compared to Intel. But for Intel a lot platforms just showed up
because somebody did it in his spare time (without documentation). So
it seems doable.

Nico
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
T***@gmx.com
2018-11-25 05:04:05 UTC
Permalink
I get the impressions that a few people are quite vocal on the mailing
list about keeping stuff in the master branch that fell into disrepair
and hinders the project in moving forward and improving things.
I can agree yes some stuff that clearly no longer works should be
removed from master but people were talking about for instance removing
the native fam15h boards KGPE-D16 and KCMA-D8 (last and best owner
controlled libre firmware x86 boards and arguably the best examples of
coreboot ports and hw init code) because they thought they didn't have a
working S3 mode without soliciting someone to test it until I reported
back that it still works (I use it all the time and tested it in master).

I feel as though at the current rate of people being too eager to remove
still functional boards for arbitrary reasons there won't be any easily
obtainable non development boards on master - another side issue is that
coreboot repos don't contain the libs required to compile the older
versions which are becoming increasingly unavailable with some only
downloadable from a single site hence I suggest the direct hosting of
them rather than requiring people to download from third party websites
that may or may not work in the future.

There needs to be some type of solution to this issue or in so many
years coreboot master will no longer be an open source firmware project
since it will only be able to initiate new x86 systems that happen to
require binary blobs.

I have never met a comp-sci/comp-engineering graduate or anyone in a
computer field who has heard of coreboot and that needs to change -
there needs to be some type of advertising so that there can be more
than a few wizards capable of the dark arts of firmware editing and who
have the time and resources to deal with arbitrary continued maintenance.
but those few people seem to mostly complain, but don't either contribute
patches to be merged in upstream master or hire people to fix things.
I have provided technical support to over 100 coreboot users and have
enticed many more to procure a supported board and start using it, I
also donate to projects and provide hardware to developers when I
can...the ways you say are not the only ways to contribute :D
--
coreboot mailing list: ***@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Matt B
2018-11-25 20:01:02 UTC
Permalink
I need to pick a better email client, or remember to say "reply all"

---------- Forwarded message ---------
From: Matt B <***@gmail.com>
Date: Sun, Nov 25, 2018 at 2:59 PM
Subject: Re: [coreboot] Supported Motherboards
To: <***@gmx.com>


I also don't see "drop it and if someone likes it they'll work to get it
back to master" as being more than a band-aid solution. It doesn't do
anything to raise the probability of bad code getting dealt with, but it
does put the problem out of sight and out of mind.

The reason people who use this laptop are so resistant is that they see it
as a statement that the speaker doesn't care about fixing what's broken and
would much rather it just disappear. (regardless of who happens to be using
it) It's saying you want the other side just be quiet and go away, which
isn't constructive.

-Matt
Hi,
It seems that whenever someone mentions the ME (or one of a number of
other topics) the G505s is inevitably recommended, and people subsequently
get into a debate over the relative badness of the ME vs atomBIOS/microcode
ect. [1] This also leads to people lamenting the G505s for it's shitty
AGESA codebase [2], and arguments over dropping boards like the G505s from
master. If the thread gets really nasty, it gets into arguments over
corporate influence of coreboot.
But this cycle of arguments doesn't get us anywhere and the G505s code
continues to languish. It hasn't been abandoned *yet* but it doesn't become
any less likely that some new feature will lead to it getting dropped [3].
I think this is tragic, since it's a still reasonably powerful laptop,
probably took a lot of porting work, and has advantages over a lot of
alternatives. [4] The fundamental problem seems to me to be that there are
a hell of a lot of people who use G505s (seems very popular with people who
run qubes), there haven't been a lot of people with the skill or
inclination [5] to do the work required to put it on par with [insert
favorite thinkpad]. The task of doing the cleanup or rewrite (whatever is
required) may not be the most immediately attractive or productive task,
but it seems like something that would make everybody a lot happier and
eliminate a lot of arguing in the long run.
Now, I may be a G505s owner, but I'm certainly not qualified to work on
it's code. Rather than argue that "some developer"
should, I'd like to propose something different. I think we should have a
proper, technical discussion of what we want the G505s port to look like,
what the best means to get there is (cleanup or rewrite, for example), and
based on who wants to volunteer and who would be willing to do it under
contract, figure out how much it would cost. Then we ask the people who own
G505s or who want to see it improved to pony up the money to make that
happen in a crowd-funding campaign, like any other open source software
project would. [6]
Then maybe we can firmly put this laptop on the list of "great to use
with coreboot" without this massive asterisk beside it.
Sincerely,
-Matt
[1] It's interesting to note that there has been some recent movement on
improving the atomBIOS situation a little bit. While I have a hard time
imagining a future where all the drivers are patched to not need atomBIOSs,
I can imagine a future where we compile and use open source
re-implementations of existing atomBIOSs.
https://www.phoronix.com/scan.php?page=news_item&px=Flashrom-AMD-SPI-Patches
[2] For an example, look no further that is the current workaround for
getting up-to-date microcode into these things, which I understand is borne
in part from buggyness in AGESA microcode loading code
[3] These rules are probably very reasonable, but I don't think there's
any way that people won't read them as malicious in contexts like these.
[4] To name a recent example, there are threads from this month that look
like discrete GPU support will come in the immediate future, along with
better support for variants with the A8 APU.
[5] Empirically, since this still hasn't been done. No offense to anyone
who's tried.
[6] Inspired by the recent talk about offering funding to paulk to work on
his open source EC firmware for the G505s.
Loading...