i.MX7D M4 boot trouble

[jtheath]

I received an i.MX7D SABRE-SD last week.  All relevant documents, code, etc. was downloaded. One thing I noted is pretty much all documents are packaged for i.MX6SoloX.  Likely not a big deal but even the FreeRTOS source references i.MX6SX not i.MX7.

First I simply powered up with the provided uSD.  Get the openEmbedded GUI and all.  Looks good.

Unarchived the rel_imx_4.1.15_1.1.0_ga.tar.bz2 image, installed latest cross compilers on my Linux workstation, built the image, loaded and ran.  Good.  Did more work on the kernel - tracked down relevant 4.1.15 RT patch set, applied, fought the gpu-viv code for a while (until I realized it isn't needed for i.MX7 build), updated imx-sdma.c as documented in meta-fsl-arm rt.  Replaced rootfs with minimal Debian.  Fired everything up and it runs.

Today back to original rel_imx_4.1.15_1.1.0_ga image and working to light up the M4.  Pulled the necessary compilers from launchpad.net, set up the ARMGCC_DIR environmental variable and built rpmsg pingpong demo.  Everything looks good so far.  Copy the .bin onto the FAT section of uSD.  Open terminals to ttyUSB0 & ttyUSB1.  Plug uSD (in carrier) into the i.MX7D SABRE-SD and powered on.  Interrupted uboot during boot and copied bin image into memory using the instructions here, i.MX 7Dual SABRE Board|NXP  No joy.  Nothing in M4 console terminal.

Ok, backed away from rpmsg, let's just do "hello_world" to verify things.  Same behavior.  It seems there are at least three points of possible failure - bad build, bad ttyUSB1 circuitry, bad silicon.

There are no errors on the build.  Output of CMakeOutput.log

The target system is: Generic -  - arm

The host system is: Linux - 3.19.0-61-generic - x86_64

Checking whether the ASM compiler is GNU using "--version" matched "(GNU assembler)|(GCC)|(Free Software Foundation)":

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589]

Copyright (C) 2015 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Where can I find a known good binary to eliminate the build image?  Are there other techniques to determine whether the M4 is running but silent (possibly indicating a tty issue)?  Looking for some ideas and/or guidance.

Thank you in advance,   Joe

[Carlos_Musich]

Thank you Joseph and Stefan for this enriching discussion.

As you pointed imx6SX and imx7D are not using same FreeRTOS version.

www.nxp.com/imx6SX > Software & Tools tab

FreeRTOS™ BSP 1.0.1 for the i.MX 6SoloX ARM® Cortex®-M4 core

www.nxp.com/imx7D > Software & Tools tab

FreeRTOS™ BSP for the i.MX 7Dual ARM® Cortex®-M4 core

I will share this feedback to our team.

Regards,

Carlos

[falstaff]

Back in June 2016, the FreeRTOS 1.0.1 version was not yet publicly available... But agreed, today, for i.MX 7, the 1.0.1 GA version from the described location works fine.

[falstaff]

josephheath​ what FreeRTOS and U-Boot version are you exactly running (boot banner/git hash)?

Before taking Linux into the mix I recommend focusing on getting output when just using U-Boot (e.g. with the Hello World binary).

FreeRTOS initializes several things before initializing the UART. In particular, I discovered an issue when mixing newer U-boot version with older FreeRTOS firmwares: Newer U-Boot versions make use of RDC and isolate WDOG3. The first FreeRTOS release I had access to (1.0.0) did not set up the RDC for WDOG3, which lead to a crash when FreeRTOS accessed WDOG3 (which happend before anything showed up on UART).

To continue using older FreeRTOS firmwares with the new U-Boot release, I just removed WDOG3 from the list of resources (in U-Boot source):

--- a/arch/arm/cpu/armv7/mx7/soc.c

+++ b/arch/arm/cpu/armv7/mx7/soc.c

