Hello Piotr,

On Mon, Aug 16, 2021 at 2:09 PM Piotr Piwko <piotr.piwko@...> wrote:

pon., 16 sie 2021 o 13:39 Andrey Zhizhikin <andrey.z@...> napisał(a):

Are you sure that the failed boot behavior is indeed caused by
845620ec5d3b ("MLK-24940 arm: imx: correctly check the return value of
"of_get_mac_address"")? If you revert it locally - does your board
boots OK?

Yes I'm sure. I have tested it several times and with this commit reverted, the board boots successfully exactly the same as it was in the previous versions (i.e dunfell).

That is the trick: [dunfell] uses 5.4-2.1.x-imx branch, where the
proper check for the return of of_get_mac_address() is not
implemented. [hardknott] uses 5.4-2.3.x-imx branch, which contains
845620ec5d3b to address it. Perhaps, this is the root cause of the
behavior you're experiencing now when you switched branches.

The commit in question is coming from NXP directly and is not present
in the mainline kernel tree, but from what I can tell - it brings the
correct error handling for the updated of_get_mac_address() call, so
as other HW does.

Yes, it seems that is the correct way for error handling, but I'm not sure if it shall stop the boot in case of failure.

Do you have a valid MAC address set in either DTB or nvmem?

I'm not sure about that. However, in the previous version it was exactly the same.

The order of MAC address fetch is described in [1], with the note
regarding the U-Boot not setting "mac-address" bindings. I believe it
is worth checking to make sure the MAC is set to valid one and not
"All-zero".

--
Piotr Piwko
http://www.embedded-engineering.pl/

Link: [1]: https://github.com/torvalds/linux/blob/7c60610d476766e128cc4284bb6349732cbd6606/drivers/of/of_net.c#L115

--
Regards,
Andrey.