But that's the mainline way of working, no? When using etnaviv/drm/imx-ipu... ?
Why would the old ldb-style still work, but the old lcd isn't?

On Thu, 2020-08-13 at 03:28 -0700, Wouter Vanhauwaert wrote:

How do you correctly put a parallel lcd display in linux 5.4?
Uptill 4.9, there was a mxc_lcdif.c, but seems to be missing now?
In the devicetree, you used to add a node which had
compatible="fsl,lcd", addressing the pinctrl etc
But none of these seem to exist now?
I see a commit
https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c
This is supposed to add the lcdif, but hasn't or principle has
changed? Can someone explain?

Yes this has completely changed, look at NXP's MEK devicetrees to figure that out, at least I was once able to figure it out like that.
On Colibri-iMX8X I once had it running with something like this:

&dpu_disp1_lcdif {
remote-endpoint = <&lcd_display_in>;
status = "okay";
};


This points to:

panel {
compatible = "logictechno,lt161010-2nhc";
backlight = <&backlight>;
status = "okay";

port {
lcd_panel_in: endpoint {
remote-endpoint = <&lcd_display_out>;
};
};
};

display@disp1 {
compatible = "fsl,imx-lcdif-mux-display";
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcdif>;
clocks = <&clk IMX_SC_R_LCD_0 IMX_SC_PM_CLK_BYPASS>,
<&clk IMX_SC_R_LCD_0 IMX_SC_PM_CLK_MISC0>;
clock-names = "bypass_div", "pixel";
assigned-clocks = <&clk IMX_SC_R_LCD_0 IMX_SC_PM_CLK_MISC0>;
assigned-clock-parents = <&clk IMX_SC_R_LCD_0
IMX_SC_PM_CLK_BYPASS>;
fsl,lcdif-mux-regs = <&lcdif_mux_regs>;
fsl,interface-pix-fmt = "bgr666";
power-domains = <&pd IMX_SC_R_LCD_0>;
status = "okay";

port@0 {
reg = <0>;

lcd_display_in: endpoint {
remote-endpoint = <&dpu_disp1_lcdif>;
};
};

port@1 {
reg = <1>;

lcd_display_out: endpoint {
remote-endpoint = <&lcd_panel_in>;
};
};
};

Hope this helps,
Philippe

How do you correctly put a parallel lcd display in linux 5.4?
Uptill 4.9, there was a mxc_lcdif.c, but seems to be missing now?
In the devicetree, you used to add a node which had compatible="fsl,lcd", addressing the pinctrl etc
But none of these seem to exist now?
I see a commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c
This is supposed to add the lcdif, but hasn't or principle has changed? Can someone explain?

On Mon, 2020-08-10 at 17:24 -0300, Otavio Salvador wrote:

Hello all,

First, I'd like to thank you all for the great work.

Em seg., 10 de ago. de 2020 às 17:02, Andrey Zhizhikin
<andrey.z@gmail.com> escreveu:
...

Yeap, Kernel build off commit
1e10771673463a332a7e477fcba0b9488ec5362b
boots fine on i.MX8M Mini EVK. I haven't verified whether graphics
and
multimedia are OK, but in general at this state this merge is
absolutely fine!

I believe you can make a PR in
https://github.com/Freescale/linux-fslc
for Otavio to have a look at it.

With that said:
Tested-By: Andrey Zhizhikin <andrey.z@gmail.com>

I made the baseline branch based on codeaurora one. Here it goes:

https://github.com/Freescale/linux-fslc/tree/5.4-2.1.x-imx

So please, prepare a PR against it, so we can merge it there.

Haven't read all mails have created the PR now!

Also thanks from my side for the fast support Otavio!

Philippe

On Mon, 2020-08-10 at 22:02 +0200, Andrey Zhizhikin wrote:

On Mon, Aug 10, 2020 at 5:33 PM Philippe Schenker
<philippe.schenker@toradex.com> wrote:

On Mon, 2020-08-10 at 16:10 +0200, Andrey Zhizhikin wrote:

Hey Philippe,

On Mon, Aug 10, 2020 at 1:52 PM Philippe Schenker
<philippe.schenker@toradex.com> wrote:

On Mon, 2020-08-10 at 12:42 +0200, Andrey Zhizhikin wrote:

Hello Philippe,

On Mon, Aug 10, 2020 at 12:01 PM Philippe Schenker via
lists.yoctoproject.org
<philippe.schenker=toradex.com@lists.yoctoproject.org> wrote:

Hi,

Toradex is currently working on integrating the new NXP
release
'L5.4.24_2.1.0'. For this we created a new kernel branch
'5.4-
2.1.x-
imx'
based on NXP's kernel 'imx_5.4.24_2.1.0'.
We already merged patches from stable linux 5.4.47 into
'5.4-
2.1.x-
imx'.

This is great news! I was half the way of working on the same
update,
but now since you have the merge done - I can take your
version
instead.

@Otavio: I sincerely ask you if you could place the branch
'5.4-
2.1.x-
imx' that resides currently in my private github account:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fphilschenker%2Flinux-fslc%2Ftree%2F5.4-2.1.x-imx&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=BZDTVKY%2BQJDwIgsBjAeRshdTw2i7Ksh0RjGtw92ZZHw%3D&amp;reserved=0

I'll grab this one to test on i.MX8M Mini EVK now and try it
out.

