03-27-2018 12:33 AM
Hi Eric,
same issue here. I am using the linux-xlnx 2017.4 version with remoteproc modules loaded at runtime (remoteproc and zynq_remoteproc).
When I first load the zynq_remoteproc I got the following msg
remoteproc remoteproc0: remoteproc@0 is available remoteproc remoteproc0: Note: remoteproc is still under development and considered experimental. remoteproc remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. remoteproc remoteproc0: Direct firmware load for rproc-remoteproc@0-fw failed with error -2 remoteproc remoteproc0: powering up remoteproc@0 remoteproc remoteproc0: Direct firmware load for rproc-remoteproc@0-fw failed with error -2
Then when I upload the new firmware (the OpenAMP echo-test example, compiled for CPU1 and with -DUSE_AMP=1)
sudo sh -c "echo test.elf > /sys/class/remoteproc/remoteproc0/firmware" sudo sh -c "echo start > /sys/class/remoteproc/remoteproc0/state"
I got the following message
remoteproc remoteproc0: powering up remoteproc@0 remoteproc remoteproc0: Direct firmware load for test.elf failed with error -2 remoteproc remoteproc0: request_firmware failed: -2 remoteproc remoteproc0: Boot failed: -2
Luca
04-06-2018 09:09 AM
Just replying to myself, I was missing the -DUSE_AMP=1 in the extra compiler flags (why the OpenAMP echo example does not consider it automatically?).
So far, the system is now running with the following dts (in case some other users might need it)
/{ amba { elf_ddr_0: ddr@3e000000 { compatible = "mmio-sram"; reg = <0x3e000000 0x00400000>; }; }; remoteproc0: remoteproc@0 { compatible = "xlnx,zynq_remoteproc"; firmware = "firmware"; vring0 = <15>; vring1 = <14>; srams = <&elf_ddr_0>; }; };
Still I do not understand why it does not work with 0x30000000 base address, but is not essential for the application. Now's time to play with OpenAMP ;).
Thank you @jovitac for your support...
Luca
03-27-2018 12:55 PM
Hi Luca,
Could you please attach your device-tree?
03-28-2018 12:13 AM
Hi @jovitac,
thank you for your answer.
Here the device tree entry for the remoteproc item
/ { reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; rproc_0_reserved: rproc@30000000 { no-map; reg = <0x30000000 0x10000000>; }; }; amba { elf_ddr_0: ddr@0 { compatible = "mmio-sram"; reg = <0x30000000 0x10000000>; }; }; remoteproc0: remoteproc@0 { compatible = "xlnx,zynq_remoteproc"; firmware = "firmware"; vring0 = <15>; vring1 = <14>; srams = <&elf_ddr_0>; }; };
I am using PicoZed board, with 1GB RAM. The remoteproc has exclusive access to 256MB DDR (0x30000000-0x40000000).
Thank you,
Luca
03-28-2018 08:09 AM
elf_ddr_0: ddr@0 { compatible = "mmio-sram"; reg = <0x30000000 0x10000000>; };
You have changed the elf_ddr address in the device-tree. This should also be reflected in your linker script for your rpu firmware application build in SDK.
Firmware memory needs to correspond to the firmware's linker script.
03-28-2018 08:15 AM
Hi @jovitac
if I understand correctly, elf_ddr_0 still refers to the DDR memory. If so, the linker script (of cpu1) have been previously modified as:
MEMORY { ps7_ddr_0_S_AXI_BASEADDR : ORIGIN = 0x30000000, LENGTH = 0x10000000 ps7_qspi_linear_0_S_AXI_BASEADDR : ORIGIN = 0xFC000000, LENGTH = 0x1000000 ps7_ram_0_S_AXI_BASEADDR : ORIGIN = 0x0, LENGTH = 0x30000 ps7_ram_1_S_AXI_BASEADDR : ORIGIN = 0xFFFF0000, LENGTH = 0xFE00 }
L
04-03-2018 09:40 AM
Hi all,
just an update. I moved to the 2017.4 version of Vivado and SDK. With the major updates done between versions (mine was the 2016.3), now something seems to be detected. Still I do not have any luck to launch the second CPU ...
remoteproc remoteproc0: powering up remoteproc@0 remoteproc remoteproc0: Booting fw image openamp.elf, size 2584592 virtio_rpmsg_bus virtio0: rpmsg host is online remoteproc remoteproc0: registered virtio0 (type 7) remoteproc remoteproc0: bad phdr da 0x30000000 mem 0x1b384 remoteproc remoteproc0: Failed to load program segments: -22 remoteproc remoteproc0: Boot failed: -22
Linker script and configuration is the same as above. This is the vanilla "OpenAmp echo test" template.
L
04-03-2018 02:43 PM
Hi Luca,
I did test this briefly. The address ranges you have provided do not work. There may be some additional changes you will need to make. Kernel booting should be moved to a higher address range.
Did you try with the values that are specified in the user guide? The default values work perfectly. Can you start with the address range that we have specified, and then proceed with the ranges you are interested in from there?
04-06-2018 08:54 AM
Hi @jovitac,
testing again with modified openamp address ranges (starting on 0x3e000000) as in the OpenAMP echo template. Something different now is different. Yet Linux kernel complains. Getting closer ;)
remoteproc remoteproc0: powering up remoteproc@0 remoteproc remoteproc0: Booting fw image openamp2.elf, size 2584748 remoteproc remoteproc0: registered virtio0 (type 7) remoStarting application... Try to init remoteproc resource teproc remoteproc0: remote processor remoteproc@0 is now up Unable to handle kernel NULL pointer dereference at virtual address 00000011 pgd = c0004000 [00000011] *pgd=00000000 Internal error: Oops - BUG: 5 [#1] PREEMPT SMP ARM Modules linked in: rpmsg_core zynq_remoteproc remoteproc virtio virtio_ring CPU: 0 PID: 647 Comm: mmcqd/1 Not tainted 4.9.0-xilinx-dirty #65 Hardware name: Xilinx Zynq Platform task: ed0ca100 task.stack: ec878000 PC is at schedule+0xa8/0xcc LR is at finish_task_switch+0xe4/0x190 pc : [<c0577244>] lr : [<c01365f4>] psr: 60000113 sp : ec879e50 ip : 00000000 fp : ec879e5c r10: ec805b00 r9 : ed338034 r8 : eedd09f8 r7 : 00000000 r6 : c0576f84 r5 : ec879e74 r4 : 0000000d r3 : 00000000 r2 : 00000001 r1 : 00000002 r0 : eedd09c0 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 18c5387d Table: 2b98404a DAC: 00000051 Process mmcqd/1 (pid: 647, stack limit = 0xec878210) Stack: (0xec879e50 to 0xec87a000) 9e40: ec805800 00000000 ec805afc c045123c 9e60: ed33810c 00000000 ed0ca100 c014b368 ec879e70 ec879e70 00000000 ec805b0c 9e80: ffffa0b4 00000000 0000000e 00000000 ffffffff 00000000 00000002 c0133358 9ea0: c092e3c8 00000002 ebbf0000 ffffffff 00000000 c0133464 00000000 00000002 9ec0: ec87b800 00000000 00000000 ec878000 00000000 c02d6f34 ec878000 ec805b0c 9ee0: 00000000 ed339800 ed33800c ed338000 ec805800 ed338000 00000000 c045f7c0 9f00: ec81f4d8 00000000 00000000 ec878000 00000000 ed33800c ffffe000 ed338014 9f20: ec81f4d8 00000000 00000000 ec878000 00000000 c045fbd0 ed33800c 00000000 9f40: 00000000 ec843040 00000000 ed33800c c045facc 00000000 00000000 00000000 9f60: 00000000 c01322a0 ec879f88 00000000 00000000 ed33800c 00000000 00000000 9f80: ec879f80 ec879f80 00000000 00000000 ec879f90 ec879f90 ec843040 ec843040 9fa0: c01321c8 00000000 00000000 c0106c18 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<c0577244>] (schedule) from [<c045123c>] (mmc_start_req+0xa0/0x37c) [<c045123c>] (mmc_start_req) from [<c0133358>] (notifier_call_chain+0x44/0x68) [<c0133358>] (notifier_call_chain) from [<c0133464>] (__atomic_notifier_call_chain+0x3c/0x48) [<c0133464>] (__atomic_notifier_call_chain) from [<c02d6f34>] (cfq_dispatch_requests+0x14c/0xa20) [<c02d6f34>] (cfq_dispatch_requests) from [<ed33800c>] (0xed33800c) Code: e2833001 e5843004 e3a00000 ebfffecb (e5943004) ---[ end trace e3f76b302655160b ]---
04-06-2018 09:09 AM
Just replying to myself, I was missing the -DUSE_AMP=1 in the extra compiler flags (why the OpenAMP echo example does not consider it automatically?).
So far, the system is now running with the following dts (in case some other users might need it)
/{ amba { elf_ddr_0: ddr@3e000000 { compatible = "mmio-sram"; reg = <0x3e000000 0x00400000>; }; }; remoteproc0: remoteproc@0 { compatible = "xlnx,zynq_remoteproc"; firmware = "firmware"; vring0 = <15>; vring1 = <14>; srams = <&elf_ddr_0>; }; };
Still I do not understand why it does not work with 0x30000000 base address, but is not essential for the application. Now's time to play with OpenAMP ;).
Thank you @jovitac for your support...
Luca