Stefan,

Are you sure that you need this board specific flash driver? Can't you use the common CFI flash driver? What FLASH chips are used on the board?

There is no speed performance in erasing and reading between common CFI flash driver and board specific flash driver, except programming. CFI flash driver needs ~80s to program 1MB data compare to board specific flash driver needs only ~14s. User has a choice to select them either by define or undef CFG_FLASH_CFI in configuration file. If there is a 8MB flash, it would take about 640s compare to 112s. Big different. I might have missed a define for common flash driver in configuration file that might caused slow programming in flash, if I do please let me know.

Do you think it is needed to create a new CPU directory for this ColdFire family? Or should we rename the old directory and try to merge the files together?

Are the differences that big between the ColdFire families? How much of the code is duplicated now?

I thought of the merging before, but it might get complicated in the long run. As for the assembly, there is not much different between v1, v2, v3, or v4, except some special features such as MMU, MBAR2, etc.

We could do a common and cpu specific directories, such as cpu/coldfire/common, cpu/coldfire/52x2, cpu/coldfire/532x. The code is less duplicated using this method but organized. (532x - 5327, 5328, and 5329) What is your opinion?

How about introducing a new header which will do this CPU architecture include handling. Something like this:

include/asm-m68k/immap.h:

... #ifdef CONFIG_5329 #include <asm/immap_5329.h> #endif ...

And also one for the general defines.

include/asm-m68k/mcf5xxx.h: ... #ifdef CONFIG_5329 #include <asm/m5329.h> #endif ...

Then all files including those headers only need to include those "generic" headers. What do you think?

Originally, the idea came from ATA driver. Anyway, I like yours idea, but two general defines seem duplicate effort. I will make it in one files rather than two.

include/asm-m68k/mcfdefines.h <-- temporary ... $ifdef CONFIG_5329 #include <asm/immap_5329.h> #include <asm/m5329.h> #endif ...

Hmmm. Not sure. I have to admit that I am no expert in the ColdFire FEC and especially not regarding your eval board. But the MII code in mxxxevb.c doesn't look board specific to me. Why do you think it is board specific? And if it really is board specific then please move it into a separate file.

The only function need to separate from the fec's functions is mii_discover_phy(). Each platform might have different ethernet phy, in this case 5329 uses National 83848. Some might use different one - LSI, amd, intel, etc. To minimize the change/update in driver/net/fec.c, supposely, I seperated the the mii_discover_phy() function from fec.c . For quick solution, I moved all mii's functions.

AFIK, there is no EHCI support in U-Boot right now. Do you really plan to support EHCI, or is your USB host controller also OHCI compatible?

Yes. We plan to support EHCI/OTG in u-boot, the module does not have OHCI data structure. The 547x/548x/532x and some freescale powerpc products might have the same EHCI/OTG data structure.

Regards, TsiChung

-----Original Message----- From: Stefan Roese [mailto:sr@denx.de] Sent: Friday, June 22, 2007 12:47 AM To: u-boot-users@lists.sourceforge.net Cc: Liew Tsi Chung-r5aahp; Wolfgang Denk Subject: Re: [U-Boot-Users] U-boot ColdFire development

TsiChung,

On Thursday 21 June 2007, Liew Tsi Chung-r5aahp wrote:

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

Are you sure that you need this board specific flash driver? Can't you use the common CFI flash driver? What FLASH chips are used on the board?

cpu/mcf532x/Makefile config.mk cpu.c cpu_init.c speed.c start.S

Do you think it is needed to create a new CPU directory for this ColdFire family? Or should we rename the old directory and try to merge the files together?

Are the differences that big between the ColdFire families? How much of the code is duplicated now?

drivers/net/mcffec.c drivers/serial/mcfserial.c

Naming this driver mcfserial.c in the serial directory is somewhat redundant. Why not just call it mfc.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

You changed the file modes of Makefile and MAKEALL. Please revert this change.

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?

How about introducing a new header which will do this CPU architecture include handling. Something like this:

include/asm-m68k/immap.h:

... #ifdef CONFIG_5329 #include <asm/immap_5329.h> #endif

#ifdef CONFIG_5272 #include <asm/immap_5272.h> #endif ...

And also one for the general defines.

include/asm-m68k/mcf5xxx.h:

