UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer pstootman
Observer
12,819 Views
Registered: ‎03-29-2015

SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution

Hi,

Using SDK 2015.4, we can run OpenAMP echo test demo successfully per UG1186 (linux PS0, FreeRTOS OS1).

We generate FreeRTOS BSP for PS1 in SDK, then generate the echo test template application in SDK, build/run, all good.

What we can't figure out is why when we change some kernel behaviour settings in the BSP FreeRTOS options page, the AMP communications stops working.

Specifically if we change minimal_stack_size from 200 (default) to 4096 (desired), the AMP communications fails.

Or, if we change total_heap_size from 65536 (default) to 16777216 (desired), the AMP communication fails.

Note we have made no changes to the echo test application project whatsoever... all source files and linker script is 'as generated by the new application template'.. we are just changing the settings of the referenced BSP.

[we are working towards our own freeRTOS app on PS1 which will require a heap much larger than the default 65536].

 

1) Working BSP settings (the defaults);

 

case1.png

 

working means this output on linux side when echo test app started;

 

CPU1: shutdown
 remoteproc0: 0.remoteproc is available
 remoteproc0: Note: remoteproc is still under development and considered experimental.
 remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
 remoteproc0: registered virtio0 (type 7)
 remoteproc0: powering up 0.remoteproc
 remoteproc0: Booting fw image echo_test_v1.elf, size 562626
 remoteproc0: remote processor 0.remoteproc is now up
virtio_rpmsg_bus virtio0: rpmsg host is online
virtio_rpmsg_bus virtio0: creating channel rpmsg-openamp-demo-channel addr 0x1
Jan  1 00:02:58 tcu400r2 user.notice kernel: CPU1: shutdown
Jan  1 00:02:58 tcu400r2 user.info kernel:  remoteproc0: 0.remoteproc is available
Jan  1 00:02:58 tcu400r2 user.info kernel:  remoteproc0: Note: remoteproc is still under development and considered experimental.
Jan  1 00:02:58 tcu400r2 user.info kernel:  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
Jan  1 00:02:58 tcu400r2 user.info kernel:  remoteproc0: registered virtio0 (type 7)
Jan  1 00:02:58 tcu400r2 user.info kernel:  remoteproc0: powering up 0.remoteproc
Jan  1 00:02:58 tcu400r2 user.info kernel:  remoteproc0: Booting fw image echo_test_v1.elf, size 562626
Jan  1 00:02:58 tcu400r2 user.info kernel:  remoteproc0: remote processor 0.remoteproc is now up
Jan  1 00:02:58 tcu400r2 user.info kernel: virtio_rpmsg_bus virtio0: rpmsg host is online
Jan  1 00:02:58 tcu400r2 user.debug kernel: rpmsg_virtio RX: 00 00 00 00 35 00 00 00 00 00 00 00 28 00 00 00  ....5.......(...
Jan  1 00:02:58 tcu400r2 user.debug kernel: rpmsg_virtio RX: 72 70 6d 73 67 2d 6f 70 65 6e 61 6d 70 2d 64 65  rpmsg-openamp-de
Jan  1 00:02:58 tcu400r2 user.debug kernel: rpmsg_virtio RX: 6d 6f 2d 63 68 61 6e 6e 65 6c 00 00 00 00 00 00  mo-channel......
Jan  1 00:02:58 tcu400r2 user.debug kernel: rpmsg_virtio RX: 01 00 00 00 00 00 00 00                          ........
Jan  1 00:02:58 tcu400r2 user.debug kernel: NS announcement: 72 70 6d 73 67 2d 6f 70 65 6e 61 6d 70 2d 64 65  rpmsg-openamp-de
Jan  1 00:02:58 tcu400r2 user.debug kernel: NS announcement: 6d 6f 2d 63 68 61 6e 6e 65 6c 00 00 00 00 00 00  mo-channel......
Jan  1 00:02:58 tcu400r2 user.debug kernel: NS announcement: 01 00 00 00 00 00 00 00                          ........
Jan  1 00:02:58 tcu400r2 user.info kernel: virtio_rpmsg_bus virtio0: creating channel rpmsg-openamp-demo-channel addr 0x1

 

2) Change BSP minimal stack size from 200 to 4096 causes AMP to fail.

 

case2.png

 

Now AMP no longer works.

 

CPU1: shutdown
 remoteproc0: 0.remoteproc is available
 remoteproc0: Note: remoteproc is still under development and considered experimental.
 remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
 remoteproc0: registered virtio0 (type 7)
 remoteproc0: powering up 0.remoteproc
 remoteproc0: Booting fw image echo_test_v1.elf, size 562626
 remoteproc0: remote processor 0.remoteproc is now up
