* [U-Boot-Users] [PATCH] ARM: DAVINCI: Write ECC understandable by RBL
2008-01-02 21:14 ` ksi at koi8.net
@ 2008-01-03 6:05 ` Dirk Behme
0 siblings, 0 replies; 3+ messages in thread
From: Dirk Behme @ 2008-01-03 6:05 UTC (permalink / raw)
To: u-boot
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@gmail.com>
>>
>
> ---
> ******************************************************************
> * KSI at home KOI8 Net < > The impossible we do immediately. *
> * Las Vegas NV, USA < > Miracles require 24-hour notice. *
> ******************************************************************
>
^ permalink raw reply [flat|nested] 3+ messages in thread