Can I implement SMP with Cortex-R5F dual core in zynqultraScale+ mpsoc?

If SMP implementation of FreeRTOS is possible, how should I modify it?
Is there another example?

Currently there is an SMP branch of FreeRTOS at this location: GitHub - FreeRTOS/FreeRTOS-Kernel at smp
There are a few ports available. The RP2040 is a good device to use as a reference to an SMP port.

The Cortex-R5 devices I have seen so far do not have unified RAM so they are best suited for AMP implementations. Essentially an AMP is a separate copy of FreeRTOS running on each core. If your R5 system unifies the RAM, then SMP will likely work with some porting.

Thank you so much for your explanation.
Does the case of R5 system unifies RAM mean a change in the chip?
Why use unified RAM to use FreeRTOS?
If RAM is not unifies, is there any way to implement it in FreeRTOS?

The SMP version of FreeRTOS schedules tasks to ALL cores in the system. That requires that the each core have access to the memory required by any task. Even the kernel task list must be shared between the cores. This requirement forces each R5 to have full access to ALL the memory.

If the R5’s do not have shared access to all the memory, then you can run 1 instance of FreeRTOS on each R5. Tasks will only run on a single R5. In effect you will have multiple applications running and each application will have its own copy of FreeRTOS. In this system, any communication between R5 applications will need to be handled with special features in that SOC.

For Xilinx ultrasound + MPSoC, R5 is the memory of the TCM.
After checking the Xilinx sheet, TCM is divided into A and B.
Can I use FreeRTOS if I unify this memory?
Also, does using DDR as a shared memory have any performance problems?
The A53 core is also used as Linux in DDR memory.

This is the Zynq UltraScale+ MPSoC Software Developer’s Guide.
There is no other word about why XILINX can’t apply for.

My guess is that the memories can’t both be TCM for both processors at the same time. That would need arbitration logic that would make it hard to be Tightly Coupled.

Normally, sharing a memory between processors will add delays to its access, and DDR also normally has a delay in accessing it

Reading the details of RPU in this document, I do not thin is possible to unify.

Likely. The recommendation from Xilinx is to use TCM -

There are two TCM interfaces that permit connection to configurable memory blocks of tightly-coupled memory (ATCM and BTCM).

•An ATCM typically holds interrupt or exception code that must be accessed at high speed, without any potential delay resulting from a cache miss.

•A BTCM typically holds a block of data for intensive processing, such as audio or video processing.

Would you please elaborate on why do you want to use SMP? What is the problem that you are trying to solve?

We are going to use CAN communication and various interfaces for the Cortex-R5F core. In terms of performance, I think you can show higher performance when you use two rather than one. Therefore, I want to operate as SMP.

[Sharing memory between processors typically adds a delay in access, and DDRs also typically experience a delay in access]
The key to what I want to know is the text above. I want to know exactly why.

Why is it delayed when shared?
Will it be delayed if I use DDR?

This question is very specific to Xilinx hardware and I’d recommend reaching out to them as they would be able to provide accurate information.

This time it’s a different matter. I want to make sure that it runs on Linux on the three cores of the A53 in zynqMP, and that it works by booting together in FreeRTOS. However, at Linux boot time
“Assert failed in file port.c, line 658”
“Assert failed in file port.c, line 609” has an error and is stopping operation. I think it’s an Interrupt related error, but I don’t know how to solve it.

