[PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support
alan.cudmore at gmail.com
Sun Sep 4 16:46:34 UTC 2016
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.
> 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,
> 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':
>> e/cpu.h:522: multiple definition of `_CPU_SMP_Start_processor'
>> 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
> 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
> #define CONFIGURE_SMP_MAXIMUM_PROCESSORS 2
> #define CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP
> #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
> 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,
More information about the devel