I've tried to build the branch from your repo with latest master
of
meta-freescale, and saw couple of issue with imx8mmevk machine:

1. imx-gpu-sdk recipe fails to build, as it requires the header
which
is most probably missing in the kernel:

make: *** No rule to make target

'/development/projects/master/build-output/work/cortexa53-crypto-
mx8mm-fsl-linux/imx-gpu-sdk/5.0.2-r0/recipe-
sysroot/usr/include/bits/sys_errlist.h',
needed by
'build/Yocto/obj/Release/source/FslBase/Bits/ByteArrayUtil.o'.
Stop.

I guess any user-space stuff need updating to versions that NXP
provides
with BSP 'L5.4.24_2.1.0'.

OE-core updated glibc which is the provider of 'sys_errlist.h' so
maybe
that is the reason for build failure?

Correct! My bad: I did a pull of OE-Core and then your Kernel branch,
which I should not have been doing in the first place. This issue is
not from Kernel, it is a pure glibc one. Thanks for pointing it out!

2. Kernel panics on the startup, there is something related to FEC
driver:
[ 0.994893] Unable to handle kernel paging request at virtual
address 0000000000023779
[ 1.002814] Mem abort info:
[ 1.005614] ESR = 0x96000004
[ 1.008668] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.013983] SET = 0, FnV = 0
[ 1.017040] EA = 0, S1PTW = 0
[ 1.020178] Data abort info:
[ 1.023062] ISV = 0, ISS = 0x00000004
[ 1.026901] CM = 0, WnR = 0
[ 1.029872] [0000000000023779] user address but active_mm is
swapper
[ 1.036262] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1.041833] Modules linked in:
[ 1.044891] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
5.4.47+g1310c126dd1e #1
[ 1.052022] Hardware name: FSL i.MX8MM EVK board (DT)
[ 1.057073] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 1.061868] pc : fec_probe+0x280/0x1340
[ 1.065703] lr : fec_probe+0x80/0x1340
[ 1.069449] sp : ffff80001003baf0
[ 1.072761] x29: ffff80001003baf0 x28: 0000000000000000
[ 1.078072] x27: 0000000000000000 x26: ffff80001114d9b8
[ 1.083383] x25: 0000000000000000 x24: ffff000076090000
[ 1.088694] x23: ffff00007dc03bd8 x22: ffff000076404c10
[ 1.094005] x21: ffff000076404c00 x20: ffff0000762f8000
[ 1.099316] x19: ffff0000762f87c0 x18: 0000000000000020
[ 1.104626] x17: 0000000000000001 x16: 0000000000000019
[ 1.109937] x15: ffff000076090470 x14: 0000000000000000
[ 1.115248] x13: ffff000076090000 x12: 0000000000000000
[ 1.120559] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[ 1.125870] x9 : 49fffeff06fefeff x8 : 7f7f7f7f7f7f7f7f
[ 1.131180] x7 : 01fefefefefefeff x6 : 8080808080808000
[ 1.136491] x5 : 0080808080808080 x4 : 0000000000000000
[ 1.141802] x3 : ffff80001114ea48 x2 : 0000000000000000
[ 1.147113] x1 : ffff000076090000 x0 : 0000000000023779
[ 1.152424] Call trace:
[ 1.154871] fec_probe+0x280/0x1340
[ 1.158361] platform_drv_probe+0x50/0xa0
[ 1.162371] really_probe+0xd8/0x410
[ 1.165946] driver_probe_device+0x54/0xe4
[ 1.170042] device_driver_attach+0xb4/0xc0
[ 1.174225] __driver_attach+0x80/0x114
[ 1.178060] bus_for_each_dev+0x6c/0xbc
[ 1.181895] driver_attach+0x20/0x30
[ 1.185469] bus_add_driver+0xfc/0x1e0
[ 1.189218] driver_register+0x74/0x120
[ 1.193052] __platform_driver_register+0x44/0x50
[ 1.197756] fec_driver_init+0x18/0x20
[ 1.201506] do_one_initcall+0x50/0x190
[ 1.205343] kernel_init_freeable+0x194/0x22c
[ 1.209700] kernel_init+0x10/0x100
[ 1.213188] ret_from_fork+0x10/0x18
[ 1.216765] Code: 2a1303e2 b940afe1 b900b3f3 17ffff75
(b9400000)
[ 1.222866] ---[ end trace 31a90d201ff67100 ]---
[ 1.227505] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 1.235161] SMP: stopping secondary CPUs
[ 1.239085] Kernel Offset: disabled
[ 1.242572] CPU features: 0x0002,2000200c
[ 1.246579] Memory Limit: none
[ 1.249634] ---[ end Kernel panic - not syncing: Attempted to
kill
init! exitcode=0x0000000b ]---

Thanks for pointing this out, I could reproduce the issue and
checked.
There were still two commits missing. One revert that we believe is
not
applicable to downstream fec_main.c
This one also solved the issue. The other IPU commit was also
missing.
Now it works on our side. Can you confirm?

Yeap, Kernel build off commit 1e10771673463a332a7e477fcba0b9488ec5362b
boots fine on i.MX8M Mini EVK. I haven't verified whether graphics and
multimedia are OK, but in general at this state this merge is
absolutely fine!

I believe you can make a PR in https://github.com/Freescale/linux-fslc
for Otavio to have a look at it.