virtio_rpmsg_bus virtio0: rpmsg host is online
Jan  1 00:24:25 tcu400r2 user.notice kernel: CPU1: shutdown
Jan  1 00:24:25 tcu400r2 user.info kernel:  remoteproc0: 0.remoteproc is available
Jan  1 00:24:25 tcu400r2 user.info kernel:  remoteproc0: Note: remoteproc is still under development and considered experimental.
Jan  1 00:24:25 tcu400r2 user.info kernel:  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
Jan  1 00:24:25 tcu400r2 user.info kernel:  remoteproc0: registered virtio0 (type 7)
Jan  1 00:24:25 tcu400r2 user.info kernel:  remoteproc0: powering up 0.remoteproc
Jan  1 00:24:25 tcu400r2 user.info kernel:  remoteproc0: Booting fw image echo_test_v1.elf, size 562626
Jan  1 00:24:25 tcu400r2 user.info kernel:  remoteproc0: remote processor 0.remoteproc is now up
Jan  1 00:24:25 tcu400r2 user.info kernel: virtio_rpmsg_bus virtio0: rpmsg host is online

[no channel setup messages follow]

 

3) Or, change total_heap_size to 16777216

 

case3.png

 

Now AMP no longer works.

 

CPU1: shutdown
 remoteproc0: 0.remoteproc is available
 remoteproc0: Note: remoteproc is still under development and considered experimental.
 remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
 remoteproc0: registered virtio0 (type 7)
 remoteproc0: powering up 0.remoteproc
 remoteproc0: Booting fw image echo_test_v1.elf, size 562630
Jan  1 00:30:42 tcu400r2 user.notice kernel: CPU1: shutdown
Jan  1 00:30:42 tcu400r2 user.info kernel:  remoteproc0: 0.remoteproc is available
Jan  1 00:30:42 tcu400r2 user.info kernel:  remoteproc0: Note: remoteproc is still under development and considered experimental.
Jan  1 00:30:42 tcu400r2 user.info kernel:  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
Jan  1 00:30:42 tcu400r2 user.info kernel:  remoteproc0: registered virtio0 (type 7)
Jan  1 00:30:42 tcu400r2 user.info kernel:  remoteproc0: powering up 0.remoteproc
Jan  1 00:30:42 tcu400r2 user.info kernel:  remoteproc0: Booting fw image echo_test_v1.elf, size 562630
 remoteproc0: remote processor 0.remoteproc is now up
virtio_rpmsg_bus virtio0: rpmsg host is online
Jan  1 00:30:44 tcu400r2 user.info kernel:  remoteproc0: remote processor 0.remoteproc is now up
Jan  1 00:30:44 tcu400r2 user.info kernel: virtio_rpmsg_bus virtio0: rpmsg host is online

[no channel setup messages follow]

 

Basic question; do we need to change something in the linker script file for these desired FreeRTOS BSP changes to work nicely with openamp ? or change something in the build settings of the application project ?

a) changing minimal_stack_size in the FreeRTOS source code appears to affect nothing except the stack size of the idle task... so why does increasing this affect openAMP behaviour ?

b) changing total_heap_size just changes size of ucHeap[] array in heap_4 and FreeRTOS should be using this custom heap implementation for all of the task stacks. This array is near bottom of DDR; this is from .map file;

 .bss           0x001202f8    0x10018 ../../MDB02_bsp_xf823_amp_PS1/ps7_cortexa9_1/lib\libfreertos.a(heap_4.o)

and I believe vring buffers are up much higher in DDR (at address 0x08000000); so why does increasing size of heap like this affect openAMP behaviour ?

 

Many thanks!

 

0 Kudos
1 Solution

Accepted Solutions
Explorer
Explorer
23,421 Views
Registered: ‎02-22-2012

Re: SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution

I can give you an update to FreeRTOS and OpenAMP echo_test. I was courouse about your problem with FreeRTOS and echo_test example. Since the BM echo_test (I used in my tests) and FreeRTOS example share the same echo_test source (separated by #ifdef USE_FREERTOS) I was able to quickly switch to FreeRTOS echo_test example.

The default version runs OK, NS announcemet message comes from remote to master and exchange of echo messages runs sucessfully.

Then I chnaged the stack and heap size as you wrote and I got the same problem as you desribe, no NS message (announcement) send.

 

The good news is that I was able to make FreeRTOS echo_test successfuly run by sending SGI KICK via irq kernel attribute (echo '?' > /sys/devices/soc0/amba/0.remoteproc/remoteproc0/irq). With this bigger stack and heap the FreeRTOS echo_test example startup takes longer to execute and it misses the first LX SGI KICK.

I changed in FreeRTOSConfig.h:

#define configMINIMAL_STACK_SIZE ( ( unsigned short ) 4096)
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 16777216 ) )

and in lscript.ld:

_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x8000;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x1500000;

I am convinced that you will also make your FreeRTOS example run by using the same SGI KICK workarond as I did.

