Hi @derekparks,
Yes, I can explain a little bit. The trouble was linked to our custom hardware, with NAND we have to respect timing and printed circuit must be designed with propagation time...
I'm not sure to be really clear, but if you have different conductive trace you have to set correctly timing in Vivado AND in your device-tree also:
&nand0 {
arm,nand-cycle-t0 = <0x3>;
arm,nand-cycle-t1 = <0x3>;
arm,nand-cycle-t2 = <0x2>;
arm,nand-cycle-t3 = <0x2>;
arm,nand-cycle-t4 = <0x2>;
arm,nand-cycle-t5 = <0x1>;
arm,nand-cycle-t6 = <0x3>;
status = "okay";
partition@nand-fsbl-uboot {
label = "nand-fsbl-uboot";
reg = <0x0 0x100000>;
};
partition@nand-linux {
label = "nand-linux";
reg = <0x100000 0x500000>;
};
partition@nand-device-tree {
label = "nand-device-tree";
reg = <0x600000 0x20000>;
};
partition@nand-rootfs {
label = "nand-rootfs";
reg = <0x620000 0x5E0000>;
};
partition@nand-bitstream {
label = "nand-bitstream";
reg = <0xC00000 0x400000>;
};
Edit:
Device-tree settings:
The timing parameters t0, t1, t2, t3, t4, t5, t6 denotes
nand-cycle-t0 : Read cycle time(t_rc).
nand-cycle-t1 : Write cycle time(t_wc).
nand-cycle-t2 : re_n assertion delay(t_rea).
nand-cycle-t3 : we_n de-assertion delay(t_wp).
nand-cycle-t4 : Status read time(t_clr)
nand-cycle-t5 : ID read time(t_ar)
nand-cycle-t6 : busy to re_n(t_rr)
For our custom design, we had to update timing up to:
arm,nand-cycle-t0 = <0x4>; /* t_rc */
arm,nand-cycle-t1 = <0x4>; /* t_wc */
arm,nand-cycle-t2 = <0x1>; /* t_rea */
arm,nand-cycle-t3 = <0x2>; /* t_wp */
arm,nand-cycle-t4 = <0x2>; /* t_clr */
arm,nand-cycle-t5 = <0x2>; /* t_ar */
arm,nand-cycle-t6 = <0x4>; /* t_rr */
Cheers,
Trigger
