On Wed, Jan 22, 2020 at 2:18 AM Christian Mauderer <l...@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 <l...@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...@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.cudm...@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 <chr...@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 > >>> > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