8 Replies
Explorer
Explorer
12,736 Views
Registered: ‎02-22-2012

Re: SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution

I tested echo_test OpenAMP example on 7Z010 and one problem I need to solve was that my BM remote application was slower in its startup and it missed LX master startup KICK SGI. I used BM example without FreeRTOS, but they are very similar (same code, #ifdef-ined).

As this BM example is written it requires an SGI KICK from LX master to send NS message. The insmod (or modprobe sequence) from LX will trigger one(!) SGI to BM remote. If BM remote captures this first SGI KICK it will send NS mesasage. This NS message received in LX master will then trigger all probing chain in LX which ends in /dev/rpmsg0 create. Now if this first SGI KICK is missed, then there is no play.

0 Kudos
Observer pstootman
Observer
12,640 Views
Registered: ‎03-29-2015

Re: SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution

Many thanks. Sounds possible, we will follow up.

Grateful for some advice on what is the actual method (compatible with 2015.4 petalinux distribution ideally) to get linux/PS0 side to wait longer for freertos/PS1 side to start up and be ready to receive this initial interrupt.

Is it done by changing some petalinux configuration or some kernel code on the linux side ?

Or is it done by putting something in the resource table which linux side uses (reads out of the .elf) to know how long to wait (after booting PS1) before giving the startup interrupt to PS1 ?

Thanks.

 

0 Kudos
Explorer
Explorer
12,527 Views
Registered: ‎02-22-2012

Re: SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution

I wrote in this forum message how I workaround my problem. My problem was that after some modifications of BM startup, I did not got "NS announcement" message . Not necessary is this the same problem you have, but I think it is worth to try. Just a few changes are needed: in BM you deliberately delay startup (e.g. loop or other delay) and in LX zynq_remoteproc driver add kernel attribute to fire SGI some later time.

0 Kudos
Explorer
Explorer
23,422 Views
Registered: ‎02-22-2012

Re: SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution

I can give you an update to FreeRTOS and OpenAMP echo_test. I was courouse about your problem with FreeRTOS and echo_test example. Since the BM echo_test (I used in my tests) and FreeRTOS example share the same echo_test source (separated by #ifdef USE_FREERTOS) I was able to quickly switch to FreeRTOS echo_test example.

The default version runs OK, NS announcemet message comes from remote to master and exchange of echo messages runs sucessfully.

Then I chnaged the stack and heap size as you wrote and I got the same problem as you desribe, no NS message (announcement) send.

 

The good news is that I was able to make FreeRTOS echo_test successfuly run by sending SGI KICK via irq kernel attribute (echo '?' > /sys/devices/soc0/amba/0.remoteproc/remoteproc0/irq). With this bigger stack and heap the FreeRTOS echo_test example startup takes longer to execute and it misses the first LX SGI KICK.

I changed in FreeRTOSConfig.h:

#define configMINIMAL_STACK_SIZE ( ( unsigned short ) 4096)
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 16777216 ) )

and in lscript.ld:

_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x8000;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x1500000;

I am convinced that you will also make your FreeRTOS example run by using the same SGI KICK workarond as I did.

Observer pstootman
Observer
12,189 Views
Registered: ‎03-29-2015

Re: SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution

Many thanks indeed!!! Great.

 

Our linux engineer has followed your advice to get the echo-test example working with modified FreeRTOS memory settings.

 

0 Kudos
Visitor prasanna_mn
Visitor
8,496 Views
Registered: ‎11-10-2016

Re: SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution

Hi All, I am trying to run both CPU0 (PetaLinux) & CPU! (FreeRtos) followed UG978 , 2016.2, and Chapter 3 of the UG1186.

Also tried steps given in the following blogs

http://blog.idv-tech.com/2014/02/26/zedboard-linux-freertos-amp-board-bringup-guide/

http://henryomd.blogspot.in/2015/02/zynq-amp-linux-on-cpu0-and-bare-metal.html

Not able to successfully load the cpu1(FreeRTOS).

I am able to create a linux project and debug using TCF agent. I searched blogs, community forum & requested even xilinx also, but no reply.

I am stuck in the basic sytem up & running on both the cores.

Please can you share any document or the procedure that you followed for booting both the cores will be a great help.

 

Thanks & Best Regards, 

Prasanna

0 Kudos
Visitor agent147
Visitor
5,206 Views
Registered: ‎08-18-2017

Re: SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution
0 Kudos
Visitor agent147
Visitor
5,190 Views
Registered: ‎08-18-2017

Re: SDK 2015.4 Changing FreeRTOS BSP stack/heap settings breaks AMP channel setup

Jump to solution
can you please post the screen shots of how you gave SGI KICK echo '?' > /sys/devices/soc0/amba/0.remoteproc/remoteproc0/irq?!!
0 Kudos