Thanks Andrey for testing!
I guess Otavio needs to pull it from my branch, I'm not able to create a
new branch as PR.

Philippe

With that said:
Tested-By: Andrey Zhizhikin <andrey.z@gmail.com>

Philippe

Have you ported the patch [1] from upstream? Without it - the
latest
master build would fail (it is needed for binutils-2.35).

Hi Andrey,

We were building binutils-2.34 so didn't notice this issue. I've
cherry-
picked the patch you mentioned.

That's great, I've synced up the tree to your latest commit and
the
perf build build went through.

Philippe

into the repository

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Flinux-fslc&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=qkHhXyQfUuvj1C9u3FbPaqrmx6TsszVHpiRi9azUyR0%3D&amp;reserved=0

Thanks and best regards,
Philippe

[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D39efdd94e314336f4acbac4c07e0f37bdc3bef71&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=gDSV0ochz6GpX1DQ6EU%2Bn6BtpvDVBNbgPkWGWEqNegY%3D&amp;reserved=0

On Mon, Aug 10, 2020 at 07:51 AM, Brian Hutchinson wrote:

Hi,

I'm looking into doing the rt patch against linux-fslc-imx 5.4.51.  Doesn't look like anyone has done this for the imx8mm.  I see a recipe for linux-fslc-imx-rt 4.1.-1.0.x but looks like it's for the imx6.

Just wondering if anyone has gone down this road before and can point me toward the right path or am I going to have to weed wack through the brush to get there?

Thanks,

Brian

I'll answer my own question ... I applied the 5.4.54 rt patch and it worked.  Built rt-tests and ran cyclictest and pi_stress so I'm happy.  At this point looks like things are working as far as I can tell.

Regards,

Brian

Thanks, Otavio. Much appreciated! We will send you a PR first thing tomorrow morning.

Hello all,

First, I'd like to thank you all for the great work.

Em seg., 10 de ago. de 2020 às 17:02, Andrey Zhizhikin
<andrey.z@gmail.com> escreveu:
...

Yeap, Kernel build off commit 1e10771673463a332a7e477fcba0b9488ec5362b
boots fine on i.MX8M Mini EVK. I haven't verified whether graphics and
multimedia are OK, but in general at this state this merge is
absolutely fine!

I believe you can make a PR in https://github.com/Freescale/linux-fslc
for Otavio to have a look at it.

With that said:
Tested-By: Andrey Zhizhikin <andrey.z@gmail.com>

I made the baseline branch based on codeaurora one. Here it goes:

https://github.com/Freescale/linux-fslc/tree/5.4-2.1.x-imx

So please, prepare a PR against it, so we can merge it there.

--
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 Mon, Aug 10, 2020 at 5:33 PM Philippe Schenker
<philippe.schenker@toradex.com> wrote:

On Mon, 2020-08-10 at 16:10 +0200, Andrey Zhizhikin wrote:

Hey Philippe,

On Mon, Aug 10, 2020 at 1:52 PM Philippe Schenker
<philippe.schenker@toradex.com> wrote:

On Mon, 2020-08-10 at 12:42 +0200, Andrey Zhizhikin wrote:

Hello Philippe,

On Mon, Aug 10, 2020 at 12:01 PM Philippe Schenker via
lists.yoctoproject.org
<philippe.schenker=toradex.com@lists.yoctoproject.org> wrote:

Hi,

Toradex is currently working on integrating the new NXP release
'L5.4.24_2.1.0'. For this we created a new kernel branch '5.4-
2.1.x-
imx'
based on NXP's kernel 'imx_5.4.24_2.1.0'.
We already merged patches from stable linux 5.4.47 into '5.4-
2.1.x-
imx'.

This is great news! I was half the way of working on the same
update,
but now since you have the merge done - I can take your version
instead.

@Otavio: I sincerely ask you if you could place the branch '5.4-
2.1.x-
imx' that resides currently in my private github account:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fphilschenker%2Flinux-fslc%2Ftree%2F5.4-2.1.x-imx&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=BZDTVKY%2BQJDwIgsBjAeRshdTw2i7Ksh0RjGtw92ZZHw%3D&amp;reserved=0

I'll grab this one to test on i.MX8M Mini EVK now and try it out.

I've tried to build the branch from your repo with latest master of
meta-freescale, and saw couple of issue with imx8mmevk machine:

1. imx-gpu-sdk recipe fails to build, as it requires the header which
is most probably missing in the kernel:

make: *** No rule to make target

'/development/projects/master/build-output/work/cortexa53-crypto-
mx8mm-fsl-linux/imx-gpu-sdk/5.0.2-r0/recipe-
sysroot/usr/include/bits/sys_errlist.h',
needed by
'build/Yocto/obj/Release/source/FslBase/Bits/ByteArrayUtil.o'.
Stop.

I guess any user-space stuff need updating to versions that NXP provides
with BSP 'L5.4.24_2.1.0'.

OE-core updated glibc which is the provider of 'sys_errlist.h' so maybe
that is the reason for build failure?

Correct! My bad: I did a pull of OE-Core and then your Kernel branch,
which I should not have been doing in the first place. This issue is
not from Kernel, it is a pure glibc one. Thanks for pointing it out!

2. Kernel panics on the startup, there is something related to FEC
driver:
[ 0.994893] Unable to handle kernel paging request at virtual
address 0000000000023779
[ 1.002814] Mem abort info:
[ 1.005614] ESR = 0x96000004
[ 1.008668] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.013983] SET = 0, FnV = 0
[ 1.017040] EA = 0, S1PTW = 0
[ 1.020178] Data abort info:
[ 1.023062] ISV = 0, ISS = 0x00000004
[ 1.026901] CM = 0, WnR = 0
[ 1.029872] [0000000000023779] user address but active_mm is
swapper
[ 1.036262] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1.041833] Modules linked in:
[ 1.044891] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
5.4.47+g1310c126dd1e #1
[ 1.052022] Hardware name: FSL i.MX8MM EVK board (DT)
[ 1.057073] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 1.061868] pc : fec_probe+0x280/0x1340
[ 1.065703] lr : fec_probe+0x80/0x1340
[ 1.069449] sp : ffff80001003baf0
[ 1.072761] x29: ffff80001003baf0 x28: 0000000000000000
[ 1.078072] x27: 0000000000000000 x26: ffff80001114d9b8
[ 1.083383] x25: 0000000000000000 x24: ffff000076090000
[ 1.088694] x23: ffff00007dc03bd8 x22: ffff000076404c10
[ 1.094005] x21: ffff000076404c00 x20: ffff0000762f8000
[ 1.099316] x19: ffff0000762f87c0 x18: 0000000000000020
[ 1.104626] x17: 0000000000000001 x16: 0000000000000019
[ 1.109937] x15: ffff000076090470 x14: 0000000000000000
[ 1.115248] x13: ffff000076090000 x12: 0000000000000000
[ 1.120559] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[ 1.125870] x9 : 49fffeff06fefeff x8 : 7f7f7f7f7f7f7f7f
[ 1.131180] x7 : 01fefefefefefeff x6 : 8080808080808000
[ 1.136491] x5 : 0080808080808080 x4 : 0000000000000000
[ 1.141802] x3 : ffff80001114ea48 x2 : 0000000000000000
[ 1.147113] x1 : ffff000076090000 x0 : 0000000000023779
[ 1.152424] Call trace:
[ 1.154871] fec_probe+0x280/0x1340
[ 1.158361] platform_drv_probe+0x50/0xa0
[ 1.162371] really_probe+0xd8/0x410
[ 1.165946] driver_probe_device+0x54/0xe4
[ 1.170042] device_driver_attach+0xb4/0xc0
[ 1.174225] __driver_attach+0x80/0x114
[ 1.178060] bus_for_each_dev+0x6c/0xbc
[ 1.181895] driver_attach+0x20/0x30
[ 1.185469] bus_add_driver+0xfc/0x1e0
[ 1.189218] driver_register+0x74/0x120
[ 1.193052] __platform_driver_register+0x44/0x50
[ 1.197756] fec_driver_init+0x18/0x20
[ 1.201506] do_one_initcall+0x50/0x190
[ 1.205343] kernel_init_freeable+0x194/0x22c
[ 1.209700] kernel_init+0x10/0x100
[ 1.213188] ret_from_fork+0x10/0x18
[ 1.216765] Code: 2a1303e2 b940afe1 b900b3f3 17ffff75 (b9400000)
[ 1.222866] ---[ end trace 31a90d201ff67100 ]---
[ 1.227505] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 1.235161] SMP: stopping secondary CPUs
[ 1.239085] Kernel Offset: disabled
[ 1.242572] CPU features: 0x0002,2000200c
[ 1.246579] Memory Limit: none
[ 1.249634] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b ]---

