From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marek.vasut@gmail.com>
Date: Wed, 11 Jan 2012 16:01:31 +0100
Subject: [U-Boot] [PATCH 1/2 V2] arm926: Flush the data cache before
	disabling it.
In-Reply-To: <20120111144625.GA4301@Hardy>
References: <1326133550-6706-1-git-send-email-urwithsughosh@gmail.com>
	<201201111452.44551.marek.vasut@gmail.com>
	<20120111144625.GA4301@Hardy>
Message-ID: <201201111601.31484.marek.vasut@gmail.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

> On Wed Jan 11, 2012 at 02:52:44PM +0100, Marek Vasut wrote:
> > > >   Changing the ecc layout for a single board, hmm not sure. Using a
> > > >   spl instead does me no harm whatsoever -- I don't need to update
> > > >   the spl frequently in any case, and then can use the nand driver
> > > >   as is.
> > > 
> > > And how do you replace the SPL?
> > > 
> > > Either way, I think the correct approach is to allow the driver to
> > > handle the SPL update too.
> > 
> > Or rather -- to be able to load u-boot directly. It seems to be more
> > correct solution. The SPL you're using is just a workaround and also you
> > need to TI flasher to replace it, right ?
> 
>   Yes, using the spl is a workaround, and like i mentioned in my
>   previous mail, i thought having the spl was not a problem on the
>   hawkboard. I had thought putting a new oob layout in the common
>   davinci nand driver for a single board to be not a clean fix
>   either.

Then just allow the driver to be passed different OOB layout and make the 
current one a default

>   More so, given the fact that we don't have any control over
>   rbl -- so if rbl changes it's layout for any subsequent board, we'd
>   have to add that as well to the nand driver, and both in u-boot as
>   well as the kernel.
> 
>   I guess the cleanest solution would have been for the rbl to have
>   used the same layout as the one used by u-boot and linux.

Yep, why not do that then?

> 
>   Btw, can you please review this change, that this patch
>   fixes. ACK/NAK?

I'll think about it. It's ok, but it piles one workaround on top of another one, 
I don't like that approach.

M

> 
> -sughosh