Using "core 1 release" with U-Boot in P1020RDB

[ricardofranca]

Hello,

I intend to run some simple applications on P1020RDB in a bare-metal configuration. While running something in core 0 is relatively straightforward, I am not being able to run anything on core 1. I made the following code:

volatile unsigned int change_me = 2;

void main(void)
{
change_me += 1;
return;
}

When running this on core 0 (e.g. by uploading the binary file to 0x04000000 and running "go 0x04000000"), I can see the memory corresponding to change_me was updated when the application ends and U-Boot prompt returns. When running "cpu 1 release 0x04000000", it seems cpu 1 gets stuck somewhere - the memory location of change_me is not updated and the core never gets back to the spin loop it was before I released it (though I do not know if it was supposed to return there when things go fine). When running "cpu 1 status", I could see "addr" was updated from 0x1 to 0x3, as expected when the core leaves its spin loop, but I do not know if there is an issue with the code or the memory write because I am currently without a debugging probe.

As far as I understood the U-Boot code, as soon as I release cpu 1, it creates a TLB entry for a 64MB page, using the address given in the "cpu 1 release" command (in this case, 0x04000000) masked to a multiple of 64MB. In this case, since my executable file (text and data) goes from 0x04000000 to 0x04000028, I expected things to work fine.

In a last attempt, I deployed my code in 0x3ff33500 (i.e. inside the 4KB TLB entry that was already mapped for cpu1 during boot), but the results were the same - core 0 ran the code without problems and core 1 seemed to get lost.

As I get the very same results when I try to release secondary cores on a T1042 board, I understand I am going wrong somewhere, but I do not understand where. If anyone has a working example of any working code (without the complexity of an OS), it will be very helpful for me.

Thanks!

Ricardo

[June_Lu]

So could I consider the "infinite loop" solve your issue? Please click the "ACCEPT AS SOLUTION" if it could solve your issue, any further help please kindly update your queries.

[June_Lu]

Any update please let me know.

[ricardofranca]

Hello,

Placing an infinite loop in the end of the function did not seem to make much of a difference. However, when I decided to configure a new TLB entry (even though U-Boot already creates one that looks fine) and store my data there, things seemed to work.

Thanks,

Ricardo

[June_Lu]

Here reply from Internal team:

"

Once core1 leave the spin table, it will keep executing the code.

So in your code, return is meaningless.

Could you please replace the return to a infinite loop?

that way you can check if the variable change_me is updated.

"

Please try it, any update please let me know.

[June_Lu]

Is there any update?

" If anyone has a working example of any working code (without the complexity of an OS), it will be very helpful for me."

Could share more details about the working code you want except without OS? 

[ricardofranca]

Hello,

I am still stuck on this topic. The working code would be very simple: anything that could show some activity in core 1 (e.g. change a value in the RAM memory or turn a CPLD LED on) would be sufficient for me to know core 1 has done something meaningful. In the small code I presented in this topic, I expected that any core that ran main() would update variable "change_me", but this worked only for core 0.

Thanks,

Ricardo

[June_Lu]

If you have installed CW v10.5.1, please refer C:\Freescale\CW_PA_v10.5.1\PA\Help\PDF\Targeting_PA_Processors.pdf, 2.1 CodeWarrior Bareboard Project Wizard