Issue with NXP S32G274A RDB2 - IPCF

[Harshalshinde]

Hello,  

We have bellow issue with IPCF(Single instance) between A core and M core. 

For A core we are using BSP 37.0  

For M core IPCF sample application from NXP S32DS. 

• S32Ds version is 3.5 Build id: 230629 (Update 3)  
• IPCF version is SW32G_IPCF_4.9.0_D2310_updatesite 
• RTD version is SW32G_RTD_4.4_4.0.1_DS_updatesite_D2302.  

Error we are facing in A core is:  

[   52.844377] ipc-shm-sample: starting demo... 

[   52.844398] ipc-shm-sample: ch 0 >> 20 bytes: SENDING MESSAGES: 10 

[   52.844410] ipc-shm-sample: send_data_msg(): failed to get buffer for channel ID 1 and size 32 

Following are the configuration in linker file. 

Note: We also tried with default configuration that comes with sample application same result observed.  

* Derivative: S32G254A, S32G274A 

* 0x34000000 0x34800000 8192KB Internal SRAM 

* Derivative: S32R45 

* 0x34000000 0x34800000 8192KB Internal SRAM 

* 

* 0x43000000    0x43FFFFFF  16384KB LLCE Address Space (16M) 

* Please note that current demo linker target only for S32G233A, in order to maximum benefit of ram usage, please modify linker and MPU default setting in system.c 

*/ 

HEAP_SIZE  = DEFINED(__heap_size__)  ? __heap_size__  : 0x00003000; 

ENTRY(Reset_Handler) 

MEMORY 

{ 

    int_itcm                : ORIGIN = 0x00000000, LENGTH = 0x00000000 /* 0KB - Not Supported */ 

    int_dtcm                : ORIGIN = 0x20000000, LENGTH = 0x0000E000 /* 64K */ 

    int_dtcm_stack          : ORIGIN = 0x2000E000, LENGTH = 0x00002000 /* 8K */ 

    int_sram_shareable      : ORIGIN = 0x22C00000, LENGTH = 0x00004000 /* 16KB */ 

    IPCFsharedRAM (RW)      : ORIGIN = 0x34000000, LENGTH = 0x00300000 /* 3MB */ 

    int_sram                : ORIGIN = 0x34300000, LENGTH = 0x00200000 /* 2MB */ 

    int_sram_no_cacheable   : ORIGIN = 0x34500000, LENGTH = 0x00100000 /* 1MB, needs to include int_results  */ 

    ram_rsvd2               : ORIGIN = 0x34800000, LENGTH = 0          /* End of SRAM */ 

    LLCE_CAN_SHAREDMEMORY   : ORIGIN = 0x43800000 LENGTH = 0x3C800 

    LLCE_LIN_SHAREDMEMORY   : ORIGIN = 0x4383C800 LENGTH = 0xa0 

    LLCE_BOOT_END           : ORIGIN = 0x4383C8A0 LENGTH = 0x50 

    LLCE_MEAS_SHAREDMEMORY  : ORIGIN = 0x4384FFDF LENGTH = 0x20 

} 

Following are the IPCF configuration and interrupt configuration seen in the S32DS 

/* ipc shm configuration */ 

struct ipc_shm_cfg ipcf_shm_cfg_instances[1] = { 

{ 

.local_shm_addr  = 0x34200000, 

.remote_shm_addr = 0x34100000, 

.shm_size  = 0x100000, 

.inter_core_tx_irq = INT1_IRQn, 

.inter_core_rx_irq = INT2_IRQn, 

.local_core = { 

.type = IPC_CORE_M7, 

.index = IPC_CORE_INDEX_0, 

}, 

.remote_core = { 

.type = IPC_CORE_A53, 

.index = IPC_CORE_INDEX_0, 

}, 

.num_channels = 3, 

.channels = ipcf_shm_cfg_channels0, 

}, 

}; 

struct ipc_shm_instances_cfg ipcf_shm_instances_cfg = { 

.num_instances = 1u, 

.shm_cfg = ipcf_shm_cfg_instances, 

}; 

Interrupt configured 

static const IntCtrl_Ip_IrqConfigType aIrqConfiguration[] = { 

    {Pcie_1_MSI_IRQn, (boolean)FALSE, 0U}, 

    {INT0_IRQn, (boolean)FALSE, 0U}, 

    {INT1_IRQn, (boolean)FALSE, 0U}, 

    {INT2_IRQn, (boolean)TRUE, 1U}, 

… 

const IntCtrl_Ip_CtrlConfigType intCtrlConfig = { 

    183U, 

    aIrqConfiguration 

}; 

/* List of configurations for routing interrupts */ 

static const IntCtrl_Ip_IrqRouteConfigType aIrqRouteConfig[] = { 

    {Pcie_1_MSI_IRQn, 14U, undefined_handler}, 

    {INT0_IRQn, 14U, undefined_handler}, 

    {INT1_IRQn, 14U, undefined_handler}, 

    {INT2_IRQn, 14U, ipc_shm_hardirq}, 

Steps that we executed from description.txt 

1. Copy the stripped binary (IPCF_Example_S32G274A_M7_0.bin) to a FAT partition 

      on a SD-card 

1. Establish a serial connection with the S32G274A board and power it on 
2. Hit any key to stop in the u-boot console 
3. Disable Data Cache from uboot:: 

            dcache off 

1. Zero-set SRAM shared memory used by both sample apps:: 

            mw.q 0x34100000 0x0 0x40000 

1. Load binary in DDRAM and after is SRAM:: 

            fatload mmc 0:1 0x80000000 IPCF_Example_S32G274A_M7_0.bin 

            cp.b 0x80000000 0x34300000 0x300000 

Note: instead of running above two commands we ran below command ( directly loading into SRAM ). because we are facing kernel panic when the kernel boots  

fatload mmc 0:3 0x34300000 IPCF_Example_S32G274A_M7_0.bin 

1. Start M7 core (the argument is the address of the Interrupt Vector):: 

            startm7 0x34500400 

1. Boot Linux :: 

            boot 

Can you please help us what went wrong? 

As per the research done on other community answers. We found that they could succeed with bootloader in place and loading A core and M core from bootloader.  

Is it not possible to run without bootloader? 

Many Thanks,

Harshal. 

[Ramjee]

Hi Daniel/Team,

Thanks for your continued support!

We are able to establish communication b/w A-core and M-core using IPCF4.9 and BSP 38.0, as suggested by Daniel.

Thanks again for guiding on this issue.

Moreover, I seek another guidance on one of use case.

I need to read shared memory data written by M-core using Docker container application running on A-core.

Requesting to suggest me ways to do so.

Another doubt I am having is "How to create DEVICE interface" in application code in order to write it by application and same written data could be read by driver .ko file.

For example,
/dev/ttyPA1 in below code.

int fd = open("/dev/ttyPA1", O_RDWR | O_NONBLOCK);

[Daniel-Aguirre]

Hi,

Good to know that you were able to run the application. 

On regards of Docker, we understand that all available information under S32G is provided under Chapter 24.2 Docker Containers, under BSP38.0 User Manual.

As for the last request, we don't see much information from the available documentation from our side. We do apologize. We see that under a different community (not managed by NXP) there is some information:

How are "/dev" Linux files created? - Unix & Linux Stack Exchange

Since this seems to be more related to Linux than to S32G itself, might be better looking into the different Linux communities. Again, we apologize for the inconvenience.

Please, let us know.

[Daniel-Aguirre]

Hi,

We are looking into the IPCF 4.9.0 release notes and see the following information:

Where both RTD and BSP versions are different from the ones you are using. Can you help us verify if using the required versions for both RTD and BSP provides the expected outcome? We do apologize for the inconvenience.

Please, let us know.

[Ramjee]

Hi Daniel,

 As per your suggestion, I updated following OS versions:
     RTD_4.4_4.0.2_D2306
     NXP Linux BSP37.0[ As on github page not able to find 38.0 version.]

But still we are not able to get expected output messages on A core as mentioned in "Description.txt"
Below are messages just for references.

[ timestamp ] ipc-shm-sample: ipc-shm-sample: starting demo...
[ timestamp ] ipc-shm-sample: ipc-shm-sample: ch 0 >> 20 bytes: SENDING MESSAGES: 10
[ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #0 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #0 HELLO WORLD! from CORE 4
[ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #1 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #1 HELLO WORLD! from CORE 4
[ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #2 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #2 HELLO WORLD! from CORE 4
[ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #3 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #3 HELLO WORLD! from CORE 4
[ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #4 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #4 HELLO WORLD! from CORE 4
[ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #5 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #5 HELLO WORLD! from CORE 4
[ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #6 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #6 HELLO WORLD! from CORE 4
[ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #7 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #7 HELLO WORLD! from CORE 4
[ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #8 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #8 HELLO WORLD! from CORE 4
[ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #9 HELLO WORLD! from KERNEL
[ timestamp ] ipc-shm-sample: ch 0 << 20 bytes: REPLIED MESSAGES: 10
[ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #9 HELLO WORLD! from CORE 4

I am pasting the output logs and steps we followed.

NOTICE:  Reset status: Power-On Reset

NOTICE:  BL2: v2.5(release):bsp38.0_rc9-2.5

NOTICE:  BL2: Built : 17:13:42, Sep 15 2023

NOTICE:  BL2: Booting BL31

U-Boot 2020.04+g57741dd80e (Sep 15 2023 - 15:06:56 +0000)

SoC:   NXP S32G274A rev. 2.0

CPU:   ARM Cortex-A53 r0p4 @ max 1000 MHz

Model: NXP S32G274A-RDB2

DRAM:  3.5 GiB

MMC:   FSL_SDHC: 0

Loading Environment from MMC... OK

Configuring PCIe0 as RootComplex

PCIe0: Failed to get link up

PCI: Failed autoconfig bar 20

PCI: Failed autoconfig bar 24

In:    serial@401c8000

Out:   serial@401c8000

Err:   serial@401c8000

Board revision: RDB2/GLDBOX Revision D

Net:   EQOS phy: rgmii @ 1

Warning: eth_eqos (eth0) using random MAC address - ee:f7:32:6e:55:ff

eth0: eth_eqos PFE: emac0: sgmii emac1: none emac2: rgmii

Warning: eth_pfeng using MAC address from ROM

, eth1: eth_pfeng

Hit any key to stop autoboot:  0

=>

=>

=> dcache off

=> mw.q 0x34100000 0x0 0x40000

=> fatload mmc 0:1 0x80000000 IPCF_Example_S32G274A_M7_0.bin

=> startm7 0x34500400

Starting CM7_0 core at SRAM address 0x34500400 ... done.

=> boot

 PFE: emac0: sgmii emac1: none emac2: rgmii

 PFE: emac0: sgmii emac1: none emac2: rgmii

switch to partitions #0, OK

mmc0 is current device

14344200 bytes read in 650 ms (21 MiB/s)

Booting from mmc ...

52128 bytes read in 26 ms (1.9 MiB/s)

## Flattened Device Tree blob at 83000000

   Booting using the fdt blob at 0x83000000

   Using Device Tree in place at 0000000083000000, end 000000008300fb9f

   fixup: pfe0 set to 00:01:be:be:ef:11

   fixup: pfe1 set to 00:01:be:be:ef:22

   fixup: pfe2 set to 00:01:be:be:ef:33

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

[    0.000000] Linux version 5.15.119-rt65+ge18f05316cd9 (oe-user@oe-host) (aarch64-fsl-linux-gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.38.20220708) #1 SMP PREEMPT Fri Sep 15 16:46:03 UTC 2023

[    0.000000] Machine model: NXP S32G274A-RDB2

[    0.000000] earlycon: linflex0 at MMIO 0x00000000401c8000 (options '115200n8')

[    0.000000] printk: bootconsole [linflex0] enabled

[    0.000000] Reserved memory: created DMA memory pool at 0x0000000083200000, size 3 MiB

[    0.000000] OF: reserved mem: initialized node pfebufs@83200000, compatible id shared-dma-pool

<snip...>

[  OK  ] Started Xinetd A Powerful Replacement For Inetd.

[  OK  ] Finished Permit User Sessions.

[  OK  ] Started Getty on tty1.

[  OK  ] Started Serial Getty on ttyLF0.

[  OK  ] Reached target Login Prompts.

[  OK  ] Reached target Multi-User System.

         Starting Record Runlevel Change in UTMP...

[  OK  ] Finished Record Runlevel Change in UTMP.

Auto Linux BSP 38.0 s32g274ardb2 ttyLF0

s32g274ardb2 login:

root@s32g274ardb2:~# insmod /lib/modules/`uname -r`/extra/ipc-shm-dev.ko

root@s32g274ardb2:~# insmod /lib/modules/`uname -r`/extra/ipc-shm-sample.ko

root@s32g274ardb2:~# echo 10 > /sys/kernel/ipc-shm-sample/ping

We are not receiving the desired output after running the above command up to login. Would you kindly advise us on how to get the desired results?

we are expecting below output:

[ timestamp ] ipc-shm-sample: ipc-shm-sample: starting demo...

            [ timestamp ] ipc-shm-sample: ipc-shm-sample: ch 0 >> 20 bytes: SENDING MESSAGES: 10

            [ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #0 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #0 HELLO WORLD! from CORE 4

            [ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #1 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #1 HELLO WORLD! from CORE 4

            [ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #2 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #2 HELLO WORLD! from CORE 4

            [ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #3 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #3 HELLO WORLD! from CORE 4

            [ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #4 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #4 HELLO WORLD! from CORE 4

            [ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #5 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #5 HELLO WORLD! from CORE 4

            [ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #6 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #6 HELLO WORLD! from CORE 4

            [ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #7 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #7 HELLO WORLD! from CORE 4

            [ timestamp ] ipc-shm-sample: ch 1 >> 32 bytes: #8 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 1 << 32 bytes: #8 HELLO WORLD! from CORE 4

            [ timestamp ] ipc-shm-sample: ch 2 >> 32 bytes: #9 HELLO WORLD! from KERNEL

            [ timestamp ] ipc-shm-sample: ch 0 << 20 bytes: REPLIED MESSAGES: 10

            [ timestamp ] ipc-shm-sample: ch 2 << 32 bytes: #9 HELLO WORLD! from CORE 4

Another issue we're having is figuring out how to confirm whether or not the interrupt is being called from shared memory on the M core side.
or If the interrupt will only reach M core once communication with A core's interrupt has been established.

We have been battling this problem for a long time and are need your assistance as soon as feasible.

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

We assume by the following:

"s32g274ardb2 login:

root@s32g274ardb2:~# insmod /lib/modules/`uname -r`/extra/ipc-shm-dev.ko

root@s32g274ardb2:~# insmod /lib/modules/`uname -r`/extra/ipc-shm-sample.ko

root@s32g274ardb2:~# echo 10 > /sys/kernel/ipc-shm-sample/ping

We are not receiving the desired output after running the above command up to login. Would you kindly advise us on how to get the desired results?"

That you are expecting that after the "echo" command, you should be able to see the IPCF log. If so, help us input the following command after executing the echo command:

dmesg | grep ipc-shm

With this, you should be able to see the log of both cores communicating with each other.

As for the following question:

"Another issue we're having is figuring out how to confirm whether or not the interrupt is being called from shared memory on the M core side.
or If the interrupt will only reach M core once communication with A core's interrupt has been established."

We may not understand correctly this question. The interrupt for M7 core is the one available under the S32G2 as Core-to-Core MSI [Page 291, S32G2 Reference Manual, Rev. 7, February 2023] which is treated as an IRQ, which should be attended once it triggers.

Please, let us know.

[Ramjee]

Dear Daniel,

Executed commands suggested by you "dmesg | grep ipc-shm" and got below output.

[ 8233.699328] ipc-shm-sample: starting demo...
[ 8233.699351] ipc-shm-sample: ch 0 >> 20 bytes: SENDING MESSAGES: 10
[ 8233.699364] ipc-shm-sample: send_data_msg(): failed to get buffer for channel ID 1 and size 32

root@s32g274ardb2:~# dmesg | grep ipc-shm
[ 8233.699328] ipc-shm-sample: starting demo...
[ 8233.699351] ipc-shm-sample: ch 0 >> 20 bytes: SENDING MESSAGES: 10
[ 8233.699364] ipc-shm-sample: send_data_msg(): failed to get buffer for channel ID 1 and size 32
root@s32g274ardb2:~#

Debugged further and found that issue is occurred as "ipc_shm_acquire_buf()" not able to allocate correct buffer address and returning buf value as NULL. 
[Below code snippet is from A core BSP's,  sample.c]

static int send_data_msg(const uint8_t instance, int msg_len, int msg_no,

int chan_id)

{

int err = 0;

char *buf = NULL;

buf = ipc_shm_acquire_buf(instance, chan_id, msg_len);

if (!buf) {

sample_err("failed to get buffer for channel ID"

" %d and size %d\n", chan_id, msg_len);

return -ENOMEM;

}

Requesting to suggest me exact reason for NOT able to allocate correct buf address for shared memory.
Or are we missing some setting?

[Daniel-Aguirre]

Hi,

Thanks for your feedback. We understand that you are using BSP37.0, is this correct? If so, we understand that IPCF v4.9.0 is not compatible with BSP37.0 (as previously shown).

Still, once you are able to locate BSP38.0, the default version under BSP38.0 is v4.8.0. If you would like to use IPCF 4.9.0, you need to update the IPCF version under BSP38.0 to v4.9.0. The following was provided by the internal team:

"Please confirm that the IPCF version in BSP38 is IPCF4.9.0. Because the default IPCF version in BSP38 is 4.8.0. I have tested the configuration as customer configured for the demo, and it works."

We can also recommend using IPCF v4.8.0 or v4.6.0.

Please, let us know.

[Ramjee]

Dear Daniel, 

We are using BSP38 and IPCF4.9.0.

Still we are getting the same error on A core.

root@s32g274ardb2:~# dmesg | grep ipc-shm
[ 8233.699328] ipc-shm-sample: starting demo...
[ 8233.699351] ipc-shm-sample: ch 0 >> 20 bytes: SENDING MESSAGES: 10
[ 8233.699364] ipc-shm-sample: send_data_msg(): failed to get buffer for channel ID 1 and size 32

Please suggest us, how to resolve error and establish communication between A core and M core.

Another doubt I am having,  is "fsl-image-auto-s32g274ardb2.sdcard" file contain 

kernel image (linux/arch/arm64/boot/Image) and 

dtb image (linux/arch/arm64/boot/dts/freescale/s32g274a-rdb2.dtb) , both?

Thanks for your support.!

Regards,

Ramjee Yadav

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

We do understand that you are using BSP38.0, but the default IPCF version under BSP38.0 is IPCF v4.8.0, for which we understand that you are using the following scenario:

BSP38.0 (with IPCF v4.8.0) + IPCF v4.9.0

Which is causing problems. If you wish to use IPCF 4.9.0, you need to also update the BSP38.0 IPCF version to v4.9.0, hence the following comment from the internal team:

"Please confirm that the IPCF version in BSP38 is IPCF4.9.0. Because the default IPCF version in BSP38 is 4.8.0."

Help us understand if you can follow the example with IPCF v4.8.0, for us to confirm that BSP38.0 default IPCF version is indeed IPCF v4.8.0.

As for the additional question, the *.sdcard should contain both Image and DTB as shown below:

Please, let us know.

[Ramjee]

Dear Daniel,

Thanks for your support!

Could you please provide the step/procedure how to remove default IPCF v4.8.0 from BSP38.0 and update IPCF v4.9.0?

Or If possible, could you please provide the BSP38.0 with IPCF v4.9.0 on NXP site so that we can download it from there and verify it?

Another query I am having, Which version of BSP will run Docker Engine integrated with Yocto Linux on NXP hardware?
Because We tried with BSP37.0, Docker Engine is not running and BSP38.0 is not available on github. So not able to decide which version should we select?

Regards,

Ramjee Yadav

[Daniel-Aguirre]

Hi,

We don't see any specific information on how to remove the current IPCF version, but as for building it, we see the following information:

Where the clone should be changed to the following repo:

https://github.com/nxp-auto-linux

We have done the following steps to build IPCF v4.9.0 under BSP38.0:

• [Under the same folder as linux BSP38.0 folder was created]
• git clone https://github.com/nxp-auto-linux/ipc-shm
• cd ipc-shm/
• git checkout release/SW32G_IPCF_4.9.0_D2310
• cd ..
• [link to where your toolchain is located] export CROSS_COMPILE=$HOME/../arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-
• cd linux
• make ARCH=arm64 s32cc_defconfig
• make ARCH=arm64 -j8
• cd ..
• make -C ./ipc-shm/sample KERNELDIR=$PWD/linux modules PLATFORM_FLAVOR=s32g2
• Copy "ipc-shm/ipc-shm-dev.ko" and "ipc-shm/sample/ipc-shm-sample.ko" to the "boot" partition of the BSP38.0 SD card image.
• Copy "linux/arch/arm64/boot/Image" file the "boot" partition of the BSP38.0 SD card image (replace the Image file that was previously in there).

After this, start following the IPCF "description.txt" file instructions for v4.9.0:

1. Copy the stripped binary (IPCF_Example_S32G274A_M7_0.bin) to a FAT partition
on a SD-card
2. Establish a serial connection with the S32G274A board and power it on
3. Hit any key to stop in the u-boot console
4. Disable Data Cache from uboot::

dcache off

5. Zero-set SRAM shared memory used by both sample apps::

mw.q 0x34100000 0x0 0x40000

6. Load binary in DDRAM and after is SRAM::

fatload mmc 0:1 0x80000000 IPCF_Example_S32G274A_M7_0.bin
cp.b 0x80000000 0x34300000 0x300000

7. Start M7 core (the argument is the address of the Interrupt Vector)::

startm7 0x34500400

8. Boot Linux ::

boot

Then, execute the following commands under the user-space:

As for sharing files, we don't commonly share through the public community. Help us contacting your local NXP representative or opening a ticket under the NXP online services for this request. We do apologize.

As for the "BSP38.0 is not available on github" comment, we do see that there is a branch for BSP38.0, are you not able to locate it?

Please, let us know.

[Ramjee]

Dear Daniel,

Thanks for your support!

I followed the above steps suggested by you, and able to clone the required packages but while build I am facing following errors.

ramjeey@blrhondelite05:~/naviStar/linux$ make ARCH=arm64 s32cc_defconfig
scripts/Kconfig.include:39: compiler '/home/ramjeey/naviStar/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-linux-gnu-gcc' not found
make[1]: *** [scripts/kconfig/Makefile:94: s32cc_defconfig] Error 1
make: *** [Makefile:627: s32cc_defconfig] Error 2

Requesting for your recommendations on how to fix the above errors.

Requesting to provide the required document where the manual building steps are mentioned.

Another question I have is: Which BSP version will allow me to install Yocto Linux with Docker Engine integrated on NXP hardware?

[Daniel-Aguirre]

Hi,

We do apologize for the delay.

The error you are seeing is related to the compiler toolchain not being found under your specific path. Can you confirm the path "home/ramjeey/naviStar/gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu/bin/aarch64-linux-gnu-gcc" exists under your setup?

As for the questions: "Which BSP version will allow me to install Yocto Linux with Docker Engine integrated on NXP hardware?"

We don't see any information on regards of Docker support from our side. We do apologize. We can recommend contacting your local NXP FAE/DFAE, since they might have more information on this regard.

Please, let us know.