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

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