<div dir="auto">What is your debugging setup? It would be really helpful for my future works on Rpi3.<div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Niteesh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 21 Jan, 2020, 7:23 AM Alan Cudmore, <<a href="mailto:alan.cudmore@gmail.com">alan.cudmore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A little more information on my Raspberry Pi 2 SMP tests:<br>
<br>
The BSP startup is getting to this loop:<br>
<a href="https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49" rel="noreferrer noreferrer" target="_blank">https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49</a><br>
(In the function _Per_CPU_State_wait_for_non_initial_state)<br>
In the while loop on line 49, the CPU state is PER_CPU_STATE_INITIAL (0).<br>
The while loop calls _CPU_SMP_Processor_event_receive() and returns,<br>
but the state is still 0<br>
It calls _CPU_SMP_Processor_event_receive() again and does not return.<br>
<br>
I'm reading up on the defines in percpu.h (comments for the defines<br>
are very helpful by the way)<br>
Based on what I can tell in the comments, the boot CPU will wait in<br>
PER_CPU_STATE_INITIAL<br>
until the secondary processors complete their primary initialization<br>
and transition to<br>
PER_CPU_STATE_READY_TO_START_MULTITASKING.<br>
<br>
Next is to figure out why the secondary processors are not<br>
transitioning or possibly why events are not occurring?<br>
<br>
Alan<br>
<br>
On Mon, Jan 20, 2020 at 6:25 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>> wrote:<br>
><br>
> On 21/1/20 10:20 am, Alan Cudmore wrote:<br>
> > As it turns out the latest RTEMS master may need some of the dtb<br>
> > and/or overlay files in the raspberry pi SD card. But the updated<br>
> > instructions that Niteesh submitted for the raspberrypi BSP should<br>
> > still be valid.<br>
><br>
> Great.<br>
><br>
> > Either way, we should be able to automate it. A firmware release on<br>
> > Github is ~180 megabytes. If you clone the whole repository, it's 10+<br>
> > Gigabytes, probably because you get every binary release.<br>
><br>
> Ouch. If we list the needed files, even if there is a few, I can fetch them from<br>
> github and avoid a full clone. We would need to settle on a specific hash or<br>
> version but that is not a bad thing.<br>
><br>
> > I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP<br>
> > code seems to work on the Pi 2, but when you have an example with<br>
> > #define CONFIGURE_MAXIMUM_PROCESSORS 4<br>
> > it crashes during initialization.<br>
><br>
> Awesome and all the best. I am sure you will figure it out.<br>
><br>
> Chris<br>
</blockquote></div>