Hello Piotr,

Em ter., 10 de ago. de 2021 às 08:52, Piotr <piotr.piwko@...> escreveu:

I've just built the hardknott branch and the kernel is not bootable on my SABRE-based platform. I was digging a little bit the linux-fslc/5.4-2.3.x-imx repo and found the commit which causes the problem:

845620ec5d3b MLK-24940 arm: imx: correctly check the return value of "of_get_mac_address"

The above commit strongly depends on the following one which is currently missing on the latest revision:

d01f449c008a of_net: add NVMEM support to of_get_mac_address

Is that issue is known to you and has other solution than reversing the 845620ec5d3b?

It seems it'd be better to cherry-pick d01f449c008a to solve it. Could
you prepare a PR for it?

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750

On Tue, Aug 10, 2021 at 04:56 AM, Otavio Salvador wrote:

It seems it'd be better to cherry-pick d01f449c008a to solve it. Could
you prepare a PR for it?

I would try. It should be done via https://github.com/Freescale/linux-fslc/pulls, right?

-- 
Piotr Piwko

Em ter., 10 de ago. de 2021 às 09:27, Piotr <piotr.piwko@...> escreveu:

On Tue, Aug 10, 2021 at 04:56 AM, Otavio Salvador wrote:

It seems it'd be better to cherry-pick d01f449c008a to solve it. Could
you prepare a PR for it?

I would try. It should be done via https://github.com/Freescale/linux-fslc/pulls, right?

Yes. Please.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750

On Tue, Aug 10, 2021 at 04:56 AM, Otavio Salvador wrote:

Hello Piotr,

Em ter., 10 de ago. de 2021 às 08:52, Piotr <piotr.piwko@...> escreveu:

I've just built the hardknott branch and the kernel is not bootable on my SABRE-based platform. I was digging a little bit the linux-fslc/5.4-2.3.x-imx repo and found the commit which causes the problem:

845620ec5d3b MLK-24940 arm: imx: correctly check the return value of "of_get_mac_address"

The above commit strongly depends on the following one which is currently missing on the latest revision:

d01f449c008a of_net: add NVMEM support to of_get_mac_address

Is that issue is known to you and has other solution than reversing the 845620ec5d3b?

It seems it'd be better to cherry-pick d01f449c008a to solve it. Could
you prepare a PR for it?

I've take a look at the mainline linux tree and seems that the above commit is still not merged there. According to that, I think it will be better to revert 845620ec5d3b.

-- 
Piotr Piwko

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750

Hello Piotr,

Em ter., 10 de ago. de 2021 às 10:13, Piotr <piotr.piwko@...> escreveu:

I've take a look at the mainline linux tree and seems that the above commit is still not merged there. According to that, I think it will be better to revert 845620ec5d3b.

I didn't check what those two changes do but I believe it'd be better
to keep the of_get_mac_address working as this is the forked Linux
kernel of NXP. As it used to work on other 5.4 Linux kernels
preserving it seems to be a good approach except if cherry-pick
doesn't work.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750

Hello Piotr,

On Tue, Aug 10, 2021 at 3:13 PM Piotr <piotr.piwko@...> wrote:

On Tue, Aug 10, 2021 at 04:56 AM, Otavio Salvador wrote:

Hello Piotr,

Em ter., 10 de ago. de 2021 às 08:52, Piotr <piotr.piwko@...> escreveu:

I've just built the hardknott branch and the kernel is not bootable on my SABRE-based platform. I was digging a little bit the linux-fslc/5.4-2.3.x-imx repo and found the commit which causes the problem:

845620ec5d3b MLK-24940 arm: imx: correctly check the return value of "of_get_mac_address"

The above commit strongly depends on the following one which is currently missing on the latest revision:

d01f449c008a of_net: add NVMEM support to of_get_mac_address

From what I see, the d01f449c008a ("of_net: add NVMEM support to
of_get_mac_address") is indeed present on all NXP branches in the
repository:
$ git branch -r --contains d01f449c008a
upstream/5.10.x+fslc
upstream/5.12.x+fslc
upstream/5.13.x+fslc
upstream/5.2.x+fslc
upstream/5.3.x+fslc
upstream/5.4-1.0.0-imx
upstream/5.4-2.0.x-imx
upstream/5.4-2.1.x-imx
upstream/5.4-2.2.x-imx
upstream/5.4-2.3.x-imx
upstream/5.4.x+fslc
upstream/5.4.y+qoriq
upstream/5.4.y+qoriq+fslc
upstream/5.9.x+fslc

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?

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.

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

Is that issue is known to you and has other solution than reversing the 845620ec5d3b?

It seems it'd be better to cherry-pick d01f449c008a to solve it. Could
you prepare a PR for it?

I've take a look at the mainline linux tree and seems that the above commit is still not merged there. According to that, I think it will be better to revert 845620ec5d3b.

--
Piotr Piwko



--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750

--
Regards,
Andrey.

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.