Raspberry Pi test report

[Alan Cudmore]

I don't really have a debug setup.. I'm just using printk for now. But
I have a pretty efficient setup where I can add a few printk
statements, rebuild and copy the smp01.exe sample over to the SD card.
I use this board:
https://www.adafruit.com/product/3589
It lets me connect the serial port using a USB cable, and it also
supplies power and provides a switch. I can pop the SD card in, flip
the switch and watch the UART output.
(Edit, make, objcopy, move card to pi, and flip the power switch).
The board provides plenty of power for the single core models through
the host USB port. I should double check that it's providing enough
power for the Pi2 before I spend too much time!

Here is an example of my latest output where the SMP initialization is
not completing:
RTEMS RPi 2B 1.1 (1GB) [00a21041]
in _SMP_Handler_initialize
in _SMP_Handler_initialize, max processors = 4
in _SMP_Handler_initialize - calling _CPU_SMP_Initialize
in _CPU_SMP_Initialize
in _SMP_Handler_initialize - _SMP_Processor_maximum = 4
in _SMP_Handler_initialize - calling _SMP_Start_processors
In _SMP_Start_processors
In _SMP_Start_processors - index = 0
In _SMP_Start_processors - index = 1
In _SMP_Start_processors - calling _CPU_SMP_Start_processor
in _CPU_SMP_Start_processor
in _CPU_SMP_Start_processor - wait for secondary processor to complete
in Per_CPU_State_wait_for_non_initial_state
 CPU state = 0
in Per_CPU_State_wait_for_non_initial_state - about to call
_CPU_SMP_Processor_event_receive in while loop
in Per_CPU_State_wait_for_non_initial_state - after
_CPU_SMP_Processor_event_receive in while loop
 CPU state  after = 0
in Per_CPU_State_wait_for_non_initial_state - about to call
_CPU_SMP_Processor_event_receive in while loop


Alan

On Mon, Jan 20, 2020 at 9:03 PM Niteesh <gsnb.gn at gmail.com> wrote:
>
> What is your debugging setup? It would be really helpful for my future works on Rpi3.
>
> Thanks,
> Niteesh
>
> On Tue, 21 Jan, 2020, 7:23 AM Alan Cudmore, <alan.cudmore at gmail.com> wrote:
>>
>> 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