This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am working on a custom board design based on Spectrum Digital's TI8168EVM.
I would like to define a method to test DDR memory in our production line so that we can detect any soldering problems that might occur during our manufacturing process.
Is there a recommended way to test DDR memory in a fast way either on Linux or in U-Boot?
I have found a command in u-boot named mtest that seems to perform a very basic test, but I am not able to test the complete 1GB memory on my system.
Taking a deeper look into my problem, I have discovered that U-Boot is placing part of its code on 0x40400000 (SRAM) and 0x80700000 (DDR RAM), so I can understand why my system crashes when testing some of the addresses.
Why is it that looking at my code u-boot.map and board/ti/ti8168/config.mk are showing me that U-Boot should be at address 0x80700000, but doing md -s in U-boot I can see that there's actually some sort of information starting at address 0x806F4000 ? What is that information, and why does my system crash when I try to write there?
What can I do to be able to test my whole RAM address range, from 80000000 to C0000000 ?
Thank you in advance for your help.
The standard U-Boot memory test is very basic. There's also an advanced version of this under the post/ folder but you'll need to adapt it for DM8168.
There's also a memtester utility that you can use from the kernel. It does a very comprehensive testing and you'll can try that out.
Xabier Marquiegui said:I can see that there's actually some sort of information starting at address 0x806F4000 ? What is that information, and why does my system crash when I try to write there?
This would be the runtime environment for U-Boot. Depending on what you overwrite you will get unexpected results.
Xabier Marquiegui said:What can I do to be able to test my whole RAM address range, from 80000000 to C0000000 ?
Once the standard U-Boot and Linux start executing there will always be some memory location that will be occupied by them. You can either skip the necessary region or you could explore using a U-Boot version running from internal memory and then run a mtest over the full memory space.
Regards,
Vaibhav
Hi Xabier,
I'm just starting to work on the same task and I believe you have it already done.
Could you tell me please, what and where I have to change in order to make U-boot running from internal memory only?
Thanks a lot !
Hi, Yuri!
You need build u-boot with minimal configuration:
make ti8168_evm_min_ocmc
Thank you for quick response.
Now I'm trying to toggle GPIO (pin 26) from u-boot. The code shown below works fine if I compile it by using
make ti8168_evm_config but does not work with make ti8168_evm_min_ocmc
I'll be appreciated for any help
u32 gpio_reg_val = 0;
#define TI816X_GPIO0_BASE 0x48032000
/*pin mux GPIO 26*/
__raw_writel(0x02, 0x48140B20);
/* enable GPIO clock*/
__raw_writel(0x102, 0x4818155c);
while((__raw_readl(0x4818155c) & 0x3) != 0x2);
__raw_writel(0x102, 0x48181560);
while((__raw_readl(0x48181560) & 0x3) != 0x2);
gpio_reg_val = 0x04000000;
__raw_writel(gpio_reg_val, TI816X_GPIO0_BASE + 0x194);
gpio_reg_val = ~(0x04000000);
__raw_writel(gpio_reg_val, TI816X_GPIO0_BASE + 0x134);
gpio_reg_val = 0x04000000;
__raw_writel(gpio_reg_val, TI816X_GPIO0_BASE + 0x190);
BR,
Hi Yuri!
In file ti8168_evm.h all subsystems were disabled:
#ifdef CONFIG_MINIMAL
# undef CONFIG_MMC
# undef CONFIG_NAND
# undef CONFIG_SPI
# undef CONFIG_I2C
# define CONFIG_NO_ETH
#endif
May be this code simply not compile? Or this configuration settings exclude some additional initialization.
Hi,
We've built u-boot with ti8168_evm_min_ocmc, but unfortunately, don't get any reply from uart. (BTW with ti8168_config everything OK).
Did you have same issue?
Thanks
Hi, Yuri!
Did you see this wiki page?
http://processors.wiki.ti.com/index.php/Understanding_u-boot-min_startup_for_DM814x
May be this information will be useful for you.
I don't have any problems with messages from UART2.
Hi,
I have implemented a DDR test in my uboot ported for my custom platform. But it doesn't seem to catch any address/data line shorts.
The code for ddr test is as below:
for ( l1 = ddr_base; l1 < DDR_START + size; )
{
printf("W[0x%x] = 0x%x\n", l1, ~l1);
*( volatile unsigned int* )l1 = ~l1;
if (shift)
{
shift <<= 1;
}
else
{
shift = 4;
}
l1 = ddr_base + shift;
}
shift = 0;
for ( l2 = ddr_base; l2 < DDR_START + size; )
{
read = *( volatile unsigned int* )l2;
printf("R[0x%x] = 0x%x\n", l2, read);
if ( read/**( volatile unsigned int* )l2*/ != ~l2 )
{
errorcount++;
printf("Inv addr failed at %x (%x)\n",l2,*( volatile unsigned int* )l2);
goto LBL_DDR_TEST_ERROR;
}
if (shift)
{
shift <<= 1;
}
else
{
shift = 4;
}
l2 = ddr_base + shift;
}
could somebody point me out if there is any obvious issue with the above code as this is able to read data correctly even address line short.
Another possible alternative is the DDR test from Spectrum digital's BSP. I've run it successfully with CCS 5.2 & the XDS100v2.
Hello argeebee,
Can you provide more details about the DDR test from Spectrum Digital's BSP? Can you share the link?
Thanks a lot!
Nikko
You can download it from their website:
http://support.spectrumdigital.com/boards/evm816x/revg/
Scroll down to DM816x/C6A816x/AM389x EVM Software Resources, Gel file, Test Code
Hi argeebee,
I've got the test code archive downloaded and found the DDR test code. Thank you so much!
Nikko