Hello Tim,

On Tue, Sep 21, 2021 at 7:11 PM Tim Harvey <tharvey@...> wrote:

On Tue, Sep 21, 2021 at 1:36 AM Andrey Zhizhikin <andrey.z@...> wrote:

Hello Ankur,

On Mon, Sep 20, 2021 at 11:30 PM Ankur Tyagi <ankur.tyagi@...> wrote:

Hi,

We are currently using Linux v5.4 for i.MX8 provided by recipe linux-fslc-imx_5.4.bb because as mentioned in recipe as well, branch "5.4-2.3.x-imx" from repo "linux-fslc" get changes merged from branch "imx_5.4.70_2.3.0" of linux-imx repo (https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_5.4.70_2.3.0)

Now we are planning to upgrade to Linux v5.10 and here I have few questions:

1. Recipe linux-fslc-lts_5.10.bb doesn't support i.MX8 https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... Neither I can see any merge from NXP linux-imx branch "lf-5.10.y" into linux-fslc branch "5.10.x+fslc".

When you say that i.MX8 is not supported - to which SoC you're
referring to? Mainline kernel on the [master] branch of this layer
does provide a descent support for all i.MX8M derivatives, but I'm not
entirely sure of the state for i.MX8 family SoC support since I do not
have that HW.

Andrey,

By decent support for i.MX8M derivatives you mean no USB, no PCI, no
DSI, no MIPI right? :)

It depends on the definition of "decency". :)

Actually, I was referring to 5.14.y kernel, and at least from what I
know USB support is present, although I did not test the performance
of it.

Of course, there are few pieces that are missing in upstream kernel,
which are present in the vendor one, but there are different opinion
on the topic of "Vendor vs Vanilla" kernel, some tend to favor one for
the other.

My take on this is: if the functionality I need is present in upstream
- I tend to use it, otherwise I take a vendor kernel (but would look
for an option to have at least latest LTS patchset applied on it).
This is strictly IMHO, and might not reflect the opinion of the
others. :)

I haven't looked at the yocto kernel recipes but I spend a lot of time
with the mainline kernel that I'm sure they are based on. While most
of the power-domain stuff landed in 5.13 we are still waiting for
blk-ctl which is needed to finish out the power-domain and reset
control for all of those blocks unfortunately.

Correct, linux-fslc recipe on [master] branch does provide
linux-5.14.y now with handful of patches on top. I'm not aware of
those missing pieces you referred here, but your input here is pretty
valuable! If you have any other constraints you're aware of - please
share it here, or in the layer on GitHub.

Can you specify which derivative you're talking about?

Is there any plan for that merge? If yes, any timeline by which it will happen?

I've looked into updating NXP branch [lf-5.10.y], and it is not
trivial... I'm now short on time to have a full swing of merging the
latest stable update on top of it, but probably would get to this
eventually. If there are any volunteers here that are willing to
undertake this task - this would be really appreciated.

Could you explain the difference between NXP's 'lf-' and 'imx-'
branches? I can never understand their branch naming scheme nor their
commit log prefix scheme.

This was always a mystery to me as well... I guess I would need to
make a disclaimer here: I'm neither employed nor affiliated with NXP,
so I cannot answer this. :)

If there is a person from NXP on this list, then perhaps he/she can
comment on this point.

Best regards,

Tim

If no, then can I use "imx_v8_defconfig" from linux-imx repo to build kernel using linux-fslc repo?

You can use the `defconfig` file, which is present in the layer to
build [linux-fslc] for i.MX8 machine. It resides in
recipes-kernel/linux/linux-fslc/armv8a/defconfig and is synchronized
with stable kernel release 5.14.

If you however opt-in for [linux-fslc-lts] kernel package, then the
kernel config file would be taken from
recipes-kernel/linux/linux-fslc-lts/armv8a/defconfig, which is also
synchronized with 5.10 from stable.

Are there any specific configuration options you need from
imx_v8_defconfig, which should be present in the defconfig for
mainline recipes?

