Hacker News new | ask | show | jobs
by mswann 1965 days ago
> If you are familiar with work done in the FOSS community to procure devices with fully open firmware, the name Synopsys may ring a bell here. Synopsys is a company which sells IP blocks[...]. One of their IP block products is a DDR4 memory controller and PHY solution, which appears popular and which is found in a number of SoCs. It is however a known fact that Synopsys's DDR4 PHY requires a Synopsys-issued firmware blob to operate; therefore, chips which use the Synopsys DDR4 PHY inevitably have firmware blobs in their boot path

> Probably the most notable SoC containing a Synopsys DDR4 memory controller and PHY is the NXP i.MX8M series, which was for example selected by Purism to form the heart of their Librem 5 phone.

Is this (still) true? I just tried to find any binary blobs in U-Boot source tree [0], but didn't find any.

At least for some Rockchip SoCs (RK3399), which I assume also use Synopsys IP DDR PHYs, I know that it's not necessary to provide anything else apart from upstream U-Boot and Arm Trusted Firmware (ATF) [1]. And AFAICT current mainline U-Boot can initialize NXP i.MX8M's DDR PHY, too.

[0] https://gitlab.denx.de/u-boot/u-boot

[1] https://stikonas.eu/wordpress/2019/09/15/blobless-boot-with-...

3 comments

That would be odd if true.

I've personally created a BSP and did board bring-up on a platform based on the NXP LS1046A (one of their ARM based QorIQ SoCs). That chip uses DDR4 and didn't require any blobs (aside from the Ethernet hardware). All of the memory controller registers were fully documented too. The DDR4 controller there was very similar to the DDR3 controller on their older T2080 PPC chip that I've worked with.

In fact, one of the most annoying parts of the board bring up was determining what data strobe delay values to use via a process of trial and error.

I'm not sure why NXP would use a different DDR4 controller for the iMX that requires a blob while their other chips don't.

Author here. It wouldn't particularly surprise me. If I had to guess why other NXP products didn't go with Synopsys, it might be related to the fact that the i.MX8M is intended to be suitable for mobile applications therefore support for LPDDR4 is more important. In fact Synopsys's DDR4 PHY can support both, I believe (IIRC) dynamically, with i.MX8M chips which can be used with either. There are other DDR PHY IP providers (e.g. Cadence) which don't require blobs. Plus these are probably separate business units.

I've confirmed the presence of these blobs in i.MX8M BSPs myself, as has Purism, see their blog post.

Author here. It is correct that mainline U-Boot can handle the i.MX8M DDR PHY, but it is still dependent on these blobs being provided. See here:

https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-i...

I don't know whether RK3399 uses Synopsys. There are other DDR4 PHY IP providers, like Cadence, which don't require firmware.

After digging through some resources on the web I now believe that this is indeed still true - at least I couldn't find anything to the contrary (apparently you have to provide the firmware blob outside of U-Boot, which then loads it at runtime). This probably means the Rockchip SoCs I was talking about don't use Synopsys IP for the DDR PHY (although they tend to use a lot of Synopsys IP for all kinds of other components).

I wonder how I could have missed that issue with the Librem 5 till now.

Author here. This is correct. There are other DDR PHY IP providers such as Cadence, which did not elect to require firmware blobs in their design. You could say that the Synopsys DDR4 PHY design is a little overengineered. I've confirmed the presence of these blobs in i.MX8M BSPs myself. See also Purism's blogpost discussing this very subject.