... #ifdef CONFIG_5329 #include <asm/m5329.h> #endif

#ifdef CONFIG_5272 #include <asm/m5272.h> #endif ...

Then all files including those headers only need to include those "generic" headers.

What do you think?

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?

Hmmm. Not sure. I have to admit that I am no expert in the ColdFire FEC and especially not regarding your eval board. But the MII code in mxxxevb.c doesn't look board specific to me. Why do you think it is board specific? And if it really is board specific then please move it into a separate file.

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?

AFIK, there is no EHCI support in U-Boot right now. Do you really plan to support EHCI, or is your USB host controller also OHCI compatible?

Thanks again for your effort.

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 =====================================================================

Detlev,

Ok. I'll remove the board specific flash driver. I misunderstood his intention. I'll see if I can improve the programming time in CFI driver.

Regards, TsiChung

-----Original Message----- From: Detlev Zundel [mailto:dzu@denx.de] Sent: Friday, June 29, 2007 6:56 AM To: Liew Tsi Chung-r5aahp Cc: Stefan Roese; u-boot-users@lists.sourceforge.net; Wolfgang Denk Subject: Re: [U-Boot-Users] U-boot ColdFire development

Hi Liew,

...

Are you sure that you need this board specific flash driver? Can't you use the common CFI flash driver? What FLASH chips are used on the board?

There is no speed performance in erasing and reading between common CFI flash driver and board specific flash driver, except programming. CFI flash driver needs ~80s to program 1MB data compare to board specific flash driver needs only ~14s. User has a choice to select them either by define or undef CFG_FLASH_CFI in configuration file. If

there is a 8MB flash, it would take about 640s compare to 112s. Big different. I might have missed a define for common flash driver in configuration file that might caused slow programming in flash, if I

do please let me know.

I think Stefans intention of the question was a little bit different. For the maintainability of U-Boot we should strive to share as many code as possible between different boards, so for quite sometime now we generally(*) encourage people to use the CFI driver in order to achieve this goal.

I am not at all convinced that even a factor of two in programming times can compensate for the added complexity of Yet Another Custom Flash Driver.

What would really be interesting is to find out why the CFI driver is slower. I think fixing this will be a much more worthwhile contribution to U-Boot as a whole.

Thanks Detlev

(*) Wolfgang happily allows exceptions for resource limited setups.

-- A statistician can have his head in an oven and his feet in ice, and he will say that on the average he feels fine. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de

Hi TsiChung,

On Saturday 30 June 2007, Wolfgang Denk wrote:

...

There is no speed performance in erasing and reading between common CFI flash driver and board specific flash driver, except programming. CFI flash driver needs ~80s to program 1MB data compare to board specific flash driver needs only ~14s. User has a choice to select them either by

Are you absolutely sure about this? Did you enable CFG_FLASH_USE_BUFFER_WRITE in your board config file?

If yes, then can you please try to explain *why* there is such a speed difference? In general, the CFI driver should be able to do exactly the same what a custom flash driver can do - if there is anything missing, it should be added. Patches welcome.

Yes, I would expect when the write buffering is enabled (Wolfgang mentioned the config option above) the programming speed should be the same to your board specific driver.

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 TsiChung,

On Tuesday 03 July 2007, Liew Tsi Chung-r5aahp wrote:

The CFG_FLASH_USE_BUFFER_WRITE does not help in this case because the intel flash chip on M5329EVB does not support Buffer Write. (It could be verified by reading the CFI at offset 0x2a)

Which chips is it? Just curious.

I were doing an experiment days ago by redirected some of the CFI driver functions to board specific flash driver functions. I replaced flash_write_cfiword() in write_buff() to write_data(). Program the flash for 1MB. flash_add_byte() is ~5s more than total time in board specific flash driver. Replaced the write_data() flash status check in while loop - while ((*addr & (u16) FLASH_STATUS_DONE) != (u16) FLASH_STATUS_DONE) to while(!flash_isset (info, sec, 0, FLASH_STATUS_DONE)), this will add another ~11s.

Seems there is some need to enhance the CFI driver. Unfortunately we don't have an custodian for this anymore.

There are some overhead in the CFI flash driver for non Buffer Write. Anyway, I am going to use the CFI flash driver from now on.

Thanks. We should keep in mind to address you thoughts about speed improvement later.

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 =====================================================================