Hello
I am trying to configure DDR2 sdram on a custom imx6q board for the first time using jtag, (openocd and a flyswatter2)
I am able to read SDRAM memory space but when trying to write to it nothing happens.
This is a custom board using an iMX6Q and Micron DDR2 MT42L256M32D2LG-18 WT:A
Any suggestions would be much appreciated.
Original Attachment has been moved to: gdb_console_dump.txt.zip
Original Attachment has been moved to: new_board.cfg.zip
1. The MT42L256M32D2LG-18 is a LPDDR2 memory device (MX6Q didn't support DDR2), and the DRAM bus connection is different with DDR3. Please reference to section 44.4.5 LPDDR2 and DDR3 pin mux mapping in RM rev1 to check your HW connection is correct.
2. There has a useful tool can help you to modify the related REGs (the link is https://community.freescale.com/docs/DOC-95089). Since the script file format different, please convert it to your format (openocd and a flyswatter2) by yourself .
Thanks Yung, we fixed the pin mux mapping and am now getting back garbage data when performing a read at 0x80000000. Every time I read I receive something completely different. If I try to write to this area the data appears to store but quickly disappears after a few reads. What could this mean? Could this be a delay/calibration issue?
Also I am unable to peform # Switch PL301_FAST2 to DDR Dual-channel mapping
mww 0x00B00000 0x1
I receive a JTAG-DP STICKY ERROR
I perform a dap apsel 0 and a dap apcsw 1 before performing DCD
I attached my DCD code, are we supposed to have additional settings in there such that at power up the boot clock timing is between 10Mhz and 55Mhz? I tried reducing this to appx 40Mhz and the issue remained the same. Thanks for the spreadsheet link it is very helpful.
From the LPDDR2 SPEC (MT42L256M32D2), it shows the device type is signal channel and dual rank. (256M*32Bit *2CS), and it seems some dram settings are not correct in you dcd file. Please reference the ddr init script (in attached) and check below items for your dram settings.
Ps. The DDR calibration values are not includes in the ddr init script, please use the ddr stress tester to do the ddr calibration.
Best regards
Aven
Thanks a lot! The settings you provided resolved my issue of not being able to read/write to LPDDR via jtag.
Can you please provide information regarding how to use the DDR stress test to do the calibration. Is this something that has to be done via the bootloader?
Can you contact with local FAE for the mx6 ddr stress test tool?
This tool can help you to do the ddr calibration and ddr performance test, and you just need update the dram related paramter into the dcd table of u-boot.
Best regards
Aven
..
Thanks I will reach out to the FAE for the stress tool, should ddr be initializing at all 0's? I get the following with my current settings
(gdb) monitor mdw 0x10000000 10
0x10000000: da858be9 5e08533a 2e0d6114 330f6ddf 122b998c d01742fc 09ac4d4d 045443fe
0x10000020: 410acd4e 40688a10
(gdb) monitor mww 0x10000000 0xffffcccc
(gdb) monitor mdw 0x10000000 10
0x10000000: ffffcccc 5e08533a 2e0d6114 330f6ddf 122b998c d01742fc 09ac4d4d 045443fe
0x10000020: 410acd4e 40688a10
The ddr init didn't reset the content to 0, so the disorderly contect is normal.
And the test log shows you can access the ddr (address 0x1000000)
Thanks! I think my lpddr2 is working correctly now. Next fire is trying to boot from the SD Card. I am using uboot as the bootloader and putting it onto the SD card via
I get no console response so I connected jtag up to see what is going on. It doesn't seem like the IVT header is in 0x907400 nor is my dram initialized ( i do not even see a clock turn on when probing with a scope), so i don't think the DCD header is being run. I also connected the scope to the data0 line, command line and clock of the sd card. Upon reset of the card there is activity on the command and clock lines but i do not see any activity on the Data 0 line.
The sd card is connected to USDHC 1 with the following pads
The boot pins are set to: (and verified via console dump of 0x20d8004: 0x00012040)
SD Loopback Clock Source sel(for SDR50 and SDR104 only) 0 - through SD pad 1 – direct | 0 |
SD Power Cycle Enable/eMMC Reset Enable 0 - No power cycle 1 - Power cycle enabled via SD_RST pad (on USDHC3 and USDHC4 only) | 0 |
SD/MMC Speed (see below) | X |
BOOT_CFG[3:2]: 0x - High/Normal 10 - SDR50 11 - SDR104 | 0 |
0 - Normal Boot 1 - Fast Boot | 0 |
0 - SD/eSD/SDXC 1 - MMC/eMMC | 0 |
1 – SD boot (BOOT_CFG1[7] must be 0) | 1 |
0 | 0 |
0 - Use default values 1 - Use PAD_SETTINGS values | 0 |
0 - Use default SD pad settings during power cycle 1 - Set pull-down on SD pads during power cycle (used only if "SD Power Cycle Enable" enabled) | 0 |
0 | |
Port Select (see below) | 0 |
BOOT_CFG2[4:3]: 00 - USDHC-1 01 - USDHC-2 10 - USDHC-3 11 - USDHC-4 | 0 |
Bus Width xx0 - 1-bit xx1 - 4-bit | 1 |
SD Calibration (see below) | 0 |
BOOT_CFG2[7:6] SD/eSD/SDXC BOOT_CFG1[5]=0) SD Calibration Step 00x - 1 delay cells 01x - 1 delay cells 10x - 2 delay cells 11x - 3 delay cells | 0 |
I also try to boot the image via the mfgtool and see no activity there either (should the ivt be put into the same 0x907400 iram location too?) Also since i do not have a working kernel yet I dont know if the mfgtool would be helpful
I usually flash the SD with these parameters: bs=512 seek=2 skip=2'. Looking a the man page, kB=1000 and K=1024, and you used k, which may be interpreted as 1000, an this value is wrong.
Leo
Thanks Leo, but I tried both of those and still nothing coming out of the Data 0 line / ivt header in 0x907400
I'm working with Rob on this: We do see commands going out from the SD card controller, and the SD card responding, but we see no toggling of data. Is there any other card formatting that needs to be done? When Rob created the SD card image we read back the first 50K into a file to verify that the IVT appeared at the correct 0x400 offset.
Another tack we're attempting is to load our uBoot image into DRAM with JTAG and then execute it. We are able to download the image into the DRAM, we set a hardware breakpoint to the first or second instruction, set the CPU to ARM mode, then resume to the "_start" address. We never trigger the breakpoint, and when we halt the processor it is program counter is still in the internal ROM of the iMX6. Is there a register that needs to be turned from JTAG on so that the CPU can read the DRAM?