The source code of FreeRTOS is as follows:

    FreeRTOS V8.2.1 - Copyright (C) 2015 Real Time Engineers Ltd.
    All rights reserved


    This file is part of the FreeRTOS distribution.

    FreeRTOS is free software; you can redistribute it and/or modify it under
    the terms of the GNU General Public License (version 2) as published by the
    Free Software Foundation >>!AND MODIFIED BY!<< the FreeRTOS exception.

    >>!   NOTE: The modification to the GPL is included to allow you to     !<<
    >>!   distribute a combined work that includes FreeRTOS without being   !<<
    >>!   obliged to provide the source code for proprietary components     !<<
    >>!   outside of the FreeRTOS kernel.                                   !<<

    FreeRTOS is distributed in the hope that it will be useful, but WITHOUT ANY
    WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
    FOR A PARTICULAR PURPOSE.  Full license text is available on the following

    1 tab == 4 spaces!

     *                                                                       *
     *    Having a problem?  Start by reading the FAQ "My application does   *
     *    not run, what could be wrong?".  Have you defined configASSERT()?  *
     *                                                                       *
     *                               *
     *                                                                       *

     *                                                                       *
     *    FreeRTOS provides completely free yet professionally developed,    *
     *    robust, strictly quality controlled, supported, and cross          *
     *    platform software that is more than just the market leader, it     *
     *    is the industry's de facto standard.                               *
     *                                                                       *
     *    Help yourself get started quickly while simultaneously helping     *
     *    to support the FreeRTOS project by purchasing a FreeRTOS           *
     *    tutorial book, reference manual, or both:                          *
     *                              *
     *                                                                       *

     *                                                                       *
     *   Investing in training allows your team to be as productive as       *
     *   possible as early as possible, lowering your overall development    *
     *   cost, and enabling you to bring a more robust product to market     *
     *   earlier than would otherwise be possible.  Richard Barry is both    *
     *   the architect and key author of FreeRTOS, and so also the world's   *
     *   leading authority on what is the world's most popular real time     *
     *   kernel for deeply embedded MCU designs.  Obtaining your training    *
     *   from Richard ensures your team will gain directly from his in-depth *
     *   product knowledge and years of usage experience.  Contact Real Time *
     *   Engineers Ltd to enquire about the FreeRTOS Masterclass, presented  *
     *   by Richard Barry:
     *                                                                       *

     *                                                                       *
     *    You are receiving this top quality software for free.  Please play *
     *    fair and reciprocate by reporting any suspected issues and         *
     *    participating in the community forum:                              *
     *                                    *
     *                                                                       *
     *    Thank you!                                                         *
     *                                                                       *
    *************************************************************************** - Documentation, books, training, latest versions,
    license and Real Time Engineers Ltd. contact details. - A selection of FreeRTOS ecosystem products,
    including FreeRTOS+Trace - an indispensable productivity tool, a DOS
    compatible FAT file system, and our tiny thread aware UDP/IP stack. - Where new FreeRTOS products go to incubate.
    Come and try FreeRTOS+TCP, our new open source TCP/IP stack for FreeRTOS. - Real Time Engineers ltd license FreeRTOS to High
    Integrity Systems ltd. to sell under the OpenRTOS brand.  Low cost OpenRTOS
    licenses offer ticketed support, indemnification and commercial middleware. - High Integrity Systems also provide a safety
    engineered and independently SIL3 certified version for use in safety and
    mission critical applications that require provable dependability.

    1 tab == 4 spaces!

/* FreeRTOS includes. */
#include "FreeRTOS.h"
#include "task.h"
#include "queue.h"
#include "timers.h"
/* Xilinx includes. */
#include <stdio.h>
#include "platform.h"
#include "xil_printf.h"
#include "xgpiops.h"
#include "sleep.h"


#define TIMER_ID	1
#define DELAY_10_SECONDS	10000UL
#define DELAY_1_SECOND		1000UL
#define DELAY_100_MSECOND   100UL

XGpioPs Gpio;	/* The driver instance for GPIO Device. */
unsigned int PsLedVal = 0 ;
unsigned long IdleCount = 0UL ;

/* The Tx and Rx tasks as described at the top of this file. */

static void prvPsLedTask( void *pvParameters );
static QueueHandle_t xQueue = NULL;
void PsGpioSetup() ;

/* The queue used by the Tx and Rx tasks, as described at the top of this
file. */

char HWstring[15] = "Hello World";

