According to the steps described in S32R45_LinuxBSP_33.0_User_Manual.pdf, I finally generated a fsl-image-auto-s32r45evb.sdcard file. I use the dd command to write it to the SD card. Then I plug it into the S32R45EVB card slot. I set S32R45EVB to start from SD card. After Linux is started, when I execute insmod ipc-shm-sample.ko as described in SW32R45_IPCF_4.3.0_D2203_UserManual.pdf, an error occurs, as shown in the following figure:
I modified the ipc-shm.bb file in two places, as follows:
1. Change the value of BRANCH to release/bsp33.0;
2. Change the value of SRCREV to d80b27e5fc6c3d6a9d53de6ae23fa84a17560fd3(commit id)。
I want to know the reason and solution of this error.
Thank you very much.
解決済! 解決策の投稿を見る。
Yeah, that is because the kernel reports have an associated log level that defines the importance of the message. The kernel.printk defines which buffer message are printed in the console.
To change this value you can use the command dmesg -n 7
It uses "1" from the beginning because these log messages can cause misfunctions in other projects.
Let me know if this worked for you.
Hi @amei_liu,
Could you please try rebuilding those .ko files? The problem may be these were not added correctly to the Linux image.
You can have information of how to do this in the SW32R45_IPCF_4.3.0_D2203_UserManual.pdf, (Section 6.1/Page 18-19)
Best regards,
Urik
Before you rebuild the .ko files, change the ipc-os.c and the ipc-uio.c files that are in the folder: ipc-shm/os/
You need change the parameter "fsl,s32cc-mscm" to "nxp,s32cc-mscm" in both files.
Best regards,
Urik
According to your method:
First, I modified the ipc-os. c and the ipc-uio. c files as follows;
Then I rebuild those. ko files according to SW32R45_IPCF_4.3.0_D2203_UserManual.pdf (Section 6.1/Page 18-19). I copied those *. ko files to the SD card and executed the insmod command on the S32R45EVB, and then reported an error: insmod: ERROR: could not insert module ipc-shm-dev.ko: Invalid module format
There are 2 compilers in my ubuntu: one is aarch64-linux-gnu-gcc, the other is gcc-arm-10.2-2020.11-x86_ 64-aarch64-none-linux-gnu。 I rebuild those *.ko whith aarch64-linux-gnu-gcc according to the following steps:
See the attachment for detailed compilation log.
To solve the above problem, I modified the utsrelease. h file in the linux/include/generated directory. Change the value of UTS_RELEASE to "5.10.109-rt65+g0bace7fde5f5".
Then I rebuilt those. ko files.
I copy these files to the SD card and insert them into the slot of the S32R45EVB. When Linux starts up, i execute the insmod ipc-shm-sample.ko command, the shell prints the following information, and then Linux crashes.
Instead of changing the utsrelease.h file, to insert the .ko files with the correct format, you can insert those .ko files into a partition of the SD:
I inserted directly the .ko files and the Linux image that I compiled ("image") changing the name of the original to "image2".
Then I load the files from the partition:
First of all, thank you very much for your response。
According to your method, I rebuild the Image and *. ko files and copied them to SD for testing. When executing the insmod ipc-shm-sample.ko command, the following error occurred and my Linux crashed:
For the image and. ko file rebuild process, see the attachment rebuild.txt。
For the execution process of insmod,see the annex insmod.txt。
Before boot the Linux image, zero set the SRAM shared memory:
-dcache off
-mw.q 0x34000000 0x0 0x100000
If this doesn't work, another suggestion is to use the BSP35 version:
NXP.COM:
-binaries_auto_linux_bsp35.0_s32r45.tgz
NXP REPOSITORIES:
-linux repository : remotes/github/release/bsp35.0-5.10.145-rt
-ipc-shm repository: remotes/Github/release/bsp35.0
In this version there is no need to change the ipc-os.c nor the ipc--uio.c files.
Also use the s32cc_defconfig instead of s32gen1_defconfig.
For the CROSS_COMPILE try with the aarch64-none-linux-gnu-
For the PLATFORM_FLAVOR try with s32g2
Let me know if you have any issue.
Hi, what is an SRAM with an address starting at 0x34000000 and a length equal to 0x100000 bytes used for?
HI @amei_liu,
Could you please open this question in the forum, as a new one, to have a better control of the cases?
Thank you
ok.
Before boot the Linux image, zero set the SRAM shared memory:
-dcache off
-mw.q 0x34000000 0x0 0x100000
Execute insmod ipc-dev-sample.ko and no error will be reported.
After that, I did the test as described in 6.5.4 of SW32R45_IPCF_4.3.0_D2203_UserManual.pdf, but after executing "echo 10>/sys/kernel/ipc-shm-sample-instance/ping", I did not see any print information and did not receive the data sent by M7.
The BSP version I use is 35.
Ipc-shm-dev.ko and ipc-shm-sample.ko come with BSP35, not recompiled by me。
See attachment for test log。
Yeah, that is because the kernel reports have an associated log level that defines the importance of the message. The kernel.printk defines which buffer message are printed in the console.
To change this value you can use the command dmesg -n 7
It uses "1" from the beginning because these log messages can cause misfunctions in other projects.
Let me know if this worked for you.
This problem has been solved.
Now the ipcf sample can run correctly.
Thank you very much for your help.
Hello,
Could you please share name of your company? I need it to be able ask RADAR team.
Best regards,
Peter