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.