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.

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

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

2 - What is the best way to do RPmsg communication between a7 and m4 using Yocto on a7?

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.

If you have any suggestions, please let me know.

Daiane

Thank you!
Cengiz Can

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'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

Hello Otavio,

On Sat, 2021-08-07 at 08:33 -0300, Otavio Salvador wrote:

Em sáb., 7 de ago. de 2021 às 05:32, Thomas Perrot
<thomas.perrot@...> escreveu:

Signed-off-by: Thomas Perrot <thomas.perrot@...>

Please prepare a PR to github.

I prepared a PR to Github:
https://github.com/Freescale/meta-freescale/pull/842

Best regards,
Thomas

--
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Hello Fabio,
On Sat, 2021-08-07 at 08:46 -0300, Fabio Estevam wrote:

Hi Thomas,

On Sat, Aug 7, 2021 at 5:32 AM Thomas Perrot <
thomas.perrot@...> wrote:

+SRC_URI = "git://gitlab.apertis.org/pkg/imx-code-signing-
tool.git;protocol=https;tag=debian/3.3.0+dfsg2-1;nobranch=1"

Could you please use CST 3.3.1 instead? It is the latest one available
at:
https://www.nxp.com/webapp/Download?colCode=IMX_CST_TOOL_NEW

I have already tried to use the https link above, but it is necessary
to be identified, otherwise the archive isn't downloaded:

cat work/armv7at2hf-neon-oe-linux-gnueabi/imx-cst/3.3.1-
r0/Download\?colCode\=IMX_CST_TOOL_NEW

</script>
<script type="text/javascript" charset="utf-8">
var i18n_en = { 'We detected that your email is a Freescale
account. Please go to SPS X.500 Directory Services indicated on top of
the page to request for password reset.' : 'We detected that your email
is an employee account. Please go to SPS X.500 Directory Services
indicated on top of the page to request for password reset.','<b>NXP
(Non-legacy Freescale) employees:</b> Please use your WBI ID and
nxp.com password after <a
href="http://password.freescale.net">activating your nxp.com login
here</a>. (VPN access required)' : '<b>If you do NOT have a core ID
(Legacy NXP employees and new employees hired at a legacy NXP
facility):</b> Please use your WBI ID and nxp.com password after <a
href="http://password.freescale.net">activating your nxp.com login
here</a>. (VPN access required)','We detected that your email is a
Freescale account. To reset your password, please go to' : 'We detected
that your email is a NXP account. To reset your password, please go
to','Country' : 'Territory/Country',', Your request to reset your
Freescale.com Password' : ', Your request to reset your NXP.com
Password','<b>Legacy Freescale employees:</b> Please use your core ID
and OneIT password to log in.' : '<b>If you have a core ID (Legacy
Freescale employees and new employees hired at a legacy Freescale
facility):</b> Please use your core ID and OneIT password to log in.'}

i18n.set({lang: 'en', data : i18n_en } );
</script>
<script type="text/javascript" charset="UTF-8">
function getTranslatedText(input){
var translatedValue = i18n._(input);
return translatedValue;
}
</script>
</body>
<footer class="loadnav">
<!-- // /* FOOTER CONTENT GOES HERE */ -->
</footer>



<!--
/data/devs_git_repositories/b56858/ebiz/projects/ebiz/WebContent/NewCoS
ectionalNavRules.json -->
<script type="text/javascript" src="/resources/scripts/nxp-cms/global-
bundle.js"></script>


<script type="text/javascript">
var XMLRequest=getAjaxRequest();
function
openfeedBackBlock(window_title,blockDiagUrl,code,psp_URL,width,height,f
astpreview){
if(document.getElementById('feedBackajaxbox')!=null){

document.getElementById('feedBackajaxbox').contentarea.innerHTML="";
}
var url =
getPreviewUrl('/webapp/sps/components/hotFeedback.jsp?collateralCode=NE
WCO_FEEDBACK_FORM');
ajaxwin=dhtmlwindow.open('feedBackajaxbox',url,window_title,
'width='+width+'px,height='+height+'px,left=172px,top=1px,resize=0,scro
lling=1');
return ajaxwin ;
}

function
openthankYouBlock(window_title,blockDiagUrl,code,psp_URL,width,height,f
astpreview){
var url =
getPreviewUrl('/webapp/sps/components/hotFeedback.jsp?collateralCode=ON
LINE_THANK_YOU');
ajaxwin=dhtmlwindow.open('feedBackajaxbox',url,window_title,
'width='+width+'px,height='+height+'px,left=165px,top=1px,resize=0,scro
lling=1');
return ajaxwin ;
}

function getPreviewUrl(url, fastpreview){
if(fastpreview!=null && (trim(fastpreview) != '' ) ){
return url+'&fastpreview=1' ;
}else{
return url ;
}
}

</script>

Best regards,
Thomas