Thanks for pointing this out, I could reproduce the issue and checked.
There were still two commits missing. One revert that we believe is not
applicable to downstream fec_main.c
This one also solved the issue. The other IPU commit was also missing.
Now it works on our side. Can you confirm?

Yeap, Kernel build off commit 1e10771673463a332a7e477fcba0b9488ec5362b
boots fine on i.MX8M Mini EVK. I haven't verified whether graphics and
multimedia are OK, but in general at this state this merge is
absolutely fine!

I believe you can make a PR in https://github.com/Freescale/linux-fslc
for Otavio to have a look at it.

With that said:
Tested-By: Andrey Zhizhikin <andrey.z@gmail.com>

Philippe

Have you ported the patch [1] from upstream? Without it - the
latest
master build would fail (it is needed for binutils-2.35).

Hi Andrey,

We were building binutils-2.34 so didn't notice this issue. I've
cherry-
picked the patch you mentioned.

That's great, I've synced up the tree to your latest commit and the
perf build build went through.

Philippe

into the repository

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Flinux-fslc&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=qkHhXyQfUuvj1C9u3FbPaqrmx6TsszVHpiRi9azUyR0%3D&amp;reserved=0

Thanks and best regards,
Philippe

[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D39efdd94e314336f4acbac4c07e0f37bdc3bef71&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=gDSV0ochz6GpX1DQ6EU%2Bn6BtpvDVBNbgPkWGWEqNegY%3D&amp;reserved=0

--
Regards,
Andrey.

On Mon, Aug 10, 2020 at 6:30 PM Cengiz Can via lists.yoctoproject.org
<cengizc=gmail.com@lists.yoctoproject.org> wrote:

Hello,

I have a custom board that has IMX6 Solo Automotive Grade SoC. I need
to bring it up with Automotive Grade Linux. (Using linux-fslc 4.20).

I have copied mx6sabreauto machine and renamed it to something else,
let's say `megatron`. (I'm not really sure this is absolutely
necessary but I've done every other board bring-up like that before.).

Can someone please answer those questions for me?

1) How can I create an updater u-boot that mfgtools can use to
bootstrap? So I can flash eMMC over USB etc. And initramfs?

