From mboxrd@z Thu Jan  1 00:00:00 1970
From: Holger Brunck <holger.brunck@keymile.com>
Date: Thu, 20 Dec 2012 13:44:03 +0100
Subject: [U-Boot] Bricked when trying to attach UBI
In-Reply-To: <50D1FB46.9000209@comelit.it>
References: <50D1A4C2.6020207@comelit.it> <50D1DC30.1060701@gmail.com>
	<50D1E3AD.30208@comelit.it> <50D1E6BF.9090407@gmail.com>
	<50D1FB46.9000209@comelit.it>
Message-ID: <50D30813.9080905@keymile.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Luca,

On 12/19/2012 06:37 PM, Luca Ceresoli wrote:
> I had some days ago, but I double-checked now as you suggested. Indeed
> there is an important difference: attach_by_scanning() (build.c) calls
> ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
> a swapped order!
> 
> This swap dates back to:
> 
> commit d63894654df72b010de2abb4b3f07d0d755f65b6
> Author: Holger Brunck <holger.brunck@keymile.com>
> Date:   Mon Oct 10 13:08:19 2011 +0200
> 
>     UBI: init eba tables before wl when attaching a device
> 
>     This fixes that u-boot gets stuck when a bitflip was detected
>     during "ubi part <ubi_device>". If a bitflip was detected UBI tries
>     to copy the PEB to a different place. This needs that the eba table
>     are initialized, but this was done after the wear levelling worker
>     detects the bitflip. So changes the initialisation of these two
>     tasks in u-boot.
> 
>     This is a u-boot specific patch and not needed in the linux layer,
>     because due to commit 1b1f9a9d00447d
>     UBI: Ensure that "background thread" operations are really executed
>     we schedule these tasks in place and not as in linux after the inital
>     task which schedule this new task is finished.
> 
>     Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
>     cc: Stefan Roese <sr@denx.de>
>     Signed-off-by: Stefan Roese <sr@denx.de>
> 
> I tried reverting that commit and... surprise! U-Boot can now attach UBI
> and boot properly!
> 

:-(

> But the cited commit actually fixed a bug that bite our board a few
> months back, so it should not be reverted without thinking twice. Now
> it apparently introduced another bug. :-(
> 

yes definetely.

I didn't read the whole thread, so I don't know what your exact problem is. On
my boards the ubi layer seems to work fine on latest u-boot. But I see a general
problem we have in the ubi layer in u-boot. I try to summarize my view:

The UBI layer was initialy copied from the linux implementation. But the linux
implementation relies for some tasks e.g. fix correctable errors on a background
thread. Due to the fact that u-boot is single threaded there was one commit
which wants to take care that these background tasks are really executed (CC-ing
the author):
commit 1b1f9a9d00  UBI: Ensure that "background thread" operations are really
executed

U-boot executes this background taks immediately but the linux implementation
executes this tasks later with the help of some synchronisation mechanism.
Therefore we have a different order executing these tasks. My fix did now a
change in the initialisation order of eba tables and the wear leveling thread,
to address my problem. But now it seems to cause a new problem on your side.

So the synchronisation mechanism in u-boot for the ubi tasks which are running
on linux in background is incorrect. But how this could be fixed needs to have
some deeper analyses.

Regards
Holger