[U-Boot-Users] [PATCH] ARM: DAVINCI: Write ECC understandable by RBL

[Dirk Behme]

ksi at koi8.net wrote:
> On Wed, 2 Jan 2008, Dirk Behme wrote:
> 
> I think it is not right.

Let us try to be a little more precise, not so general and don't mix 
things ;)

As you didn't comment below technically on any line of the patch, it 
seems to be technically correct.

So please apply.

> By making this a configuration choice (read compile-time) you introduce two
> different U-Boot versions; one being able to write RBL _BUT_ incompatible
> with the kernel ECC, another one being compatible with kernel _BUT_ not
> being able to write RBL. 

If I got it right you already introduced two different U-Boot versions 
with your Davinci patch. One to be used for NOR and one for NAND? Or 
can a U-Boot configured via davinci_dvevm.h for NAND used in NOR?

> What version are you going to use as a main one?

The one compatible with kernel of course. See below as well.

> Remember, if you have saved U-Boot environment in NAND only one version 
> will
> be able to read it...

I don't have to remember this because I'm aware of it ;) Did you 
notice that I mentioned 2nd stage NAND loader? Because of its 14k size 
limitation, this will never be U-boot. So I never talked about writing 
this special U-Boot version to NAND. Sorry if I was unclear regarding 
this.

> First of all, I don't think it is the U-Boot task to write RBL.

We never write RBL cause its in ROM? Did you mean NAND first stage UBL 
(2nd stage NAND loader)?

> I think 
> it's
> up to the initial bootloader to do this.

Okay, that's your opinion. I and maybe others may want to have a 
U-Boot to write 2nd stage NAND loader because of U-Boot powerful 
options (tftp, command line, dump & diff etc.). Therefore I made it as 
an option for everybody wanting to use this and knowing what he/she 
does. It doesn't touch anything else. If you don't like, ignore it and 
use your bootloader. But let others finding this usful use it.

> You don't have U-Boot on a fresh
> virgin board anyways so you use some kind of initial bootloader to boot 
> that
> board. So why not use that same bootloader for writing itself in NAND? I 
> did
> post the full source of such a bootloader to Davinci list where it went
> unnoticed.

Why do you think it was unnoticed? Do you remember that it was me 
answering to it? So at least one noticed it ;)

> It was able to write both itself _AND_ U-Boot in NAND while
> booting up a virgin DaVinci board through serial port.

Yes, I know. See above: Maybe others prefer other ways to do this.

> If this feature is to be integrated in U-Boot, it should be done as an
> extension to NAND-related command set so one would be able to choose which
> ECC to use for writing to NAND at the _RUN_ time.

Yes, this is the first good technical point :)

I did it this way, first, cause it is only for some experts as 
explained above. I made it as small and non-intrusive as possible. 
Second, is there an *easy* way to extend the NAND related command set 
without being too intrusive to non-Davinci code? I think changing a 
lot of non-Davinci code only for this special feature wouldn't be a 
real option. But you are right, technically it would be the cleanest way.

Thanks for your comments,

Dirk

>> ARM based TI DaVinci devices have a RomBootLoader (RBL) which is able
>> to load a 2nd stage user defined loader from NAND into internal RAM
>> and start it there. This RBL expects a special ECC format (4 byte big
>> endian) as calculated by DaVinci hardware. Make U-Boot able to write
>> this RBL compatible format if user selects it in configuration.
>>
>> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
>>
> 
> ---
> ******************************************************************
> *  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
> *  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
> ******************************************************************
>