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....@nxp.com> > > > > Cc: Fabio Estevam <fabio.este...@nxp.com> > > > > Cc: Stefano Babic <sba...@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/ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