i.MX8 is supported in linux-imx_5.10.bb recipe https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... which is using kernel from branch "lf-5.10.y" provided by linux-imx repo but this repo is NXP internal and doesn't get updated with stable Linux kernel. It is providing v5.10.35 (https://source.codeaurora.org/external/imx/linux-imx/log/?h=lf-5.10.y)

Correct, but as I've already pointed out - the merge of stable updates
to this kernel base is not trivial... :/

So ideally, just like v5.4 would like to use linux-fslc repo for v5.10 development as well.


Will appreciate any guidance around appropriate repo for v5.10 development for i.MX8

As one of the things to try out: you can switch the BSP flavor to use
"mainline" instead of "nxp", which would take all upstream components
instead of those provided by NXP. Be aware, that if you rely on any
functionality which is present in NXP BSP only (e.g. GPU/VPU) - this
would be unavailable in Mainline BSP.

thanks
Ankur

--
Regards,
Andrey.

--
Cheers,
Andrey.

On Tue, Sep 21, 2021 at 1:36 AM Andrey Zhizhikin <andrey.z@...> wrote:

Hello Ankur,

On Mon, Sep 20, 2021 at 11:30 PM Ankur Tyagi <ankur.tyagi@...> wrote:

Hi,

We are currently using Linux v5.4 for i.MX8 provided by recipe linux-fslc-imx_5.4.bb because as mentioned in recipe as well, branch "5.4-2.3.x-imx" from repo "linux-fslc" get changes merged from branch "imx_5.4.70_2.3.0" of linux-imx repo (https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_5.4.70_2.3.0)

Now we are planning to upgrade to Linux v5.10 and here I have few questions:

1. Recipe linux-fslc-lts_5.10.bb doesn't support i.MX8 https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... Neither I can see any merge from NXP linux-imx branch "lf-5.10.y" into linux-fslc branch "5.10.x+fslc".

When you say that i.MX8 is not supported - to which SoC you're
referring to? Mainline kernel on the [master] branch of this layer
does provide a descent support for all i.MX8M derivatives, but I'm not
entirely sure of the state for i.MX8 family SoC support since I do not
have that HW.

Andrey,

By decent support for i.MX8M derivatives you mean no USB, no PCI, no
DSI, no MIPI right? :)

I haven't looked at the yocto kernel recipes but I spend a lot of time
with the mainline kernel that I'm sure they are based on. While most
of the power-domain stuff landed in 5.13 we are still waiting for
blk-ctl which is needed to finish out the power-domain and reset
control for all of those blocks unfortunately.

Can you specify which derivative you're talking about?

Is there any plan for that merge? If yes, any timeline by which it will happen?

I've looked into updating NXP branch [lf-5.10.y], and it is not
trivial... I'm now short on time to have a full swing of merging the
latest stable update on top of it, but probably would get to this
eventually. If there are any volunteers here that are willing to
undertake this task - this would be really appreciated.

Could you explain the difference between NXP's 'lf-' and 'imx-'
branches? I can never understand their branch naming scheme nor their
commit log prefix scheme.

Best regards,

Tim

If no, then can I use "imx_v8_defconfig" from linux-imx repo to build kernel using linux-fslc repo?

You can use the `defconfig` file, which is present in the layer to
build [linux-fslc] for i.MX8 machine. It resides in
recipes-kernel/linux/linux-fslc/armv8a/defconfig and is synchronized
with stable kernel release 5.14.

If you however opt-in for [linux-fslc-lts] kernel package, then the
kernel config file would be taken from
recipes-kernel/linux/linux-fslc-lts/armv8a/defconfig, which is also
synchronized with 5.10 from stable.

Are there any specific configuration options you need from
imx_v8_defconfig, which should be present in the defconfig for
mainline recipes?

i.MX8 is supported in linux-imx_5.10.bb recipe https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... which is using kernel from branch "lf-5.10.y" provided by linux-imx repo but this repo is NXP internal and doesn't get updated with stable Linux kernel. It is providing v5.10.35 (https://source.codeaurora.org/external/imx/linux-imx/log/?h=lf-5.10.y)

Correct, but as I've already pointed out - the merge of stable updates
to this kernel base is not trivial... :/

