On 09/13/2011 05:31 PM, Holger Brunck wrote:
On 09/13/2011 10:37 AM, Stefan Roese wrote:
On Tuesday 13 September 2011 10:32:34 Holger Brunck wrote:
But this patch is not easy to port onto u-boot because previously undergoing changes in the kernels ubi layer...
Correct. UBI has undergone many changes since the integration into U-Boot back in the end of 2008 (nearly 3 years ago now). Perhaps the best would be to re- synch with the latest Linux UBI version. But this sounds like quite a lot of work as well...
if found a way to port only this patch.
Good. :)
But I had to do some changes to it. E.g. exchange the constants for errors with numeric values as present in u-boots ubi version. And remove setting of the constants (MOVE_TARGET_RD_ERR) values which are not evaluated in u-boots ubi version. This fixes my problem. Should I post this patch?
Yes, please do.
argh, I realized that in my working branch I had your patch "UBI: Ensure that "background thread" operations are really executed" was still reverted. And after removing this revert, I had the same problems as before...
So there is another problem present and I currently don't find the reason why...
I have finished my investigations here. My patch mentioned above was not the solution for the problem. What really fixed my problem was to revert this "UBI: Ensure that "background thread" operations are really executed".
The reason is that the UBI layer assumes that these "background threads" are executed after the task who scheduled the "thread" was finished. U-boot gets stuck during calling ubi_wl_init_scan(ubi, si). The problem here is that now if a bitflip was detected in the linux implementation a background thread was started to schedule an erase for this PEB. In the current u-boot implementation this is done immediately and this is a problem because some needed datas aren't initialized at this stage. So reverting this commit fixes the problem for me.
Best regards Holger