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

Thu Jun 21 18:29:12 UTC 2018

+Angus into the thread...

On Thu, 2018-06-21 at 02:07 +0100, André Przywara wrote:
> On 06/20/2018 06:16 PM, Paul Kocialkowski wrote:
> > 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)
> 
> I know, this is where I was coming from ;-) We tried to get the DRAM
> code from Allwinner, but this didn't really end well.
> I guess they will play ping-pong: Synopsis won't talk to you, since
> you
> are not their customer, and NXP will tell you that they can't share
> third party code, partly from Synopsis.
> 
> > 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 :)
> 
> OK, godspeed, and sorry for my pessimism!
> 
> > > 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?
> 
> Yeah, don't tell me!
> 
> > 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!
> 
> Please be careful when an NDAs is offered, that makes releasing the
> code
> under a FOSS license quite complicated. AFAIK most NDAs explicitly
> forbid this even. In the worst case you taint yourself for a long
> time
> from working with Open Source in this area.
> 
> > > > 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!
> 
> Alright, keeping my fingers crossed!
> 
> Cheers,
> Andre.
> 
> > > > > > 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
> > > > 
> 
> 
-------------- 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/20180621/8cd98afd/attachment.sig>