Re: [meta-freescale] #meta-freescale Broken linux-fslc/5.4-2.3.x-imx repo on hardknott branch

"Andrey Zhizhikin" <[email protected]> Mon, 16 Aug 2021 13:39:37 +0200
Newsgroups org.yoctoproject.lists.meta-freescale
Message-ID <CAHtQpK4Yos+djqgig+9G9xwYPLG=TYg6Ky=0kAs2bkw+hUFgZQ@mail.gmail.com>
Hello Piotr,

On Tue, Aug 10, 2021 at 3:13 PM Piotr <[email protected]> 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 <[email protected]> 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.