AMP - Direct firmware load issue

[lucam]

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

[jovitac]

Hi Luca,

Could you please attach your device-tree?

[lucam]

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

[jovitac]

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.

[lucam]

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

[lucam]

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

[jovitac]

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?

[lucam]

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 ]---

[lucam · Accepted solution]

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