[PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support

[Alan Cudmore]

Hi Pavel,
Thanks for the information. I will try to enable SMP in my application too and see how that works. 

I do have a raspberry Pi 3, but I think the UART is different. The original UART from the processor is used for the Bluetooth module, and the UART pins are now connected to the mini-uart port on the Pi. So there will have to be some changes. I tried booting with HDMI as well, but that did not work. 

But it is exciting to see SMP code running on the Pi 2. 

Thanks,
Alan 



> On Sep 4, 2016, at 12:14 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> 
> Hello Alan,
> 
> On Sunday 04 of September 2016 16:38:36 Alan Cudmore wrote:
>> Hi Pavel,
>> I applied your patches, and verified that my apps still work on the
>> Raspberry Pi 1 ( Pi Zero ). Now I am moving to the Pi 2 for some tests.
>> 
>> When building for the Pi 2, I need to use the —enable-smp configure switch,
>> correct?
> 
> Yes. There is even added configure option RASPBERRYPI_CPUS which controls
> number of CPUs reported trough linker script to the application.
> The default is all four (4) when --enable-smp is set. If it is not set
> then it is set to 1. I have not solved misconfiguration which can
> be caused by selection --enable-smp for RPi1. It fails horribly
> because some peripherals referenced by SMP code are not available.
> 
>> When I build the raspberrypi2 BSP with —enable-smp and —enable-tests, the
>> smpfatal08 test does not compile. It has multiple definition errors like
>> the following:
>> ../../../../../raspberrypi2/lib/librtemsbsp.a(libbsp_a-bspsmp.o): In
>> function `_CPU_SMP_Get_current_processor':
>> /Users/alan/rtems/build/build-pavel-tmp/arm-rtems4.12/c/raspberrypi2/lib/li
>> bbsp/arm/raspberrypi/../../../../../.././raspberrypi2/lib/include/rtems/scor
>> e/cpu.h:522: multiple definition of `_CPU_SMP_Start_processor'
>> init.o:/Users/alan/rtems/build/build-pavel-tmp/arm-rtems4.12/c/raspberrypi2
>> /testsuites/smptests/smpfatal08/../../../../../../../../rtems-src/rtems-pave
>> l/c/src/../../testsuites/smptests/smpfatal08/init.c:60: first defined here
> 
> I have tried complete tests build and this one fails for me as well.
> I have removed references to smpfatal08 from lists in the file
> 
>  arm-rtems4.12/c/raspberrypi2/testsuites/smptests/Makefile
> 
> The test seems to check cpukit core by replacing BSP provided
> CPU management functions by some dummy/test ones and for given
> setup the original ones are pull in together with some another
> symbol and result is clash.
> 
> Then all other tests build OK. I have tried many of them. I have
> noticed only one failure (testsuites/smptests/smpmutex01)
> 
> *** BEGIN OF TEST SMPMUTEX 1 ***
> ../../../../../../../../../git/rtems/c/src/../../testsuites/smptests/smpmutex01/init.c: 184 expected == actual
> 
> Has that problem been spotted on Zynq or Altera too?
> 
>> But I tried several of the SMP tests that did compile before this one and
>> they are working on my Raspberry Pi 2!
>> 
>> When I build with just the samples, rather than the full test suite, the
>> build completes, and I can link and run my application just like the Pi.
> 
> If you build own application then you need to to include something
> like
> 
>  #define CONFIGURE_SMP_MAXIMUM_PROCESSORS  2
>  #define CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP
> 
> before
> 
>  #include <rtems/confdefs.h>
> 
> to configure application to actually use more CPUs. Example is to use
> only two. If you select limit above 4 then it is corrected by BSP.
> 
> I have prepared simple OMK example which runs two tasks on two CPUs
> 
>  https://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/refs/heads/master:/rtems-omk-template/appsmptest
> 
> I used it during SMP mailboxes and timer debugging.
> 
> By the way, have you Raspberry Pi 3?
> I have not tested that but there is some chance that RPi2
> build could run on RPi3 unmodified for 32-bit mode.
> According to scattered information it seems that
> there are no differences in base addresses of critical
> peripherals. But may it be that there would be some problem
> in core code support or elsewhere.
> 
> Best wishes,
> 
>              Pavel