int main( void )

	xil_printf( "Hello from Freertos example main\r\n" );
	PsGpioSetup() ;

	xTaskCreate( prvPsLedTask,
				( const char * ) "Ps Led",
				tskIDLE_PRIORITY + 1,

	/* Create the queue used by the tasks.  The Rx task has a higher priority
	than the Tx task, so will preempt the Tx task and remove values from the
	queue as soon as the Tx task writes to the queue - therefore the queue can
	never have more than one item in it. */
	xQueue = xQueueCreate( 	1,						/* There is only one space in the queue. */
							sizeof( HWstring ) );	/* Each space in the queue is large enough to hold a uint32_t. */

	/* Check the queue was created. */
	configASSERT( xQueue );

	/* Start the tasks and timer running. */

	/* If all is well, the scheduler will now be running, and the following line
	will never be reached.  If the following line does execute, then there was
	insufficient FreeRTOS heap memory available for the idle and/or timer tasks
	to be created.  See the memory management section on the FreeRTOS web site
	for more details. */
	for( ;; );

void PsGpioSetup()
	int Status ;
	XGpioPs_Config *GpioCfg ;

	GpioCfg = XGpioPs_LookupConfig(GPIO_DEVICE_ID) ;
	Status = XGpioPs_CfgInitialize(&Gpio, GpioCfg, GpioCfg->BaseAddr) ;
	if (Status != XST_SUCCESS)
		xil_printf("PS GPIO Configuration failed!\r\n") ;
	XGpioPs_SetDirectionPin(&Gpio, 40, 1);
	XGpioPs_SetOutputEnablePin(&Gpio, 40, 1);

static void prvPsLedTask( void *pvParameters )
    //const TickType_t x1second = pdMS_TO_TICKS( DELAY_100_MSECOND );

	for( ;; )
		XGpioPs_WritePin(&Gpio, 40, PsLedVal);
		PsLedVal = ~PsLedVal ;

		/* Delay for 100 millisecond. */
		//vTaskDelay( x1second );

Which FreeRTOS version and port are you using? Can you share the assert at those lines? Are these the following 2 asserts:

If yes, comments in the source file right above the assert tell you how to fix those. For the first one, you need to find out which interrupt is firing and set its priority to lower than (numerically higher) configMAX_SYSCALL_INTERRUPT_PRIORITY. An for the second one, you need to program ICCBPR register correctly.

vitis 2022.
freertos version : freertos10_xilinx_v1_12
port.c, line 658 :

#if defined(GICv2)

※ fully
if( ( ( *( ( const volatile uint32_t * ) ( ( 0xF9010000U + 0x10000 ) + ( 0x14 ) ) ) ) == ( uint32_t ) ( ( ( ( ( uint32_t ) 32 ) - 1UL ) - 1UL ) << 3 ) ) == 0 ) vApplicationAssert( "/home/park/peta_ws/design_1_wrapper/psu_cortexa53_3/freertos10_xilinx_psu_cortexa53_3/bsp/psu_cortexa53_3/libsrc/freertos10_xilinx_v1_12/src/port.c", 658)

port.c, line 609 :

	/* This is not the interrupt safe version of the enter critical function so
	assert() if it is being called from an interrupt context.  Only API
	functions that end in "FromISR" can be used in an interrupt.  Only assert if
	the critical nesting count is 1 to protect against recursive calls if the
	assert function also uses a critical section. */
	if( ullCriticalNesting == 1ULL )
		configASSERT( ullPortInterruptNesting == 0 );

The first one seems to indicate that you are calling FreeRTOS API from an ISR which is running at higher priority than configMAX_SYSCALL_INTERRUPT_PRIORITY.

The second one seems that you are calling enter critical function from an ISR.

It seems that there are some issues when running Linux and FreeRTOS concurrently. Are there any ways to resolve these problems?

I have not done that so cannot say why that is happening. But does running Linux on other cores interferes in any manner with R5 core?

R5 has been confirmed to work properly in the user space of Linux. A53 seems to be a bit different.

Can you describe your setup - which core is running Linux and which core is running FreeRTOS?

A53 core is running Linux, and R5 is running FreeRTOS.

In the previous test, there were four A53 cores, with three running Linux and the remaining one running FreeRTOS.

if( ( ( *( ( const volatile uint32_t * ) ( ( 0xF9010000U + 0x10000 ) + ( 0x14 ) ) ) ) == ( uint32_t ) ( ( ( ( ( uint32_t ) 32 ) - 1UL ) - 1UL ) << 3 ) ) == 0 ) vApplicationAssert( "/home/park/peta_ws/design_1_wrapper/psu_cortexa53_3/freertos10_xilinx_psu_cortexa53_3/bsp/psu_cortexa53_3/libsrc/freertos10_xilinx_v1_12/src/port.c", 658 ) 

I would like to check if changing the priority value here can solve the problem.