[U-Boot-Users] U-boot ColdFire development

[U-Boot-Users] U-boot ColdFire development

[Liew Tsi Chung-r5aahp]

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

[U-Boot-Users] U-boot ColdFire development

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot-Users] U-boot ColdFire development

[Liew Tsi Chung-r5aahp]

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 at denx.de] 
Sent: Friday, June 22, 2007 12:47 AM
To: u-boot-users at 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 at denx.de
=====================================================================

[U-Boot-Users] U-boot ColdFire development

[Detlev Zundel]

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 at denx.de

[U-Boot-Users] U-boot ColdFire development

[Liew Tsi Chung-r5aahp]

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 at denx.de] 
Sent: Friday, June 29, 2007 6:56 AM
To: Liew Tsi Chung-r5aahp
Cc: Stefan Roese; u-boot-users at 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 at denx.de

[U-Boot-Users] U-boot ColdFire development

[Wolfgang Denk]

Dear Liew Tsi Chung,

in message <4791E710007FEB4BBF83775D787F462F047A3F6C@az33exm22.fsl.freescale.net> you 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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"When people are least sure, they are often most dogmatic."
- John Kenneth Galbraith

[U-Boot-Users] U-boot ColdFire development

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot-Users] U-boot ColdFire development

[Liew Tsi Chung-r5aahp]

Wolfgang, Stefan and Detlev,

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)

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.

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.

Again. Thanks for yours help and comments.

Regards,
TsiChung

-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: Tuesday, July 03, 2007 3:54 AM
To: Liew Tsi Chung-r5aahp
Cc: Wolfgang Denk; u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] U-boot ColdFire development

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 at denx.de =====================================================================

[U-Boot-Users] U-boot ColdFire development

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot-Users] U-boot ColdFire development

[Liew Tsi Chung-r5aahp]

Stefan,

	The flash chips are Intel JS28F160 (2MiB), JS28F320 (4MiB) and JS28F640 (8MiB). 

Regards,
TsiChung

-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: Wednesday, July 04, 2007 1:21 AM
To: u-boot-users at lists.sourceforge.net
Cc: Liew Tsi Chung-r5aahp; Wolfgang Denk; Detlev Zundel
Subject: Re: [U-Boot-Users] U-boot ColdFire development

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 at denx.de =====================================================================

[U-Boot-Users] U-boot ColdFire development

[Liew Tsi Chung-r5aahp]

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

[U-Boot-Users] U-boot ColdFire development

[Stefan Roese]

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

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 at denx.de
=====================================================================

[U-Boot-Users] U-boot ColdFire development

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot-Users] U-boot ColdFire development

[Liew Tsi Chung-r5aahp]

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 at denx.de] 
Sent: Friday, July 20, 2007 7:32 AM
To: u-boot-users at 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 at denx.de =====================================================================

[U-Boot-Users] U-boot ColdFire development

[w.wegner at astro-kom.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

[U-Boot-Users] U-boot ColdFire development

[Liew Tsi Chung-r5aahp]

> 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 at lists.sourceforge.net] On Behalf Of w.wegner at astro-kom.de
Sent: Wednesday, July 25, 2007 10:54 AM
To: Stefan Roese; u-boot-users at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] U-boot ColdFire development

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot-Users] U-boot ColdFire development

[Liew Tsi Chung-r5aahp]

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 at denx.de] 
Sent: Thursday, July 26, 2007 11:51 PM
To: u-boot-users at lists.sourceforge.net
Cc: Liew Tsi Chung-r5aahp; w.wegner at 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 at denx.de =====================================================================

[U-Boot-Users] U-boot ColdFire development

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot-Users] U-boot ColdFire development

[w.wegner at astro-kom.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

[U-Boot-Users] U-boot ColdFire development

[w.wegner at astro-kom.de]

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