AM2634: RBL firmware will use the OCRAM from 0x70100000 to 0x701FFFFF?

Hi Will,

Will Gao said:

I found that under QSPI boot mode, the 0x70100000 to 0x701FFFFF OCRAM have random initial values but not 0x0 or 0xF.

I don't yet have a summary of RBL / SBL memory usage. I'll investigate and get back with you.

Does the SBL finish executing? Do the aborts occur in the application code after the SBL has finished?

Where do the aborts occur? Do they occur on both cores? If stack is placed in that OCRAM range for only one of the cores, do the aborts only occur on that core?

I don't know why random values in stack memory would cause a problem since stack memory is explicitly pushed/popped and the random values will be overwritten when values are pushed to the stack. Have you found that initializing the memories to a known, pre-determined value resolves the aborts?

Regards,
Frank

Hi Will,

Do the executable work when loaded from JTAG? Do they work from JTAG if the random data patterns are written to the stack memory area?

Regards,
Frank

Hi Frank, 

In JTAG debug mode, the program can work since the RAM has initial value of 0x0. The reason is that the RBL firmware is not using OCRAM under NOBOOT mode. 

Best Regards, 

Will 

Hi Frank, 

Thanks for your reply. 

Frank Livingston said:

Does the SBL finish executing? Do the aborts occur in the application code after the SBL has finished?

The SBL has finished and the aborts occur in APP code. 

Frank Livingston said:

Where do the aborts occur? Do they occur on both cores? If stack is placed in that OCRAM range for only one of the cores, do the aborts only occur on that core?

The occurring place is random. They only occur in core 1-0. The aborts will occur when the core's irq_stacks section is placed on 0x70100000 range.  

Frank Livingston said:

Have you found that initializing the memories to a known, pre-determined value resolves the aborts?

This is a good idea. I can let customer try this method.  

Best Regards, 

Will 

Hi Will,

When you use the acronym "RBL", do you instead mean "SBL"?

Ok, I suggest clearing the stack area since this is what is observed in the JTAG debug mode.

I'll wait for the result of the experiment.

Regards,
Frank

Hi Frank, 

I think the SBL will not manipulate the OCRAM space from 0x70100000 to 0x701FFFFF unless there are some cores' appimage should be located there. From the memory contents, I suppose the random value of OCRAM is written by ROM bootloader (RBL) of R5F. Please help confirm whether the RBL firmware will do this or not. Thanks. 

The problem can be solved by allocating the stacks section into 0x70000000 to 0x70100000. But I will also let customer to clean the OCRAM in their Second bootloader (SBL). Thanks for your guidance. 

Best Regards, 

Will 

Hi Will,

Will Gao said:

From the memory contents, I suppose the random value of OCRAM is written by ROM bootloader (RBL) of R5F. Please help confirm whether the RBL firmware will do this or not

I was told the following by internal experts: ROM uses initial 640B from TCMA (IVT & startup code) and 16KB for stack and global data in TCMB.

Will Gao said:

The problem can be solved by allocating the stacks section into 0x70000000 to 0x70100000

It's good to know there's a workaround.

Will Gao said:

But I will also let customer to clean the OCRAM in their Second bootloader (SBL)

Ok, I'm curious to know the outcome of the experiment. As I said before, I don't see how random values in OCRAM cause a problem with stack. Are they certain these random values are static code/data which SBL has loaded?

Regards,
Frank

Hi Frank, 

Thanks for your information. 

Frank Livingston said:

I'm curious to know the outcome of the experiment. As I said before, I don't see how random values in OCRAM cause a problem with stack.

On possible I can imagine is If some local variables are used as pointer but without initialization, random vale in stack will cause exception. 

Frank Livingston said:

ROM uses initial 640B from TCMA (IVT & startup code) and 16KB for stack and global data in TCMB.

Ok, I need to check this in customer's field and in my CC card. If these random values are not written by RBL, I think they need to check their SBL again. 

Will update the information, thanks for your help. 

Best Regards, 

Will 

Hi Will,

Will Gao said:

On possible I can imagine is If some local variables are used as pointer but without initialization, random vale in stack will cause exception. 

Good point, but these variables should be initialized before being used! Clearing the stack masks the issue.

Regards,
Frank