Raspberry Pi test report

[Alan Cudmore]

A little more information on my Raspberry Pi 2 SMP tests:

The BSP startup is getting to this loop:
https://git.rtems.org/rtems/tree/cpukit/score/src/percpustatewait.c#n49
(In the function _Per_CPU_State_wait_for_non_initial_state)
In the while loop on line 49, the CPU state is PER_CPU_STATE_INITIAL (0).
The while loop calls _CPU_SMP_Processor_event_receive() and returns,
but the state is still 0
It calls _CPU_SMP_Processor_event_receive() again and does not return.

I'm reading up on the defines in percpu.h (comments for the defines
are very helpful by the way)
Based on what I can tell in the comments, the boot CPU will wait in
PER_CPU_STATE_INITIAL
until the secondary processors complete their primary initialization
and transition to
PER_CPU_STATE_READY_TO_START_MULTITASKING.

Next is to figure out why the secondary processors are not
transitioning or possibly why events are not occurring?

Alan

On Mon, Jan 20, 2020 at 6:25 PM Chris Johns <chrisj at rtems.org> wrote:
>
> On 21/1/20 10:20 am, Alan Cudmore wrote:
> > As it turns out the latest RTEMS master may need some of the dtb
> > and/or overlay files in the raspberry pi SD card. But the updated
> > instructions that Niteesh submitted for the raspberrypi BSP should
> > still be valid.
>
> Great.
>
> > Either way, we should be able to automate it. A firmware release on
> > Github is ~180 megabytes. If you clone the whole repository, it's 10+
> > Gigabytes, probably because you get every binary release.
>
> Ouch. If we list the needed files, even if there is a few, I can fetch them from
> github and avoid a full clone. We would need to settle on a specific hash or
> version but that is not a bad thing.
>
> > I'm trying to troubleshoot the RPi 2 SMP a little bit now. Non SMP
> > code seems to work on the Pi 2, but when you have an example with
> > #define CONFIGURE_MAXIMUM_PROCESSORS 4
> > it crashes during initialization.
>
> Awesome and all the best. I am sure you will figure it out.
>
> Chris