Why does booting Linux on iMX7D A7 stop operation of M4 running out of QSPI?

[jeremym]

On the iMX7D Sabre board we are able to launch an M4 application from UBOOT which is running exclusively out of TCM and then launch Linux (running in DDR) on the A7 without issue (both cores run as expected without interruption).  If we link the M4 application to execute out QSPI, and launch it from UBOOT, it runs OK until we proceed to boot Linux.  Once the "Starting Kernel" message appears on the A7 console, the M4 stops executing.

I have looked through the KCONFIG and DTS files and do not see any obvious reason why the A7 booting Linux stops the M4's execution in this scenario?  Any thoughts or insights would be appreciated.  Also, the application note AN5317 does not address starting M4 QSPI based applications, it is only directly applicable to RAM based applications.  Even though the steps should be the same, Linux does not seem to have access to the 0x60000000 address space by default, and I cannot find the configuration/DTS settings to enable this.

thanks,

Jeremy

[erikfriedel]

Hi Jeremy,

I am trying to get the QSPI demo startet in me imx7s. But as soon as I try to load the image to the QSPI via tftp the A7 reboots the board. I tried every address in the linker file and none of them worked. (0x60100000/0x60100240/0x20000000 and everything in between)

Could you please share with me, where you put the image?

[jeremym · Accepted solution]

Hi Erik - are you trying to load an A7 image in the QSPI or an M4 image in the QSPI?  My original post was concerning loading and running and M4 image from QSPI while simultaneously running Linux in the A-Core.  When you tftp your image to the board, is this via u-boot, or in Linux?  If the board is automatically rebooting during or immediately after the tftp, I am guessing that you are overwriting some critical memory region with your image (i.e. it may be too large, or you may be trying to load it in a restricted memory region).  When we load the M4 image to be put into QSPI, we typically load it from an SD/CF card.  It first gets loaded into a region in RAM which is free and available, and then programmed into flash using the u-boot sf commands.  You are not able to directly load an image into QSPI as there are programming algorithms which need to be employed, it cannot be treated like a direct memory mapped region in that sense.  Hope this helps. 

For anyone else having the original issue above, here are some hopefully helpful hints to how we got it working: 

I never did get any answers from NXP which addressed our problem, but we did eventually get it to work with quite a few modifications to both the U-boot script (needed to add clk_ignore_unused to console arguments to Linux to prevent the QSPI clock from being disabled since it is unused in our scenario by Linux), and to the Kernel itself (the NXP-ARM port has some low-power mode code which access the M4's TCM (for low power mode operation).  We also had to address all Resource Domain Controller conflicts we had, which makes sense, cannot have both cores trying to exclusively use the same peripheral or you get all kinds of weird behavior, lock-ups of either or both cores, among them.

[jeremym]

Correction: my original statements about the NXP iMX7 low-power code 'stomping' on TCM in the M4 was incorrect. 

The statement above: "Kernel itself (the NXP-ARM port has some poorly written low-power mode code which 'initializes' the M4's TCM by wiping it out on Linux boot.  Upon entering low-power mode the TCM is saved off and eventually restored - which is great - but why they wipe the memory initially is beyond me, it completely stomps on any code currently executing on the M4 which is utilizing it; presumably the Linux port was written with the assumption that the A-core would be launching the M4 after it boots itself, which is really a poor assumption).

... is not a true statement.  The low-power code does try to copy off TCM to DDR which 'may' cause issues if your resource domain controller settings disallow the A-core from accessing this memory - which may result in lock-ups or 'weird' behavior.

[erikfriedel]

Hi Jeremy,

thank you for your answer.

I am trying to boot the M4 from QSPI via u-Boot. Using the sf Command in uboot does not seem to solve this problem. Even if I "sf read ..." the board resets itself and showing the usage of sf didn't work either.

Is this due to bad programming, compatibility issues or related to my specific Chip/board/uboot-settings?

EDIT: "sf" - undefined instruction | "sf probe 0 0" - data abort

in /include/configs/<myboard> the "CONFIG_SYS_USE_QSPI" isn't defined. Maybe this is the problem?

Best regards

Erik

[jeremym]

Yes, u-boot will likely need to be re-built with the 'sf' commands enabled (I believe CONFIG_SYS_USE_QSPI is the correct define).  Once you have u-boot rebuilt, make sure your QSPI application for the M4 is linked into the correct address space for QSPI (which it looks like yours is).  Then you can load the binary into RAM however works best (from SD card, tftp, etc.).  Then erase QSPI (sf erase 0x100000 0x2000, for example - most of the NXP literature uses an offset into QSPI because the u-boot ENV variables are stored in the lower portion of QSPI by default - you don't want to erase them by accident).  Also, notice that addressing for the 'sf' commands are relative to the QSPI part itself, not the address space used by the M4 or A-core.  Then you should be able to 'sf write' from RAM into the QSPI.  Then use the 'bootaux 0x60100000' command and you should be good to go.  Notice the address used for bootaux is relative to the A-core in this case which is running u-boot.  The offset (0x100000 in this case) needs to match your sf write offset.  The bootaux command will take care of copying your stack pointer and initial vector from the 0x60100000 address to the appropriate memory locations and then executing the 'jump' to the initial vector.

[Carlos_Musich]

Hi Jeremy,

basically what is happening is that the clock initialization that uboot do is different form the clock initialization that Linux set. Then when Linux starts it re-configures all clocks according to device tree and this is why M4 stops running. I would try to set the clocks in uboot as Linux does so when Linux starts they are not reconfigured. You may also take a look to the following posts:

FlexCAN interface not working on i.MX 6SoloX M4 and A9

I.MX6 SoloX M4 Problem 

Regards,
Carlos
NXP Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jeremym]

Hello Carlos - thanks for the reply.  Why is it that the TCM application does not suffer from this problem?  It continues to run as expected.  Its only the QSPI based M4 applications which seem to stop.  Is it because we launched the QSPI application from UBOOT (clock to QSPI NOR flash enabled and running) and then when Linux boots it stops the clock to the QSPI?  Is the A7 the clock master for the QSPI NOR flash even though the M4 is executing out of it?