imx7d: Mainstream boots, fslc does not.

[danmerillat]

Mainline 4.14.x kernel works, freescale/nxp modified 4.14.x kernel does not.

Running the 4.14.x mainstream kernel on my i.mx7d (specifically the 7d3evk10sc) and everything works as expected except the m4 co-processor.

Attempting to run the 4.14-2.0.x-imx branch from https://github.com/Freescale/linux-fslc/tree/4.14-2.0.x-imx  does nothing.  No early-printk on the console, nothing at all.

I spent some time doing bisection and the following commits cause a complete boot failure, no serial output after "Starting kernel":

9a0a578 MLK-11349-3 ARM: imx: update clk driver for imx7d

Specifically this line in clk-imx7d.c:

/* set lcdif pixel root clock source to get the required 33Mhz clock */
imx_clk_set_parent(clks[IMX7D_LCDIF_PIXEL_ROOT_SRC], clks[IMX7D_PLL_VIDEO_POST_DIV]);

a75767c774c32  MLK-10406 ARM: imx: check the clk_set_rate() return value - apparently the clock rate is being set correctly but returning an error, and this change aborts serial setup causing no output.

And the this one starts to boot but oopses out early on:

58e25094b4 MLK-11357-2 ARM: imx: add cpuidle support for imx7d

Additionally, even with those commits reverted, attempting to use the new entries in the device tree fails.

Specific problems include:

imx7d.dtsi unconditionally enabling 1.2ghz, even on the older 1ghz parts.  No console output during boot.

Anything that touches the OCRAM_CLK (ocram, ocrams, ocrams_ddr, etc).  No console output during boot.

Possibly others but this was already getting ridiculous.  Clearly something is fundamentally wrong here.

My DTS file is currently pared down to just #include "imx7d.dtsi", plus the RAM and serial port for the console to eliminate all other drivers as possible causes.  This boots on mainline, and not on 4.14.x+fslc

Specific questions:

What board/processor is current imx7d development being tested against?

Are there differences between the 1ghz and 1.2ghz parts that would require separate .dtsi files?

Are there differences between the two pin-count options that would require separate .dtsi files except for the obvious pinctl differences?

If the freescale development kernel is "unsupported", What supported kernel version is newer than 5 years old and has support for the m4 core of the 7d?

Alternately, what changes need to be made to enable the m4 core on the mainline kernels, which work correctly?

Mainline 4.14.x kernel works, freescale/nxp modified 4.14.x kernel does not.

[igorpadykov]

Hi Dan

almost all answers can be found in nxp official linux documentation on i.MX Software | NXP 

In particular from Linux L4.14.98_2.0.0 Documentation  Release Notes:

- offical nxp software (mainline and "fslc" not supported) is located on     Code Aurora git repositories 

linux-imx - i.MX Linux kernel 

uboot-imx - i.MX U-Boot 

FreeRTOS_iMX7D_1.0.1_WIN

FreeRTOS_iMX7D_1.0.1_LINUX

from imx7d.dtsi file 1.2GHz is also supported

imx7d.dtsi\dts\boot\arm\arch - linux-imx - i.MX Linux kernel 

m4 is supported with imx7d-sdb-m4.dts

imx7d-sdb-m4.dts\dts\boot\arm\arch - linux-imx - i.MX Linux kernel 

support for mainline kernels can be posted on meta-fsl-arm mailing list:

meta-freescale Info Page 

Release Notes p.1 shows what is supported for i.MX7 : "i.MX7Dual SABRE-SD Board"

(has MCIMX7D7DVM10SC part).

For other parts/boards it is necessary to run i.MX6/7 DDR Stress Test Tool V3.00 

and update uboot dcd header, implement changes (from i.MX7D Sabre SD) in own codes,

one can use Porting Guide included in documentation.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[danmerillat]

Already tried that 4.14.98-2.0.0-ga release, that's a release tag of the development tree I linked so it has all the same problem commits.  The problems weren't fixed with later development either.

Mainline works, why would I need support for it?  The problem is you haven't gotten the rpmsg changes upstream yet so I need to use the massively-modified vendor kernel tree which does not boot at all.

Just to be sure, I started a fresh directory and followed the i.MX porting guide exactly, to get an identical result.

The sabre dts is unlikely to work for me as this is not a sabre board, but I tested it as well.  The fact that I can't get any output on the serial console at all limits how much I can debug the problems.

As for u-boot, I can't even get that far if I try to use your documentation:

$ git clone https://source.codeaurora.org/external/imx/uboot-imx -b imx_v2018.03_4.14.98-2.0.0_ga
Cloning into 'uboot-imx'...
fatal: Remote branch imx_v2018.03_4.14.98-2.0.0_ga not found in upstream origin

Cut & paste the command from page 14 of i.MX Porting Guide, Rev. L4.14.98-2.0.0_ga 4/2019.

(Obviously you can just clone it and checkout the branch, but I wanted to point out the documentation error)

igorpadykov wrote:

Hi Dan

almost all answers can be found in nxp official linux documentation on i.MX Software | NXP 

In particular from Linux L4.14.98_2.0.0 Documentation  Release Notes:

- offical nxp software (mainline and "fslc" not supported) is located on     Code Aurora git repositories 

linux-imx - i.MX Linux kernel 

uboot-imx - i.MX U-Boot

support for mainline kernels can be posted on meta-fsl-arm mailing list:

