On Sun, 17 Feb 2008, Bernard Blackham wrote:
Hi Dirk!
[dd]
-- cut --
You cannot use u-boot's NAND drivers to write the UBL because the RBL
(that
loads the UBL) expects a non-standard ECC format.
-- cut --
While this is totally correct, you can write UBL to NAND if you apply
a
patch teaching U-Boot to write the special ECC format. I sent one some
weeks ago
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/34602
Sergey commented that this isn't "right", but seems that he didn't
refer to
the technical part of the patch.
No, there is nothing wrong with that patch from technical standpoint. That's
implementation that is not even wrong but awkward...
If you find this useful like me, I can try to update the patch and
resend
it again. Or should we at least mention it in wiki, so that interested
people can apply it? (Assuming they know what they do regarding
Sergeys
comments)
What do you think?
Thanks for pointing that patch out! I agree with Sergey that it should
be a
run-time option. Perhaps some generic infrastructure to support
additional
NAND commands could be leveraged upon later.
The proper way to do this would be adding an additional command to NAND
tools suite. Something like "nand write-ubl" or something.
Personally, I think it's silly to have one tool to write one part of
flash
and another tool to write the other, but I can understand why people
want to
do it in different ways.
Those are totally different tools. Initial bootloader is used on virgin
DaVinci hardware that doesn't have any software on it. Sure one can use
U-Boot to write UBL and U-boot into NAND but one has to load that U-Boot
somehow first... Once U-Boot is running it is easy to do anything but it
doesn't come up all by itself, one needs an initial boot loader for this.
And if an initial boot loader is required anyways (it is required to boot
off of NAND anyways, U-Boot can NOT boot itself from NAND) why not use it
for writing itself and user application (e.g. U-Boot) into NAND? That makes
it self-sufficient.
Another consideration is that U-Boot is not omnipresent and omnipotent. Yes,
it is most frequently used user application but it is not mandatory. One can
use something else (e.g. some standalone OS-less app, some OS kernel etc.)
instead of U-Boot thus having no other options for writing into NAND...
And that TI UBL thing is simply ridiculous, pardon my French... It clearly
shows Windoze roots of its developers and their lack of *nix understanding.
They did not grok it. There is absolutely no need for any .NET "server" with
associated infrastructure from Billy You-Know-Wno. It is much simpler than
that; there is no need for Pentium CPU for a toster, a spring is enough...
Why should one pay for Micro$oft, sorry for an expression, OS just to be
able to boot an embedded device? I personally didn't use any their products
since Windoze 3.11 and I don't have any of them at all. And I can't see any
reason to get any at all -- *nix (Linux) has absolutely everything I ever
needed without paying a dime.
From a quick Google and glance at the uboot code
(drivers/mtd/nand/nand_util.c), it seems there are already differences
in ECC
formats between jffs2 and yaffs. From the user's point of view, it would
make
sense to extend the "nand read[.jffs2|...]" syntax, but I haven't looked
yet
at how that would find its way cleanly up to the Davinci NAND driver.
No, ECC is the same. ECC is on driver level and it is the same no matter
what data is written to NAND. ECC takes just a _PART_ of OOB area and ECC
code doesn't care what is written to unused OOB parts. That is where YAFFS
and JFFS2 differ -- they use those _UNUSED_ OOB bytes differently. But that
doesn't have anything to do with ECC. As a matter of fact those unused OOB
bytes are not even included in regular ECC calculations so they are _NOT_
even protected by driver level ECC...
---
******************************************************************
* [EMAIL PROTECTED] KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
