From mboxrd@z Thu Jan 1 00:00:00 1970 From: Todd Weaver Date: Thu, 21 Jun 2018 11:29:12 -0700 Subject: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support In-Reply-To: <52fca3b7-88c8-5444-8351-6fa2aa081626@arm.com> References: <20180110052048.4425-1-peng.fan@nxp.com> <20180110052048.4425-32-peng.fan@nxp.com> <070f9f1eb36ab6365440a8c227a751eb6e7771af.camel@paulk.fr> <02ffebb3d0038e45c41ed5c86e7c87ca803ec1ba.camel@paulk.fr> <552c6e47-c700-829f-c03b-a8576f616050@arm.com> <4a825c59fc50082a46308cbd40000e760b7c7d79.camel@paulk.fr> <52fca3b7-88c8-5444-8351-6fa2aa081626@arm.com> Message-ID: <5a3cbec0f790c92219534607a870f395b92dd8d9.camel@puri.sm> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de +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: