FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

OpenAMP u-boot startup

Go to solution
JMein.1
Associate III

‎2021-08-27 03:27 AM

After reading most of the topics concerning my question and not finding an answer, which solves our problem, here my describtion:

We are currently integrating OpenAMP in our Application. For now, we are using the configuration from the OpenAMP_TTY_echo example project with enabled trace logs, and a single virtual UART between the M4 and the A7.

When starting the Application by using 'rproc start' in a booted linux system, it works as expected. The trace logs are available, and the /dev/ttyRPMSG0 virtual UART is loaded:

  • cat /sys/class/remoteproc/remoteproc0/state outputs 'running'
  • cat /sys/kernel/debug/remoteproc/remoteproc0/trace0 shows our debug outputs from the M4

We can send dummy data to /dev/ttyRPMSG0 and get the echoed response

In our use case we need the M4 Application to start as early as possible, so we have configured u-boot SSBL to load the ELF file and start the M4 execution. We are then facing the problem that the software is started, but the linux kernel does not load the /dev/ttyRPMSG0 device:

  • cat /sys/class/remoteproc/remoteproc0/state outputs 'running'
  • /sys/kernel/debug/remoteproc/remoteproc0/trace0 is not loaded
  • cat /sys/kernel/debug/remoteproc/remoteproc0/resource_table is empty
  • /dev/ttyRPMSG0 is not loaded

We checked the following points:

When attaching to the running M4 execution after the startup sequence has completed we see that the function rproc_virtio_wait_remote_ready(vdev) does not return. It seems that linux rproc does not load the resource table.

The resource_table is present in the ELF file (checked with readelf)

u-boot rproc does load the correct address of the resource table into the TAMPER backup register

During our investigations we found out that the issue seems to be M4 code + ram size dependent. When the code size exceeds ~130KB (Code + RAM where Code is placed in MCU SRAM 1) we can reproduce the problem.

Below that size the M4 Application is started correctly from u-boot and under Linux the trace is available and the RPMSG device is created.

We tried to output verbose log messages for the related kernel modules (stm32_rproc and remoteproc*) during boot and added the dyndbg parameter to the u-boot kernel command line (dyndbg="file ec.c +p") but we only got kernel panic errors when trying to boot with this parameter. Dynamic debugging is enabled in the kernel configuration. How can we switch on to get this additional debug infos?

Any ideas or suggestions from your side to solve this issue would be greatly appreciated. 

Best regards,

Jan-Otto

Labels:
10 REPLIES 10
Go to solution
ArnaudP
Senior

‎2021-09-17 03:18 AM

hello @JMein.1​ 

Regarding the startup_stm32mp15xx.s, I think you are right, a memset is done to initialize the .bss.

So the check on the .bss and ._user_heap_stack is probably useless . And the LMA area in the m_text memory is not used.

So only protection on the resource table should be sufficient.

Please, could you confirm this in your link error usecase ?

In addition to have a cleaner mapping, you could declare the add "AT (ADDR (.bss)) to the . bss as follow to make the LMA address equal to the VMA in the m_data memory section.

 .bss : AT (ADDR (.bss))
 {
...
}

Best regards,

Arnaud

0 Kudos
Top