[igorpadykov]

Hi Dan

you are right, original i.MX7D software will not run on your board,

since it was developed for i.MX7D Sabre SD board. So it is necessary to add

modifications related to differencies with custom board. In particular

run i.MX6/7 DDR Stress Test Tool V3.00 and update uboot dcd header (*.cfg file)

mx7dsabresd\freescale\board - uboot-imx - i.MX U-Boot 

add changes in dts file (differencies in iomux settings, used modules..)

imx7d-sdb.dts\dts\boot\arm\arch - linux-imx - i.MX Linux kernel 

Note, NXP has special service for helping customer with porting software:

Commercial Support and Engineering Services | NXP 

Best regards
igor

[danmerillat]

That misses the point that I've already modified the .dts file to work on my board, and modified u-boot for the correct memory layout, and it boots both cores and runs linux fine.  I don't need help with porting to this board, it's already running.

The problem is when trying to use the NXP modified kernel it can no longer boot at all.  I've tried various versions, including the release-tagged branches such as 4.14.98_2.0.0_ga and the current development , and they fail.

I need to bring up the m4 core which is not supported by the mainline kernel, but your kernel cannot boot at all.

[igorpadykov]

had you changed nxp dts according to your processor :

7d3evk10sc vs MCIMX7D7DVM10SC has not No EPDC, No CAN and only 4 tamper pins.

Also is custom board using PMIC, is it the same as on i.MX7D Sabre SD  - PC32PF3000A1EP.

In general it can be debugged using AN4553 Using Open Source Debugging Tools for Linux on i.MX Processors
https://www.nxp.com/docs/en/application-note/AN4553.pdf

Best regards
igor

[danmerillat]

I have started everything from scratch based on i.MX Porting Guide Rev L4.14.98-2.0.0_ga 04/2019

First was to update u-boot for dram chip and run DDR stress test:

U-Boot 2018.03 imx_v2018.03_4.14.98_2.0.0_ga with the imximage.cfg generated via the imx7d DDR XLS:

Read calibration
DDRPHY_OFFSETR_CON0 (0x30790020) = 0x06060606

Write calibration
DDRPHY_OFFSETW_CON0 (0x30790030) = 0x06060606

Success: DDR calibration completed!!!

...

DDR Freq: 537 MHz
t0.1: data is addr test
t0: memcpy11 SSN test
t1: memcpy8 SSN test
t2: byte-wise SSN test
t3: memcpy11 random pattern test
t4: IRAM_to_DDRv2 test
t5: IRAM_to_DDRv1 test
t6: read noise walking ones and zeros test

DDR Stress Test is complete!

So uboot and imximage.cfg are working.

had you changed nxp dts according to your processor :

7d3evk10sc vs MCIMX7D7DVM10SC has not No EPDC, No CAN and only 4 tamper pins.

What do I need to change in the dts file for those differences, and would that cause the failure to boot I'm seeing?

Also is custom board using PMIC, is it the same as on i.MX7D Sabre SD  - PC32PF3000A1EP.

Yes, a different PMIC: bd7181x. That is trivial to port because another vendor uses it on the imx7s so the drivers were just directly copied over.

Started with a fresh copy of 4.14.98_2.0.0_ga which should be supported and made a board .dts file from scratch. I've narrowed it down to ocrams_ddr blowing up when enabled:

&ocrams_ddr {
   compatible = "nothing";
};

by setting the compatibility to an invalid name busfreq-imx.c:imx_dt_find_ddr_sram() can't find it and cause a hardlock.  With this patch I can boot, although many things expect the ddr sram to exist, such as sdma and those modules fail when loaded.

What could be causing the on-chip sram to fail?  Did I miss setting something up in the .xlsx to imximage.cfg?

[C] dts file - Pastebin.com 

imximage.cfg - Pastebin.com 

[igorpadykov]

Hi Dan

NXP has special service for support with porting custom boards which

uses different than NXP reference boards harwdare configuration (like PMIC: bd7181x)

Commercial Support and Engineering Services | NXP 

Best regards
igor

[danmerillat]

I do not believe I need any assistance with the PMIC integration, as it has been working (with a different kernel) for over a year now.  I'm looking into why your reference kernel is faulting when attempting to configure the on-chip sram. 

It's very clearly faulting in one following call-trees, mostly in busfreq-imx.c:

devicemaps_init()

    imx7d_map_io()

    imx_busfreq_map_io()

      imx_dt_find_ddr_sram() // search devicetree for ocram node, set ddr_freq_change_iram_phys

                         // this node is defined by imx7d.dtsi as ocrams_ddr: sram@00900000

      iotable_init(&ddr_iram_io_desc, 1)

      memset(ddr_freq_change_iram_base, 0, ddr_freq_change_total_size);

Alternately and more likely when the platform driver is probed:

 busfreq_driver.probe()

   busfreq_probe()

     if (!ddr_freq_change_iram_base)

         return

     if (cpu_is_imx7d()) {

        // get all the clocks

        of_property_read("fsl,max_ddr_freq")

        // actually setup all the bus-frequency changes via callbacks.

     }

Remember, getting rid of the ocrams_ddr node in the device-tree allows the kernel to boot, as that disables all this logic.

If you believe the failure is in the latter, I can see where it may be a PMIC issue as frequency changes require regulator changes and that gives me a place to look.

I appreciate your time on this.