We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
At the minute: 56.38 (according to the attached screen) he says to make modifications to the kernel (in my case it’s 5.6.17) using kconfig to show some *.c files (which currently, as I’ve already verified, don’t exist yet )
You are using Mainline Linux, that driver referenced in your video does not “exist” on Mainline Linux. NXP/Freescale has not pushed it Mainline, thus it only exists on NXP/Freescale’s Linux tree.
So you need to use NXP/Freescale’s 4.9-1.0.x-imx branch to utilze that driver.
Can I use this (generic rpmsg subsystem) to my project?
My project is use rpmsg and/or rpmsg-lite to send messages from a7(linux) to m4(zephyr) via u-boot (stty -f option) and (if possible) later send messages after full linux boot
No, while this is the generic subsystem, you still need a driver for the specific hardware implementation imx7 (a7 and m4) that utilzes this subsystem. In the case of 4.9-1.0.x-imx NXP/Freescale wrote this driver (imx_rpmsg.c and imx_rpmsg_tty.c), but have not pushed it mainline…
I have the sources for U-boot 2020.04 here and I have already removed several things related to 0x7F8000, 0x720000, 0x780000 and I can never get the *.bin to 0X7F8000 (only 0X808000. I need to know what is blocking it at 0X7F8000
issue: Reading file would overwrite reserved memory. Failed to load 'hello_world.bin
@RobertCNelson in this issue in technexion repo, Paolo Turim it is me. That company blocked me on github since the day I found out that USB-C (3.0 or 3.1) can burn imx7d-pico components. They are no longer responding to me. Much less about imx7d-pico and much less about RPMsg on that device
Hi @neuberfran i can’t take sides… That’s between you and them…
Looking at the docs, they used NXP’s u-boot fork in their project. NXP’s u-boot was forked from mainline a long time ago… You need to use their u-boot source to make it work…
There “hello_world.bin” demo uses a feature that is not in mainline u-boot… You need to contact the developer and find out what branch of NXP’s version of u-boot they used when creating that demo…
@RobertCNelson No Sir. I can run fatload mmc 0:1 0x80800 hello_world.bin. But I can’t run fatload mmc 0:1 0x7F8000 hello_world.bin. As Mr @sawdust said in the question, I need to use LMB (Debug) before the line log_err("** Reading the file would overwrite the reserved memory **\n"); in order to find out what is using 0x7F8000 memory
Hi @neuberfran looking at the document posted by that user…
The following table lists some NXP SoCs that can be used in the AMP configuration and the software support for Cortex-M loading
from a side in U-Boot and Linux starting with NXP Linux BSP versions ≥ L5.10.35_2.0.0.
In this link I can’t see imx7d. That would be the reason for my issue. Because I already did the build with the latest version of u-boot-tn-imx (2021.04/by TechNexion) and the command fatload mmc 0:1 0x7F8000 hello_world.bin didn’t work?
That specific “git” commit “3463140881c523e248d2fcb6bfc9ed25c0db93bd” happens to be modifying arch/arm/dts/fsl-imx8qm.dtsi… That does NOT matter… behind that specific git commit is a branch, imx_v2021.04, that NXP created to support “L5.10.35_2.0.0.” That is the exact u-boot tree, you NEED to be running on your board to utilize NXP’s appnote…
