[U-Boot] [PATCH 0/5] Add support for using an UBI volume for environment

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/11/2013 09:37 PM, Scott Wood wrote:
> On 02/08/2013 02:07:21 PM, Joe Hershberger wrote:
>> NAND is not good at handling absolute addresses to sectors for 
>> storing particular data.  The current implementation of the NAND 
>> env support works around this in several ways such as storing a 
>> pointer to the sector in the OOB of the first sector (interferes 
>> with some CRC) or supporting a range of sectors (which unless it 
>> is huge is not guaranteed to be safe).  None of these options 
>> address wear-leveling concerns or bad block handling.
>> 
>> Accessing the u-boot env from UBI eliminates these concerns. 
>> However, it does require some of the basic settings for finding 
>> the UBI env to be in the default u-boot env.
> 
> The downside is this moves us further away from having an 
> environment available before relocation (e.g. loaded by SPL),
> which is important not just for serial config but also hwconfig,
> which can affect how RAM is set up among other things.
> 
> Maybe the "OOB of first sector" approach could be changed to be 
> more like how bad block tables are allocated, with a special
> marker in the env block's own OOB that we scan for.

There's pluses and minuses to "throw more stuff in UBI".  So long as
it doesn't break the ability to have env pre-relocation (and it
shouldn't, we already support env in a file), is there a problem here?

Or just hoping to encourage other robust methods?

I think somewhere there's a wishlist for UBI in SPL (for Falcon mode),
for example..

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRGmf4AAoJENk4IS6UOR1W4IUP/0bcsyrI+ufUPf99ME/bkQq0
NhCP3/DH/CxtXrTzsl4mkPOv/C0ziMmQiGpz58k63ITqSPJL/pAZgVqmy1DwhIB/
u/y2F3IYZTwllw06OykesKd8GlP4+oiQokYDAHywfOzw/SyUI3t4jZCGTR2BOvbt
TWw6XL8Rm7sGi3nWRhFlQt4AfRvdidlzcOFppjrQsf7wS39Ho6ALRs0kSh/pVy7h
MoQcICC/+vRc/qDXV6QKlQ3EHK3+3+/3HKUQiKbsw+hrPJua6Ur8+6PpLS96Qc8F
r7+hnOHS+pPVuoIzOfRBn8+R3LDccPskirFGlT0uHXMpph/nQBohLXFMt0CMe9/9
8CwXyMSckpZdPM+2EeGURqQdJZ/fBL+WJEmke6BUnLdOdw8Ks2PuIGQWonlrsLkq
Q7ZHyqN2RtC9veGadRvKhR8GOZP7bQPLMiIWpThNQQTaSUKKYoUFjlxgcaiLAsoC
grO2S0AIBTQx3D0Vzfrka1shttYBd5vqs85bRt/EZAi5YDMeeSTkc3D/wiZST3bP
q8GNyM6p7QNXMnM0hNgQRZIhw5iStaMohh517h84JN69RkQ4TwRUt8HdJPXnPPHq
F1+gmWLKeJRSSza9uIWsUlU4VTE1vVLo7H3hIq1EigERLdg3Z3g9WirkPuSMYEjX
XuvGODaEQ4wqM6yH1XFQ
=rkT9
-----END PGP SIGNATURE-----