[U-Boot-Users] ARM VersatilePB - Fixed flash support

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Philippe Robin]

Greetings,

I have attached a patch fixing flash support with Versatile Boards:

CHANGELOG Entry:

* Patch by Philippe Robin, 28 Sept 2004:
  - Fix Flash support for Versatile.

Regards,
Philippe


-------------- next part --------------
A non-text attachment was scrubbed...
Name: versatile-flash.patch.gz
Type: application/x-gzip
Size: 2319 bytes
Desc: versatile-flash.patch.gz
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040928/5abdde82/attachment.bin 

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Wolfgang Denk]

In message <89A528FE6DB0FA44877BB2F05B84671801285A97@ZIPPY.Emea.Arm.com> you wrote:
> 
> * Patch by Philippe Robin, 28 Sept 2004:
>   - Fix Flash support for Versatile.

Added, thanks.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Always leave room to add an explanation if it doesn't work out.

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Shawn]

The current flash support for Integrator CP supports only one flash
type 28F256L18T. However the flash on the CP board we recently bought
is 28F640J3C. I ported flash.c to support this type of flash. If you'd
like, I'll post the patch.

One issue I've encoutered is flash write timeout of a big chunk of
data (> 128KB). Write always times out no matter how big the value of
CFG_FLASH_WRITE_TOUT is. The issue hasn't been solved yet. Any hints
are appreciated.

-Shawn.

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Philippe Robin]

> -----Original Message-----
> From: Shawn [mailto:shawnxjin at gmail.com] 
> Sent: 12 October 2004 00:21
> To: Philippe Robin
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] ARM VersatilePB - Fixed flash support
> 
> The current flash support for Integrator CP supports only one 
> flash type 28F256L18T. However the flash on the CP board we 
> recently bought is 28F640J3C. I ported flash.c to support 
> this type of flash. If you'd like, I'll post the patch.

Yes please. The flash.c was cut and paste and needed to be fixed. The
flash part is indeed a 28F640J3C. 

> One issue I've encoutered is flash write timeout of a big 
> chunk of data (> 128KB). Write always times out no matter how 
> big the value of CFG_FLASH_WRITE_TOUT is. The issue hasn't 
> been solved yet. Any hints are appreciated.

I will have a go with your code on my board once you've posted it. I
checked here with the tools we use and we have not had this problem with
that board.

Thanks,
Philippe

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Shawn]

> Yes please. The flash.c was cut and paste and needed to be fixed. The
> flash part is indeed a 28F640J3C.

So 28F256L18T is not a flash part on CP board? If that's the case I
can remove all its stuff from flash.c.

-Shawn.

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Philippe Robin]

Shawn,

> One issue I've encoutered is flash write timeout of a big 
> chunk of data (> 128KB). Write always times out no matter how 
> big the value of CFG_FLASH_WRITE_TOUT is. The issue hasn't 
> been solved yet. Any hints are appreciated.

I have tried with removing the test for timeout in the write_data()
routine, just looping on the status:

    while (((status = *addr) & (FPW) 0x00800080) != (FPW) 0x00800080) ;

This worked fine for large amounts of data so the timeout value is
probably too low. Let me know if this is the same with your setting.

Regards,
Philippe

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Shawn]

Philippe,

> > One issue I've encoutered is flash write timeout of a big
> > chunk of data (> 128KB). Write always times out no matter how
> > big the value of CFG_FLASH_WRITE_TOUT is. The issue hasn't
> > been solved yet. Any hints are appreciated.
> 
> I have tried with removing the test for timeout in the write_data()
> routine, just looping on the status:
> 
>    while (((status = *addr) & (FPW) 0x00800080) != (FPW) 0x00800080) ;
> 
> This worked fine for large amounts of data so the timeout value is
> probably too low. Let me know if this is the same with your setting.

Good try. I'm not sure if this is a decent fix. It's possible that
Flash write gets stuck in while loop if there is a real problem. It
may be other factor(s) that cause this problem. For example, timer is
not accurate?

Best regards,
-Shawn.

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Wolfgang Denk]

In message <c3d0340b04101409512a20b628@mail.gmail.com> you wrote:
> 
> >    while (((status = *addr) & (FPW) 0x00800080) != (FPW) 0x00800080) ;
> > 
> > This worked fine for large amounts of data so the timeout value is
> > probably too low. Let me know if this is the same with your setting.
> 
> Good try. I'm not sure if this is a decent fix. It's possible that

It is not a proper fix, as it might hang the board  without  even  an
error message.

> Flash write gets stuck in while loop if there is a real problem. It
> may be other factor(s) that cause this problem. For example, timer is
> not accurate?

