[U-Boot] [PATCHv1 02/22] arm: socfpga: enable saveenv to mmc partition

[Marek Vasut]

On Friday, January 16, 2015 at 07:35:11 PM, Pavel Machek wrote:
> Hi!
> 
> > > > -#define CONFIG_ENV_IS_NOWHERE
> > > > 
> > > >  #define CONFIG_ENV_SIZE			4096
> > > > 
> > > > +#define CONFIG_ENV_IS_IN_MMC
> > > > +#define CONFIG_SYS_MMC_ENV_DEV		0/* device 0 */
> > > > +#define CONFIG_ENV_OFFSET		512/* just after the MBR */
> > > > +
> > > 
> > > Would it make sense to make environment bigger (64K?) at this point,
> > > and enabling the redundant environment option, so that one bad block
> > > does not bring the whole device down?
> > 
> > Do you think you'll ever have more than a 4KiB of text data in the env ?
> > I can see a reason for some 16 KiB environment, but that's the
> > 
>  > ceiling.
> 
> We have hit 4KiB size already, and I believe we are over 8KiB,
> even. wagabuibui loads a lot of small files from flash.
> 
> So if 16KiB is acceptable, lets do that.

16KiB is fine by me, though I'm not quite sure how you managed to stuff 8KiB
full of env ;-)

> > Usually, the env only has to be a few KiB and it's size has to be
> > multiple of the underlying device's erase block. But in case of SD card,
> > there are no explicit erase blocks exported to the user, all is hidden
> > by the controller in the SD card and gives an illusion of a device which
> > has 512b
> > blocks and
> 
> Allocation unit is usually 2, 4, 6, 8, 12 or 16 MiB on recent flash
> cards. It is field in uSD card structure somewhere. We could choose
> 24MiB, to have GCD, but... see:
> 
> https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurv
> ey

OK, this is even more precise. Thanks for the link.

> > the user doesn't care for bad block management. Since the controller in
> > the card does the bad block management and wear leveling/relocation of
> > blocks, it also means that in case the controller did fail to provide
> > the block which contains env, the whole card would already be in a very
> > bad state.
> 
> Bad block management means you don't get errors during write, but you
> can still get errors during read.

That in fact depends on the BBM implementation, but in case you get error
during read, it's usually a game over kind of situation. But I agree.

Best regards,
Marek Vasut