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

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

[Robert S. Grimes]

Liew Tsi Chung-r5aahp wrote:
> Robert,
>
> 	Just to let you know that the denx git server now have M5329 support. Please use it for your future development.
>   
Hi TsiChung,

I just downloaded it, and after a couple of silly hiccups, I got it to 
compile.  However, it did get very far.  I at first thought it was the 
call to icache_enable() at the end of cpu_init_f(), as gdb always got 
there, until I temporarily removed it discovered the real culprit.  It 
was the setup of CS2 for the NAND Flash.  I am 99% sure I have a 
M5329BFE Fire Engine, as I have the M5329EVB, but it seems something's 
wrong there.  If I pretent I have the M5329AFE (i.e. no NAND Flash), it 
works great!  Burned it to NOR and power-cycle - boots right up!

I would like to get the NAND working, though... Any ideas?

Thanks!
-Bob
> 	Thanks,
>
> Regards,
> TsiChung
>  
>
> -----Original Message-----
> From: Robert S. Grimes [mailto:rsg at alum.mit.edu] 
> Sent: Tuesday, June 19, 2007 8:08 PM
> To: Liew Tsi Chung-r5aahp
> Subject: Re: U-boot for MCF5329
>
> Liew Tsi Chung-r5aahp wrote
> TsiChung,
>
> That is great news!  I do wish I knew about that earlier!  Of course, I did get a better understanding of both the hMCF5329 and U-Boot, porting it myself.  My port currently works with the m5329evb, and supports the uart, flash, and sdram.  The timer is used for delays, but I'm not sure how thorough it is implemented.  I don't have rtc, the clock PLL is quirky, and I especially miss the fec.  I read up on the Ethernet last Friday, but I hadn't gotten a chance to attempt that.  Given my project resources, think I'll use yours instead!  I'll certainly look at what you've got, and am very interested in future developments!
>
> Thanks,
> -Bob
>
> P.S. By the way, please use rsg at alum.mit.edu for my email address - the 
> other one is obsolete, and somewhat unreliable.
>   
>> Robert,
>>
>> 	Freescale already has u-boot ported for MCF5329. Currently, the
>> u-boot is in test version and the version is not finalized yet until
>> some structures are in place. For example, the tradition way for each
>> processor cpu/m5xxx has repeated serial.c, fec.c, interrupts.c, etc. The
>> new way of structure is to have common generic driver such as
>> drivers/serial/mcfserial.c to share among coldfire family for better
>> portability and easy of use.
>>
>> 	You are welcome to download the test version of u-boot from
>> opensource.freescale.com. However, more changes will be made soon. The
>> current version has uart, flash, timer, rtc, and fec support.
>>
>> 	Here is the link to download the source.
>> http://opensource.freescale.com/git?p=u-boot-coldfire.git;a=tree;h=u-boo
>> t-5329-early;hb=u-boot-5329-early
>>
>> 	I will notify you once the port is final.
>>
>> Regards,
>> TsiChung
>>
>>   
>>     
>
>   

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

[w.wegner at astro-kom.de]

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().

When trying to put the RAM (Mobile DDR in my case) into self-refresh mode and/or setting 
the PLL via LIMP mode, the program crashes. The function itself is copied from the linux 
kernel, but there it is used only with fsys==0, thus bypassing the whole re-setting of the PLL.

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.

Best regards,
Wolfgang

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

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

[Robert S. Grimes]

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

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

[w.wegner at astro-kom.de]

On 27 Jul 2007 at 10:06, Robert S. Grimes wrote:
[...]
> 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? ;-)

I am running on my custom board. The flash is working there, too - the only problem is that 
there are some places in flash where it seems I can only write with U-Boot, not from the BDM 
interface. I have no idea why, but this is why I currently need running from RAM here to flash 
the image...

With the workaround mentioned in the last mail running from RAM works, but depending on 
configuration, the risk is that CPU and/or bus clock are not at the correct values. I can live 
with that, but it would be nice to solve it.
 
Sorry I can?t help you with the CS2 problem!

With the MCF5329 port running on MCF5373L, I also do have another funny problem:
I cannot boot my linux image.
The image is decompressed (taking around 3 times longer than with my old U-Boot port, 
BTW), and when starting the kernel, there is no reaction any more. Again, no idea yet, but I 
will let you know when I find out.

Regards,
Wolfgang

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

[w.wegner at astro-kom.de]

Sorry I can not yet give an answer to why I cannot boot linux with the new coldfire port.
I just found another thing worth thinking about:

In icache_enable (cpu/mcf532x/start.S), the following line should include a mask
in case the SDRAM size is larger than 16MB.

	move.l	#(CFG_SDRAM_BASE + 0xc000), %d0	/* Setup cache mask */

would something like

move.l	#(CFG_SDRAM_BASE + 0xc000 + ((CFG_SDRAM_SIZE & 0x1fe0) << 11)), %d0

do the trick?
(It works for me with CFG_SDRAM_SIZE of 32, but I am not really sure what is done by 
preprocessor and what by assembler)

Regards,
Wolfgang

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

[Liew Tsi Chung-r5aahp]

Wolfgang,

	Check your NOR flash model make sure your flash algorithm able to support -B and -T version, u-boot CFI driver able to configure both model. Also, unlock the Read only bit in u-boot (prot off bank #) before you use the BDM. Some flash will lock itself after reset, if I recall correctly, M5329EVB Intel flash JS28F160C3 is one of them.

IMPORTANT NOTE: Intel flash has a feature that will lock certain block permanently. Make sure not writing to this bit. Otherwise, you have to replace the whole flash.

Regards,
TsiChung



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

On 27 Jul 2007 at 10:06, Robert S. Grimes wrote:
[...]
> 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? ;-)