When I show-recipes with "*mfgtool*" I get these results and I'm confused.

fsl-image-mfgtool-initramfs: meta-freescale 1.0
linux-imx-mfgtool: meta-freescale 4.9.123 (skipped)
packagegroup-fsl-mfgtool: meta-freescale 1.0
u-boot-imx-mfgtool: meta-freescale 2017.03 (skipped)

2) How can I tag my custom machine to be COMPATIBLE with `linux-imx-mfgtool`?

linux-imx-mfgtool PROVIDES linux-mfgtool but was skipped:
incompatible with machine megatron (not in COMPATIBLE_MACHINE)

Appendix: I tried to use a machine configuration that's been already
shipped by AGL (imx6qdlsabreauto) and that machine also throws not
compatible error when asked to build `fsl-image-mfgtool-initramfs`.

3) u-boot-imx produces a SPL version of u-boot, because my board uses
default u-boot configuration of mx6sabreauto. Will this work with IMX6
Solo? If not, how can I disable SPL and make sure my BSP is aware of
it?

These might be easy to answer but I've been struggling for days and I
would be extremely happy if someone knowledgeable can help me out.

Thank you.

Cengiz Can

On Mon, 2020-08-10 at 16:10 +0200, Andrey Zhizhikin wrote:

Hey Philippe,

On Mon, Aug 10, 2020 at 1:52 PM Philippe Schenker
<philippe.schenker@toradex.com> wrote:

On Mon, 2020-08-10 at 12:42 +0200, Andrey Zhizhikin wrote:

Hello Philippe,

On Mon, Aug 10, 2020 at 12:01 PM Philippe Schenker via
lists.yoctoproject.org
<philippe.schenker=toradex.com@lists.yoctoproject.org> wrote:

Hi,

Toradex is currently working on integrating the new NXP release
'L5.4.24_2.1.0'. For this we created a new kernel branch '5.4-
2.1.x-
imx'
based on NXP's kernel 'imx_5.4.24_2.1.0'.
We already merged patches from stable linux 5.4.47 into '5.4-
2.1.x-
imx'.

This is great news! I was half the way of working on the same
update,
but now since you have the merge done - I can take your version
instead.

@Otavio: I sincerely ask you if you could place the branch '5.4-
2.1.x-
imx' that resides currently in my private github account:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fphilschenker%2Flinux-fslc%2Ftree%2F5.4-2.1.x-imx&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=BZDTVKY%2BQJDwIgsBjAeRshdTw2i7Ksh0RjGtw92ZZHw%3D&amp;reserved=0

I'll grab this one to test on i.MX8M Mini EVK now and try it out.

I've tried to build the branch from your repo with latest master of
meta-freescale, and saw couple of issue with imx8mmevk machine:

1. imx-gpu-sdk recipe fails to build, as it requires the header which
is most probably missing in the kernel:

make: *** No rule to make target

'/development/projects/master/build-output/work/cortexa53-crypto-
mx8mm-fsl-linux/imx-gpu-sdk/5.0.2-r0/recipe-
sysroot/usr/include/bits/sys_errlist.h',
needed by
'build/Yocto/obj/Release/source/FslBase/Bits/ByteArrayUtil.o'.
Stop.

I guess any user-space stuff need updating to versions that NXP provides
with BSP 'L5.4.24_2.1.0'.

OE-core updated glibc which is the provider of 'sys_errlist.h' so maybe
that is the reason for build failure?

