Hello,
Now, we can booting the u-boot ls1043aqds from qspi used in our custom board but after booting, we can not read in 0x7fb00000 address (our cpld id register):
=> md.b 0x7fb00000
7fb00000:"Synchronous Abort" handler, esr 0x96000006
elr: 0000000040165d38 lr : 0000000040165c50 (reloc)
elr: 00000000fbda5d38 lr : 00000000fbda5c50
x0 : 0000000000000009 x1 : 000000000000003a
x2 : 0000000000000020 x3 : 000000007fb00000
x4 : 0000000000000000 x5 : 00000000fbdc2745
x6 : 0000000000000001 x7 : 000000000000000f
x8 : 00000000ffffffd0 x9 : 000000000000000c
x10: 0000000000000010 x11: 0000000000000006
x12: 000000000001869f x13: 0000000000002048
x14: 00000000fbc38a68 x15: 0000000000000008
x16: 0000000000000001 x17: 000000000000010f
x18: 00000000fbc3bdb8 x19: 0000000000000040
x20: 000000007fb00000 x21: 000000007fb00000
x22: 00000000fbdc144f x23: 0000000000000002
x24: 0000000000000010 x25: 0000000000000010
x26: 0000000000000001 x27: 00000000fbc38858
x28: 0000000000000000 x29: 00000000fbc387d0
The NXP forum suggested checks if IFC chip-select is configured for the address 0x7fb00000, but how we can do this?
The NXP forum also communicated us to provide this output:
=> md.l 1530000 40
01530000: 00000401 00000000 00000000 00000000 ................
01530010: 00000000 00000000 00000000 00000000 ................
01530020: 00000000 00000000 00000000 00000000 ................
01530030: 00000000 00000000 00000000 00000000 ................
01530040: 00000000 00000000 00000000 00000000 ................
01530050: 00000000 00000000 00000000 00000000 ................
01530060: 00000000 00000000 00000000 00000000 ................
01530070: 00000000 00000000 00000000 00000000 ................
01530080: 00000000 00000000 00000000 00000000 ................
01530090: 00000000 00000000 00000000 00000000 ................
015300a0: 00000000 00000000 00000000 00000000 ................
015300b0: 00000000 00000000 00000000 00000000 ................
015300c0: 00000000 00000000 00000000 00000000 ................
015300d0: 00000000 00000000 00000000 00000000 ................
015300e0: 00000000 00000000 00000000 00000000 ................
015300f0: 00000000 00000000 00000000 00000000 ................
Should we activate something in defconfig to can read from these addresses?
Can you take a look to our H board file and defconfig that have some changes made by us, we also verified these files before.
Best regards
There is no problem for CPLD reading at address 0x7FB00000 on the LS1043ARDB board.
It looks like that CS is not configured for this address. Check your CS configuration for CPLD.
But the CS configuration for CPLD is related to u-boot or is an external hardware CPLD configuration?
Thank you
And we have the ifc mentioned in dts also as:
&ifc {
status = "okay";
#address-cells = <2>;
#size-cells = <1>;
/* NOR, NAND Flashes and FPGA on board */
ranges = <0x0 0x0 0x0 0x60000000 0x08000000
0x1 0x0 0x0 0x7e800000 0x00010000
0x2 0x0 0x0 0x7fb00000 0x00000100>;
nor@0,0 {
compatible = "cfi-flash";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0 0x0 0x8000000>;
bank-width = <2>;
device-width = <1>;
};
nand@1,0 {
compatible = "fsl,ifc-nand";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x1 0x0 0x10000>;
};
cpld: board-control@2,0 {
compatible = "fsl,ls1043ardb-cpld";
reg = <0x2 0x0 0x0000100>;
};
};
What can be wrong?
Thank you
Is there problem under u-boot for CPLD using?
Good morning,
With some changes (in files), in our custom board with ls1043aqds QSPI u-boot we have one CPLD configured to 0x7fb00000 but we have successive reads (successive addresses) with the same values:
The expected behavior is (using u-boot in NAND flash):
What can be wrong?
Thank you
Below is log from the LS1043ARDB board. Check reading all CPLD data.
=> md 7fb00000 20
7fb00000: 00020401 00000400 01010100 01000001 ................
7fb00010: fbfbfb00 fbfbfbfb fbfbfbfb fbfbfbfb ................
7fb00020: 00020401 00000400 01010100 01000001 ................
7fb00030: fbfbfb00 fbfbfbfb fbfbfbfb fbfbfbfb ................
7fb00040: 00020401 00000400 01010100 01000001 ................
7fb00050: fbfbfb00 fbfbfbfb fbfbfbfb fbfbfbfb ................
7fb00060: 00020401 00000400 01010100 01000001 ................
7fb00070: fbfbfb00 fbfbfbfb fbfbfbfb fbfbfbfb ................
=> md.b 7fb00000 80
7fb00000: 01 04 02 00 00 04 00 00 00 01 01 01 01 00 00 01 ................
7fb00010: 00 fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ................
7fb00020: 01 04 02 00 00 04 00 00 00 01 01 01 01 00 00 01 ................
7fb00030: 00 fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ................
7fb00040: 01 04 02 00 00 04 00 00 00 01 01 01 01 00 00 01 ................
7fb00050: 00 fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ................
7fb00060: 01 04 02 00 00 04 00 00 00 01 01 01 01 00 00 01 ................
7fb00070: 00 fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ................
Hello,
If we reading all CPLD data in our custom board, using this board file:
Perhaps there is incorrect answer from CPLD on your board or hardware problem concerning to address lines in your board.
Hello,
But the CPU address lines connected to the CPLD are the same using U-BOOT for NAND (generated from u-boot-7-2017-LSDK-17.12) where the CPLD read is correct.
Thank you
Is CPLD correct on your board?
Is there possibility to check connecting address lines to this CPLD?