RE: [U-Boot-Users] ARM VersatilePB - Fixed flash support
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
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.
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
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.
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,
- 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
participants (3)
-
Philippe Robin -
Shawn -
Wolfgang Denk