From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Heider Date: Fri, 11 Sep 2020 17:52:26 +0200 Subject: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR In-Reply-To: <20200911135505.4e902304@dellmb.labs.office.nic.cz> References: <20200908063500.480897-1-a.heider@gmail.com> <20200908074259.63fai53pej72epm4@pali> <20200908125256.GH7259@bill-the-cat> <20200908223831.qzqzyqrdvybri6z5@pali> <20200911135505.4e902304@dellmb.labs.office.nic.cz> Message-ID: <1da8d6e3-dc10-2aa2-ce4f-26edf25bd74d@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Marek, On 11/09/2020 13:55, Marek Beh?n wrote: > On Wed, 9 Sep 2020 00:38:31 +0200 Pali Roh?r wrote: >> On Tuesday 08 September 2020 08:52:56 Tom Rini wrote: >>> Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only use a >>> random MAC address when we haven't found one either on the hardware >>> or environment. >> >> I know. >> >>> It also prints a warning that you are using a random MAC, >>> so if it's documented on how to recover the real MAC a user should >>> see that warning and fix it. >> >> In case you did backup of MAC address or you have MAC address printed >> on sticker, you can restore it. If you loaded distribution U-Boot >> which erase MAC address and you have not did any backup, then your >> MAC address is forever lost. > > On Turris MOX we write the MAC address into OTP of the SOC during > manufacturing. > > It is possible to write code that burns the MAC address into OTP, I > consider this a better option than enabling random MAC address. > > Maybe we can enable random MAC address, and if MAC address is not found > in environment nor OTP, issue a warning, something like > "WARNING: MAC address lost, please burn the MAC address of your device > to OTP with command xyz" > > What do you think? if there's a mac stored in otp during manufacturing, that's of course the best solution. There's no need for CONFIG_NET_RANDOM_ETHADDR then. But globalscale does not do that. Doing it afterwards, so u-boot claiming some otp space for itself, and instructing the user how to write to it sounds too dangerous/error-prone. For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be enabled if there's no mac address stored in a sane way (where saving it just to an u-boot env during manufacturing doesn't count as sane, especially if the vendor moves the spi env offset around in a firmware update). So I think CONFIG_NET_RANDOM_ETHADDR is enough. But it would be nice if e.g. a board could set specific env vars as indestructible/unwipeable/precious/whatever, which instructs `env default -a` to keep those (which is common after updating the bootloader). Maybe that's an idea worth pursuing? Thanks, Andre