2. Kernel panics on the startup, there is something related to FEC
driver:
[ 0.994893] Unable to handle kernel paging request at virtual
address 0000000000023779
[ 1.002814] Mem abort info:
[ 1.005614] ESR = 0x96000004
[ 1.008668] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.013983] SET = 0, FnV = 0
[ 1.017040] EA = 0, S1PTW = 0
[ 1.020178] Data abort info:
[ 1.023062] ISV = 0, ISS = 0x00000004
[ 1.026901] CM = 0, WnR = 0
[ 1.029872] [0000000000023779] user address but active_mm is
swapper
[ 1.036262] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1.041833] Modules linked in:
[ 1.044891] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
5.4.47+g1310c126dd1e #1
[ 1.052022] Hardware name: FSL i.MX8MM EVK board (DT)
[ 1.057073] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 1.061868] pc : fec_probe+0x280/0x1340
[ 1.065703] lr : fec_probe+0x80/0x1340
[ 1.069449] sp : ffff80001003baf0
[ 1.072761] x29: ffff80001003baf0 x28: 0000000000000000
[ 1.078072] x27: 0000000000000000 x26: ffff80001114d9b8
[ 1.083383] x25: 0000000000000000 x24: ffff000076090000
[ 1.088694] x23: ffff00007dc03bd8 x22: ffff000076404c10
[ 1.094005] x21: ffff000076404c00 x20: ffff0000762f8000
[ 1.099316] x19: ffff0000762f87c0 x18: 0000000000000020
[ 1.104626] x17: 0000000000000001 x16: 0000000000000019
[ 1.109937] x15: ffff000076090470 x14: 0000000000000000
[ 1.115248] x13: ffff000076090000 x12: 0000000000000000
[ 1.120559] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[ 1.125870] x9 : 49fffeff06fefeff x8 : 7f7f7f7f7f7f7f7f
[ 1.131180] x7 : 01fefefefefefeff x6 : 8080808080808000
[ 1.136491] x5 : 0080808080808080 x4 : 0000000000000000
[ 1.141802] x3 : ffff80001114ea48 x2 : 0000000000000000
[ 1.147113] x1 : ffff000076090000 x0 : 0000000000023779
[ 1.152424] Call trace:
[ 1.154871] fec_probe+0x280/0x1340
[ 1.158361] platform_drv_probe+0x50/0xa0
[ 1.162371] really_probe+0xd8/0x410
[ 1.165946] driver_probe_device+0x54/0xe4
[ 1.170042] device_driver_attach+0xb4/0xc0
[ 1.174225] __driver_attach+0x80/0x114
[ 1.178060] bus_for_each_dev+0x6c/0xbc
[ 1.181895] driver_attach+0x20/0x30
[ 1.185469] bus_add_driver+0xfc/0x1e0
[ 1.189218] driver_register+0x74/0x120
[ 1.193052] __platform_driver_register+0x44/0x50
[ 1.197756] fec_driver_init+0x18/0x20
[ 1.201506] do_one_initcall+0x50/0x190
[ 1.205343] kernel_init_freeable+0x194/0x22c
[ 1.209700] kernel_init+0x10/0x100
[ 1.213188] ret_from_fork+0x10/0x18
[ 1.216765] Code: 2a1303e2 b940afe1 b900b3f3 17ffff75 (b9400000)
[ 1.222866] ---[ end trace 31a90d201ff67100 ]---
[ 1.227505] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 1.235161] SMP: stopping secondary CPUs
[ 1.239085] Kernel Offset: disabled
[ 1.242572] CPU features: 0x0002,2000200c
[ 1.246579] Memory Limit: none
[ 1.249634] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b ]---

Thanks for pointing this out, I could reproduce the issue and checked.
There were still two commits missing. One revert that we believe is not
applicable to downstream fec_main.c
This one also solved the issue. The other IPU commit was also missing.
Now it works on our side. Can you confirm?

Philippe

Have you ported the patch [1] from upstream? Without it - the
latest
master build would fail (it is needed for binutils-2.35).

Hi Andrey,

We were building binutils-2.34 so didn't notice this issue. I've
cherry-
picked the patch you mentioned.

That's great, I've synced up the tree to your latest commit and the
perf build build went through.

Philippe

into the repository

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Flinux-fslc&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=qkHhXyQfUuvj1C9u3FbPaqrmx6TsszVHpiRi9azUyR0%3D&amp;reserved=0

Thanks and best regards,
Philippe

[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D39efdd94e314336f4acbac4c07e0f37bdc3bef71&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=gDSV0ochz6GpX1DQ6EU%2Bn6BtpvDVBNbgPkWGWEqNegY%3D&amp;reserved=0

Hello,

I have a custom board that has IMX6 Solo Automotive Grade SoC. I need
to bring it up with Automotive Grade Linux. (Using linux-fslc 4.20).

I have copied mx6sabreauto machine and renamed it to something else,
let's say `megatron`. (I'm not really sure this is absolutely
necessary but I've done every other board bring-up like that before.).

Can someone please answer those questions for me?

1) How can I create an updater u-boot that mfgtools can use to
bootstrap? So I can flash eMMC over USB etc. And initramfs?

When I show-recipes with "*mfgtool*" I get these results and I'm confused.

fsl-image-mfgtool-initramfs: meta-freescale 1.0
linux-imx-mfgtool: meta-freescale 4.9.123 (skipped)
packagegroup-fsl-mfgtool: meta-freescale 1.0
u-boot-imx-mfgtool: meta-freescale 2017.03 (skipped)

2) How can I tag my custom machine to be COMPATIBLE with `linux-imx-mfgtool`?

linux-imx-mfgtool PROVIDES linux-mfgtool but was skipped:
incompatible with machine megatron (not in COMPATIBLE_MACHINE)

3) u-boot-imx produces a SPL version of u-boot, because my board uses
default u-boot configuration of mx6sabreauto. Will this work with IMX6
Solo? If not, how can I disable SPL and make sure my BSP is aware of
it?

These might be easy to answer but I've been struggling for days and I
would be extremely happy if someone knowledgeable can help me out.

Thank you.

Cengiz Can

Hi,

I'm looking into doing the rt patch against linux-fslc-imx 5.4.51.  Doesn't look like anyone has done this for the imx8mm.  I see a recipe for linux-fslc-imx-rt 4.1.-1.0.x but looks like it's for the imx6.

Just wondering if anyone has gone down this road before and can point me toward the right path or am I going to have to weed wack through the brush to get there?

Thanks,

Brian

linux-fslc-imx-rt 4.1-1.0.x+gitX

Hey Philippe,

On Mon, Aug 10, 2020 at 1:52 PM Philippe Schenker
<philippe.schenker@toradex.com> wrote:

On Mon, 2020-08-10 at 12:42 +0200, Andrey Zhizhikin wrote:

Hello Philippe,

