Synchronous Abort Exception when booting u-boot from eMMC

[juddwang]

Hi all,

We designed a board similar as LS1043ARDB. The main difference between our board and LS1043ARDB is that our board use 4 MT40A1G8 DDR4 chips while LS1043ARDB use 4 MT40A512M8 DDR4 chips. And on our board, there's no nand flash & nor flash mounted. We want to boot from eMMC (similar as SD card on LS1043RDB).

We built a u-boot-sdcard image on SDK 2.0. This image booted up successfully on LS1043ARDB, but it failed on our board, error print is as following:

U-Boot SPL 2016.012.0+ga9b437f (Jan 04 2017 - 20:45:24)

Initializing DDR....
starting at step 1 (STEP_GET_SPD)
Filling dimm parameters from board specific file
Computing lowest common DIMM parameters for memctl=0
lowest_common_spd_caslat is 0xb
Warning: not all DIMMs ECC capable, cant enable ECC
tCKmin_ps = 938
trcd_ps = 13500
trp_ps = 13500
tras_ps = 33000
trfc1_ps = 260000
trfc2_ps = 160000
trfc4_ps = 110000
trrds_ps = 3700
trrdl_ps = 5300
tccdl_ps = 5355
twr_ps = 15000
trc_ps = 46500
Reloading memory controller configuration options for memctl=0
mclk_ps = 1250 ps
Found timing match: n_ranks 1, data rate 1666, rank_gb 0
0 of 1 controllers are interleaving.
Checking interleaving options completed
dbw_cap_adj[0]=0
ctrl 0 dimm 0 base 0x0
ctrl 0 total 0x80000000
Total mem by __step_assign_addresses is 0x80000000
Total mem 2147483648 assigned
Programming controller 0
total 2 GB
Need to wait up to 132 * 10ms
total_memory by __fsl_ddr_sdram = 2147483648
>>spl:board_init_r()
using memory 0x820a0000-0x821a0000 for malloc()
spl_init()
Trying to boot from MMC
After announce_boot_device, calling spl_load_image...
Calling spl_mmc_load_image
spl: spl_mmc_load_image, calling spl_mmc_find_device
"Synchronous Abort" handler, esr 0x96000000
ELR: 1000768c
LR: 100026fc
x0 : 0000000000000000 x1 : 0000000080102d78
x2 : ff000000ff001014 x3 : 0000000000000001
x4 : 000000001001d630 x5 : ffffff80ffffffc8
x6 : 0000000000000000 x7 : 000000000000000f
x8 : 0000000000000000 x9 : 0000000000000080
x10: 0000000000000003 x11: 0000000000000000
x12: 0000000000000000 x13: 0000000000000000
x14: 00000000100181e8 x15: 0000000000000001
x16: 0000000000000000 x17: 0000000000000000
x18: 000000001001ddf0 x19: 0000000000000000
x20: 0000000000000000 x21: 000000001001b000
x22: 00000000deadbeef x23: 0000000000000001
x24: 0000000000000000 x25: 0000000010014000
x26: 000000001001bd78 x27: 0000000000000001
x28: 0000000000000000 x29: 000000001001d940

We have tested the DDR function under CodeWarrior, it seems to be OK.

Any suggestion will be appreciated. 

[tracysmith]

Hi Judd, please provide the parameters you used for the MT40A512M8 and the files you touched/updated?  Other customer's are seeing similar issues with the part and this would help customers in general since this is a common part.

[juddwang]

Hi Tracy, sorry for late reply. We get the parameters from Codewarrior default settings for LS1043ARDB. And the main changing is to downgrade DDR data rate from 1600 to 1300.

[juddwang]

Hi chris,

We have solved the problem, it's caused by DDR. The default DDR parameters of LS1043ARDB doesn't fit for our board.

Thank you all the same.

[juddwang]

Hi chris,

Thanks for your reply. We are using the same u-boot-sdcard.bin image on our board and LS1043ARDB. And we are sure this image contains RCW+PBL+SPL_Uboot. So the root cause of our problem maybe not the same as yours.

Is there any difference between eMMC (used on our board) and SD card (used on LS1043ARDB)? 

[cswarth]

Sorry, I haven't enough experience to answer your question re: difference between eMMC and sdcard.   Someplace I ran across the documentation of why the RCW on the sdcard has to start at offset 0x1000.  There is also a memory map for QSPI that lays out exactly where RCW, U-BOOT, FMAN microcode needs to go.  I haven't seen a similar map for eMMC.

[cswarth]

It looks like your SPL is not finding a valid u-boot image for the second part of the boot.  Are you sure you are using an image that combines RXW+PBL+SPL+uboot?

I just solved a very similar "Synchronous Abort" at about the same location yesterday - almost certainly not caused by the same problem, though.  In my case when I dumped the uboot image (od -tx1 u-boot-with-spl-pbl.bin), I noticed some suspicious gaps in the image when compared to a working image on the reference board.  In my case the problem was caused by a modification I had made to the `mkimage` tool; once I back out that change I was back in business.