So ideally, just like v5.4 would like to use linux-fslc repo for v5.10 development as well.


Will appreciate any guidance around appropriate repo for v5.10 development for i.MX8

As one of the things to try out: you can switch the BSP flavor to use
"mainline" instead of "nxp", which would take all upstream components
instead of those provided by NXP. Be aware, that if you rely on any
functionality which is present in NXP BSP only (e.g. GPU/VPU) - this
would be unavailable in Mainline BSP.

thanks
Ankur

--
Regards,
Andrey.

An update on this project.

From my perspective, all issues are closed now (~20).
I let a few open (although they were created a long time ago) because
I don't have the complete background to decide a better way to deal
with them.

We have 12 open issue:
3 from Freescale/meta-freescale
9 from Freescale/gstreamer-imx

I understand that dv1 (Carlos) has been doing an outstanding and
amazing job with Freescale/gstreamer-imx.

I hope I could better help him on answering the issues because almost
all issues still open are questions.

I'm going to focus (from now on) to review if a current issue can be
closed yet or not.

I'm still learning the new GitHub tools on how to better handle the
issues, so I'm also going to read some docs to find how to automate
things in the future.

Thanks,
Daiane

Hello Andrey,

Hello Ankur,

On Mon, Sep 20, 2021 at 11:30 PM Ankur Tyagi <ankur.tyagi@...> wrote:

Hi,

We are currently using Linux v5.4 for i.MX8 provided by recipe linux-fslc-imx_5.4.bb because as mentioned in recipe as well, branch "5.4-2.3.x-imx" from repo "linux-fslc" get changes merged from branch "imx_5.4.70_2.3.0" of linux-imx repo (https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_5.4.70_2.3.0)

Now we are planning to upgrade to Linux v5.10 and here I have few questions:

1. Recipe linux-fslc-lts_5.10.bb doesn't support i.MX8 https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... Neither I can see any merge from NXP linux-imx branch "lf-5.10.y" into linux-fslc branch "5.10.x+fslc".

When you say that i.MX8 is not supported - to which SoC you're
referring to? Mainline kernel on the [master] branch of this layer
does provide a descent support for all i.MX8M derivatives, but I'm not
entirely sure of the state for i.MX8 family SoC support since I do not
have that HW.

I was referring to COMPATIBLE_MACHINE in linux-fslc-lts_5.10.bb recipe.
It doesn't have mx8 in it (sorry above link is broken)

Can you specify which derivative you're talking about?

We are using i.MX8 Dual core A35

Is there any plan for that merge? If yes, any timeline by which it will happen?

I've looked into updating NXP branch [lf-5.10.y], and it is not
trivial... I'm now short on time to have a full swing of merging the
latest stable update on top of it, but probably would get to this
eventually. If there are any volunteers here that are willing to
undertake this task - this would be really appreciated.

If no, then can I use "imx_v8_defconfig" from linux-imx repo to build kernel using linux-fslc repo?

You can use the `defconfig` file, which is present in the layer to
build [linux-fslc] for i.MX8 machine. It resides in
recipes-kernel/linux/linux-fslc/armv8a/defconfig and is synchronized
with stable kernel release 5.14.

If you however opt-in for [linux-fslc-lts] kernel package, then the
kernel config file would be taken from
recipes-kernel/linux/linux-fslc-lts/armv8a/defconfig, which is also
synchronized with 5.10 from stable.

Thank you for sharing this insight, this is helpful

Are there any specific configuration options you need from
imx_v8_defconfig, which should be present in the defconfig for
mainline recipes?

I haven't done any comparison yet between imx_v8_defconfig from 5.4-2.3.x-imx branch
and mainline defconfig but now I will do that since I know which defconfig is to be used :)

i.MX8 is supported in linux-imx_5.10.bb recipe https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... which is using kernel from branch "lf-5.10.y" provided by linux-imx repo but this repo is NXP internal and doesn't get updated with stable Linux kernel. It is providing v5.10.35 (https://source.codeaurora.org/external/imx/linux-imx/log/?h=lf-5.10.y)

