[U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

Wed Jun 20 17:16:30 UTC 2018

Hi,

Le mercredi 20 juin 2018 à 17:12 +0100, Andre Przywara a écrit :
> On 20/06/18 16:24, Paul Kocialkowski wrote:
> > Regarding the DDR firmware: I would like to start a discussion with NXP
> > and Synopsys about making the firmware free software/open source.
> 
> Don't want to temper your enthusiasm, but I believe this has been tried
> before - in vain. Hence my proposal to work around this. This is a
> common problem for many platforms: DDR training or initialisation code
> is not documented and/or provided as a closed source blob.
> I very much appreciate your push for FOSS code, but I guess this is
> where reality kicks in.

I somewhat share your analysis here and I am well aware of the general
issue (I remember not too long ago when nobody could say for sure
whether the Allwinner A64 platform would see free DRAM init code or not)
but I still feel like trying the political way first is the most
reasonable way to go.

And I am definitely not going to give up so easily for now :)

> There was and is quite some reverse engineering effort around this,
> though, and a lot of similarities have been found between the DDR
> controllers in different platforms, for instance between Rockchip and
> Allwinner. I believe it would be worthwhile to go over what we have in
> U-Boot and try to unify this. AFAIK many vendors use Synopsis IP, but
> don't necessarily say so. This might lead to some insight about the
> controllers used in i.MX as well.

Indeed, that is another not-so-painful way to go towards resolving this
problem. And it also helps with the political way, since it seems that
code covering these DRAM controllers' innards tends to come out sooner
or later. So what's the point in Synopsys keeping it a secret?

And even if the code can't be released as-is, I'm sure that
documentation that would allow writing a feature-equivalent firmware
could be released without too much trouble involving lawyers.

Heck, it could even be released under NDA and a company could be
mandated to write such a clean firmware!

> > Would you be able to tell me who to contact about this (probably a
> > manager on the NXP DDR team to begin with)? Feel free to answer off-list 
> > if contact information cannot be shared publicly. 
> 
> Good luck with that, but don't be disappointed ...

To be honest, I would mostly feel disappointed for not trying!

Cheers,

Paul

> > > > About that DDR PHY firmware: to what extent is it necessary? It is
> > > > common that DDR link training is required for socketed DRAM chips, but
> > > > properly-tuned static per-board configuration is usually enough for
> > > > soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> > > > it be possible to provide such a static configuration mode, that does
> > > > not involved any firmware for link training?
> > > 
> > > The DDR PHY firmware is not per board. It is required.
> > > 
> > > There is a ddr tool developed by NXP, like what i.MX6/7 uses, it could generated
> > > the script like what this patch contains regarding the ddr part. But the DDR
> > > PHY firmware is a must, the DDR PHY firmware will be loaded to a place
> > > saying IMEM/DMEM inside DDR PHY.
> > 
> > Okay, so if I understand correctly, we there is already static
> > configuration. Do you know the role of the DDR PHY in details?
> > 
> > It is very unclear to me why the firmware is required. If you do not
> > have the details, could you direct me to someone who knows such details?
> > 
> > > > Perhaps the PHY link training code (with the firmware) could be kept
> > > > around as a fallback, disabled by default. Also, I see lots of
> > > > undocumented registers in the process. Does it seem feasable to document
> > > > these? This currently does not really like the source form of the
> > > > software.
> > > 
> > > There are lots lots of registers to configure, honestly, I also do not
> > > know the detailed meaning. The ddr code is from DDR team, hard
> > > for me to restructure. I suggest you use the DDR tool from NXP to
> > > generate the ddr code you need.
> > 
> > Well, this is a very borderline situation, where we can consider that
> > the register dumps are not really source code. I understand that you may
> > not have the necessary information here. Do you know who to contact to
> > solve this problem?
> > 
> > > > Having a firmware in the boot process is a fatal flaw when it comes to
> > > > software freedom, as it prevents having a fully free boot chain. Since
> > > > some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> > > > for this precise reason, this is a serious (if not fatal) drawback.
> > > 
> > > The DDR PHY firmware runs inside DDR PHY, it is only DDR TYPE specific,
> > > such as DDR4 and LPDDR4 use different DDR PHY firmware.
> > 
> > I see, that makes sense.
> > 
> > > If different boards use LPDDR4, they could use same firmware.
> > > 
> > > > 
> > > > Moreover, it is really not convenient to have a non-free firmware that
> > > > must be carried around with U-Boot and prevents user from just cloning
> > > > u-boot, building and running (by adding an extra step that complicates
> > > > the process and makes it different from other platforms that do not
> > > > require such a blob).
> > > 
> > > imx-mkimage, might be good to added into U-Boot as Stefano suggests.
> > > Then it will be easy a lot. But the firmware could not be avoided.
> > 
> > Yes, having that tool in U-Boot would be a very good thing indeed!
> > 
> > > > Thanks in advance for your time and consideration of these questions!
> > > 
> > > Things become complicated, good documentation is required.
> > > 
> > > Shame on me that the ddr code still be held there.
> > 
> > Don't worry, I'm sure we can work together to solve these problems :)
> > 
> > Cheers,
> > 
> > Paul
> > 
-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180620/4f89dc4e/attachment.sig>