Hi Yordan,

       we do the patches follow  "3.4 Build Linux Vision SDK for fast boot (Early boot and late attach of remote cores)" in <VSDK_DIR>/vision_sdk/docs/Linux/VisionSDK_Linux_UserGuide.pdf.

       but the IPU1,IPU2,DSP1,DSP2 memorys didn't consistent in the mem_segment_definition_linux.xs, arch/arm/boot/dts/dra7-evm.dts and the lateattach.c,  which is required in the link https://processors.wiki.ti.com/index.php/Early_Boot_and_Late_Attach_in_Linux   "Pre-flight checks" part.

      we don't need to keep the memory of  IPU1,IPU2,DSP1,DSP2 consistent?

when we do the earlyboot patches to the original vsdk_3.06, it shows that:

the definitions in the file arch/arm/boot/dts/dra7-evm.dts in the kernel source:

ipu1_cma_pool: ipu1_cma@9d000000 {
    compatible = "shared-dma-pool";
    reg = <0x9d000000 0x2000000>;
    reusable;
    status = "okay";
};

ipu2_cma_pool: ipu2_cma@95800000 {
    compatible = "shared-dma-pool";
    reg = <0x95800000 0x3800000>;
    reusable;
    status = "okay";
};

dsp1_cma_pool: dsp1_cma@99000000 {
    compatible = "shared-dma-pool";
    reg = <0x99000000 0x4000000>;
    reusable;
    status = "okay";
};

dsp2_cma_pool: dsp2_cma@9f000000 {
    compatible = "shared-dma-pool";
    reg = <0x9f000000 0x800000>;
    reusable;
    status = "okay";
};

but the lateattach.c shows like this:

#define DRA7_RPROC_CMA_BASE_IPU1 0x9e000000
#define DRA7_RPROC_CMA_BASE_IPU2 0x99000000
#define DRA7_RPROC_CMA_BASE_DSP1 0xA1000000
#define DRA7_RPROC_CMA_BASE_DSP2 0xA3000000

#define DRA7_RPROC_CMA_SIZE_IPU1 0x02000000
#define DRA7_RPROC_CMA_SIZE_IPU2 0x05000000
#define DRA7_RPROC_CMA_SIZE_DSP1 0x02000000
#define DRA7_RPROC_CMA_SIZE_DSP2 0x02000000

the mem_segment_definition_linux.xs shows like this:

IPU2_START_ADDR = 0x99000000;
IPU2_CODE_SIZE = 8*MB;
if (ipummSupport == "yes") {
IPU2_DATA_SIZE = 60*MB;
}
else {
IPU2_DATA_SIZE = 20*MB;
}

IPU1_START_ADDR = 0x9e000000;
IPU1_0_CODE_SIZE = 8*MB;
IPU1_0_DATA_SIZE = 21*MB;

DSP1_START_ADDR = 0xA1000000;
DSP1_CODE_SIZE = 2*MB;
DSP1_DATA_SIZE = 24*MB;

DSP2_START_ADDR = 0xA3000000;
DSP2_CODE_SIZE = 2*MB;
DSP2_DATA_SIZE = 14*MB;

we can see the arch/arm/boot/dts/dra7-evm.dts is different from others when we do the earlyboot patches followed the section "3.4 Build Linux Vision SDK for fast boot (Early boot and late attach of remote cores)" in <VSDK_DIR>/vision_sdk/docs/Linux/VisionSDK_Linux_UserGuide.pdf

Hi Yordan,

       It seems the kernel still load the firmwarm during it starts:

20200330_16:15:50[ 1.254492] remoteproc0: 58820000.ipu is available
20200330_16:15:50[ 1.259409] remoteproc0: Note: remoteproc is still under development and considered experimental.
20200330_16:15:50[ 1.268405] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
20200330_16:15:50[ 1.278893] remoteproc0: Direct firmware load for dra7-ipu1-fw.xem4 failed with error -2
20200330_16:15:50[ 1.287251] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000
20200330_16:15:50[ 1.295058] remoteproc0: Falling back to user helper
20200330_16:15:50[ 1.300288] remoteproc1: 55020000.ipu is available
20200330_16:15:50[ 1.305185] remoteproc1: Note: remoteproc is still under development and considered experimental.
20200330_16:15:50[ 1.314202] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
20200330_16:15:50[ 1.324823] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@99000000
20200330_16:15:50[ 1.332689] remoteproc2: 40800000.dsp is available
20200330_16:15:50[ 1.337586] remoteproc2: Note: remoteproc is still under development and considered experimental.
20200330_16:15:50[ 1.346669] remoteproc1: Direct firmware load for dra7-ipu2-fw.xem4 failed with error -2
20200330_16:15:50[ 1.354916] remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
20200330_16:15:50[ 1.365329] remoteproc1: Falling back to user helper
20200330_16:15:50[ 1.370812] omap-rproc 41000000.dsp: assigned reserved memory node dsp2_cma@9f000000
20200330_16:15:50[ 1.378629] remoteproc3: 41000000.dsp is available
20200330_16:15:50[ 1.383579] remoteproc3: Note: remoteproc is still under development and considered experimental.
20200330_16:15:50[ 1.392600] remoteproc3: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
20200330_16:15:50[ 1.403090] remoteproc2: Direct firmware load for dra7-dsp1-fw.xe66 failed with error -2
20200330_16:15:50[ 1.412378] NET: Registered protocol family 10
20200330_16:15:50[ 1.417187] remoteproc2: Falling back to user helper
20200330_16:15:50[ 1.432579] remoteproc3: Direct firmware load for dra7-dsp2-fw.xe66 failed with error -2
20200330_16:15:50[ 1.441008] sit: IPv6 over IPv4 tunneling driver

Hi Yordan,

      The link  https://processors.wiki.ti.com/index.php/Early_Boot_and_Late_Attach_in_Linux  says:

Debugging Late Attach

1. Ensure that all the 3 late attach attributes are set on the device tree nodes corresponding to the remotecore node being loaded from the boot loader. Otherwise the kernel will reset and reload the remotecore as in the normal boot flow.
2. Ensure that the 3 late attach attributes are set only on the device tree nodes corresponding to the remotecore node being loaded from the boot loader. Otherwise the kernel will try to communicate with a remotecore that is not loaded and run into an error or a crash in a worst case scenario.
3. Ensure that the peripherals accessed by the remotecore are not being handled by the kernel. This can be accomplished by removing the corresponding nodes from the device tree.

we use some peripherals(i.e. GPIO, I2C)  to drive the cameras, so we need to follow the steps above?