Correct, but as I've already pointed out - the merge of stable updates
to this kernel base is not trivial... :/

So ideally, just like v5.4 would like to use linux-fslc repo for v5.10 development as well.


Will appreciate any guidance around appropriate repo for v5.10 development for i.MX8

As one of the things to try out: you can switch the BSP flavor to use
"mainline" instead of "nxp", which would take all upstream components
instead of those provided by NXP. Be aware, that if you rely on any
functionality which is present in NXP BSP only (e.g. GPU/VPU) - this
would be unavailable in Mainline BSP.

We don't need GPU/VPU so will try your suggestion to use linux-fslc kernel
and defconfig from linux-fslc-lts/armv8a and see how it goes.

Once again, thanks for your response and suggestions.

thanks
Ankur

--
Regards,
Andrey.

Regards
Ankur
________________________________
This email is confidential and may contain information subject to legal privilege. If you are not the intended recipient please advise us of our error by return e-mail then delete this email and any attached files. You may not copy, disclose or use the contents in any way. The views expressed in this email may not be those of Gallagher Group Ltd or subsidiary companies thereof.
________________________________

Hello Ankur,

On Mon, Sep 20, 2021 at 11:30 PM Ankur Tyagi <ankur.tyagi@...> wrote:

Hi,

We are currently using Linux v5.4 for i.MX8 provided by recipe linux-fslc-imx_5.4.bb because as mentioned in recipe as well, branch "5.4-2.3.x-imx" from repo "linux-fslc" get changes merged from branch "imx_5.4.70_2.3.0" of linux-imx repo (https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_5.4.70_2.3.0)

Now we are planning to upgrade to Linux v5.10 and here I have few questions:

1. Recipe linux-fslc-lts_5.10.bb doesn't support i.MX8 https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... Neither I can see any merge from NXP linux-imx branch "lf-5.10.y" into linux-fslc branch "5.10.x+fslc".

When you say that i.MX8 is not supported - to which SoC you're
referring to? Mainline kernel on the [master] branch of this layer
does provide a descent support for all i.MX8M derivatives, but I'm not
entirely sure of the state for i.MX8 family SoC support since I do not
have that HW.

Can you specify which derivative you're talking about?

Is there any plan for that merge? If yes, any timeline by which it will happen?

I've looked into updating NXP branch [lf-5.10.y], and it is not
trivial... I'm now short on time to have a full swing of merging the
latest stable update on top of it, but probably would get to this
eventually. If there are any volunteers here that are willing to
undertake this task - this would be really appreciated.

If no, then can I use "imx_v8_defconfig" from linux-imx repo to build kernel using linux-fslc repo?

You can use the `defconfig` file, which is present in the layer to
build [linux-fslc] for i.MX8 machine. It resides in
recipes-kernel/linux/linux-fslc/armv8a/defconfig and is synchronized
with stable kernel release 5.14.

If you however opt-in for [linux-fslc-lts] kernel package, then the
kernel config file would be taken from
recipes-kernel/linux/linux-fslc-lts/armv8a/defconfig, which is also
synchronized with 5.10 from stable.

Are there any specific configuration options you need from
imx_v8_defconfig, which should be present in the defconfig for
mainline recipes?

i.MX8 is supported in linux-imx_5.10.bb recipe https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... which is using kernel from branch "lf-5.10.y" provided by linux-imx repo but this repo is NXP internal and doesn't get updated with stable Linux kernel. It is providing v5.10.35 (https://source.codeaurora.org/external/imx/linux-imx/log/?h=lf-5.10.y)

Correct, but as I've already pointed out - the merge of stable updates
to this kernel base is not trivial... :/

So ideally, just like v5.4 would like to use linux-fslc repo for v5.10 development as well.


Will appreciate any guidance around appropriate repo for v5.10 development for i.MX8

As one of the things to try out: you can switch the BSP flavor to use
"mainline" instead of "nxp", which would take all upstream components
instead of those provided by NXP. Be aware, that if you rely on any
functionality which is present in NXP BSP only (e.g. GPU/VPU) - this
would be unavailable in Mainline BSP.

