<div dir="ltr"><div dir="ltr">On Wed, Jan 22, 2020 at 2:18 AM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think the not yet merged patch from Niteesh is a good reference:<br>
<br>
<a href="https://lists.rtems.org/pipermail/devel/2020-January/056860.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-January/056860.htm</a>l</blockquote><div><br></div><div>The above instructions are not valid anymore, you have to provide a DTB file.</div><div>You need to execute two more commands before running the executable</div><div>1)  restore dtb_file_name.dtb binary 0x2ef00000</div><div>2) set $r2 = 0x2ef00000</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 21/01/2020 21:31, Alan Cudmore wrote:<br>
> I can try QEMU. Is there a quick pointer to the QEMU parameters needed<br>
> to run a Pi2 image?<br>
> Alan<br>
> <br>
> On Tue, Jan 21, 2020 at 3:22 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>> wrote:<br>
>><br>
>> Does the same error occur on the Pi2 Qemu? In that case you could use it<br>
>> for proper debugging.<br>
>><br>
>> On 21/01/2020 03:35, Alan Cudmore wrote:<br>
>>> I don't really have a debug setup.. I'm just using printk for now. But<br>
>>> I have a pretty efficient setup where I can add a few printk<br>
>>> statements, rebuild and copy the smp01.exe sample over to the SD card.<br>
>>> I use this board:<br>
>>> <a href="https://www.adafruit.com/product/3589" rel="noreferrer" target="_blank">https://www.adafruit.com/product/3589</a><br>
>>> It lets me connect the serial port using a USB cable, and it also<br>
>>> supplies power and provides a switch. I can pop the SD card in, flip<br>
>>> the switch and watch the UART output.<br>
>>> (Edit, make, objcopy, move card to pi, and flip the power switch).<br>
>>> The board provides plenty of power for the single core models through<br>
>>> the host USB port. I should double check that it's providing enough<br>
>>> power for the Pi2 before I spend too much time!<br>
>>><br>
>>> Here is an example of my latest output where the SMP initialization is<br>
>>> not completing:<br>
>>> RTEMS RPi 2B 1.1 (1GB) [00a21041]<br>
>>> in _SMP_Handler_initialize<br>
>>> in _SMP_Handler_initialize, max processors = 4<br>
>>> in _SMP_Handler_initialize - calling _CPU_SMP_Initialize<br>
>>> in _CPU_SMP_Initialize<br>
>>> in _SMP_Handler_initialize - _SMP_Processor_maximum = 4<br>
>>> in _SMP_Handler_initialize - calling _SMP_Start_processors<br>
>>> In _SMP_Start_processors<br>
>>> In _SMP_Start_processors - index = 0<br>
>>> In _SMP_Start_processors - index = 1<br>
>>> In _SMP_Start_processors - calling _CPU_SMP_Start_processor<br>
>>> in _CPU_SMP_Start_processor<br>
>>> in _CPU_SMP_Start_processor - wait for secondary processor to complete<br>
>>> in Per_CPU_State_wait_for_non_initial_state<br>
>>>  CPU state = 0<br>
>>> in Per_CPU_State_wait_for_non_initial_state - about to call<br>
>>> _CPU_SMP_Processor_event_receive in while loop<br>
>>> in Per_CPU_State_wait_for_non_initial_state - after<br>
>>> _CPU_SMP_Processor_event_receive in while loop<br>
>>>  CPU state  after = 0<br>
>>> in Per_CPU_State_wait_for_non_initial_state - about to call<br>
>>> _CPU_SMP_Processor_event_receive in while loop<br>
>>><br>
>>><br>
>>> Alan<br>
>>><br>
>>> On Mon, Jan 20, 2020 at 9:03 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>> wrote:<br>
>>>><br>
>>>> What is your debugging setup? It would be really helpful for my future works on Rpi3.<br>
>>>><br>
>>>> Thanks,<br>
>>>> Niteesh<br>
>>>><br>
>>>> On Tue, 21 Jan, 2020, 7:23 AM Alan Cudmore, <<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> 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" 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">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>
>>><br>
> <br>
</blockquote></div></div>