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
