Raspberry Pi test report

[Christian Mauderer]

I think the not yet merged patch from Niteesh is a good reference:

https://lists.rtems.org/pipermail/devel/2020-January/056860.html

On 21/01/2020 21:31, Alan Cudmore wrote:
> I can try QEMU. Is there a quick pointer to the QEMU parameters needed
> to run a Pi2 image?
> Alan
> 
> On Tue, Jan 21, 2020 at 3:22 PM Christian Mauderer <list at c-mauderer.de> wrote:
>>
>> Does the same error occur on the Pi2 Qemu? In that case you could use it
>> for proper debugging.
>>
>> On 21/01/2020 03:35, Alan Cudmore wrote:
>>> 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
>>>
>