Where and how does VF61/M4 gets it's initial SP ..

[dry]

When you start Vybrid VF61x  /M4 core,  how does it get/set the SP from the firmware image, when

this is not debugging case where you can manipulate that directly?

In the Vybrid manual and the app note, it refers only to the "entry point of app"  which goes into SRC.GPR2, and some "argument"  (any param we want..?) into SRC.GPR3.   

And it says Boot ROM just checks if entry in SRC.GPR2 is valid address space, and jumps on it.  But no mentioning of setting the stack pointer. ...

[Carlos_Musich]

Hi D. RY,

"the bin blob contains the stack pointer (SP) at the beginning of the file (offset 0), and the program counter (PC) info at offset 4."

Not exactly, when M4 boots, the program Counter has reset value of 0x0, so it looks in this address and it will find the Vectors Table. The first vector is located at address 0x0 and it is the SP vector which loads SP value, but this does not mean that the SP value is loaded in address 0x0. Then PC continues with next address which is 0x4 (because of 32 bit architecture) and jump to the second vector which indicates the startup address, and here all the startup process starts until it reaches main.So after reset it will always look for the first vector at address 0x0.

Now, when M4 is a secondary core the process is the same but with a memory alias. M4 application including the vector table will be copied into shared memory (RAM), and it will internally look in the RAM copy what matches with address 0x0 of M4.

[dry]

Note on this: 

"  .. The first vector is located at address 0x0 and it is the SP vector which loads SP value, but this does not mean that the SP value is loaded in address 0x0.  ..."

If I understand your point correctly, this is note quite so.  (Unless you thought I meant that SP, after found by processor, gets loaded into address 0, but I didn't ...).   So on the ' .. SP vector which loads SP value' : 

See p. B1-581 of ARMv7-M Arch Reference Manual:

"The vector table contains the initialization value for the stack pointer, and the entry point addresses of each
exception handler. "

Actual _value_ that is stored, vs _entry_ point. 

( You can also see this in MQX's source code:   the first entry in the vector table is the actual _value_ of boot stack address. Not an 'SP vector' entry which loads SP. )

[dry]

Hello Carlos,

Thanks for engaging to help.

"the bin blob contains the stack pointer (SP) at the beginning of the file (offset 0), and the program counter (PC) info at offset 4."

What I mean is,  the _desired_ or target SP and PC values for this specific application code I build to be loaded by M4.

"...Not exactly, when M4 boots, the program Counter has reset value of 0x0, so it looks in this address and it will find the Vectors Table .."

Yes. On p. 1060 of Vybrid manual, Sec. 8.4.2 describes, that for M4 the first two words of the exception vector table are remapped by Hw to 0x00016000 and 0x00016004. This is the location of the default SP, and PC respectively.  The core, by default, boots from ROM as mentioned on that page.

Looking at those addresses after the module reset, on my SoC at least, the 0x00016000 (SP) has value 0x3f07ffb4  - end of OCRAM - sysRAM1 - while  0x00016004 (PC) contains  0x0000f4b9 - in Boot ROM, as expected.  So those are the values good for whatever the default M4 boot code is to do.

Thus after reset, it's the Boot ROM code that runs first, with no initial idea of my application needed SP and PC values.

(And for my MQX based example, my SP is very, very very far off the Boot ROM's code SP value. As per my example above, my SP is in 0x1f807ef0, MQX linking script sets it to CM4 TCML area)

On p.990 of Vybrid manual, sec. 7.5.11 Running Secondary Core, it says:

" ... The Boot ROM code checks the validity of the application entry address pointed to by SRC_GPR2 and, if valid, jumps to that address"

So the Boot ROM code jumps to whatever I've set as entry point into the application in the SRC_GPR2 register. How if at all the Boot ROM code gets the new SP value for the application code...? 

( I know it's somehow obvious, but I don't see it :smileysad: )

Per my previous example,  the app entry point is 0x3f00ca89  (in my case matching MQX's __boot function).  That's the value set into SRC_GPR2.  App also needs it's initial SP value (in my case 0x1f807ef0, per previous example, that's MQX's __BOOT_STACK_ADDRESS).

If the app binary - of the format as per my example, where first 4 bytes contain value for SP, and next 4 bytes value for app's entry point PC - got loaded into memory at 0x3f000000, then initial SP value to be fetched is from address 0x3f000000.

So how is that SP value fetched from there?   (If it's Boot ROM code's job, it only knows where app entry (which by the App note I assume is the app's entry point / PC value) to jump to.   .. Does it assume the initial vector table must be at the beginning of SysRAM0 based on app entry point given in SRC_GPR2 .... ? )

Thanks in advance.. Cheers.

(I Do feel a bit stupid by asking about this, but I rather have this cleared out in my head with someone's help, then not to ask and have an incomplete picture of how this works .)

[Carlos_Musich]

Hi D. RY,

this information is relative to the ARM Cortex core rather than the whole MCU. ARM provides this documentation. Please take a look to links below.

ARM Information Center 

boot - What is the booting process for ARM? - Stack Overflow 

Regards,
Carlos

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

[dry]

Hi Carlos,

Thank you for the links.

I'm referring to specifically to Vybrid's M4 firmware image startup procedure - code load, and CPU start. So specifically to Vybrid, the App note 4947.  

For example I'm loading an M4 binary image in bin format,  the bin blob contains the stack pointer (SP) at the beginning of the file (offset 0), and the program counter (PC) info at offset 4.  For a concrete MQX based example, say this is 

0000000: 7ef0 1f80 ca89 3f00.

Suppose the binary is getting loaded to address 0x3f000000.

Following App note 4947, I'm loading the PC (=3f00ca89) address into SRC_GPR2, and the argument register is ignored , no arguments for the code to start running (?).  App note says nothing about using/setting SP anywhere.

After I enable M4 through CCM.CCOWR, it will , as I understand, fetch the entry point from SRC_GPR2, and begin executing. It starts from 3f00ca89

I don't understand how and when will it fetch the SP from address 0x3f000000 (the load address)?  Because this is where the SP information is.  

In the general M4 case, it would start with vector table, which would contain SP as the first entry, followed by reset handler / app entry. (The same I see in MQX M4 vector table). But I don't understand how M4 fetches it, as it needs to know the binary load address (0x3f000000) or the new reset vector address?

(Sorry for my lack of seeing this. This is may be to clarify my confusion: if we would load the address of where app got loaded into the SRC_GPR2 then somehow it would be clear, as on reset M4 would fetch SP from it, and PC from offset +4.).   

So if you Carlos could explain the missing pieces for me here, I would appreciate it very much.

For iMX7,  you specify both, PC, and SP, for M4 loading, which is kinda nice I think. .. At least I have no confusion in that case.