On Mon, Aug 10, 2020 at 12:01 PM Philippe Schenker via
lists.yoctoproject.org
<philippe.schenker=toradex.com@lists.yoctoproject.org> wrote:

Hi,

Toradex is currently working on integrating the new NXP release
'L5.4.24_2.1.0'. For this we created a new kernel branch '5.4-2.1.x-
imx'
based on NXP's kernel 'imx_5.4.24_2.1.0'.
We already merged patches from stable linux 5.4.47 into '5.4-2.1.x-
imx'.

This is great news! I was half the way of working on the same update,
but now since you have the merge done - I can take your version
instead.

@Otavio: I sincerely ask you if you could place the branch '5.4-
2.1.x-
imx' that resides currently in my private github account:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fphilschenker%2Flinux-fslc%2Ftree%2F5.4-2.1.x-imx&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=BZDTVKY%2BQJDwIgsBjAeRshdTw2i7Ksh0RjGtw92ZZHw%3D&amp;reserved=0

I'll grab this one to test on i.MX8M Mini EVK now and try it out.

I've tried to build the branch from your repo with latest master of
meta-freescale, and saw couple of issue with imx8mmevk machine:

1. imx-gpu-sdk recipe fails to build, as it requires the header which
is most probably missing in the kernel:
| make: *** No rule to make target
'/development/projects/master/build-output/work/cortexa53-crypto-mx8mm-fsl-linux/imx-gpu-sdk/5.0.2-r0/recipe-sysroot/usr/include/bits/sys_errlist.h',
needed by 'build/Yocto/obj/Release/source/FslBase/Bits/ByteArrayUtil.o'.
Stop.

2. Kernel panics on the startup, there is something related to FEC driver:
[ 0.994893] Unable to handle kernel paging request at virtual
address 0000000000023779
[ 1.002814] Mem abort info:
[ 1.005614] ESR = 0x96000004
[ 1.008668] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.013983] SET = 0, FnV = 0
[ 1.017040] EA = 0, S1PTW = 0
[ 1.020178] Data abort info:
[ 1.023062] ISV = 0, ISS = 0x00000004
[ 1.026901] CM = 0, WnR = 0
[ 1.029872] [0000000000023779] user address but active_mm is swapper
[ 1.036262] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1.041833] Modules linked in:
[ 1.044891] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.4.47+g1310c126dd1e #1
[ 1.052022] Hardware name: FSL i.MX8MM EVK board (DT)
[ 1.057073] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 1.061868] pc : fec_probe+0x280/0x1340
[ 1.065703] lr : fec_probe+0x80/0x1340
[ 1.069449] sp : ffff80001003baf0
[ 1.072761] x29: ffff80001003baf0 x28: 0000000000000000
[ 1.078072] x27: 0000000000000000 x26: ffff80001114d9b8
[ 1.083383] x25: 0000000000000000 x24: ffff000076090000
[ 1.088694] x23: ffff00007dc03bd8 x22: ffff000076404c10
[ 1.094005] x21: ffff000076404c00 x20: ffff0000762f8000
[ 1.099316] x19: ffff0000762f87c0 x18: 0000000000000020
[ 1.104626] x17: 0000000000000001 x16: 0000000000000019
[ 1.109937] x15: ffff000076090470 x14: 0000000000000000
[ 1.115248] x13: ffff000076090000 x12: 0000000000000000
[ 1.120559] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[ 1.125870] x9 : 49fffeff06fefeff x8 : 7f7f7f7f7f7f7f7f
[ 1.131180] x7 : 01fefefefefefeff x6 : 8080808080808000
[ 1.136491] x5 : 0080808080808080 x4 : 0000000000000000
[ 1.141802] x3 : ffff80001114ea48 x2 : 0000000000000000
[ 1.147113] x1 : ffff000076090000 x0 : 0000000000023779
[ 1.152424] Call trace:
[ 1.154871] fec_probe+0x280/0x1340
[ 1.158361] platform_drv_probe+0x50/0xa0
[ 1.162371] really_probe+0xd8/0x410
[ 1.165946] driver_probe_device+0x54/0xe4
[ 1.170042] device_driver_attach+0xb4/0xc0
[ 1.174225] __driver_attach+0x80/0x114
[ 1.178060] bus_for_each_dev+0x6c/0xbc
[ 1.181895] driver_attach+0x20/0x30
[ 1.185469] bus_add_driver+0xfc/0x1e0
[ 1.189218] driver_register+0x74/0x120
[ 1.193052] __platform_driver_register+0x44/0x50
[ 1.197756] fec_driver_init+0x18/0x20
[ 1.201506] do_one_initcall+0x50/0x190
[ 1.205343] kernel_init_freeable+0x194/0x22c
[ 1.209700] kernel_init+0x10/0x100
[ 1.213188] ret_from_fork+0x10/0x18
[ 1.216765] Code: 2a1303e2 b940afe1 b900b3f3 17ffff75 (b9400000)
[ 1.222866] ---[ end trace 31a90d201ff67100 ]---
[ 1.227505] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 1.235161] SMP: stopping secondary CPUs
[ 1.239085] Kernel Offset: disabled
[ 1.242572] CPU features: 0x0002,2000200c
[ 1.246579] Memory Limit: none
[ 1.249634] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b ]---

Have you ported the patch [1] from upstream? Without it - the latest
master build would fail (it is needed for binutils-2.35).

