[U-Boot] Run a standalone application on a core other than 0

[U-Boot] Run a standalone application on a core other than 0

[João Fernandes]

As the subject says, I'm trying to run the "Hello world" standalone
application example on a core other than 0, on a Freescale QorIQ P4080.

I tried through the shell and programmatically by exporting cpu_release
function... nothing. My first thought was that only core 0 has register r2
with the address of the "global_data" structure, so I tried to set it on
the other cores, but still nothing. Help on this matter is highly
appreciated.

Regards,
Jo?o Fernandes

[U-Boot] Run a standalone application on a core other than 0

[Scott Wood]

On 07/02/2013 07:02:21 AM, Jo?o Fernandes wrote:
> As the subject says, I'm trying to run the "Hello world" standalone
> application example on a core other than 0, on a Freescale QorIQ  
> P4080.
> 
> I tried through the shell and programmatically by exporting  
> cpu_release
> function... nothing. My first thought was that only core 0 has  
> register r2
> with the address of the "global_data" structure, so I tried to set it  
> on
> the other cores, but still nothing. Help on this matter is highly
> appreciated.

If you mean a U-Boot application, this is not supported.  U-Boot  
doesn't run on cores other than 0, except for a small stub for the spin  
table code.

If you have true standalone code, you can release it on other CPUs  
using the "cpu <n> release" command.  That code will not have access to  
any U-Boot functionality.  Its entry state will be as described for  
secondary CPUs in ePAPR.  It will be the same as if an OS were spinning  
up its secondary cores by writing directly to the spin table.

-Scott

[U-Boot] Run a standalone application on a core other than 0

[João Fernandes]

Thank you Scott. On a somehow related question, when I use "cpu X release"
to run some code on a core other than 0, the changes to memory made by cpu
X are not made visible globally. I believe this is connected with WIMGE
bits - as soon as disable L1 and L2 it works fine - am I correct? If so,
does core 0 have 0x00000000 - 0x3FFFFFFF and 0x40000000 - 0x7FFFFFFF TLB
entries marked as cache coherent, or do I also have to set them for it?

Jo?o

On Tue, Jul 2, 2013 at 11:11 PM, Scott Wood <scottwood@freescale.com> wrote:

> On 07/02/2013 07:02:21 AM, Jo?o Fernandes wrote:
>
>> As the subject says, I'm trying to run the "Hello world" standalone
>> application example on a core other than 0, on a Freescale QorIQ P4080.
>>
>> I tried through the shell and programmatically by exporting cpu_release
>> function... nothing. My first thought was that only core 0 has register r2
>> with the address of the "global_data" structure, so I tried to set it on
>> the other cores, but still nothing. Help on this matter is highly
>> appreciated.
>>
>
> If you mean a U-Boot application, this is not supported.  U-Boot doesn't
> run on cores other than 0, except for a small stub for the spin table code.
>
> If you have true standalone code, you can release it on other CPUs using
> the "cpu <n> release" command.  That code will not have access to any
> U-Boot functionality.  Its entry state will be as described for secondary
> CPUs in ePAPR.  It will be the same as if an OS were spinning up its
> secondary cores by writing directly to the spin table.
>
> -Scott
>

[U-Boot] Run a standalone application on a core other than 0

[Scott Wood]

On 07/08/2013 12:22:03 PM, Jo?o Fernandes wrote:
> Thank you Scott. On a somehow related question, when I use "cpu X  
> release"
> to run some code on a core other than 0, the changes to memory made  
> by cpu
> X are not made visible globally. I believe this is connected with  
> WIMGE
> bits - as soon as disable L1 and L2 it works fine - am I correct? If  
> so,
> does core 0 have 0x00000000 - 0x3FFFFFFF and 0x40000000 - 0x7FFFFFFF  
> TLB
> entries marked as cache coherent, or do I also have to set them for  
> it?

You need to set the M bit in all TLB entries that reference memory that  
is shared.  U-Boot already does this, but perhaps the code you're  
running on the secondary CPU does not?  Is U-Boot still running on core  
0 at that point?

Also be sure you're using the proper memory barriers to ensure that  
changes are seen in the right order.

-Scott

[U-Boot] Run a standalone application on a core other than 0

[Scott Wood]

On 07/08/2013 02:07:53 PM, Jo?o Fernandes wrote:
> Indeed, my code currently doesn't setup the TLB.

So you're using the initial mapping that the U-Boot spin table code  
creates?

It looks like that entry is missing MAS2_M.  This needs to be fixed.

The secondary IMA that U-Boot creates also needs to begin at effective  
address zero to be ePAPR-compliant.

> Yes, U-Boot is still running on core 0. I'm looking for a  
> non-preemptive environment to run some
> benchmarks,

U-Boot is a bootloader, not a benchmarking environment.  It is strongly  
recommended that you not leave U-Boot running on any CPU (including  
spin table code) if you're running benchmarks.  For example, U-Boot  
will be continuously polling the serial port, which includes sync  
instructions that get broadcast to other CPUs.

> Is there a way to link my standalone application with the functions in
> U-Boot that manage the TLB, caches, etc.?

You could in theory create a custom U-Boot instance that runs in this  
way -- but again, U-Boot is a bootloader and is not ideally suited to  
this task.  What hardware init are you referring to?

-Scott