How to debug M4 firmware based on "st_image_core" using the EV1 board?

[Machilus]

hello all

​

i have a STM32MP157C-EV1, and I want to build an m4 core development and debugging environment in minimal "st-image-core".

​

M4 firmware created using "STM32CudeIDE" can be debugged in "st-image-weston", but an error occurs in "st-image-core".

​

​What items should be added to "st-image-core.bb" to work normally?

error message :

[ 100.552483] remoteproc remoteproc0: powering up m4

[ 100.555897] remoteproc remoteproc0: Direct firmware load for OpenAMP_TTY_echo_CM4.elf failed with error -2

[ 100.571270] remoteproc remoteproc0: request_firmware failed: -2

[ 100.575829] remoteproc remoteproc0: Boot failed: -2

I will wait for your reply.

​

​

​

[Olivier GALLIEN]

Hi @Machilus​ ,

By comparing with st-image-weston.bb, I guess adding "eclipe-debug" in IMAGE_FEATURES looks to be good candidate.

I will ask for confirmation from expert.

Does your traces come from a Debug session from STM32CubeIDE or a manual start of firmware from Linux ?

Olivier

[Machilus]

Hi ​ @OlivierG (ST Employee)

Thank you for your reply.

​

Tracking is a kernel message when executing a debug session of "STM32CubeIDE".

​

Adding "eclipse-debug" to "st-image-core.bb" has not solved the problem.

​

IMAGE_FEATURES += "\

  package-management \

  ssh-server-dropbear \

  eclipse-debug    \

  "

[Machilus]

^^:

[Olivier GALLIEN]

Hi @Machilus​ 

Your initial trace show an error due to fact that firmware is missing in /lib/firmware

STM32CubeIDE is using ethernet connection to copy the .elf to the target.

Ethernet service may likely miss in st-image-core ( check on going at my end)

Did you noticed something wrong during download of .elf with STM32CubeIDE ?

Could you try manual copy and start of firmware on target using this

https://wiki.st.com/stm32mpu/wiki/Linux_remoteproc_framework_overview#Remote_processor_boot_through_sysfs)

Thanks for feedback

Olivier

[Machilus]

Hi ​ @OlivierG (ST Employee)

​

No download problems using "STM32CubeIDE".

When manually running firmware in the manner OlivierG suggested,

the following problems occurred.

​

<< Execution Message >>

root@stm32mp1-fiscal:/lib# echo start >/sys/class/remoteproc/remoteproc0/state

[ 1090.457191] remoteproc remoteproc0: powering up m4

[ 1090.460584] remoteproc remoteproc0: loading /lib/firmware/updates/4.19.94/FISCAL_CM4.elf failed with error -20

[ 1090.474820] remoteproc remoteproc0: loading /lib/firmware/updates/FISCAL_CM4.elf failed with error -20

[ 1090.484713] remoteproc remoteproc0: loading /lib/firmware/4.19.94/FISCAL_CM4.elf failed with error -20

[ 1090.494670] remoteproc remoteproc0: loading /lib/firmware/FISCAL_CM4.elf failed with error -20

[ 1090.503785] remoteproc remoteproc0: Direct firmware load for FISCAL_CM4.elf failed with error -20

[ 1090.511210] remoteproc remoteproc0: request_firmware failed: -20

[ 1090.520436] remoteproc remoteproc0: Boot failed: -20

​

​

<<Below is a message from OpenOCD using ST-LINK.>>

​

Open On-Chip Debugger 0.10.0+dev-01193-g5ce997d (2020-02-20-10:54)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

cortex_a interrupt mask on

cortex_a interrupt mask on

cortex_a domain access control fixup on

cortex_a domain access control fixup on

none separate

adapter speed: 8000 kHz

adapter_nsrst_assert_width: 200

adapter_nsrst_delay: 200

none srst_pulls_trst

srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : STLINK V3J6M2B4S1 (API v3) VID:PID 0483:374F

Info : using stlink api v3

Info : Target voltage: 3.238171

Info : clock speed 8000 kHz

Info : SRST line released

Info : stlink_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : STM32MP151CAAx.cpu0: hardware has 6 breakpoints, 4 watchpoints

Error: Could not find MEM-AP to control the core

Info : Listening on port 3334 for gdb connections

Info : Listening on port 3333 for gdb connections

ap 0 selected, csw 0x10006000

Info : accepting 'gdb' connection on tcp/3333

Error: Target not examined yet

​

​

Info : New GDB Connection: 1, Target STM32MP157CAAx.cpu2, state: unknown

undefined debug reason 7 - target needs reset

Error: Target not examined yet

Error: Target not examined yet

Error: Target not examined yet

Error: Target not examined yet

​

Thank you for your interest in this problem.

[Olivier GALLIEN]

​Hi @Machilus​ 

I noticed very strange/abnormal traces in your OpenOCD log :

Info : STLINK V3J6M2B4S1 (API v3) VID:PID 0483:374F

Info : STM32MP151CAAx.cpu0: hardware has 6 breakpoints, 4 watchpoints

Definitly not matching an EV1 board !?

Can you clarify your setup ?

For which target did you compile the .elf ?

For manual start of firmware can you confirm the firmware is well present in /lib/firmware ?

Thanks

Olivier

[Machilus]

Hi ​ @OlivierG (ST Employee)

​

Sorry.​

I sent the wrong message.

It was a message from a custom board made from a "STM32MP151C" chip based on the "STM32MP157C-EV1" board.

Recently, I debugging "OpenAMP_TTY_echo" firmware from created a "st-image-core" distribution on the "EV1" Board.

​It worked without error.

​

However, running the M4 firmware on the custom board based on "STM32MP151C" resulted in an error.

​This error does not occur in the "st-image-weston" distribution,

Error occurs only in "st-image-core" distribution.

<<Below is a message from OpenOCD using ST-LINK V3SET>>

Open On-Chip Debugger 0.10.0+dev-01193-g5ce997d (2020-02-20-10:54)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

cortex_a interrupt mask on

cortex_a interrupt mask on

cortex_a domain access control fixup on

cortex_a domain access control fixup on

none separate

adapter speed: 8000 kHz

adapter_nsrst_assert_width: 200

adapter_nsrst_delay: 200

none srst_pulls_trst

srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : STLINK V3J6M2B4S1 (API v3) VID:PID 0483:374F

Info : using stlink api v3

Info : Target voltage: 3.234990

Info : clock speed 8000 kHz

Info : SRST line released

Info : stlink_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : STM32MP151CAAx.cpu0: hardware has 6 breakpoints, 4 watchpoints

Error: Could not find MEM-AP to control the core

Info : Listening on port 3334 for gdb connections

Info : Listening on port 3333 for gdb connections

ap 0 selected, csw 0x10006000

Info : accepting 'gdb' connection on tcp/3333

Error: Target not examined yet

Info : New GDB Connection: 1, Target STM32MP151CAAx.cpu2, state: unknown

undefined debug reason 7 - target needs reset

Error: Target not examined yet

Error: Target not examined yet

Error: Target not examined yet

Error: Target not examined yet

<< Execution Message >>

root@stm32mp1-fiscal:~# echo start > /sys/class/remoteproc/remoteproc0/state

[ 489.401238] remoteproc remoteproc0: powering up m4

[ 489.404634] remoteproc remoteproc0: loading /lib/firmware/updates/4.19.94/OpenAMP_TTY_echo_CM4.elf failed with error -20

[ 489.418946] remoteproc remoteproc0: loading /lib/firmware/updates/OpenAMP_TTY_echo_CM4.elf failed with error -20

[ 489.429594] remoteproc remoteproc0: loading /lib/firmware/4.19.94/OpenAMP_TTY_echo_CM4.elf failed with error -20

[ 489.440258] remoteproc remoteproc0: loading /lib/firmware/OpenAMP_TTY_echo_CM4.elf failed with error -20

[ 489.450382] remoteproc remoteproc0: Direct firmware load for OpenAMP_TTY_echo_CM4.elf failed with error -20

[ 489.460633] remoteproc remoteproc0: request_firmware failed: -20

[ 489.467095] remoteproc remoteproc0: Boot failed: -20

Regards

machilus

[Olivier GALLIEN]

Hi @Machilus​ 

I can not figure out why remote proc browse so many folders ?

What is the structure of the /lib/firmware on your target ?

Where /lib/firmware/updates/4.19.94/ come from ?

Where is the OpenAMP_TTY_echo_CM4.elf exactly before you start the firmware ?

If I got it right it's working with "st-image-weston". Can you share the succeeded trace of firmware start ?

Any difference in /lib/firmware folder structure ?

Hope it help,

Olivier

[Machilus]

Hi ​ @OlivierG (ST Employee)

​

I solved this problem.

In "st-image-core", "/lib/firmware" is a file.

In "st-image-weston", "/lib/firmware" is a directory.

In "st-image-core," I solved the problem by making "/lib/firmware" a directory.

Naturally, firmware exists within the "/lib/firmware" directory.

​

Thank you for helping me solve the problem.

​

Best regards.

Machilus.

[Olivier GALLIEN]

Hi @Machilus​ 

Good news but anyway still strange behavior.

If you confirm that this "/lib/firmware" is a file issue only happen on custom board and not on EV1, we can suspect the Yocto adaptation you have made to build "st-image-core" for your custom board.

Can you detail further what you have done ?

Thanks

Olivier

[Machilus]

Hi ​ @OlivierG (ST Employee)

​

Yes .

This is a phenomenon that only happens on custom board.

I distributed "st-image-core.bb" and dts on custom boards as follows.

​

​

<< st-image-core.bb >>

SUMMARY = "OpenSTLinux core image."

LICENSE = "Proprietary"

​

include recipes-st/images/st-image.inc

​

inherit core-image

​

IMAGE_LINGUAS = "en-us"

​

IMAGE_FEATURES += "\

  package-management \

  ssh-server-dropbear \

  eclipse-debug    \

  "

​

#

# INSTALL addons

#

CORE_IMAGE_EXTRA_INSTALL += " \

  packagegroup-framework-core-base  \

  packagegroup-framework-tools-base  \

  \

  ${@bb.utils.contains('COMBINED_FEATURES', 'optee', 'packagegroup-optee-core', '', d)}  \

  ${@bb.utils.contains('COMBINED_FEATURES', 'optee', 'packagegroup-optee-test', '', d)}  \

  ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd-networkd-configuration', '', d)}  \

  "

​

<< Allocate virtual device memory from "dts" >>

​

reserved-memory {

#address-cells = <1>;

#size-cells = <1>;

ranges;

​

retram: retram@0x38000000 {

compatible = "shared-dma-pool";

reg = <0x38000000 0x10000>;

no-map;

};

​

mcuram: mcuram@0x30000000 {

compatible = "shared-dma-pool";

reg = <0x30000000 0x40000>;

no-map;

};

​

mcuram2: mcuram2@0x10000000 {

compatible = "shared-dma-pool";

reg = <0x10000000 0x40000>;

no-map;

};

​

vdev0vring0: vdev0vring0@10040000 {

compatible = "shared-dma-pool";

reg = <0x10040000 0x2000>;

no-map;

};

​

vdev0vring1: vdev0vring1@10042000 {

compatible = "shared-dma-pool";

reg = <0x10042000 0x2000>;

no-map;

};

​

vdev0buffer: vdev0buffer@10044000 {

compatible = "shared-dma-pool";

reg = <0x10044000 0x4000>;

no-map;

};

};

&m4_rproc {

memory-region = <&retram>, <&mcuram>, <&mcuram2>, <&vdev0vring0>,

<&vdev0vring1>, <&vdev0buffer>;

mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;

mbox-names = "vq0", "vq1", "shutdown";

interrupt-parent = <&exti>;

interrupts = <68 1>;

interrupt-names = "wdg";

wakeup-source;

recovery;

status = "okay";

};

​

After booting up this created distribution,

Error occurs when "OpenAMP_TTY_echo" is built and executed.

This is an error caused by being made into a "/lib/firmware" file.

If you change to a directory, the error disappears.

This is all I did.

​

Regards.

Machilus.