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

Wed Jun 20 12:08:50 UTC 2018

On Wed, 2018-06-20 at 13:54 +0200, Paul Kocialkowski wrote:
> 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)?

I meant Synopsys (the company), not Designware (the line of products)
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/