Hello, > -----Original Message----- > From: Dennis Gilmore <dgilm...@fedoraproject.org> > Sent: Friday, September 11, 2020 20:16 > To: Tom Rini <tr...@konsulko.com> > Cc: Andre Heider <a.hei...@gmail.com>; Marek Behún > <marek.be...@nic.cz>; Pali Rohár <p...@kernel.org>; Stefan Roese > <s...@denx.de>; Kostya Porotchkin <kos...@marvell.com>; U-Boot Mailing > List <u-boot@lists.denx.de> > Subject: [EXT] Re: [PATCH] defconfig: espressobin: enable > NET_RANDOM_ETHADDR > > External Email > > ---------------------------------------------------------------------- > I agree with Tom here, I have a few different systems that use this feature, > it > is useful. I think most if not all of the systems I have using it have Marvell > SoC's > > Dennis > > On Fri, Sep 11, 2020 at 12:11 PM Tom Rini <tr...@konsulko.com> wrote: > > > > On Fri, Sep 11, 2020 at 06:47:02PM +0200, Andre Heider wrote: > > > On 11/09/2020 18:22, Marek Behún wrote: > > > > On Fri, 11 Sep 2020 17:52:26 +0200 Andre Heider > > > > <a.hei...@gmail.com> 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 <p...@kernel.org> > > > > > > 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 ;) > > > > It's also only used when we cannot find the MAC. At the end of the > > day, the final decision here is Konstantin's (as the listed > > maintainer). I personally think enabling the option is good given the > > apparent number of ways the real MAC will have been lost from SW, but > > if the maintainer wants to instead opt for a verbose failure message, that's > fine too. I have no objections about this configuration option. It is better to have a random MAC address rather then no MAC at all.
Regards Kosta > > > > -- > > Tom