Discussion
Many people know that regular x86 AMD CPUs have a secondary CPU for management tasks called PSP, which is an ARM CPU.
Today I learned:
The System Management Unit (SMU), which is responsible for controlling the power delivery, current limits, temperature limits, etc. is ... Xtensa!
So that's yet another fun CPU core inside your "CPU" 😹 !
I wonder if there are any other cores in there...
@manawyrm@chaos.social Who provides AMD's DDR 4 & 5 controllers? Normally there's a core from the vendor of those hidden inside. Famously for Synopsys' DDR4/5 controllers this means an ARC
@manawyrm i would be shocked if there are not more.
I mean, not too long ago i was looking at i think a chip at work that had 40-something cores in it, all doing different things
@azonenberg well, today was the first time I had to look into the SMU firmware to force an unstable mainboard into behaving properly.
Haven't had to abuse the PSP like that (yet).
Already quite interested to see what's next in this chain^^ :D
@manawyrm i mean on one of my boxes...
Everything in the main xeon and pch
Gpu management processor
Ssd controller
NIC
Those are the easy ones
But many of those probably have a lot of extra cores too.
And then the ast2500 has an arm11 main processor and there's probably some extra cores inside that too
@azonenberg the AST2500 is suuuch a fun chip with soo many absolutely cursed features. Have you read its datasheet?
Between the ability to receive/send arbitrary PCIe TLPs, their UART memory read/write 8051 and the internal JTAG controller that can be routed to the ARM11 itself and also externally, I really like these funky chips 😁 😁
(but OH GOD are they a security catastrophe!)
@manawyrm even the stm32mp2 has the two main a35s, the auxiliary m33, the low power m0+ sensor controller, and the arc in the ddr phy
Oh yea, the Arc, because Synopsys acquired it at some point.
When I looked at a handful of platforms to translate their DRAM init, I would frequently find what looks like two big memcopies, but into the MMIO region - that is how the main processing unit passes the firmware to the PHY. 🪆
Looking closer at some openly available code, I saw one block called i-something, the other d-something; those are the instructions ("text", in ELF terms) and the data.
Correct, and here is the beautiful giant uint8 array containing the blob:
https://github.com/STMicroelectronics/STM32DDRFW-UTIL/blob/main/Drivers/STM32MP2xx_HAL_Driver/Src/stm32mp2xx_hal_ddr_ddrphy_firmware_ddr_pmu_train.c
Can't blame you for sticking with the SRAM, DRAM is expensive now anyway. :D
But yea, big MCU is also how I tend to explain application processors SoCs, just transitioning to tons more RAM and having bigger cores is the main difference.
@manawyrm Yup, there are lots more, indeed.
Same with Intel btw, they also have lots more processing and control units.
With the parsers I have written for both, and also using UEFITool, you can see the many components that make up a firmware image. It's a matryoshka 🪆, as I like to say.
I wish I had the time to polish it all a bit more and integrate th into Fiedka. 😬 But maybe... I have something coming up. 🤫
If you want, let's talk about it at 40C3.