The odd Ryzen 5825U, is it a "Pro" or not?

[abufrejoval]

First time I came across a Ryzen 5825U was in a notebook I bought for one of my kids. I had bought another with a 5800U just a few months before, so I was curious to see how it was different (apart from the fact that he had a bloody brilliant OLED, and I didn't).

It seemed little more than a small refresh of Cezanne called Barceló, yet it enabled the typical Pro features like memory encryption but also ECC.

Now in an LP-DDR laptop ECC wasn't going to happen, this was also clearly a consumer laptop without any remote management, so 5825Us must have been cheap at one point, or just looked a little less dated: it was still using old VEGA style graphics after all.

Fast forward this summer I'm looking for cheap low-power Mini-ITX boards to build µ-servers and I come across a 5825U based 8-port NAS board that sells for less then €200.

It does not support ECC according to the board specs.

I put a pair of 32GB DDR4-3200 SO-DIMMs in and noticed a full set of ECC options in a BIOS, that had tons of options: evidently a developer pre-release version that never got locked down.

But could they have in fact hidden ECC capabilities in a board that was mostly about recycling surpluse AMD APUs?

AMD has been somewhat underhanded but also a bit odd with their support of ECC in APUs in general. Evidently the hardware is there and they are basically playing Intel's dirty game there, fusing off features for nothing but extra bucks in market segmentation.

But in their haste to also deliver seemingly new shiny things to the market every year, they can't be bothered to refresh the entire product range.

So for some reason, the 5825U is the only APU, which always seems to support ECC even without being a Pro... since there isn't a Pro variant ...until they came up with the Barceló-R refreshed refresh, which got 7xxx numbering to everybody's delight.

So I got myself a couple of DDR4-3200 ECC SO-DIMMs from Kingston and gave it a try: the BIOS had no qualms about enabling all those nice ECC options, but MemTest86 V11.3 Pro said there was no ECC.

And so did Linux. And HWinfo on Windows seems to just look for ECC DIMMs, doesn't dig into the memory control registers or similar.

Obviously the board designers could have saved a few copper traces by simply not connecting the 8 extra contacts between FP6 and the SO-DIMM sockets.

But perhaps that Barceló is simply such a little known oddity, that everybody, the BIOS and Linux get it all wrong while in fact it could do ECC with the proper DIMMs?

I've tried using ecc_enable_override=1 on Linux for the amd_edac module with no success.

And I've tried to identify where MemTest86 decides that ECC isn't there:

2025-07-09 09:02:59 - Getting memory controller info
2025-07-09 09:02:59 - find_mem_controller - found AMD Ryzen Zen 3 (50h-5fh) (1022:166C) at 0-24-2
2025-07-09 09:02:59 - AMD Ryzen Zen 2 chipset init
2025-07-09 09:02:59 - CfgAddressCntl = 00000000 (SecBusNum=00)
2025-07-09 09:02:59 - CPUID[0x00000001]:EBX[31:0] = 00100800 (LocalApicId=0, NBC=0, LogicalProcessorCount=16)
2025-07-09 09:02:59 - CPUID[0x00000001]:EDX[31:0] = 178BFBFF (MCA=1)
2025-07-09 09:02:59 - CPUID[0x80000007]:EBX[31:0] = 0000003B (PfehSupportPresent=1, ScalableMCA=1)
2025-07-09 09:02:59 - PFEH_CFG=0000000000000000 (PfehEnable=0)
2025-07-09 09:02:59 - PFEH_CLOAK_CFG=0000000000000000
2025-07-09 09:02:59 - MCG_CAP=000000000000011C (Count=2
2025-07-09 09:02:59 - [MC0] CPUID[0x00000001]:EBX[31:0] = 00100800 (LocalApicId=0, NBC=0, LogicalProcessorCount=16)
2025-07-09 09:02:59 - SdpCtrl[0]=B040808B (SdpInit=1)
2025-07-09 09:02:59 - [MC0] DramConfiguration=00001930
2025-07-09 09:02:59 - [MC0] DebugMisc=000000F9
2025-07-09 09:02:59 - [MC0] DramTiming1=16163416
2025-07-09 09:02:59 - [MC0] DramTiming2=0016004A
2025-07-09 09:02:59 - UmcCap[0]=0x00030097
2025-07-09 09:02:59 - EccDis = 1 for ch 0
2025-07-09 09:02:59 - Switching BSP to 8
2025-07-09 09:02:59 - [MC1] CPUID[0x00000001]:EBX[31:0] = 08100800 (LocalApicId=8, NBC=8, LogicalProcessorCount=16)
2025-07-09 09:02:59 - SdpCtrl[1]=B040808B (SdpInit=1)
2025-07-09 09:02:59 - [MC1] DramConfiguration=00001930
2025-07-09 09:02:59 - [MC1] DebugMisc=000000F9
2025-07-09 09:03:00 - [MC1] DramTiming1=16163416
2025-07-09 09:03:00 - [MC1] DramTiming2=0016004A
2025-07-09 09:03:00 - UmcCap[1]=0x00030097
2025-07-09 09:03:00 - EccDis = 1 for ch 1
2025-07-09 09:03:00 - Switching BSP back to 0
2025-07-09 09:03:00 - chmode=2

Something in those Unified Memory Controller Capabilities bits seems to indicate that support isn't there. Or it's in the DramConfiguration already?

So if someone from the PassMark team could spell out those bits or where I can find documentation for them, perhaps I could try tricking the Linux module into forcing a BIOS override.

If those traces are truly missing, nothing will help. If it's really just the BIOS playacting ECC support but not actually setting it up, there is a small chance this could be rectified via a little code change in the Linux module.

I'd just love that, given how it's pretty impossible to get such a small ECC capable machine any other way.

I got plenty of other Zen 3 and 4 systems with ECC DDR4 and DDR5 working just fine and MemTest86 saying so, except evidently being able to test ECC error injection, a standard issue with consumer boards AFAIK.

[keith]

You should be able to find some details in the public documentation:
https://www.amd.com/en/search/docume...r%20References

2025-07-09 09:02:59 - UmcCap[0]=0x00030097
2025-07-09 09:02:59 - EccDis = 1 for ch 0

This particular bit is read-only, so it doesn't seem likely that it can be overriden.