From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= <benoit.thebaudeau@advansee.com>
Date: Sun, 12 Aug 2012 16:02:48 +0200 (CEST)
Subject: [U-Boot] [PATCH 5/5] Add env var giving the board revision
In-Reply-To: <20120812115849.F0D6D202A85@gemini.denx.de>
Message-ID: <1642597694.2324115.1344780168514.JavaMail.root@advansee.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.

Best regards,
Beno?t