thanks
Ankur

--
Regards,
Andrey.

Hi,

We are currently using Linux v5.4 for i.MX8 provided by recipe linux-fslc-imx_5.4.bb because as mentioned in recipe as well, branch "5.4-2.3.x-imx" from repo "linux-fslc" get changes merged from branch "imx_5.4.70_2.3.0" of linux-imx repo (https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_5.4.70_2.3.0)

Now we are planning to upgrade to Linux v5.10 and here I have few questions:

1. Recipe linux-fslc-lts_5.10.bb doesn't support i.MX8 https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... Neither I can see any merge from NXP linux-imx branch "lf-5.10.y" into linux-fslc branch "5.10.x+fslc". Is there any plan for that merge? If yes, any timeline by which it will happen? If no, then can I use "imx_v8_defconfig" from linux-imx repo to build kernel using linux-fslc repo?
2. i.MX8 is supported in linux-imx_5.10.bb recipe https://github.com/Freescale/meta-freescale/blob/325ad529187fb1309b0a889c5196c8df039aeea9/recipes-ke... which is using kernel from branch "lf-5.10.y" provided by linux-imx repo but this repo is NXP internal and doesn't get updated with stable Linux kernel. It is providing v5.10.35 (https://source.codeaurora.org/external/imx/linux-imx/log/?h=lf-5.10.y)
   
   So ideally, just like v5.4 would like to use linux-fslc repo for v5.10 development as well.

Will appreciate any guidance around appropriate repo for v5.10 development for i.MX8

thanks
Ankur 

Hi,

I am trying to develop a custom ASoC machine driver for an i.MX6 project using yocto. 

I have followed the yocto provided 'hello-mod' recipe as an example for out-of-tree kernel modules, but unfortunately this doesn't work for my application since it requires some in-tree header files that cannot be found when the recipe is built.

Another method I tried is to use patches in order to compile this as a usual in-tree driver.
This does work, but I am not getting any error messages if I use this approach. So even if the driver contains some known error that would prevent it from compiling, these are not shown and bitbake completes successfully.

Equally, if I patch the defconfig file to include some config with a made-up false name, it doesn't show that there was an error with this module.

 

So my questions would be:
- What is the proper way of implementing out-of-tree drivers that rely on in-tree headers?

- if that's now possible, how can I make bitbake show error when compiling the files using the patched method?

Any guidance is highly appreciated !

Hi, Luo

Thank you for your reply, I'll try this linux-qoriq.


Best regards
Lei

Hi Lei,

LSDK 21.08 components will be available in Yocto 3.3 by this month, currently you can get the kernel 5.10 recipes from https://source.codeaurora.org/external/qoriq/qoriq-components/meta-qoriq/tree/recipes-kernel/linux?h=hardknott.


Best Regards,

Zhenhua

Hi, all

Version of kernel in lsdk 2108 has been upgraded to 5.10. I want to know if there is any plan to upgrade linux-qoriq in meta-freescale. It has been 5.4 for a long time.


Best regards
Lei

hi

i am not good at English 

i have a problem with compiling  a kernel module 

a board is imx6sx evk and kernel is 5.10.35 , yocto is hardknott ( is right ? i installed with this command  : repo init -u https://source.codeaurora.org/external/imx/imx-manifest
-b imx-linux-hardknott -m imx-5.10.35-2.0.0.xml )

i make SDK form core-image-full_cmdline image   and installed  and  compiled kernel and modules ( in kernel directroy) ,a test program  without problems

but when i compile a module which is not in kernel directory

no module.ko file made  

the module source is fine  ( i copy a source into kernel/driver and make modules ,,it works fine)

and i compiled previous yocto SDK  with success 

any tips and ideas will be appreciated . thank in advance 

 

 

