about M4 sw resets through SRC_M4RCR

[dry]

In context of iMX7D.

I would like to verify: for the SW_M4P_RST, and SW_M4C_RST,  does the M4P (platform) reset holds the core in reset or halted after the reset? Unlike M4C (core) reset, which resets restarts the core?

(Refreshing myself with AN5317.pdf, and this is how I think it should work using the steps in the doc... )

Also bit 0 - SW_M4C_NON_SCLR_RST (which was marked as reserved field, in rev 0 of the manual, I think, and definitely so in the AN5317) : is the only difference to the SW_M4C_RST is that it software controls when the core may come out of reset / start running again? Or is there anything else.

[dry]

Yuri‌, how does this sequence look, wrt to M4 core running/ not :

------    A  --------------

0 Fresh SoC start  --->

1  A7 boots / M4 core not running  --->

2  A7 enables m4 (ENABLE_M4 bit ) / M4 core not running  ---> 

3  A7 does M4 platform reset (SW_M4P_RST bit ) / M4 core not running --->

4  A7 programs memory (uploads M4 firmware), and sets SP, PC values in OCRAM_S / M4 core not running -->

5  A7 does M4 core reset (SW_M4C_RST) / M4 core running.

------    B  --------------

0  SoC already fully running (A7 cores and M4 up, ENABLE_M4 bit is set already ) / M4 core running  --->

1  A7 does M4 platform reset (SW_M4P_RST bit ) / M4 core not running ( held?  But ENABLE_M4 bit remains set) --> 

2  A7 programs memory (uploads M4 firmware), and sets SP, PC values in OCRAM_S / M4 core not running  -->

3  A7 does M4 core reset (SW_M4C_RST) / M4 core running

Is M4 non running under B correct?

[Yuri · Accepted solution]

Hello,

  According to section 3.2 (Detailed procedure) of app note AN5317 (Loading Code on

 Cortex-M4 from Linux for the i.MX 6SoloX and i.MX 7Dual/7Solo), Rev. 0, 08/2016

the following is recommended sequence to load and run the CM4 code:

1) Issue a software platform reset by setting up SW_M4P_RST (Bit 2) in the SRC_M4RCR

  (SRC_M4RCR[2]) register. Issuing a platform reset, resets the Cortex-M4 cores and

  associated memories.

2) Load the code for the Cortex-M4 processor into the (TCM_L) memory.

3) Setup the Stack and PC pointer in the OCRAM_S memory, because after reset the

  processor uses the OCRAM_S start address (0x0018_0000) as the first instruction.

4) Set the ENABLE_M4 (Bit 3) in the SRC_M4RCR (SRC_M4RCR[3]) register.

5) Set the SW_M4C_RST (Bit 1) in the SRC_M4RCR (SRC_M4RCR[1]) register, which will

  boot the new code on the Cortex-M4 processor.

   So, we can see that, the variant A in Your considerations is not correct; at least it violates

the recommended sequence.

  When it is needed to reload a new image, just repeat steps 1-3, as recommended in the

app note. There is no mentions about disable / enable CM4 with ENABLE_M4. Generally

such approach works, but I recommend to disable CM4 before reloading new application.

  So, regarding Your question “Is M4 non running under B correct?” - no, it is not guaranteed.

Please look at the following Community thread.

https://community.nxp.com/message/1011287 

Note, bit SW_M4C_NON_SCLR_RST (bit 0) in the SRC_M4RCR[3] can be used to hold the CM4

core in reset state.

Regards,

Yuri.

[dry]

YuriMuhin_ng‌ actually another question:

Yuri Muhin wrote:

Issuing a platform reset, resets the Cortex-M4 cores and

  associated memories. ..

Does the NXP manual give more details about what gets reset (in addition to core) and to what ?  You wrote memories is this all? Do memories get cleared ?

[Yuri]

Hello,

  According section 4.2.2 (Cortex-M4 Platform Features) of the i.MX7D RM, the CM4

platform includes:

 - Cortex M4 Core;

 - AHB LMEM;

 - Network Interconnect (PL301).

  CM4 platform reset does not guarantee CM4 memory preserving.

Regards,

Yuri.

[dry]

Thanks Yuri for coming back on this.

Thus  (among other things), AN5317 doc, Rev 0 08/2016  (is there later .. ?) is not really correct.  Forgets to mention that the core is not guaranteed to be halted.  (Ta daaaam).

Thanks will review that other thread.

Спасибо :smileyhappy:

[Yuri]

App note AN5317, Rev. 0, 08/2016 is the recent one. I do not have information if 

it will be modified. 

https://www.nxp.com/docs/en/application-note/AN5317.pdf 

~Yuri.

[dogisfat]

When ENABLE_M4 is set to "0" it seems like some of the memory doesn't get written. I am using the TCM for reference and I am guessing the ENABLE_M4 bit may disable the clock to that memory. Instead I am using the SW_M4C_NON_SCLR_RST (bit 0) to hold the M4 in reset while I do the programming. The reference manual and AN5317 BADLY need to be updated to reflect a proper programming cycle when the M4 is already running. In my case the M4 uses DDR (RPMSG and general memory). Occasionally without the M4 being held in reset it would crash BOTH the A7 cores and the M4 rendering the system completely dead.

[dry]

Hey Allen,

...When ENABLE_M4 is set to "0" it seems like some of the memory doesn't get written. I am using the TCM for reference  ...

Just wondering do you flush the cache after write?  I don't think the app note mentions this, but about all other places flush it after load (e.g. the doc covering loading of m4 samples from U-boot;  Linux kernel driver imx proc I _think_ also does it)

