U-boot Porting Issue

Hi,

What do you mean by "crash"? What is the return value of the function?

Best regards,
Miroslav

Hi Michael,

Does your DDR3 memory have Vtt termination? If you have termination could you check if the Vtt regulator is enabled?

Hi,

The device completely resets jumping back to the SPL and attempting to boot again. I'm going to dig into this a bit more this morning to see exactly what memory location the reset occurs. 

Thanks

Micheal

Hi,

I can confirm that I have the Vtt regulator enabled on the DDR3.

Thanks

Micheal

Hi,

I'm not so sure now if that function call is the problem. I added a debug print string just before the mem_malloc_init() followed by a while loop

serial_initialize();

	debug("Now running in RAM - U-Boot at: %08lx\n", dest_addr);

#ifdef CONFIG_LOGBUFFER
	logbuff_init_ptrs();
#endif
#ifdef CONFIG_POST
	post_output_backlog();
#endif

	puts("got to here");
	while(1);
	/* The Malloc area is immediately below the monitor copy in DRAM */
	//Micheal - This is crashing for some reason
	malloc_start = dest_addr - TOTAL_MALLOC_LEN;
	//printf("dest_addr: %#x \n", dest_addr);
	//printf("malloc_start: %#x \n", malloc_start);
	//printf("TOTAL_MALLOC_LEN: %#x \n", TOTAL_MALLOC_LEN);

	mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);

I assumed I would see the device boot to the loop every time (not debugging but booting from the SD card) but it doesn't seem to do this. It sometimes hits the loop but I have also got the following terminal output

U-Boot 2013.10 (Sep 16 2014 - 14:09:13)

I2C:   ready
DRAM:  256 MiB
data abort

    MAYBE you should read doc/README.arm-unaligned-accesses

pc : [<18f76179c>]         lr : [<18f793258>]
sp : 18f340ee8  ip : 18f340efc   fp : 180813d78
r10: 180837886  r9 : 18f340f38   r8 : 14030cdcc
r7 : 14030cb7c  r6 : 100000002   r5 : 100028bd0  r4 : 18f7a4e28
r3 : 150000000  r2 : 100000008   r1 : 116000f80  r0 : 100151e1e
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32
Resetting CPU ...

Does this point to some sort of incorrect configuration in the SPL or u-boot?

Thanks

Micheal

The fact that it sometimes hits the while loop and sometimes it doesn't may indicate that you have a problem with your DDR timings. Please double check and verify these.

Best regards,
Miroslav

Hi Miroslav,

I double checked my values and re-ran the tuning application and as far as I can tell the values are fine. I used the AM3358_StarterKit.gel DDR test modified to write to 10,000 locations and it is passing data integrity.

My modified MLO and u-boot will boot a beaglebone black and a Starter Kit with no issues however our own board still throws a data abort and warning about unaligned-accesses most times I try and boot the board. Would you still think this is a RAM issue?

Thanks

Micheal

Hi,

I also added a routine to the SPL after DDR3 initialisation and can confirm I can write large amounts of data to the RAM without issue. The problem seems to be the handover from the SPL to u-boot. I'm not sure what I can do to debug the issue.

Micheal 

Can you print the dest_addr and TOTAL_MALLOC_LEN inside your board_init_r() function?

Best regards,
Miroslav

Hi Miroslav,

The values are as follows 

dest_addr:                          0x8f761000
TOTAL_MALLOC_LEN:   0x420000

Thanks

Micheal

These seem normal. What changes have you made to the MLO code except the DDR timings?

Best regards,
Miroslav

The only changes I would have made are removing the EEPROM configuration steps to just configs that are applicable to our board. As I mentioned the code with my changes will boot on both a Beaglebone Black and a Am335x Starter Kit so I assume they are OK.

Thanks

Micheal

I'm sorry Michael, I'm out of ideas. If I come up with something, I'll post it here.

Best regards,
Miroslav

It is worth to still investigate on the DDR side. At the DDR level the issue might timings and/or signal integrity related.
Things like crosstalk or ground bounce could cause some wrong logic levels on the data bus and corrupt the data being transfered.

- A good test for timings would be to use slower DDR timings to add more margins and re-run your SPL/U-boot with those timings.

- Is there a JTAG header on the board? Can you run Code composer studio (CCS) to debug further?
It would surely help to have a direct look at the CPU register and internal/external memory.

From the ARM docs:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471h/Cihbffgj.html
It seems that one of the operand of a read/write instruction is an address and this address is not a valid one.

Can you find out the instruction that throw the exception and look at the register that contains the operand for this instruction (in our case the address that is suppositely wrong)? The below page does give a way to find the the address instruction that caused it:
http://www.keil.com/support/docs/3080.htm

Look at the disassembly windows in CCS to locate the instruction. The instruction  will tell you which operand is the address. See the ARM instruction set:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471h/Cihbffgj.html
If you can recover the address value that was passed you might be able to check if it is considered valid or not. If it was fetched from DDR you could check in the memory window if the DDR memory content matches what was fetched in the register.

Anthony