I am running on my custom board. The flash is working there, too - the only problem is that there are some places in flash where it seems I can only write with U-Boot, not from the BDM interface. I have no idea why, but this is why I currently need running from RAM here to flash the image...

With the workaround mentioned in the last mail running from RAM works, but depending on configuration, the risk is that CPU and/or bus clock are not at the correct values. I can live with that, but it would be nice to solve it.
 
Sorry I can?t help you with the CS2 problem!

With the MCF5329 port running on MCF5373L, I also do have another funny problem:
I cannot boot my linux image.
The image is decompressed (taking around 3 times longer than with my old U-Boot port, BTW), and when starting the kernel, there is no reaction any more. Again, no idea yet, but I will let you know when I find out.

Regards,
Wolfgang

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

[w.wegner at astro-kom.de]

On 27 Jul 2007 at 17:34, Liew Tsi Chung-r5aahp wrote:

> Wolfgang,
> 
> 	Check your NOR flash model make sure your flash algorithm able to support -B and -T version, u-boot CFI driver able to configure both model. Also, unlock the Read only bit in u-boot (prot off bank #) before you use the BDM. Some flash will lock itself after reset, if I recall correctly, M5329EVB Intel flash JS28F160C3 is one of them.
> 
> IMPORTANT NOTE: Intel flash has a feature that will lock certain block permanently. Make sure not writing to this bit. Otherwise, you have to replace the whole flash.
> 
> Regards,
> TsiChung

TsiChung,

thank you for the hint and warning.

I will have a look at it, but from U-Boot, accessing the flash seems to work perfectly (apart 
from writing being slower as with the BDM interface). It is the BDM interface I have problems 
with when writing to certain locations.

Regards,
Wolfgang

[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

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

[Robert S. Grimes]

Liew Tsi Chung-r5aahp wrote:
> 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. 
>   
I'll try it, but I can't before tomorrow.  I'll let you know...
> 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
>
>   

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

[Liew Tsi Chung-r5aahp]

Robert,

	The NAND feature has not implemented in u-boot yet. There are some conflicts. First, CFG_CS2_BASE 0x00800000 should change to 0x0080. Second, even the above was fixed, u-boot was unable to bring up w/wo icache_enable(). Still, trying to trace the issue.

Regards,
TsiChung 

-----Original Message-----
From: Robert S. Grimes [mailto:rsg at alum.mit.edu] 
Sent: Thursday, July 26, 2007 9:54 PM
To: Liew Tsi Chung-r5aahp; Das U-Boot Mailing List
Cc: Wolfgang Wegner
Subject: Re: U-boot for MCF5329

Liew Tsi Chung-r5aahp wrote:
> Robert,
>
> 	Just to let you know that the denx git server now have M5329 support. Please use it for your future development.
>   
Hi TsiChung,

I just downloaded it, and after a couple of silly hiccups, I got it to compile.  However, it did get very far.  I at first thought it was the call to icache_enable() at the end of cpu_init_f(), as gdb always got there, until I temporarily removed it discovered the real culprit.  It was the setup of CS2 for the NAND Flash.  I am 99% sure I have a M5329BFE Fire Engine, as I have the M5329EVB, but it seems something's wrong there.  If I pretent I have the M5329AFE (i.e. no NAND Flash), it works great!  Burned it to NOR and power-cycle - boots right up!

I would like to get the NAND working, though... Any ideas?

Thanks!
-Bob
> 	Thanks,
>
> Regards,
> TsiChung
>  
>
> -----Original Message-----
> From: Robert S. Grimes [mailto:rsg at alum.mit.edu]
> Sent: Tuesday, June 19, 2007 8:08 PM
> To: Liew Tsi Chung-r5aahp
> Subject: Re: U-boot for MCF5329
>
> Liew Tsi Chung-r5aahp wrote
> TsiChung,
>
> That is great news!  I do wish I knew about that earlier!  Of course, I did get a better understanding of both the hMCF5329 and U-Boot, porting it myself.  My port currently works with the m5329evb, and supports the uart, flash, and sdram.  The timer is used for delays, but I'm not sure how thorough it is implemented.  I don't have rtc, the clock PLL is quirky, and I especially miss the fec.  I read up on the Ethernet last Friday, but I hadn't gotten a chance to attempt that.  Given my project resources, think I'll use yours instead!  I'll certainly look at what you've got, and am very interested in future developments!
>
> Thanks,
> -Bob
>
> P.S. By the way, please use rsg at alum.mit.edu for my email address - 
> the other one is obsolete, and somewhat unreliable.
>   
>> Robert,
>>
>> 	Freescale already has u-boot ported for MCF5329. Currently, the 
>> u-boot is in test version and the version is not finalized yet until 
>> some structures are in place. For example, the tradition way for each 
>> processor cpu/m5xxx has repeated serial.c, fec.c, interrupts.c, etc. 
>> The new way of structure is to have common generic driver such as 
>> drivers/serial/mcfserial.c to share among coldfire family for better 
>> portability and easy of use.
>>
>> 	You are welcome to download the test version of u-boot from 
>> opensource.freescale.com. However, more changes will be made soon. 
>> The current version has uart, flash, timer, rtc, and fec support.
>>
>> 	Here is the link to download the source.
>> http://opensource.freescale.com/git?p=u-boot-coldfire.git;a=tree;h=u-
>> boo
>> t-5329-early;hb=u-boot-5329-early
>>
>> 	I will notify you once the port is final.
>>
>> Regards,
>> TsiChung
>>
>>   
>>     
>
>