[dogisfat]

I would suspect this isn't the issue as it works fine so long as ENABLE_M4 isn't cleared.

[dry]

I see, nice you tried.

I must say, for any of the small examples NXP provided (like hello TCM, OCRAM, and the rpmsg samples) I never had any issues loading them and running them. As far as I tried .. 

I'm using my modd'ed version of that loader app : GitHub - dry-75/imx-m4fwloader: Tool for loading firmware to M4 core on i.MX6SX and 7D 

( Will have to update now for this last bit & Yuri's comments).

Will be switching to Linux's imx proc driver to do this the 'proper way'  in close future ..

[dogisfat]

What is the 'imx proc driver' that you refer to? Because we use DDR and TCM having the processor not in reset is a huge problem when the memory is invalid or only slightly valid during reset/programming as it will bring the entire SOC.

[dry]

That driver is not in FSL/NXP's BSP for iMX7D (assuming last year's release I use is latest ..).

You would have to back-port it from mainline.

linux/imx_rproc.c at master · torvalds/linux · GitHub 

Can you explain what you mean : 

...

 Because we use DDR and TCM having the processor not in reset is a huge problem when the memory is invalid 

Will be eventually also moving to DDR at some stage .. 

What do you mean not in reset ? I thought , that will be sorted with the last bit 0 for M4.  On Linux/A7, that memory should be reserved/unavailable for A7.

Also do you load your M4 code at end of DDR somewhere, or into the beginning, into the cache'able part at the start.

[dogisfat]

Thanks for linking the imx_rproc. We have essentially made our own version of imx_rproc.c but it may make sense for to transition to the official one depending on what it supports. 

We currently load our image into the base of the ddr 0x80000000 to take advantage of the caching. Additionally we use the RPMSG which uses memory at a fixed location. When not setting SW_M4C_NON_SCLR_RST and using the instructions provided in AN5317 occasionally on reloading the M4 the M4 would go crazy and start trashing random locations in DDR. You are correct that it is sorted by setting SW_M4C_NON_SCLR_RST. The reference manual I had for the iMX7D showed SW_M4C_NON_SCLR_RST as reserved. Now that I know the bit isn't reserved I feel much better using it.

D.RY also be aware bugs affecting the DDR caching documented here: 

IMX7 M4 caching and execution speed 

https://community.nxp.com/thread/459977 

[dry]

ALLEN BLAYLOCK wrote:

..he instructions provided in AN5317  ..

Yea, And , also just double checked it  , their Rev 0.1 of the manual also has it Reserved.  The updated Rev 1 (01/2018) has it corrected. 

The linux driver original date, by history, is from Aug 2017, and yet he got the bit right ..  (May be he figured it out or has in-roads into NXP).

D.RY also be aware bugs affecting the DDR caching documented here: 

IMX7 M4 caching and execution speed 

i.MX7D: atomic compare and swap instructions don't work with cache 

Yea thanks, I accidentally saw it the other way ... I'm still to re-examine that M4 caching post, but it's a bit shocking (still to discuss it with our hw engineers).

Please note if you do use the Linux driver to load it, and your linker scripts are based on  NXP/FSL samples, see here:

https://www.spinics.net/lists/linux-remoteproc/msg02838.html

And related:

https://lists.gt.net/linux/kernel/2684252?search_string=rproc_elf_load_segments;#2684252

If you have your own driver then you likely not affected.

[dry]

nice you tried =  disabling m4 bit that is ..

[Yuri]

Hello,

  The CM4 reset bits SW_M4P_RST, SW_M4C_RST, and SW_M4C_NON_SCLR_RST

are used just to reset the CM4, without holding it is the reset state. Note, the CM4 will be

in some hold state after reset , when clocks are not provided. Bit ENABLE_M4 should be

set to provide the clocks.

  According to section 4.2.5 (Cortex-M4 Boot Requirements) of the i.MX7D Reference Manual

(Rev. 1, 01/2018), launching the Cortex-M4 is performed by enabling its clock and clearing its

reset bit in SRC.

Have a great day,

Yuri

------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

[dry]

Yuri Muhin wrote:

  According to section 4.2.5 (Cortex-M4 Boot Requirements) of the i.MX7D Reference Manual

(Rev. 1, 01/2018), launching the Cortex-M4 is performed by enabling its clock and clearing its

reset bit in SRC.

Sorry but which bit it this ?  

[dry]

Hi Yuri,

But per that AN5317 note, the steps for re-loading code on iMX7d/s (sub-sec. 3.3) , it does platform reset,  programming, then resets the core.  The enable m4 bit stays on, and in step 4 there it says since bootaux already booted primary image , that bit is on, and platform reset does not clear that bit. 

Thus I don't understand: if the m4 stays enabled, and you reset with platform reset, and start programming/code upload,  what you wrote above says then, the core would reset & continue running while you still busy programming memory ...  Seems it should be held in reset or core halted. 

Step missing on first clearing enable m4 bit before programming then?

[Yuri]

Hello,

  You may also look at  https://community.nxp.com/docs/DOC-106253 

Regards,

Yuri.

[dry]

Yuri,

That goes over the same boot procedure, essentially.. .The last post, from Tomasz, repeats the detailed steps from AN5317, as far as I see, for reloading the code.  (I don't understand why he wrote it " changed from m4c_non_sclr_rst to m4c_rst. ",  because the app note does not say use self-clearing, it marks that field as reserved. May be we looking at different docs).

After enable m4 bit is set , what does m4 core do after M4 platform reset (SW_M4P_RST)  is triggered  and completes?

Is it required to clear ENABLE_M4  bit before loading firmware image?