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

[Peng Fan]

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.

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

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

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

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

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

Regards,
Peng.

> 
> Cheers,
> 
> Paul
>