imx6ull@imx6ull-VirtualBox:/media/sf_shared/example/gpio-irq/dev$
imx6ull@imx6ull-VirtualBox:/media/sf_shared/example/gpio-irq/dev$ source /opt/
fsl-imx-wayland/ fsl-imx-xwayland/ VBoxGuestAdditions-5.2.32/
imx6ull@imx6ull-VirtualBox:/media/sf_shared/example/gpio-irq/dev$ source /opt/fsl-imx-
fsl-imx-wayland/ fsl-imx-xwayland/
imx6ull@imx6ull-VirtualBox:/media/sf_shared/example/gpio-irq/dev$ source /opt/fsl-imx-wayland/5.10-hardknott/
environment-setup-cortexa7t2hf-neon-poky-linux-gnueabi sysroots/
site-config-cortexa7t2hf-neon-poky-linux-gnueabi version-cortexa7t2hf-neon-poky-linux-gnueabi
imx6ull@imx6ull-VirtualBox:/media/sf_shared/example/gpio-irq/dev$ source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa7t2hf-neon-poky-linux-gnueabi
imx6ull@imx6ull-VirtualBox:/media/sf_shared/example/gpio-irq/dev$ make
make -C /home/imx6ull/work/Kernel/git.5.10.35 SUBDIRS=/media/sf_shared/example/gpio-irq/dev modules
make[1]: Entering directory '/home/imx6ull/work/imx-yocto-bsp/imx6ull/tmp/work-shared/imx6ull14x14evk/kernel-source'   --> i don't know why make goes into this directory which i made SDK
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
CHK include/generated/compile.h
make[1]: Leaving directory '/home/imx6ull/work/imx-yocto-bsp/imx6ull/tmp/work-shared/imx6ull14x14evk/kernel-source'
imx6ull@imx6ull-VirtualBox:/media/sf_shared/example/gpio-irq/dev$ ls *.ko
ls: cannot access '*.ko': No such file or directory
imx6ull@imx6ull-VirtualBox:/media/sf_shared/example/gpio-irq/dev$

and my makefile 

obj-m := of-test.o

KDIR := /home/imx6ull/work/Kernel/git.5.10.35
PWD := $(shell pwd)
NFS_ROOT = /home/imx6ull/work/imx-yocto-bsp/imx6sx/nfs_full/home/root

default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
# cp of-test.ko $(NFS_ROOT)/

clean:
rm -rf *.ko
rm -rf *.mod.*
rm -rf .*.cmd
m -rf *.o

 

On Sun, Aug 15, 2021 at 12:34 PM Daiane Angolini
<daiane.angolini@...> wrote:

Hi everyone,

I see a lot of open issues from the past 2 or 3 years on
github/Freescale projects and I'm trying to (slowly) address them as
best I can.

I am finally reviewing 2020 (latest updated) issues. My plan is to
close as much as possible, and to clean what is still an issue and
what was already solved by the normal development.

It is unfortunate that we don't actually had/have time to reply to all
of them, but I got the impression that a lot was replied at time, and
only a few issues were sitting there waiting for the future to happen.

Anyway, my point is to decrease the open issue list, so we can try to
better focus. If anyone has a better idea on how to deal with it,
please let me know.

BR,
Daiane

I'm going to close some of them, and try to assign them when I think
it's an "easy" answer, but I am sure I will make mistakes and I
apologize in advance, so I'm counting on the authors to help guide me
during this process.

If you have any suggestions, please let me know.

Daiane

Hi Neuber,

I think you forgot to hit reply-all.

On Mon, Aug 16, 2021 at 10:55 AM Neuber Sousa <neuberfran@...> wrote:

Hi Fabio,

In this video: https://mail.google.com/mail/u/0/?tab=rm&ogbl#all/FMfcgzGkZsrTzPBfwTMTnDdMWlJRQlCW

at 23 minutes and 17 seconds, Diego Suero uses the following files:

../arch/arm/mach-imx/mu.c
../drivers/rpmsg/imx_rpmsg.c
../drivers/rpmsg/imx_rpmsg_tty.c

What are the equivalent files (on mainline linux, one of them seems to be: ../drivers/remoteproc/imx_rproc.c)
so that I can implement RPmsg on mainline linux/device tree correctly?

The mailbox driver is at drivers/mailbox/imx-mailbox.c in mainline.

