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

Wed Jun 20 16:12:12 UTC 2018

Hi,

On 20/06/18 16:24, Paul Kocialkowski wrote:
> Hi and thanks for your anwers!
> 
> On Wed, 2018-06-20 at 11:56 +0000, Peng Fan wrote:
>> Hi Paul
>>
>>> -----Original Message-----
>>> From: Paul Kocialkowski [mailto:contact at paulk.fr]
>>> Sent: 2018年6月20日 16:58
>>> To: Peng Fan <peng.fan at nxp.com>; sbabic at denx.de; Fabio Estevam
>>> <fabio.estevam at nxp.com>
>>> Cc: u-boot at lists.denx.de; andre.przywara at arm.com; Todd Weaver
>>> <todd at puri.sm>; Nicole Faerber <nicole.faerber at puri.sm>
>>> Subject: Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support
>>>
>>> Hi there,
>>>
>>> On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
>>>> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
>>>> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
>>>> DRAM.
>>>
>>> First off, I'd like to express my gratitude for this port: the i.MX8
>>> looks like a great platform and it's really nice to see support for it
>>> land in U-Boot!
>>>
>>> Regarding the integration of i.MX8 with upstream software in general:
>>> are there plans to upstream the ARM Trusted Firmware port for i.MX8?
>>
>> There are i.MX8 i.MX8X i.MX8M product lines for now. This patchset
>> is upstream i.MX8MQ in i.MX8M family.
>>
>> The i.MX8QM in i.MX8 and i.MX8QXP in i.MX8X has been upstreamed to
>> ATF recently. The i.MX8MQ support will be soon sent to ATF, I think.
> 
> Okay, thanks for the clarification, this is good to know :)

Yeah, this naming is really fun ...

>>> It would be great to have both U-Boot and ATF upstream support to
>>> achieve a boot chain with (mostly-)free and upstream software.
>>>
>>> On that note, are there proprietary components involved in the boot
>>> process, other than the already-identified DDR training firmware for the
>>> DDR PHY?
>>
>> The DDR firmware is not opensource, also there is HDMI firmware.
>> U-Boot will load DDR PHY firmware and initialize DDR controller.
> 
> Oh, I didn't know about the HDMI firmware.
> 
> 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.

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.

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

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
> 