Raspberry Pi test report

[Niteesh]

On Wed, Jan 22, 2020 at 2:18 AM Christian Mauderer <list at c-mauderer.de>
wrote:

> I think the not yet merged patch from Niteesh is a good reference:
>
> https://lists.rtems.org/pipermail/devel/2020-January/056860.htm
> <https://lists.rtems.org/pipermail/devel/2020-January/056860.html>l


The above instructions are not valid anymore, you have to provide a DTB
file.
You need to execute two more commands before running the executable
1)  restore dtb_file_name.dtb binary 0x2ef00000
2) set $r2 = 0x2ef00000

>
>
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
> >>>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200122/dcd48c8b/attachment-0001.html>