[U-Boot-Users] U-boot for MCF5329

[Liew Tsi Chung-r5aahp]

Robert,

	This is what I think it is. When NAND CS2 is enabled, there seems to be a address/bus conflict between CS0 and CS1. You can do this experiment by not enable the CS2 MASK at boot time but at run time. Then, enable the valid bit in CS2_MASK. Try read address 0. 

Regards,
TsiChung

-----Original Message-----
From: Robert S. Grimes [mailto:rsg at alum.mit.edu] 
Sent: Friday, July 27, 2007 9:06 AM
To: w.wegner at astro-kom.de
Cc: Liew Tsi Chung-r5aahp; Das U-Boot Mailing List
Subject: Re: [U-Boot-Users] U-boot for MCF5329

w.wegner at astro-kom.de wrote:
> Hi Bob,
>
> did you try running U-Boot from RAM?
> I am still trying to get CONFIG_MONITOR_IS_IN_RAM to work completely, 
> but am stuck in speed.c/clock_pll().
>   
No, directly from Flash.  As I am using the factory board, flash works, and I have a P&E Micro BDM working with GDB, there is no reason for me to not run directly from Flash.  Especially since this is _not_ a custom board, and _should_ work "out of the box".  Of course, there are always little issues along the bleeding edge!

Also, given your difficulties with RAM, and the apparent advice to not bother trying to run out of RAM, it seems better not to go that route.  
But bottom line: for me, I just want to get this working in the final configuration ASAP - then again, don't we all? ;-)
> All is working when I let the code run from flash or completely 
> disable re-setting the PLL by some #ifndef CONFIG_MONITOR_IS_IN_RAM, 
> and now I am wondering if this has something to do with my RAM, or if 
> I am still doing anything wrong when trying to put the RAM in self-refresh mode.
>   
This is what I expected - it all to work when run from flash (of course, with relocation to RAM).  Are you running on your custom board?  Or the Cobra?  And more pertinent (I think), are you using NAND Flash?
> PS: the problem in env_init was related to bad chip select setups, I did not realize that the
>       values of CFG_CSx_BASE had to be truncacted to the upper 16 bits
>   
I tried that in response to your earlier email, but no luck.  the CFG_CS2_BASE _was_ indeed set to 0x00800000; setting it to 0x0080 did
*not* fix the problem. 

I found something interesting, though.  I'm not too proficient with gdb, but when I single-step to the call to icache_enable(), then enter "step" 
to step into that function, gdb never returns.  However, if I do "set lang asm" first, then I get something like this when I step:

    120    icache_enable();
    (gdb) stepi
    120    icache_enable();
    (gdb) stepi
    120    icache_enable();
    (gdb) stepi
    120    icache_enable();

I don't know what that's all about, but again, if I remove the call to icache_enable(), it still doesn't work - removing the CS2 stuff does.

Thanks,
-Bob