This is one  possible  explanation.  Check  timer  implementation.  I
noticed  that  quite  a  lot  of  boards use insane values of CFG_HZ.
Remember that this should be the  number  of  clock  ticks  (=  timer
interrupts)  per  second,  and  there  is  usually no reason to chose
anything else but the default value of 1000.  Many  boards  use  some
much,  much  higher  clock  values instead. This should be fixed. [We
recently fixed this for AT91RM9200 systems.]

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any sufficiently advanced technology is indistinguishable from magic.
                                                   - Arthur C. Clarke

[U-Boot-Users] CFG_HZ and get_timer() issue

[Shawn]

Wolfgang,

> > Flash write gets stuck in while loop if there is a real problem. It
> > may be other factor(s) that cause this problem. For example, timer is
> > not accurate?
> 
> This is one  possible  explanation.  Check  timer  implementation.  I
> noticed  that  quite  a  lot  of  boards use insane values of CFG_HZ.
> Remember that this should be the  number  of  clock  ticks  (=  timer
> interrupts)  per  second,  and  there  is  usually no reason to chose
> anything else but the default value of 1000.  Many  boards  use  some
> much,  much  higher  clock  values instead. This should be fixed. [We
> recently fixed this for AT91RM9200 systems.]

It seems that people easily get confused about what CFG_HZ should be.
A grep of CFG_HZ finds that many ARM boards (of course, some other
boards) don't interpret CFG_HZ or clock ticks in the way as you did
above. Studying your fix for AT91RM9200 systems finds out your newly
introduced get_timer_raw() function. So now we have a few functions
get_timer(), get_timer_masked(), and get_timer_raw(). I noticed that
some people called get_timer_masked() directly and other used
get_timer() in a loop to determine the timeout of some actions.

Shall we have a rule to guide where and when these functions should be used?

To my understanding based on your fix for AT91RM9200 systems,
1. get_timer_maksed() should return the number of clock ticks, just as
get_ticks().
2. get_timer_raw() returns the value of timestamp, which counts how
many clocks elapse according to the timer's setting. It'a local
function and should not be called in any other modules.

Regards,
-Shawn.

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Wolfgang Denk]

In message <c3d0340b0410111620498f967b@mail.gmail.com> you wrote:
> The current flash support for Integrator CP supports only one flash
> type 28F256L18T. However the flash on the CP board we recently bought
> is 28F640J3C. I ported flash.c to support this type of flash. If you'd
> like, I'll post the patch.

Was there a final patch posted to the list? I can't find one.

> One issue I've encoutered is flash write timeout of a big chunk of
> data (> 128KB). Write always times out no matter how big the value of
> CFG_FLASH_WRITE_TOUT is. The issue hasn't been solved yet. Any hints
> are appreciated.

Make sure to use reset_timer_masked() and get_timer_masked()  instead
of get_timer(0) / get_timer(start).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I have been over into the future, and it works.
                - Lincoln Steffens in _Letters_ (1938) vol. 1, p. 463

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Shawn Jin]

Wolfgang,

> > The current flash support for Integrator CP supports only one flash
> > type 28F256L18T. However the flash on the CP board we recently bought
> > is 28F640J3C. I ported flash.c to support this type of flash. If you'd
> > like, I'll post the patch.
> 
> Was there a final patch posted to the list? I can't find one.

It's fixed in my patch posted on Dec. 20, 2004. And also I got
confirmation from Philippe that the fix of CFG_HZ issue for ARM926EJS
works.

> Make sure to use reset_timer_masked() and get_timer_masked()  instead
> of get_timer(0) / get_timer(start).

They are used in the patch.

Regards,
-Shawn.

[U-Boot-Users] ARM VersatilePB - Fixed flash support

[Shawn Jin]

> > Was there a final patch posted to the list? I can't find one.
> 
> It's fixed in my patch posted on Dec. 20, 2004. And also I got
> confirmation from Philippe that the fix of CFG_HZ issue for ARM926EJS
> works.

Sorry. Misunderstood what Philippe said to me. He hasn't validated the
fix for ARM926 yet. We can wait for his confirmation.

> Thanks for your contribution. We will validate this for the ARM926 and
> confirm back to you and the list so that this can get integrated.

-Shawn.

[U-Boot-Users] CFG_HZ and get_timer() issue

[Wolfgang Denk]

Dear Shawn,

sorry for the long delay.

In message <c3d0340b04101516017ab281a5@mail.gmail.com> you wrote:
> 
> Shall we have a rule to guide where and when these functions should be used?

Ye. Please feel free to submit a patch to document this.

> To my understanding based on your fix for AT91RM9200 systems,
> 1. get_timer_maksed() should return the number of clock ticks, just as
> get_ticks().
> 2. get_timer_raw() returns the value of timestamp, which counts how
> many clocks elapse according to the timer's setting. It'a local
> function and should not be called in any other modules.

Indeed. And ideally we should get rid of get_timer_masked() and  make
get_timer() work as expected.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Include the success of others in your dreams for your own success.