On 11/8/18 3:29 PM, Mike Banon wrote:
Please consider AMD Lenovo G505S laptop: all the hardware virtualizations AMD-V / SLAT / IOMMU are fully supported there (although you have to install a microcode update to avoid the possible glitches), no Intel ME / AMD PSP, quad-core CPU, 16GB DDR3 RAM possible, recent build_status report,
Please avoid the G505s if possible. There might be neither ME nor PSP, but that just means the controllers that are known and researched are absent (it doesn't tell you anything about less researched ones). Also, if you want to use its integrated graphics, you can't run fully free software (not even on the main CPU) because AMD graphics driver develo- pers force you to put a usually proprietary AtomBIOS into your firmware. The Linux radeon/amdgpu drivers are only open source because they hide the proprietary parts in the host firmware (BIOS/coreboot, not some firmware that runs on the gfx processor).
and there's a cosy community around it and we intend to support it for a looong time - as long as all our G505S last
That's good to hear. But here comes a warning: The G505s still uses AGESA (a hard to maintain AMD reference code). This (and actually the native coreboot AMD code too) might get moved away from our master branch after any release. I believe it's only a question of time until coreboot maintainers are finally fed up with it*.
A good solution would be to write native coreboot code for this platform from scratch. Something at least of the quality of intel/x4x (and the compatible southbridges) would be much appreciated and would likely maintain itself for some years.
Nico
* The last time I worked on a bigger patch set in my spare time, I nearly gave up after some nights of work because of the unmain- tainable mess around {cpu,nb,sb}/amd/. It's dragging the whole project down, IMHO.
There might be neither ME nor PSP, but that just means the controllers that are known and researched are absent (it doesn't tell you anything about less researched ones).
There is no evidence that AMD processors contained any "remote management" controllers before late 16h family (Puma). Even the early 16h (Jaguar) is okay in this relation, and G505S CPU is 15h (Richland) - so, unlike the recent Intels, it does not contain any "remote management" controllers that might be exploited as a hardware backdoor via some vulnerability.
AMD graphics driver developers force you to put a usually proprietary AtomBIOS into your firmware.
1) You can move AtomBIOS from the firmware to GRUB/Linux kernel stage. Putting it into your firmware is more convenient - but it's not the only solution and could be avoided (e.g. by following some of these instructions - https://bugs.freedesktop.org/show_bug.cgi?id=26891 )
2) AtomDis of AtomBIOS is clear enough to make sure there aren't any backdoors ( https://pastebin.com/xKW9FV58 ), perhaps that's why the efforts like OpenAtom ( https://github.com/alterapraxisptyltd/openatom/ + https://github.com/mrnuke/radeon ) and OpenRadeonBIOS ( https://sourceforge.net/p/openradeonbios/ ) have been suspended.
The G505s still uses AGESA (a hard to maintain AMD reference code). This (and actually the native coreboot AMD code too) might get moved away from our master branch after any release.
You are correct, it could be that one day coreboot will go full Intel. But that is more likely to happen simply because the corporations participating in the development of coreboot aren't interested at any AMD boards. So the future coreboot indeed might support only some Google/Purism computers together with Intel/Facebook/etc. in-house proprietary boards, and there will not be any coreboot-supported boards without Intel ME + full complex set of their blobs (FSP etc.)
The last time I worked on a bigger patch set in my spare time, I nearly gave up after some nights of work because of the unmaintainable mess around {cpu,nb,sb}/amd/
If its difficult to write the crossplatform code in some cases or if you aren't interested at AMD boards (understandable if you don't have any), you could use something like "ifdef INTEL_BOARD then Enable_Feature_X else Dont_Enable". Better to live without some not-essential features than removing the boards, especially since there really aren't a lot of coreboot-supported motherboards.
I believe it's only a question of time until coreboot maintainers are finally fed up with it.
The majority of platform-specific problems discussed at the mailing lists are directly related to Intel. Sometimes I'm seeing so many of them flooding my inbox, I'm wondering how the coreboot maintainers aren't fed up with Intel mess. Here are some long thread examples:
*) "How to get correct memory params for FSP" *) "[skylake] Can not turn monitor on" *) "Kabylake unable to boot with post code 0x71" + could dig out much more if required.
Even from a bystander's point of view it is quite obvious that many of these Intel-specific problems have been caused by the improper software design and insufficient source code quality. Luckily you seem to recognize these problems, as I could see from some of your messages like this one - https://mail.coreboot.org/pipermail/coreboot/2018-November/087722.html . Whether this has been caused by Intel outsourcing to developing countries, or "quantity-over-quality" approach, I don't know. However: despite the Intel source code being as messy as AMD (if not more messy) you don't see any serious discussions regarding the removal/rewrite of Intel, and we all know why.
A good solution would be to write native coreboot code for this platform from scratch. Something at least of the quality of intel/x4x (and the compatible southbridges) would be much appreciated and would likely maintain itself for some years.
But that will not protect AMD code from removal. When someone will want to remove it, in any case they will find a reason: either "EOL and old" (could happen to intel/x4x regardless of its' source code quality) or "no feature/property X we've introduced and absolutely require" (something like "late vs early init") or simply "why should we care about AMD boards if we work with/at Intel". Maybe then the coreboot project will be forked and there will be two coreboots: one for the people, and another for corporations.
Sorry, but it seemed more like "Please avoid AMD if possible, its' going to be removed". Problem that its hard to avoid AMD without going Intel, and there are a lot more reasons to avoid Intel than AMD: in addition to the earlier introduction of remote management controllers and being a monopoly, there are serious Intel-only security vulnerabilities like Meltdown which requires a 5%-30% performance degrading patch and Intel hyperthreading will be disabled soon ( https://www.theregister.co.uk/2018/11/02/portsmash_intel_security_attack/ ). Perhaps it makes more sense to say
" Please avoid Intel if possible "
but I don't want to start "Intel vs AMD" holy war there, especially since it seems we are greatly outnumbered by Intel-employed/partnered/sympathetic folks (how could one be sincerely sympathetic to Intel is a big question though).
Best regards, Mike Banon On Thu, Nov 8, 2018 at 11:18 PM Nico Huber nico.h@gmx.de wrote:
On 11/8/18 3:29 PM, Mike Banon wrote:
Please consider AMD Lenovo G505S laptop: all the hardware virtualizations AMD-V / SLAT / IOMMU are fully supported there (although you have to install a microcode update to avoid the possible glitches), no Intel ME / AMD PSP, quad-core CPU, 16GB DDR3 RAM possible, recent build_status report,
Please avoid the G505s if possible. There might be neither ME nor PSP, but that just means the controllers that are known and researched are absent (it doesn't tell you anything about less researched ones). Also, if you want to use its integrated graphics, you can't run fully free software (not even on the main CPU) because AMD graphics driver develo- pers force you to put a usually proprietary AtomBIOS into your firmware. The Linux radeon/amdgpu drivers are only open source because they hide the proprietary parts in the host firmware (BIOS/coreboot, not some firmware that runs on the gfx processor).
and there's a cosy community around it and we intend to support it for a looong time - as long as all our G505S last
That's good to hear. But here comes a warning: The G505s still uses AGESA (a hard to maintain AMD reference code). This (and actually the native coreboot AMD code too) might get moved away from our master branch after any release. I believe it's only a question of time until coreboot maintainers are finally fed up with it*.
A good solution would be to write native coreboot code for this platform from scratch. Something at least of the quality of intel/x4x (and the compatible southbridges) would be much appreciated and would likely maintain itself for some years.
Nico
- The last time I worked on a bigger patch set in my spare time, I nearly gave up after some nights of work because of the unmain- tainable mess around {cpu,nb,sb}/amd/. It's dragging the whole project down, IMHO.
-
Mike Banon -
Nico Huber