Re: [U-Boot-Users] 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@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@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
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
w.wegner@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
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
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
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@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@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
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
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@alum.mit.edu] Sent: Friday, July 27, 2007 9:06 AM To: w.wegner@astro-kom.de Cc: Liew Tsi Chung-r5aahp; Das U-Boot Mailing List Subject: Re: [U-Boot-Users] U-boot for MCF5329
w.wegner@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
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@alum.mit.edu] Sent: Friday, July 27, 2007 9:06 AM To: w.wegner@astro-kom.de Cc: Liew Tsi Chung-r5aahp; Das U-Boot Mailing List Subject: Re: [U-Boot-Users] U-boot for MCF5329
w.wegner@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
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@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@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@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
participants (3)
-
Liew Tsi Chung-r5aahp -
Robert S. Grimes -
w.wegner＠astro-kom.de