Re: [U-Boot-Users] U-boot ColdFire development
Stefan,
I made some update on the 5329. We need to get started on migrating the mcf52x2 as soon as possible.
1. Files that use <asm/immap_5329.h> and <asm/m5329.h> were replaced to <asm/immap.h>. 2. CPU/ARCH specific defines are placed in include/asm/immap.h 3. drivers/serial/mcfserial.c renamed to drivers/serial/mcfuart.c. I want to keep it that way so that it won't mix up with other uarts drivers. 4. rtc/rtc.c renamed to rtc/mcfrtc.c, same reason as no. 3 5. cache_enable() moved from cpu_init_r() to cpu_init_f() for fast allocation 6. used generic cfi driver 7. Will keep the cpu folder for each family. Certain CPU has different cache and speed configuration. 8. MII will still be placed in board/xxxx/mii.c
http://opensource.freescale.com/git?p=u-boot-coldfire.git;a=summary
Regards, TsiChung
-----Original Message----- From: Liew Tsi Chung-r5aahp Sent: Thursday, June 21, 2007 8:53 AM To: Stefan Roese Cc: Wolfgang Denk; u-boot-users@lists.sourceforge.net Subject: RE: U-boot ColdFire development
Stefan,
Here is the test version for 5329 u-boot source at Freescale. http://opensource.freescale.com/git?p=u-boot-coldfire.git;a=summary
Added: board/freescale/M5329EVB/Makefile config.mk flash.c m5329evb.c and u-boot.lds cpu/mcf532x/Makefile config.mk cpu.c cpu_init.c speed.c start.S drivers/net/mcffec.c drivers/serial/mcfserial.c include/asm-m68k/immap_5329.h m5329.h mcfrtc.h include/configs/M5329EVB.h lib_m68k/interrupts.c rtc/rtc.c
Modified: Makefile MAKEALL README common/cmd_bdinfo.c cmd_mii.c include/asm-m68k/byteorder.h fec.h io.h mcftimer.h mcfuart.h ptrace.h u-boot.h lib_m68k/board.c time.c
I had placed the mcfserial.c under drivers/serial and mcffec.c under drivers/net. The rtc.c is under rtc/.
1. I do have one more doubt about placing the following defines as we discussed early.
/* Timer */ #define CONFIG_MCFTMR #ifdef CONFIG_MCFTMR # define CFG_UDELAY_BASE (0xFC070000) # define CFG_TMR_BASE (0xFC074000) # define CFG_INTR_BASE (0xFC048000) # define CFG_TMRINTR_NO (32) # define CFG_TMRINTR_MASK (1) #endif
If I place the #ifdef CONFIG_MCFTMR ... #endif in say immap_5329.h, isn't that in time.c must include <asm/immap_5329.h>.
Time.c #ifdef CONFIG_5329 #include <asm/immap_5329.h> #endif
#ifdef CONFIG_5272 #include <asm/immap_5272.h> #endif ...
Is there a way not to include <asm/immap_5xxx.h> in time.c each time a new processor is added?
2. I seperated the MII feature from fec.c and placed in under board/freescale/mxxxevb.c. Since the mii phy is board dependent not cpu dependent, do you agree?
3. EHCI/OTG driver development. Do I need to modify the current cmd_usb.c to include EHCI or create a new file cmd_hsusb.c?
Regards, TsiChung
TsiChung,
On Wednesday 11 July 2007, Liew Tsi Chung-r5aahp wrote:
I made some update on the 5329. We need to get started on migrating the mcf52x2 as soon as possible.
- Files that use <asm/immap_5329.h> and <asm/m5329.h> were replaced to
<asm/immap.h>. 2. CPU/ARCH specific defines are placed in include/asm/immap.h 3. drivers/serial/mcfserial.c renamed to drivers/serial/mcfuart.c. I want to keep it that way so that it won't mix up with other uarts drivers. 4. rtc/rtc.c renamed to rtc/mcfrtc.c, same reason as no. 3 5. cache_enable() moved from cpu_init_r() to cpu_init_f() for fast allocation 6. used generic cfi driver 7. Will keep the cpu folder for each family. Certain CPU has different cache and speed configuration. 8. MII will still be placed in board/xxxx/mii.c
http://opensource.freescale.com/git?p=u-boot-coldfire.git;a=summary
Thanks. Looks very promising. All ColdFire users out there, please take a look at it and send comments. If I don't hear anything negative, I'll merge the repository into the u-boot-coldfire repository soon.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
On Thursday 12 July 2007, Stefan Roese wrote:
http://opensource.freescale.com/git?p=u-boot-coldfire.git;a=summary
Thanks. Looks very promising. All ColdFire users out there, please take a look at it and send comments. If I don't hear anything negative, I'll merge the repository into the u-boot-coldfire repository soon.
The merge is now done. It's now available in the u-boot-coldfire repository. Please give it a try and let me know if you see any problems.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Stefan,
Thanks for the update.
I will start working on some the 52x2 platforms. Unless, you already started working on it. If you do, please let me know.
Regards, TsiChung
-----Original Message----- From: Stefan Roese [mailto:sr@denx.de] Sent: Friday, July 20, 2007 7:32 AM To: u-boot-users@lists.sourceforge.net Cc: Wolfgang Denk; Liew Tsi Chung-r5aahp Subject: Re: [U-Boot-Users] U-boot ColdFire development
On Thursday 12 July 2007, Stefan Roese wrote:
http://opensource.freescale.com/git?p=u-boot-coldfire.git;a=summary
Thanks. Looks very promising. All ColdFire users out there, please take a look at it and send comments. If I don't hear anything negative, I'll merge the repository into the u-boot-coldfire repository soon.
The merge is now done. It's now available in the u-boot-coldfire repository. Please give it a try and let me know if you see any problems.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hi, On 20 Jul 2007 at 14:31, Stefan Roese wrote:
On Thursday 12 July 2007, Stefan Roese wrote:
http://opensource.freescale.com/git?p=u-boot-coldfire.git;a=summary
Thanks. Looks very promising. All ColdFire users out there, please take a look at it and send comments. If I don't hear anything negative, I'll merge the repository into the u-boot-coldfire repository soon.
The merge is now done. It's now available in the u-boot-coldfire repository. Please give it a try and let me know if you see any problems.
Thanks.
After struggling with git again to get the correct tree, I finally could get the source but am still struggling to get it ported to my board. As I do not know when this will be done, here my comments "during porting".
First: the cleaned-up immap_5329.h and m5329.h look very nice! (although I think naming all registers according to their naming in the data sheet would make things easier - I am talking about SDRAM controller here, and e.g. GPIO ppdsdr)
However, I also have some comments:
First, I still think it would be possible to put together MCF532x and MCF537x into one source tree (and header files), as they only differ in some peripherals being present or not. TsiChung, you mentioned there are differences in cache handling - I can not find those? Please note that MCF5307 is indeed completely different, I am not relating to this one! In case we do so, the cpu "id" in cpu/mcf532x/cpu.c should be changed, because we would have to distinguish MCF5372/MCF5372L and MCF5373/MCF5373L.
Then, concerning UART: - is CFG_UART_PORT (in cpu_init.c) meant to be there? Configurable console port is great, I need it myself, but shouldn´t it be named CONFIG_CONSOLE_PORT or something? - is it useful to have the GPIO part of UART configuration in cpu_init.c? IIRC the console port should be changeable from the environment, then the GPIO setting for the UART should be in mcfuart, or at least somewhere accessible from there - why do we need #ifdef CONFIG_MCFSERIAL in mcfuart.c? - IMHO the GPIO initialization for UART3 is incorrect in cpu_init.c. This should be case 2: gpio->par_timer &= 0x0F; gpio->par_timer |= (GPIO_PAR_TIN3_URXD2 | GPIO_PAR_TIN2_UTXD2);
For the sync() function (needed for CFI): is it useful to have it for each board, or shouldn´t this be handled somewhere in lib_m68k?
in cpu/mcf532x/Makefile, should START = be START = start.o for start.o being correctly re-made if needed?
What is the sense of having CFG_SDRAM_CFG1 and all this stuff defined in the configuration file when you have the SDRAM configuration itself in the board-specific source code? In case of switching between DDR/SDR or mobile DDR you have to change the initialization sequence anyways...
Last but not least, there is a missing #endif at the bottom of mcfuart.h?!
I hope I got most of it correct now. Any comments welcome!
Best regards, Wolfgang
is CFG_UART_PORT (in cpu_init.c) meant to be there? Configurable console port is great, I need it myself, but shouldn´t it be named CONFIG_CONSOLE_PORT or something?
Cannot have too generic name like CONFIG_CONSOLE_PORT. To avoid confusion with others, CFG_UART_PORT is good so far.
is it useful to have the GPIO part of UART configuration in cpu_init.c? IIRC the console port should be changeable from the environment, then the GPIO setting for the UART should be in mcfuart, or at least somewhere accessible from there
The mcfuart.c not only use for mcf532x or mcf527x but it also use for mcf547x, mcf548x, mcf52x2, etc. Making gpio init to be part of mcfuart.c, isn't that have to change the file if new platform is added? Unless, you are suggesting such as port_configuration() in mcfuart.c but the actual function is in cpu_init.c something like that? Well, this work for me. And, no environment settings for UART gpio, if the environment value some how corrupted or erased, user will have to use P&E to reprogram.
why do we need #ifdef CONFIG_MCFSERIAL in mcfuart.c?
Same reason with ns16550 driver (drivers/ns16550.c). Note: The CONFIG_MCFSERIAL has renamed to CONFIG_MCFUART. Double declaration in configuration file. #define CONFIG_MCFSERIAL and #define CONFIG_MCFUART.
gpio->par_timer &= 0x0F; gpio->par_timer |= (GPIO_PAR_TIN3_URXD2 | GPIO_PAR_TIN2_UTXD2);
The TIN out/in is actually transmit/receive signal from these pins. I don't think the u-boot will ever use it, anyware I will change it.
For the sync() function (needed for CFI): is it useful to have it for each board, or shouldn´t this be handled somewhere in lib_m68k?
Have not looked deep into the CFI driver code to see there is a need for it. If there is no need for it, it will be removed.
START = start.o
Thanks for pointing out
Last but not least, there is a missing #endif at the bottom of mcfuart.h?!
I don't see a missing #endif. It is there!
Regards, TsiChung
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of w.wegner@astro-kom.de Sent: Wednesday, July 25, 2007 10:54 AM To: Stefan Roese; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] U-boot ColdFire development
Hi, On 20 Jul 2007 at 14:31, Stefan Roese wrote:
On Thursday 12 July 2007, Stefan Roese wrote:
http://opensource.freescale.com/git?p=u-boot-coldfire.git;a=summar y
Thanks. Looks very promising. All ColdFire users out there, please take a look at it and send comments. If I don't hear anything negative, I'll merge the repository into the u-boot-coldfire repository soon.
The merge is now done. It's now available in the u-boot-coldfire repository. Please give it a try and let me know if you see any problems.
Thanks.
After struggling with git again to get the correct tree, I finally could get the source but am still struggling to get it ported to my board. As I do not know when this will be done, here my comments "during porting".
First: the cleaned-up immap_5329.h and m5329.h look very nice! (although I think naming all registers according to their naming in the data sheet would make things easier - I am talking about SDRAM controller here, and e.g. GPIO ppdsdr)
However, I also have some comments:
First, I still think it would be possible to put together MCF532x and MCF537x into one source tree (and header files), as they only differ in some peripherals being present or not. TsiChung, you mentioned there are differences in cache handling - I can not find those? Please note that MCF5307 is indeed completely different, I am not relating to this one! In case we do so, the cpu "id" in cpu/mcf532x/cpu.c should be changed, because we would have to distinguish MCF5372/MCF5372L and MCF5373/MCF5373L.
Then, concerning UART: - is CFG_UART_PORT (in cpu_init.c) meant to be there? Configurable console port is great, I need it myself, but shouldn´t it be named CONFIG_CONSOLE_PORT or something? - is it useful to have the GPIO part of UART configuration in cpu_init.c? IIRC the console port should be changeable from the environment, then the GPIO setting for the UART should be in mcfuart, or at least somewhere accessible from there - why do we need #ifdef CONFIG_MCFSERIAL in mcfuart.c? - IMHO the GPIO initialization for UART3 is incorrect in cpu_init.c. This should be case 2: gpio->par_timer &= 0x0F; gpio->par_timer |= (GPIO_PAR_TIN3_URXD2 | GPIO_PAR_TIN2_UTXD2);
For the sync() function (needed for CFI): is it useful to have it for each board, or shouldn´t this be handled somewhere in lib_m68k?
in cpu/mcf532x/Makefile, should START = be START = start.o for start.o being correctly re-made if needed?
What is the sense of having CFG_SDRAM_CFG1 and all this stuff defined in the configuration file when you have the SDRAM configuration itself in the board-specific source code? In case of switching between DDR/SDR or mobile DDR you have to change the initialization sequence anyways...
Last but not least, there is a missing #endif at the bottom of mcfuart.h?!
I hope I got most of it correct now. Any comments welcome!
Best regards, Wolfgang
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
TsiChung,
On Friday 27 July 2007, Liew Tsi Chung-r5aahp wrote:
For the sync() function (needed for CFI): is it useful to have it for each board, or shouldn´t this be handled somewhere in lib_m68k?
Have not looked deep into the CFI driver code to see there is a need for it. If there is no need for it, it will be removed.
The sync() in the CFI driver *is* needed. At least on some architectures. Please move the definition of sync() from the board specific file to the common header include/asm-m68k/io.h to something like this:
static inline void sync(void) { /* * Not needed on ColdFire architecture * Added for compatibility reasons (CFI driver...) */ }
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Stefan and Wolfgang,
Sorry about previous statement. I meant is exclude it from built but still able to build it if it is not CF.
... #ifndef __M68K__ sync(); #endif ...
Anyway, the inline in io.h works too! :)
Regards, TsiChung
-----Original Message----- From: Stefan Roese [mailto:sr@denx.de] Sent: Thursday, July 26, 2007 11:51 PM To: u-boot-users@lists.sourceforge.net Cc: Liew Tsi Chung-r5aahp; w.wegner@astro-kom.de Subject: Re: [U-Boot-Users] U-boot ColdFire development
TsiChung,
On Friday 27 July 2007, Liew Tsi Chung-r5aahp wrote:
For the sync() function (needed for CFI): is it useful to have it for each board, or shouldn´t this be handled somewhere in lib_m68k?
Have not looked deep into the CFI driver code to see there is a need for it. If there is no need for it, it will be removed.
The sync() in the CFI driver *is* needed. At least on some architectures. Please move the definition of sync() from the board specific file to the common header include/asm-m68k/io.h to something like this:
static inline void sync(void) { /* * Not needed on ColdFire architecture * Added for compatibility reasons (CFI driver...) */ }
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
TsiChung,
On Friday 27 July 2007, Liew Tsi Chung-r5aahp wrote:
Sorry about previous statement. I meant is exclude it from built but still able to build it if it is not CF.
... #ifndef __M68K__ sync(); #endif ...
Sure. I understand. But please don't do it this way, since this will bring us (again) more #ifdef's.
Anyway, the inline in io.h works too! :)
Yes, this is the way to go. Please implement this change.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
On 26 Jul 2007 at 17:39, Liew Tsi Chung-r5aahp wrote:
is CFG_UART_PORT (in cpu_init.c) meant to be there? Configurable console port is great, I need it myself, but shouldn´t it be named CONFIG_CONSOLE_PORT or something?
Cannot have too generic name like CONFIG_CONSOLE_PORT. To avoid confusion with others, CFG_UART_PORT is good so far.
OK, was just an idea.
is it useful to have the GPIO part of UART configuration in cpu_init.c? IIRC the console port should be changeable from the environment, then the GPIO setting for the UART should be in mcfuart, or at least somewhere accessible from there
The mcfuart.c not only use for mcf532x or mcf527x but it also use for mcf547x, mcf548x, mcf52x2, etc. Making gpio init to be part of mcfuart.c, isn't that have to change the file if new platform is
added? Unless, you are suggesting such as port_configuration() in mcfuart.c but the actual function is in cpu_init.c something like that? Well, this work for me. And, no environment settings for UART gpio, if the environment value some how corrupted or erased, user will have to use P&E to reprogram.
Maybe others more into basic U-Boot concept should comment here. The solution with port_configuration() in cpu_init.c looks perfect to me, though.
why do we need #ifdef CONFIG_MCFSERIAL in mcfuart.c?
Same reason with ns16550 driver (drivers/ns16550.c). Note: The CONFIG_MCFSERIAL has renamed to CONFIG_MCFUART. Double declaration in configuration file. #define CONFIG_MCFSERIAL and #define CONFIG_MCFUART.
Thanks. I thought the architecture would already be sufficient to compile the correct driver, such that there does not have to be an additional #ifdef in that driver. I will think about it once more. ;-)
gpio->par_timer &= 0x0F; gpio->par_timer |= (GPIO_PAR_TIN3_URXD2 | GPIO_PAR_TIN2_UTXD2);
The TIN out/in is actually transmit/receive signal from these pins. I don't think the u-boot will ever use it, anyware I will change it.
Before, there was gpio->par_uart accessed instead of gpio->par_timer. The "&=" was just additional security.
[CFI already answered by Stefan]
Last but not least, there is a missing #endif at the bottom of mcfuart.h?!
I don't see a missing #endif. It is there!
Funny. It was definitely missing before I first opened mcfuart.h, giving me a compiler parse error. Seems I still have some git problems?!
Regards, TsiChung
Regards, Wolfgang
Hi,
I just found another potential problem with the MCF532x/537x port.
In speed.c, there is currently no handling for CONFIG_MONITOR_IS_IN_RAM. Additionally, the order of the SDRAM controller workaround and re-enabling RAM has to be changed like this according to the freescale errata document:
/* software workaround for SDRAM opeartion after exiting LIMP mode errata */ *sdram_workaround = CFG_SDRAM_BASE;
/* * Return the SDRAM to normal operation if it is in use. */
I am currently trying to work out the SDRAM self-refresh code so I can contribute it here.
(With the modifications from the last email, I have parts of the new coldfire u-boot already running. However, I still have problems with this PLL code - probably because I am running from RAM at the moment- and with env_init, of which I did not yet further investigate the latter.)
Regards, Wolfgang
participants (3)
-
Liew Tsi Chung-r5aahp -
Stefan Roese -
w.wegner＠astro-kom.de