cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
7,697 Views
Registered: ‎11-05-2014

Linux and bare-metal AMP

Following this blog post: http://henryomd.blogspot.com/2015/02/zynq-amp-linux-on-cpu0-and-bare-metal.html, I got Linux running on CPU0 loading a bare-metal application on CPU1.  I get the error "BUG: using smp_processor_id() in preemptible [00000000] code" and a stack trace though. And the LED that my cpu1 app is suppose to toggle isn't doing so. Is this error one that will prevent cpu1 application from fully running?  How can I tell what cpu1 is doing?

 

[ 2.718247] udevd[572]: starting version 182
[ 2.845012] CPU1: shutdown
[ 2.848639] BUG: using smp_processor_id() in preemptible [00000000] code: udevd/575
[ 2.856266] caller is set_ipi_handler+0x14/0x58
[ 2.860727] CPU: 0 PID: 575 Comm: udevd Not tainted 3.14.2-xilinx #1
[ 2.867097] [<800147b4>] (unwind_backtrace) from [<800116cc>] (show_stack+0x10/0x14)
[ 2.874816] [<800116cc>] (show_stack) from [<8040e040>] (dump_stack+0x80/0xc0)
[ 2.882001] [<8040e040>] (dump_stack) from [<8020a584>] (debug_smp_processor_id+0xe8/0xec)
[ 2.890255] [<8020a584>] (debug_smp_processor_id) from [<80012f30>] (set_ipi_handler+0x14/0x58)
[ 2.898947] [<80012f30>] (set_ipi_handler) from [<7f014458>] (zynq_remoteproc_probe+0x1a8/0x460 [zynq_remoteproc])
[ 2.909275] [<7f014458>] (zynq_remoteproc_probe [zynq_remoteproc]) from [<80255de0>] (platform_drv_probe+0x18/0x4c)
[ 2.919683] [<80255de0>] (platform_drv_probe) from [<80254608>] (driver_probe_device+0x7c/0x21c)
[ 2.928444] [<80254608>] (driver_probe_device) from [<80254878>] (__driver_attach+0x8c/0x90)
[ 2.936874] [<80254878>] (__driver_attach) from [<80252c14>] (bus_for_each_dev+0x6c/0xa0)
[ 2.945025] [<80252c14>] (bus_for_each_dev) from [<80253e74>] (bus_add_driver+0x148/0x1f0)
[ 2.953257] [<80253e74>] (bus_add_driver) from [<80254e74>] (driver_register+0x78/0xf8)
[ 2.961257] [<80254e74>] (driver_register) from [<8000881c>] (do_one_initcall+0xf8/0x154)
[ 2.969415] [<8000881c>] (do_one_initcall) from [<8007c3ec>] (load_module+0x1978/0x1ee0)
[ 2.977492] [<8007c3ec>] (load_module) from [<8007caac>] (SyS_finit_module+0x68/0x78)
[ 2.985299] [<8007caac>] (SyS_finit_module) from [<8000e3e0>] (ret_fast_syscall+0x0/0x30)
[ 3.038436] remoteproc0: 100000.remoteproc-test is available
[ 3.044105] remoteproc0: Note: remoteproc is still under development and considered experimental.
[ 3.129696] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 3.253705] remoteproc0: firmware_loading_complete
[ 3.259125] remoteproc0: powering up 100000.remoteproc-test
[ 3.278338] remoteproc0: Booting fw image cpu1app.elf, size 66576
[ 3.314648] remoteproc0: remote processor 100000.remoteproc-test is now up 

 

0 Kudos
5 Replies
Highlighted
Adventurer
Adventurer
7,690 Views
Registered: ‎11-05-2014

Another thing I noticed was that in the remoteproc output, it says the elf image size is 66576. My compiled elf file size is something like 160K. I put the elf file in /lib/firmware in the rootfs and its size there is also 66576. Are the sizes suppose to differ? Is there compression or something else going on when the elf is placed into the rootfs image?  I create the rootfs image with Yocto and meta-xilinx.

0 Kudos
Highlighted
Observer
Observer
7,670 Views
Registered: ‎06-13-2014

Have a look at this thread. Make sure all of the fixes described in are done.  The amp demo out of the box, especially the on from the linux_user_repository.zip is broken.

 

http://forums.xilinx.com/t5/Embedded-Linux/Linux-FreeRTOS-AMP-demo-v2014-2/m-p/569806#M12249

 

From the dump I saw, you don't have the interrupt handler fix in port.c in freertos, and so the rpmsg driver initialization doesn't complete.

0 Kudos
Highlighted
Adventurer
Adventurer
7,664 Views
Registered: ‎11-05-2014

I'm not using FreeRTOS on CPU1, it's just a bare-metal app that toggles an LED.  

 

After further investigation, the source of the kernel error seems to be in these checks:

https://github.com/Xilinx/linux-xlnx/blob/xlnx_3.14/lib/smp_processor_id.c#L14

 

None of these checks cause an exit to a "good" state and it falls through to the kernel error.

0 Kudos
Highlighted
Adventurer
Adventurer
7,430 Views
Registered: ‎06-08-2015

I have exactly that same problem that you posted on 5-19-2015, ewong.

In components/apps/app_cpu1/data, app_cpu1(.elf) size is 169056 bytes, but in ./build/linux/rootfs/targetroot/lib/firmware and  in the targets’s /lib/firmware, it’s only 66480 bytes. There is no other file anywhere in my project with that same size (66480), I have no idea where the bogus copy comes from.

 

Following an instruction in ug978, I modified my Makefile as below:

 

include apps.common.mk

all: build install

build:

clean:

.PHONY: install image

FIRMWARE=app_cpu1 
install:
 $(TARGETINST) -d data/$(FIRMWARE) /lib/firmware/$(FIRMWARE)

 

I'm using Petalinux 2014.4.

0 Kudos
Highlighted
Adventurer
Adventurer
7,181 Views
Registered: ‎11-05-2014

I now believe that somewhere along the way, the debug information has been stripped from the elf file, so that's why it's smaller.

0 Kudos