From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Heider Date: Fri, 11 Sep 2020 18:47:02 +0200 Subject: [PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR In-Reply-To: <20200911182204.56faff52@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> <1da8d6e3-dc10-2aa2-ce4f-26edf25bd74d@gmail.com> <20200911182204.56faff52@dellmb.labs.office.nic.cz> Message-ID: <3bfee41f-d243-0855-16bb-0585263fd5b0@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 On 11/09/2020 18:22, Marek Beh?n wrote: > On Fri, 11 Sep 2020 17:52:26 +0200 > Andre Heider wrote: > >> 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. >> > > I understand Pali's concerns, though. > > The thing is that if we enable CONFIG_NET_RANDOM_ETHADDR by default, > many users that have managed to wipe their env won't care about that > they are using randomly generated MAC address and won't solve the issue, > which is again the spirit of correctly configure networks. > > If we do not enable CONFIG_NET_RANDOM_ETHADDR, the worst that can > happen is that the device won't boot from network. This will force the > users to solve the issue, which is not that hard > setenv ethaddr aa:bb:cc:dd:ee:ff (address from the sticker) > saveenv > If the users boots from SD/eMMC/SATA/USB, Linux won't have problem with > network, since it will generate random MAC address anyway. Good point, so let's assume the user doesn't have a mac stored. Without CONFIG_NET_RANDOM_ETHADDR: * u-boot refuses to do anything network related * Linux generates a random mac, network works With CONFIG_NET_RANDOM_ETHADDR: * u-boot generates a random mac, network works * Linux uses the same random mac, passed on from u-boot throught the device-tree, network works It's still random, but at least it's consistent ;) > The worst case scenario does not look that bad to me if we don't enable > CONFIG_NET_RANDOM_ETHADDR by default. > > I think the option CONFIG_NET_RANDOM_ETHADDR should be used only by > developers when they are developing on devices that have not yet burned > the MAC addresses, or on some embedded devices that don't have space > for saving a MAC address (no storage for env or anything else, do such > devices exist?). It looks like it's used for more than that though: $ git ls-files configs|wc -l 1362 $ git grep CONFIG_NET_RANDOM_ETHADDR configs|wc -l 209 Some popular sbc's are part of that list. > But it shouldn't be used as a default setting for a device that has > storage where it can store the address. > >> 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? >> > > Yes, that would be nice :) > >> Thanks, >> Andre > > Marek >