-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/10/2017 01:04 PM, Kyösti Mälkki wrote:
Hi Kyösti, Alberto,
At this very moment apu2/apu3 4GB models are marketed without ECC support. Latest available binaryPI build (which contains a fix for ECC) is otherwise not compatible. You can thank AMD for not even allowing their commercial customers, who have access to said PI sources under NDA, to distribute fixed builds.
We planned get back to ECC issue in coming month by exercising 2 ideas from forum [1]:
1. Mentioned by Kyösti usage of UEFI payload and MemTest86 v7 Pro Edition. I already started work on payload [2] and have ability to boot to UEFI shell, but now working storage drivers yet.
2. Use rowhammer_test mentioned in last post [1].
But it looks I completely forget mentioned bug. I assume above scenarios will not work in light of mentioned bug ?
We know which version of AGESA breaks apu2/3. It is [3]. We tried to disable graphics in various ways, but nothing helps.
@Kyösti, maybe it is related to PspMboxBiosCmdDramInfo and PspMboxBiosCmdExitBootServices commands and PSP support in coreboot ?
[1] http://pcengines.info/forums/?page=post&id=E35B5D34-262B-480E-9887-F7F2A 292E02F&fid=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A&pageindex=2 [2] https://github.com/3mdeb/edk2/tree/apu2-uefi [3] https://review.coreboot.org/cgit/blobs.git/commit/?id=95b80508d9ba26350b 7e699decd47074f480a2f2
- -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com
On 09/10/2017 09:49 PM, Piotr Król wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/10/2017 01:04 PM, Kyösti Mälkki wrote:
Hi Kyösti, Alberto,
At this very moment apu2/apu3 4GB models are marketed without ECC support. Latest available binaryPI build (which contains a fix for ECC) is otherwise not compatible. You can thank AMD for not even allowing their commercial customers, who have access to said PI sources under NDA, to distribute fixed builds.
We planned get back to ECC issue in coming month by exercising 2 ideas from forum [1]:
- Mentioned by Kyösti usage of UEFI payload and MemTest86 v7 Pro
Edition. I already started work on payload [2] and have ability to boot to UEFI shell, but now working storage drivers yet.
- Use rowhammer_test mentioned in last post [1].
But it looks I completely forget mentioned bug. I assume above scenarios will not work in light of mentioned bug ?
We know which version of AGESA breaks apu2/3. It is [3]. We tried to disable graphics in various ways, but nothing helps.
@Kyösti, maybe it is related to PspMboxBiosCmdDramInfo and PspMboxBiosCmdExitBootServices commands and PSP support in coreboot ?
[1] http://pcengines.info/forums/?page=post&id=E35B5D34-262B-480E-9887-F7F2A 292E02F&fid=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A&pageindex=2 [2] https://github.com/3mdeb/edk2/tree/apu2-uefi [3] https://review.coreboot.org/cgit/blobs.git/commit/?id=95b80508d9ba26350b 7e699decd47074f480a2f2
Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com
Thanks for your efforts!
A quick-and-dirty way of causing bitflips is overclocking RAM. Once RAM starts becoming unstable, there will be bitflips and the ECC will log errors. The results of this test can't say if the ECC catched *all* bitflips, or just some, but will at least show if it works at all. This was used to get some proof that Ryzen ECC was working [1].
The only other ways of testing ECC RAM is to have dedicated hardware for that, modified DIMMs with a switch or masking tape that interrupts some contacts (or shorting to the ground if it is all soldered like yours). I would trust the hardware method better, as the system can't lie as it theoretically can with ECC injection, and you don't need to rely on Memtest or whatever other software doing a good job.
1. http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/75030-ecc-memo...
-Alberto
-
Alberto Bursi -
Piotr Król