[U-Boot] UBI problems on current u-boot

[Holger Brunck]

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