daniel79
Posts: 3
Joined: Mon Jul 03, 2017 8:50 am

Reset specific core

Fri Oct 13, 2017 11:44 am

Hello,
I dedicated one ARM core for baremetal application and the remaining 3 cores for Linux.
Baremetal application is loaded into memory on some address and then started executing by writing this address to the first mailbox of the dedicated core.
Is there any way how to reset specific core, so I can load new code and start executing it?

I have found something in ARM documentation (http://infocenter.arm.com/help/index.js ... index.html), but I am not sure if it is accessible, I cant find anything in BCM2836 documentation.
I was also thinking about to jump to loop, that would be waiting for mailbox with address of new code.

Thank you

LdB
Posts: 562
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reset specific core

Fri Oct 13, 2017 3:27 pm

Yes that idea works, just create your own core park loop or alternatively work the return address from the loop register when you enter your routine, your choice.

If it helps I have it done in C, I had to preserve registers R0-R3 because my function call is in C but look here
https://github.com/LdB-ECM/Raspberry-Pi ... tStart32.S
Specifically the new spincode from marked

Code: Select all

/*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++}
{    Modified bootloader Spin loop but tolerant on registers R0-R3 for C    }
{++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/
.balign	4
SecondarySpin:

So simply write this new spin loop address to the core you wish to park in this new spin loop.
The core will then jump to the new spin loop which I mostly copied from the bootloader code but preserved the registers and make it loop back to top. In C my functions are just void func (void) and when they exit they come back on the link register and around it goes.

Otherwise from the Pi bootloader code
https://github.com/raspberrypi/tools/bl ... armstub7.S
The loop position you need is label "1:" which from the bx r4 I make out should be link register - 32 if my opcode count was right.
Check my opcode count but that label is the address you need to go back to. I haven't done it that way because the C compiler will trash the registers but if you preserve them it will work.

You can see what will happen if you just return back it will drop into the wfi and deadloop to label "10:". Which is what you probably found out you can call it just once.

rst
Posts: 288
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Reset specific core

Fri Oct 13, 2017 4:09 pm

There is no way to direct a reset to a specific core. But you may use an Inter-Processor Interrupt (IPI) for this. A prerequisite for this is, that the "bare metal" core does not disable the IRQ and does not overwrite some memory. It must behave well.

Please have a look at the QA7 document for the following explanations. I suppose your bare-metal core is core 3.

You have to set-up a vector table for this core and write its address to the VBAR system control register. You have to enable "Mailbox-0 IRQ control" for your bare metal core by writing a 1 to the "Core3 Mailboxes interrupt control" register (at 0x4000005C). Then you can enable the IRQ using "cpsie i".

An IPI will be sent from core 0-2 by writing some value to the mailbox 0 set register of that core (at 0x4000008C). Your IRQ handler in the vector table (see above) will be started then. Its first action should be to acknowledge the value in mailbox 0 by writing to the mailbox 0 clear register of core 3 (at 0x400000CC). Then you can do what ever you want to start your new code on core 3.

You may also have a look at IPI support in Circle, which is pure bare metal code. I guess, in Linux you need a kernel driver to implement this.

LdB
Posts: 562
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reset specific core

Fri Oct 13, 2017 4:27 pm

He doesn't want to really reset the core rst he just wants to be able to hyperthread it and run new code. It's clear what he is doing but yes he should not have used the word reset, reloop would have been more appropriate. Good pickup and if he ever did want to reset the core he now knows how to do it.

Yes it's a mess to try and really reset the core proper under linux because it would try and run straight back into linux which you would have to stop it.

rst
Posts: 288
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Reset specific core

Fri Oct 13, 2017 5:00 pm

LdB wrote:
Fri Oct 13, 2017 4:27 pm
He doesn't want to really reset the core rst he just wants to be able to hyperthread it and run new code.
I think, I understood well, what he wanted. My solution is nearer to a "real reset" than yours. The bare metal code does not need to have an end and does not need to periodically poll some mailbox. But let him decide, what he wants to use.

EDIT: nearer to a "real reset", not near
Last edited by rst on Fri Oct 13, 2017 7:12 pm, edited 1 time in total.

LdB
Posts: 562
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reset specific core

Fri Oct 13, 2017 5:53 pm

Agreed totally but it is a lot slower response if all you want is hyperthreading, was all that crossed my mind :-)
I got something from it anyhow even if he doesn't use it and have bookmarked your code. I have often wondered if I could recover a core from a fatal crash and you have given me a way to do it as you said it's a near perfect reset.

rst
Posts: 288
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Reset specific core

Fri Oct 13, 2017 6:43 pm

Yes, of course the IPI is more difficult to implement and to debug. I also forgot to mention, that you have to leave HYP mode on start-up on the bare-metal core that it works and your are in IRQ mode when the IPI is triggered. This has to be handled.

As I wrote, that IPI solution can only work, if the core behaves well (does not disable IRQ, does not overwrite memory). So it's vague, if you can get back a core after a crash.

dwelch67
Posts: 835
Joined: Sat May 26, 2012 5:32 pm

Re: Reset specific core

Sat Oct 14, 2017 12:27 pm

The ARM IP contains individual enables and resets per core, but it is up to the chip vendor as to what to do with these. I am still hoping that broadcom has an undocumented register with individual controls that the gpu used to start the arm. If the OP is not interested in actual resets but simply wants to change the execution path of one of the cores that is a different question, although a reset could have been used to do that. (big hammer approach or not, I guess it depends).

daniel79
Posts: 3
Joined: Mon Jul 03, 2017 8:50 am

Re: Reset specific core

Sat Oct 14, 2017 8:35 pm

My use case is to update source code, recompile, load and start executing without restarting whole Raspberry even if previous program disabled interrupts or somehow crashed.

I created small bootloader that is loaded to memory only once, reloadable program is stored in different location. When I want to update program instructions I park that core in bootloader (via mailbox irq), update instructions of program and start executing new code via mailbox.
(Here is link, if anyone find it useful https://github.com/trnila/rpi2-amp/tree ... bootloader)
I am afraid to jump back to armstub7.S, because it may change in future.

I would be happier if there was way how to recover from core crash.

Thank you, you helped me a lot.

LdB
Posts: 562
Joined: Wed Dec 07, 2016 2:29 pm

Re: Reset specific core

Sun Oct 15, 2017 4:01 pm

I understand what you are doing but I had a couple of linux questions because it's a groovy idea.

1.) How do you tell linux that it has only 3 cores?
2.) How do you exclude an area of memory from linux for RTOS to run in?

daniel79
Posts: 3
Joined: Mon Jul 03, 2017 8:50 am

Re: Reset specific core

Sun Oct 15, 2017 5:21 pm

1.) number of cpus can be configured by adding maxcpus=3 to /boot/cmdline.txt
2.) currently I reserved the second half of memory to FreeRTOS with device tree:

Code: Select all

reserved-memory {
    #address-cells = <1>;
    #size-cells = <1>;
    ranges;
    
    baremetal {
        reg = <0x20000000 0x20000000>;
    };
};

Return to “Bare metal”

Who is online

Users browsing this forum: No registered users and 5 guests