Or is the approach to mainline linux (RPmsg) in imx7d-pico different?


i.e.:I haven't had any problems with dunfell using kernel 5.6.xx at the moment.

Sure, feel free to use it. It is just that you will not get any
support from the community using this version.

Personally, I haven't used the remoteproc driver in mainline, so I
can't help you.

On Mon, Aug 16, 2021 at 4:56 PM Daiane Angolini
<daiane.angolini@...> wrote:

On Sun, Aug 15, 2021 at 5:24 PM Cengiz Can <cengizc@...> wrote:

On Sun, Aug 15, 2021 at 6:35 PM Daiane Angolini
<daiane.angolini@...> wrote:

Hi everyone,

Hello Daiane!

I see a lot of open issues from the past 2 or 3 years on
github/Freescale projects and I'm trying to (slowly) address them as
best I can.

That's very good news indeed.

I'm going to close some of them, and try to assign them when I think
it's an "easy" answer, but I am sure I will make mistakes and I
apologize in advance, so I'm counting on the authors to help guide me
during this process.

I'm working with meta-freescale daily (mostly i.MX6 over dunfell
branch though) so if there's something that I can help with (reviews,
build tests, things that do not require hardware testing) I would
gladly help.

That is great! Thanks a lot, Cengiz Can!

Currently the project with most old open issues is gstreamer-imx. I
found out that there are a lot of solved but not closed issues.

However, if I find anything I let you know!!! What is your github
user? I'm @angolini !

Mine is @cengizIO
^_^

Best regards,
Daiane

If you have any suggestions, please let me know.

Daiane

Thank you!
Cengiz Can

On Sun, Aug 15, 2021 at 5:24 PM Cengiz Can <cengizc@...> wrote:

On Sun, Aug 15, 2021 at 6:35 PM Daiane Angolini
<daiane.angolini@...> wrote:

Hi everyone,

Hello Daiane!

I see a lot of open issues from the past 2 or 3 years on
github/Freescale projects and I'm trying to (slowly) address them as
best I can.

That's very good news indeed.

I'm going to close some of them, and try to assign them when I think
it's an "easy" answer, but I am sure I will make mistakes and I
apologize in advance, so I'm counting on the authors to help guide me
during this process.

I'm working with meta-freescale daily (mostly i.MX6 over dunfell
branch though) so if there's something that I can help with (reviews,
build tests, things that do not require hardware testing) I would
gladly help.

That is great! Thanks a lot, Cengiz Can!

Currently the project with most old open issues is gstreamer-imx. I
found out that there are a lot of solved but not closed issues.

However, if I find anything I let you know!!! What is your github
user? I'm @angolini !

Best regards,
Daiane

If you have any suggestions, please let me know.

Daiane

Thank you!
Cengiz Can

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.

Hi Neuber,

On Sun, Aug 15, 2021 at 10:50 PM Neuber Sousa <neuberfran@...> wrote:

I have been interested in communicating between the a7 and the m4 of my imx7d-pico using RPmsg for a long time.

Today I found that this tutorial:https://www.youtube.com/watch?v=4zMyjaEgj2U&t=1182s

I don’t use mainline linux. I stay using kernel 5.6.xx with libgpiod 1.5

5.6 is an unsupported kernel version. It is not a good idea to develop
using such an unsupported kernel version.

Please see the supported ones at https://www.kernel.org/

Using libgpiod I want to press a controlled button on a7 and flash an LED (which is waiting for this command) on m4



I was checking the issue link below and I have 2 questions below:

https://community.nxp.com/t5/i-MX-Processors/I-cant-get-the-linux-side-of-yocto-rpmsg-example-for-imx6sx/m-p/490383

1 - How can I adapt this project:https://hub.mender.io/t/technexion-pico-pi-imx7/136/6

to the nxp forum project (link above) for me to get the following files: mu.c, imx_rpmsg.c, imx_rpmsg_tty.c and/or imx_rpmsg_tty.ko

These drivers only exist on the NXP vendor kernel.

Mainline uses drivers/remoteproc/imx_rproc.c instead.

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.