Properly/consistently document the use/need of mcore_clk bootenv/clk-imx8m{m,n,p}.mcore_booted Kernel commandline flag.

[s-hemer]

          This is actually mysterious: it does  ```setenv mcore_clk clk-imx8m{m,n,p}.mcore_booted``` which is handed over to Kernel command line. 

BUT: it sets it just once and not persistently (so for loading M-core firmware from Linux that must be set always?) and, at least from my quick trail (hello_world only), not setting it when having the M core already started in u-boot does not let the M core crash (that was my initial guess: that it is relevant for preventing a crash when proceeding with the boot).
The EVK configs in uboot-imx have this command, yet the AN5317 says at the note in 9.1.1: "By default, NXP Linux BSP keeps the root clock enabled for the M core when it is started from U-Boot". Additionally, it does not highlight the need of this parameter in 9.1.1.3 "Booting firmware early using U-Boot...".

Originally posted by @s-hemer in #102 (comment)

[s-hemer]

One very useful point would be to highlight that the equivalent of running the "run prepare_mcore" is to set mcore_clk=clk-imx8m{m,n,p}.mcore_booted, i.e. in bootenv.txt (like overlays) for permanent solution.

[s-hemer]

Some more tests imply that the flag is only needed if the M core was started in uboot (so the running firmware survives the boot to Linux). It is not needed for loading firmware through remoteproc.

Concluding, I would argue that the prepare_mcore just bloats the BSP: instead update the docu to just set the mcore_clk variable by either run the setenv command directly (it is also just one step that isn't that much longer) or put the line into bootenv.txt (mcore_clk=clk-imx8mp.mcore_booted). Additionally, it is somehow misleading as i.e. a real preparation (for loading a firmware for debugging via GDB) would be the M core startup via bootaux 0x1ffe0000 0.

[pefech]

Some more tests imply that the flag is only needed if the M core was started in uboot (so the running firmware survives the boot to Linux). It is not needed for loading firmware through remoteproc.

Actually I had a different experience on the phyBOARD Pollux when working on my thesis.
Even though I booted the mcore via remoteproc, I needed to run the run prepare_mcore command in u-boot.
Otherwise Linux crashed in a panic.

Because I didn't wanted to make that every boot I ran saveenv twice to save the current environment.

Maybe the kernel flags name is misleading and does not inform the kernel about a booted mcore, furthermore it
instructs the kernel to bring the clock in that state? But thats only speculation.
I'm not sure how the kernel interprets such flags and where to look in the source to find what it's doing.

I think that could be the first step to understand what this flag is actually doing

[s-hemer]

You are right, on imx8mp I had the same experience. But I am unsure if this is intended or another bug. In principle, the flag is just an info for the kernel not to touch the M-Core clocks (again, and not a real "preparation" of the core for whatever).