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 >>> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
