public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot-Users] [PATCH] ARM: DAVINCI: Write ECC understandable by RBL
@ 2008-01-02 20:21 Dirk Behme
  2008-01-02 21:14 ` ksi at koi8.net
  0 siblings, 1 reply; 3+ messages in thread
From: Dirk Behme @ 2008-01-02 20:21 UTC (permalink / raw)
  To: u-boot


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>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: davinci_nand_rblecc.txt
Url: http://lists.denx.de/pipermail/u-boot/attachments/20080102/497bd140/attachment.txt 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot-Users] [PATCH] ARM: DAVINCI: Write ECC understandable by RBL
  2008-01-02 20:21 [U-Boot-Users] [PATCH] ARM: DAVINCI: Write ECC understandable by RBL Dirk Behme
@ 2008-01-02 21:14 ` ksi at koi8.net
  2008-01-03  6:05   ` Dirk Behme
  0 siblings, 1 reply; 3+ messages in thread
From: ksi at koi8.net @ 2008-01-02 21:14 UTC (permalink / raw)
  To: u-boot

On Wed, 2 Jan 2008, Dirk Behme wrote:

I think it is not right.

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. What version are you going to use as a main one?
Remember, if you have saved U-Boot environment in NAND only one version will
be able to read it...

First of all, I don't think it is the U-Boot task to write RBL. I think it's
up to the initial bootloader to do this. 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. It was able to write both itself _AND_ U-Boot in NAND while
booting up a virgin DaVinci board through serial port.

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.

> 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

* [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

end of thread, other threads:[~2008-01-03  6:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-01-02 20:21 [U-Boot-Users] [PATCH] ARM: DAVINCI: Write ECC understandable by RBL Dirk Behme
2008-01-02 21:14 ` ksi at koi8.net
2008-01-03  6:05   ` Dirk Behme

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox