[U-Boot] [PATCH 5/5] Add env var giving the board revision

["Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>]

Dear Wolfgang Denk,

> > > I have searched such a usage in the tree, but did not find any,
> > > so
> > > this should
> > > not break anything.
> > 
> > You cannot expect to see the real, production environments in the
> > mainline source tree.
> 
> Right, but the same applied to serial# and ethaddr when they were
> added, except
> if U-Boot deployment was not large enough at that time to worry you.
> 
> > > It could be renamed to hwrev, board_rev or whatever you like.
> > > This
> > > is not really
> > > an issue. Its purpose is the board hardware revision. The CPU
> > > revision can often
> > > be read from the CPU and is printed upon startup. U-Boot's
> > > revision
> > > already has
> > > the ver env var and the version command. On the contrary, the
> > > board
> > > revision can
> > > not always be determined by analyzing the hardware (OTP, fuses,
> > > EEPROM, GPIOs,
> > > etc.), so it can be useful to have an official env var to store
> > > it
> > > in the backed
> > > up env, exactly like for the serial# env var that can not always
> > > be
> > > stored in
> > > some dedicated hardware location.
> > 
> > As mentioned before, I don't see need for such a thing in general.
> > Any such use is highly board specific, and vendors use different
> > ways
> > to address this.
> 
> The same applies to serial# again.
> 
> > I don't intend to apply this patch, sorry.
> 
> OK.

Anyway, when you will have implemented read-only and volatile flags for env
vars, this patch will no longer be needed. But with the current code, there is
no way board-specific code can create a board revision env var and make it
read-only, except with this patch.

Best regards,
Beno?t