ksi@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@home KOI8 Net < > The impossible we do immediately. *
- Las Vegas NV, USA < > Miracles require 24-hour notice. *