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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
