@Edward
Now my issue is:
U-Boot 2018.03-ce1e3c9d29948853203c8a5805e93908daa8fa2a+gce1e3c9d29 (Mar 12 2022 - 23:49:26 +0000)
.
.
.
MU is ready for cross core communication!
No vring buffer.
imx-rpmsg: probe of 30800000.aips-bus:rpmsg failed with error -12
imx rpmsg driver is registered.
MU is ready for cross core communication!
vgaarb: loaded
Note: At an earlier time (described above) I had, and still have, similar issues. But using U-boot 2021 and Yocto Hardknott
Note 2: In u-boot 2018 and Yocto Sumo I can run llinux on A7 (0x8080000) and FreeRtos bin file on m4 (0x7F800000. But in userspace I run modprobe imx_rpmsg_tty and nothing happens on the m4 console. The word hello_world appears only when loading u-boot 2018.
Note 3: in u-boot 2021 and Hardknott I can run m4 and a7 only in 0x80800000
Your previously mentioned crash could be due to missing reserver vrings memory. If that memory isn’t reserved and M4 tries to write there - bad things may happen.
No vring buffer - perhaps rpmsg in dts doesn’t specify vring buffers memory. You dts should include something like this, as well buffer addresses should match vring buffer settings in M4 FW
@Edward tks.I have progress. But I still can’t see hello_world when I do modprobe imx_rpmsg_tty (or pingpong) and neither can /dev/ttyRPMSG
MU is ready for cross core communication!
platform 30800000.aips-bus: coherent DMA mask is unset
virtio_rpmsg_bus virtio0: rpmsg host is online
imx rpmsg driver is registered.
MU is ready for cross core communication!
pico-imx7 login: root
root@pico-imx7:~# dmesg | grep rpmsg
virtio_rpmsg_bus virtio0: rpmsg host is online imx rpmsg driver is registered.
The question is now in the output of the above command ( dmesg | grep rpmsg). Since in the link below, the result is showing something (virtio_rpmsg_bus virtio0: creating channel rpmsg-virtual-tty-channel-1 addr 0x1e) that does not appear for me. You know why?
But now, I have virtio0 device:
root@pico-imx7:/sys/bus/virtio/drivers/virtio_rpmsg_bus/virtio0# ls
device features power subsystem vendor
driver modalias status uevent
root@pico-imx7:/sys/bus/virtio/drivers/virtio_rpmsg_bus/virtio0# pwd
/sys/bus/virtio/drivers/virtio_rpmsg_bus/virtio0
root@pico-imx7:/sys/bus/virtio/devices/virtio0# pwd
/sys/bus/virtio/devices/virtio0
@Edward
There is still a issue. You may notice that the words described below are legibly while loading rpmsg_str_echo_freertos_example.bin in U-boot. When I do echo hello > /dev/ttyRPMSG0
(before ls /dev/tty* result=/dev/ttyRPMSG0) I get=���类�&a����}���w������v�
I guess after Linux loads, your M4 UART clock gets reconfigured by Linux to much lower value. Sometimes it is not enough to have UART removed from device tree. Other peripherals may using the same clock source and Linux is free to reconfigure shared clock. Try determining baudrate (when you echo hello) using oscilloscope. I guess hello is sent properly at that new baudrate.
Absolutely no problem to load M4 ELF file at 80800000, launch it with bootaux, then reuse 80800000 to load kernel or dtb. Bootaux extracts ELF segments and puts them to destination addresses, not necessarily 80800000… Please try making your own efforts to debug your issue.
I didn’t suggest you to change baudrate using stty. Please read again my replies. I suggested that when Linux loads, it changes your M4 UART clock, which leads to sending further UART messages at different baud rate than you initially set M4 UART for. Please try making your own efforts to debug your issue.
Not boot linux on A7 if I use 0x80800000 in m4 (fatload mmc 0:1 0x8080000 hello_world.bin)
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0(part 0) is current device
Failed to load ‘uEnv.txt’
Failed to load ‘boot.scr’
Failed to load ‘tnrescue.itb’
8463480 bytes read in 190 ms (42.5 MiB/s)
Booting from mmc …
10572 bytes read in 2 ms (5 MiB/s)
No elf image at address 0x80800000
Starting auxiliary core stack = 0x20008000, pc = 0x1FFF8311…
baseboard is pi
59480 bytes read in 3 ms (18.9 MiB/s)