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

Thu Jun 21 01:07:54 UTC 2018

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
>>>