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