@@ -59,7 +59,6 @@ static rdc_peri_cfg_t const resources[] = {

    (RDC_PER_SAI3 | RDC_DOMAIN(0)),

    (RDC_PER_WDOG1 | RDC_DOMAIN(0)),

    (RDC_PER_WDOG2 | RDC_DOMAIN(0)),

-    (RDC_PER_WDOG3 | RDC_DOMAIN(0)),

    (RDC_PER_WDOG4 | RDC_DOMAIN(0)),

    (RDC_PER_GPT1 | RDC_DOMAIN(0)),

    (RDC_PER_GPT2 | RDC_DOMAIN(0)),

[jtheath]

Hello Stefan,

I am using the U-boot and FreeRTOS packages provided by NXP, "U-Boot 2015.04-imx_v2015.04_4.1.15_1.0.0_ga+g0fa2a52 (Apr 30 2016 - 00:27:47)" and "FreeRTOS V8.0.0 - Copyright (C) 2014 Real Time Engineers Ltd." respectively.  These are unaltered, "plain vanilla" as provided with the SABRESD purchase (U-boot) or downloaded from the i.MX7D product page link

Output on boot...

U-Boot 2015.04-imx_v2015.04_4.1.15_1.0.0_ga+g0fa2a52 (Apr 30 2016 - 00:27:47)

CPU:   Freescale i.MX7D rev1.2 at 792 MHz

CPU:   Temperature 25 C

Reset cause: POR

Board: i.MX7D SABRESD RevB

I2C:   ready

DRAM:  1 GiB

PMIC: PFUZE300 DEV_ID=0x30 REV_ID=0x11

MMC:   FSL_SDHC: 0, FSL_SDHC: 1

No panel detected: default to TFT43AB

Display: TFT43AB (480x272)

Video: 480x272x24

In:    serial

Out:   serial

Err:   serial

switch to partitions #0, OK

mmc0 is current device

Net:   FEC0

Normal Boot

Thank you,   Joe

[falstaff]

Unfortunately the FreeRTOS version number does not help, NXP uses FreeRTOS 8.0.0 in their 1.0.0 as well as in their 1.0.1 BSP release...

I guess when you say:

downloaded from the i.MX7D product page link

You use either WIndows or Linux version of "i.MX 6SoloX FreeRTOS BSP for Cortex-M4" from www.nxp.com/imx6tools, is that correct? If yes, then you are using the 1.0.0 FreeRTOS BSP release which likely causes trouble due to the mentioned WDOG3 issue.

It seems to me that NXP did not release the source for FreeRTOS BSP 1.0.1 publicly... We at Toradex are about to release a new BSP, and you can use our  Git repo to get to the FreeRTOS BSP 1.0.1 source code: freertos-toradex.git - FreeRTOS for the Cortex M4 core of Heterogeneous Multicore modules

[jtheath]

Hello Stefan!

Yes, you are correct.  I downloaded "i.MX 6SoloX FreeRTOS BSP for Cortex-M4" from the NXP site.

On seeing your response I cloned the Toradex repository, checked out the master-1.0.1 branch and built the hello_world demo, loaded it on the uSD FAT partition then loaded it into the M4.  I crossed my fingers and executed "bootaux 0x7F8000". Success!!!  There it is in the M4 console window, "Hello World!"  Thank you!  Thank you!  Thank you!

I then built the sensor_demo, loaded and ran it.  Woo hoo!

Thank you very much Stefan.  You definitely helped me.  I won't forget.

All the best,   Joe

[jtheath]

environmental variables...

=> printenv

baudrate=115200

boot_fdt=try

bootcmd=mmc dev ${mmcdev};mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript; then run bootscript; else if run loadimage; then run mmcboot; else run netboot; fi; fi; else run netboot; fi

bootcmd_mfg=run mfgtool_args;bootz ${loadaddr} ${initrd_addr} ${fdt_addr};

bootdelay=3

bootscript=echo Running bootscript from mmc ...; source

console=ttymxc0

ethact=FEC0

ethaddr=00:04:9f:04:4a:1e

ethprime=FEC

fdt_addr=0x83000000

fdt_file=imx7d-sdb-m4.dtb

fdt_high=0xffffffff

image=zImage

initrd_addr=0x83800000

initrd_high=0xffffffff

ip_dyn=yes

loadaddr=0x80800000

loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};

loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}

loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}

loadm4image=fatload mmc ${mmcdev}:${mmcpart} 0x7F8000 ${m4image}

m4boot=run loadm4image; bootaux 0x7F8000

m4image=m4_qspi.bin

mfgtool_args=setenv bootargs console=${console},${baudrate} rdinit=/linuxrc g_mass_storage.stall=0 g_mass_storage.removable=1 g_mass_storage.file=/fat g_mass_storage.ro=1 g_mass_storage.idVendor=0x066F g_mass_storage.idProduct=0x37FF g_mass_storage.iSerialNumber="" clk_ignore_unused

mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot}

mmcautodetect=yes

mmcboot=echo Booting from mmc ...; run mmcargs; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;

mmcdev=0

mmcpart=1

mmcroot=/dev/mmcblk0p2 rootwait rw

netargs=setenv bootargs console=${console},${baudrate} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp

netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;

script=boot.scr

Environment size: 2199/8188 bytes

[jtheath]

Also wanted to note LED activity on the debug uart lines.  See both red and green on D8/D9 when using A7 console terminal.  See only green light up (D11) when typing in M4 terminal, never a red blink from D10.

[jtheath]

Continuing on this path... still no joy on the M4.

I am confident this is not an FTDI/ttyUSB issue as the A7 console is present and carried by the same hardware. 

It is not an application build problem. Joel Schoen (our Arrow FAE) sent me known working binaries from his IMX7SABRESD hands-on training session.  Loading those known good reference images caused no change in behavior.

I tried the "pingpong" demo program which runs components on both cores again.  I load and start the M4; continue to boot Linux (needed to change the fdt_file environmental variable as its default setting, imx7-sdb.dtb, prevents Linux from booting once the M4 is started); and load the A7 rpmsg_pingpong driver module.  That is expected to emit "message received" text whenever it receives communications from the M4.  Nothing is printed.

I have built, loaded and run hello_world in its various memory forms, {TCM, DDR, OCRAM}, and see the same behavior. 

A couple months ago I was doing preliminary work on an iMX6SoloX SABRE-SD and had no difficulty running code on the M4.

A dump of /proc/cpuinfo shows the following:

root@iMX7-SABRESD:/proc# cat cpuinfo

processor    : 0

model name    : ARMv7 Processor rev 5 (v7l)

BogoMIPS    : 16.00

Features    : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm

CPU implementer    : 0x41

CPU architecture: 7

CPU variant    : 0x0

CPU part    : 0xc07

CPU revision    : 5

processor    : 1
model name    : ARMv7 Processor rev 5 (v7l)
BogoMIPS    : 16.00
Features    : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer    : 0x41
CPU architecture: 7
CPU variant    : 0x0
CPU part    : 0xc07
CPU revision    : 5

Hardware    : Freescale i.MX7 Dual (Device Tree)

Revision    : 0000
Serial      : 0000000000000000