On 06/10/2011 07:44 AM, Torsten Koschorrek wrote:
Hello,
Hi Torsten,
send your answer to the ML, too. Someone else can help you ;-)
size1 = get_ram_size((volatile void *)SCB9328_SDRAM_1, SCB9328_SDRAM_1_SIZE); #if ( CONFIG_NR_DRAM_BANKS> 1 ) size2 = get_ram_size((volatile void *)SCB9328_SDRAM_2, SCB9328_SDRAM_2_SIZE); .....
and then: gd->ram_size = size1 + size2 + size3 + size4;
Yes, I thought about it. The thing is, we only have one bank on the system. So, dram_init_banksize() needs a cleanup, but that's a problem for another cleanup-patch, which will be committed in a next step.
(If it's needed I could do a minor cleanup first...)
You decide. However, the code in the patch is wrong. If you have only one bank, you could directly simplify your code, I think.
/** diff --git a/include/configs/scb9328.h b/include/configs/scb9328.h index 3da214e..c610ed1 100644 --- a/include/configs/scb9328.h +++ b/include/configs/scb9328.h @@ -127,6 +127,9 @@ #define SCB9328_SDRAM_1 0x08000000 /* SDRAM bank #1 */ #define SCB9328_SDRAM_1_SIZE 0x01000000 /* 16 MB */ +#define CONFIG_SYS_SDRAM_BASE SCB9328_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR SCB9328_SDRAM_1 + 0xf00000
In most boards/processors the stack pointer is set to the internal RAM, that is available before the SDRAM controller is activated. When not available, cache can be used. Is there no internal memory available for this processor ? It could be that the stack is used before the SDRAM is initialized, and then it hangs.
I suppose, here is the cause of the hanging problem, yes. While I was trying to solve it I saw some board configs which use sdram, too.
Take into account that a lot of new processors set automatically the RAM controller before u-boot is started. I am thinking to the newer i.MX processors, but this is true for other architectures, too. And in some cases u-boot runs as second or third bootloader, such as for at91sam, davinci and omap, without touching the RAM controller that is already programmed by the first-stage bootloader. In your case the SDRAM controller is probably not yet programmed when the stack pointer is set.
Internal RAM came to my mind, too, but I didn't had the time to investigate further.
Unfortunately I have to work on another project today and next week and I think I'm not able to solve the hanging problem.
Understood, I tried only to give you some hints where to check ;-)
Minor fixes (such as config.mk) for the above patch should be possible, though.
Ok, agree. Fix first the problem to make MAKEALL happy and build the board again.
Best regards, Stefano Babic