Hi Andrey,

We were building binutils-2.34 so didn't notice this issue. I've cherry-
picked the patch you mentioned.

That's great, I've synced up the tree to your latest commit and the
perf build build went through.

Philippe

into the repository

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Flinux-fslc&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=qkHhXyQfUuvj1C9u3FbPaqrmx6TsszVHpiRi9azUyR0%3D&amp;reserved=0

Thanks and best regards,
Philippe

[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D39efdd94e314336f4acbac4c07e0f37bdc3bef71&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=gDSV0ochz6GpX1DQ6EU%2Bn6BtpvDVBNbgPkWGWEqNegY%3D&amp;reserved=0

--
Regards,
Andrey.

On Mon, 2020-08-10 at 12:42 +0200, Andrey Zhizhikin wrote:

Hello Philippe,

On Mon, Aug 10, 2020 at 12:01 PM Philippe Schenker via
lists.yoctoproject.org
<philippe.schenker=toradex.com@lists.yoctoproject.org> wrote:

Hi,

Toradex is currently working on integrating the new NXP release
'L5.4.24_2.1.0'. For this we created a new kernel branch '5.4-2.1.x-
imx'
based on NXP's kernel 'imx_5.4.24_2.1.0'.
We already merged patches from stable linux 5.4.47 into '5.4-2.1.x-
imx'.

This is great news! I was half the way of working on the same update,
but now since you have the merge done - I can take your version
instead.

@Otavio: I sincerely ask you if you could place the branch '5.4-
2.1.x-
imx' that resides currently in my private github account:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fphilschenker%2Flinux-fslc%2Ftree%2F5.4-2.1.x-imx&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=BZDTVKY%2BQJDwIgsBjAeRshdTw2i7Ksh0RjGtw92ZZHw%3D&amp;reserved=0

I'll grab this one to test on i.MX8M Mini EVK now and try it out.

Have you ported the patch [1] from upstream? Without it - the latest
master build would fail (it is needed for binutils-2.35).

Hi Andrey,

We were building binutils-2.34 so didn't notice this issue. I've cherry-
picked the patch you mentioned.

Philippe

into the repository

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Flinux-fslc&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=qkHhXyQfUuvj1C9u3FbPaqrmx6TsszVHpiRi9azUyR0%3D&amp;reserved=0

Thanks and best regards,
Philippe

[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D39efdd94e314336f4acbac4c07e0f37bdc3bef71&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=gDSV0ochz6GpX1DQ6EU%2Bn6BtpvDVBNbgPkWGWEqNegY%3D&amp;reserved=0

Hello Philippe,

On Mon, Aug 10, 2020 at 12:01 PM Philippe Schenker via
lists.yoctoproject.org
<philippe.schenker=toradex.com@lists.yoctoproject.org> wrote:

Hi,

Toradex is currently working on integrating the new NXP release
'L5.4.24_2.1.0'. For this we created a new kernel branch '5.4-2.1.x-imx'
based on NXP's kernel 'imx_5.4.24_2.1.0'.
We already merged patches from stable linux 5.4.47 into '5.4-2.1.x-imx'.

This is great news! I was half the way of working on the same update,
but now since you have the merge done - I can take your version
instead.

@Otavio: I sincerely ask you if you could place the branch '5.4-2.1.x-
imx' that resides currently in my private github account:

https://github.com/philschenker/linux-fslc/tree/5.4-2.1.x-imx

I'll grab this one to test on i.MX8M Mini EVK now and try it out.

Have you ported the patch [1] from upstream? Without it - the latest
master build would fail (it is needed for binutils-2.35).

into the repository

https://github.com/Freescale/linux-fslc

Thanks and best regards,
Philippe

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39efdd94e314336f4acbac4c07e0f37bdc3bef71

--
Regards,
Andrey.

Hi,

Toradex is currently working on integrating the new NXP release
'L5.4.24_2.1.0'. For this we created a new kernel branch '5.4-2.1.x-imx'
based on NXP's kernel 'imx_5.4.24_2.1.0'.
We already merged patches from stable linux 5.4.47 into '5.4-2.1.x-imx'.

@Otavio: I sincerely ask you if you could place the branch '5.4-2.1.x-
imx' that resides currently in my private github account:

https://github.com/philschenker/linux-fslc/tree/5.4-2.1.x-imx

into the repository

https://github.com/Freescale/linux-fslc

Thanks and best regards,
Philippe

Hi Brian,

I fixed my problem yesterday, thank you for your answer.

The problem was the URL on the file firmware-imx.inc, i took this new file : http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-bsp/firmware-imx/firmware-imx.inc?h=pyro

Also, there was an other problem with the file "firmware-imx_5.4.bb" . I took the new file : http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-bsp/firmware-imx/firmware-imx_5.4.bb?h=morty
And i removed the line 3. 
Before it was : require recipes-bsp/firmware-imx/firmware-imx.inc
And now, i put : require firmware-imx.inc

Finally it works!

Thank you for your help, all of you.

See you soon, i hope.

Best regards

On Sun, Aug 2, 2020 at 11:53 PM, <kar_947@...> wrote:

Hi Bas,

Thank you for your answer. I dont know how to upgrade the yocto by the way. I am using the BSP of my IMX6 Board, given by the constructor. 
Anyway.

Which imx6 board are you using specifically?

Regards,

Brian