[U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support
Paul Kocialkowski
contact at paulk.fr
Wed Jun 20 11:54:52 UTC 2018
Hi,
On Wed, 2018-06-20 at 12:37 +0100, Andre Przywara wrote:
> (resending trimmed version to pass the U-Boot size limit filter ...)
>
> Hi,
>
> On 20/06/18 09:57, Paul Kocialkowski wrote:
> > 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?
> > It would be great to have both U-Boot and ATF upstream support to
> > achieve a boot chain with (mostly-)free and upstream software.
>
> The support for i.MX8QX and i.MX8QM has been merged into the official
> ATF repo yesterday:
> https://github.com/ARM-software/arm-trusted-firmware/pull/1410
>
> I am bit lost in the naming here (i.MX8QM vs i.MX8MQ), but I think that
> should answer your question.
Great to hear and great work! I must admit, I did not even check ATF
sources when writing the email from this morning, as it seemed too early
anyway.
I'm definitely glad I was wrong :)
> > On that note, are there proprietary components involved in the boot
> > process, other than the already-identified DDR training firmware for the
> > DDR PHY?
> >
> > 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?
>
> I agree on not wanting a blob for that, although that depends a bit on
> what it does: If it's an not-signed binary, that just does the training
> and then goes out of the way, and shipping the binary is reasonably
> licensed, then it might be beneficial to have it, at least for now.
Well, that covers some use cases, but definitely does not help with
software freedom issues, that can only be solved by either avoiding or
liberating that blob. Even following the RYF approach that Purism is
considering[0] (moving DDR calibration to a coprocessor) does not help
at all with freedom issues and is merely an "exception" that the FSF's
RYF certification allows.
I did not mention it, but perhaps NXP is in a positon to ask Designware
to free that blob altogether (which would definitely solve the issue at
hand here)?
> AFAIK actual DRAM training for a wide range of chips is not trivial, so
> there is probably some value in that blob.
> For specific boards with soldered chips: can't we dump the results of
> the training and use that for a static configuration? It is my
> understanding that the DRAM controller parameters depend on actual
> voltage and also temperature, but we might get some good enough values
> for a reasonable range of both? This would make this blob optional then,
> and people could decide for their own.
This is also my understanding and I would totally be satisfied with this
approach, as I mentioned earlier.
Thanks for the reply!
Paul
[0]: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/
> Cheers,
> Andre.
>
> > 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.
> >
> > 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.
> >
> > 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).
> >
> > Thanks in advance for your time and consideration of these questions!
> >
> > Cheers,
> >
> > Paul
> >
> > > The boot log with Arm trusted firmware console enabled:
> > > "
> > > U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
> > > PMIC: PFUZE100 ID=0x10
> > > Normal Boot
> > > Trying to boot from MMC2
> > > NOTICE: Configureing TZASC380
> > > NOTICE: BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
> > > NOTICE: BL31: Built : 07:17:16, Jan 8 2018
> > > NOTICE: sip svc init
> > >
> > > U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
> > >
> > > CPU: Freescale i.MX8MQ rev2.0 at 1000 MHz
> > > Reset cause: POR
> > > Model: Freescale i.MX8MQ EVK
> > > DRAM: 3 GiB
> > > MMC: FSL_SDHC: 0, FSL_SDHC: 1
> > > Using default environment
> > >
> > > In: serial
> > > Out: serial
> > > Err: serial
> > > Net: No ethernet found.
> > > Hit any key to stop autoboot: 0
> > > u-boot=>
> > > "
> > >
> > > Signed-off-by: Peng Fan <peng.fan at nxp.com>
> > > Cc: Fabio Estevam <fabio.estevam at nxp.com>
> > > Cc: Stefano Babic <sbabic at denx.de>
> > > ---
> > > arch/arm/dts/Makefile | 2 +
> > > arch/arm/dts/fsl-imx8mq-evk.dts | 424 +++++++++
> > > arch/arm/include/asm/arch-mx8m/ddr.h | 9 +
> > > arch/arm/mach-imx/mx8m/Kconfig | 12 +
> > > board/freescale/mx8mq_evk/Kconfig | 12 +
> > > board/freescale/mx8mq_evk/Makefile | 12 +
> > > board/freescale/mx8mq_evk/README | 47 +
> > > board/freescale/mx8mq_evk/ddr/ddr_init.c | 246 +++++
> > > board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 ++++++++++++++++++++++++++
> > > board/freescale/mx8mq_evk/ddr/helper.c | 101 ++
> > > board/freescale/mx8mq_evk/mx8mq_evk.c | 156 ++++
> > > board/freescale/mx8mq_evk/spl.c | 230 +++++
> > > configs/mx8mq_evk_defconfig | 27 +
> > > include/configs/mx8mq_evk.h | 269 ++++++
> > > 14 files changed, 2819 insertions(+)
> > > create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
> > > create mode 100644 board/freescale/mx8mq_evk/Kconfig
> > > create mode 100644 board/freescale/mx8mq_evk/Makefile
> > > create mode 100644 board/freescale/mx8mq_evk/README
> > > create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
> > > create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
> > > create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
> > > create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
> > > create mode 100644 board/freescale/mx8mq_evk/spl.c
> > > create mode 100644 configs/mx8mq_evk_defconfig
> > > create mode 100644 include/configs/mx8mq_evk.h
> > >
--
Developer of free digital technology and hardware support.
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
More information about the U-Boot
mailing list