meta-freescale@lists.yoctoproject.org

i.MX28 custom board ethernet link toggling up and down

Pavithra R

#24328

Hi Team,

We are using a Custom imx28-evk based board with the latest iMX yocto images (Zeus) ported into it. Linux version 5.4.20-fslc+g18d5e274c780.

The problem is when the board boots up we keep on getting prints from Ethernet driver like this:-

Configuring network interfaces... [ 15.759903] SMSC LAN8710/LAN8720 800f0000.ethernet-1:00: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=800f0000.ethernet-1:00, irq=POLL)
udhcpc: started, v1.31.0
udhcpc: sending discover
[ 17.871399] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
[ 18.940173] fec 800f0000.ethernet eth0: Link is Down
udhcpc: sending discover
[ 19.949639] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
[ 21.019241] fec 800f0000.ethernet eth0: Link is Down
[ 22.029599] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
udhcpc: sending discover
[ 23.099242] fec 800f0000.ethernet eth0: Link is Down
[ 24.109620] fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
[ 25.180685] fec 800f0000.ethernet eth0: Link is Down

Board never gets assigned any IP. This prints goes on forever. Ethernet works fine in bootloader. We are able to do TFTP from u-boot.

Also in the kernel everything works fine with static ip configuration with a PC.

There are no errors in packet reception. output of ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:00:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:66 (66.0 B) TX bytes:5130 (5.0 KiB)
We have seen that exact issue listed in a forum https://patchwork.ozlabs.org/project/netdev/patch/20151127120919.66f2bfda@.../
But this was a five year old post and seems like the mentioned patch is not relevant at all.
Our device tree contents are
<arch/arm/boot/dts/imx28.dtsi>
mac0: ethernet@800f0000 {
compatible = "fsl,imx28-fec";
reg = <0x800f0000 0x4000>;
interrupts = <101>;
clocks = <&clks 57>, <&clks 57>, <&clks 64>;
clock-names = "ipg", "ahb", "enet_out";
status = "disabled";
};
<arch/arm/boot/dts/imx28-evk.dts>
mac0: ethernet@800f0000 {
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&mac0_pins_a>;
phy-supply = <&reg_fec_3v3>;
phy-reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
phy-reset-duration = <1000>;
status = "okay";
};
Note: when we manually set the link speed to 10mbps using ethtool, Ethernet works fine.This issue occurs with 100mbps speed and it seems to have some issue with autonegotiation.
Please consider this issue in priority and help to resolve this issue at the earliest.

Regards,

Pavithra R
Hardware Engineer
Gadgeon Smart Systems
m:	+91-94965-18808 (India)
w:	www.gadgeon.com www.delpheon.io

Opal 5 (i.MX53) SD card boot fail

Bill Randle <bill.randle@...>

#24327

I have an Opal 5 SOM and DevKit which is based on the i.MX53 ARD reference design, and am trying to get it to boot via the SD card. I'm using Yocto 3.1 (Dunfell) and meta-freescale (current). My custom machine file is a copy of the imx53ard.conf with WiFi support deleted and some other tools added in. After running 'bitbake core-image-sato' I have:
core-image-sato-imx53rover-20200503193936.rootfs.wic.gz
core-image-sato-imx53rover-20200503193936.rootfs.wic.bmap
I uncompressed the gz file and wrote it to the SD card with bmaptool.

The system does not boot and there are no messages on the debug console USB serial port (which means U-boot didn't load). The hardware is good as it will boot the Windows CE image in NAND flash. Yes, I did change the boot config switches to select boot from SD.

My questions are:
1. The last embedded project I did several years ago needed a SPL loaded on the SD card. I noticed some imx u-boot configs use the imx-uboot-spl-bootpart.wks.in, but the imx53* ones use the default imx-uboot-bootpart.wks.in script. Will the internal i.MX53 firmware load U-boot directly without the need for the SPL?
2. Does anyone who has used the i.MX53 have any suggestions on how to debug this, being as I see nothing on the console? If saw something/anything from u-boot, I would have a starting point and would know how to proceed.

This is obviously an old board, as nobody makes i.MX53 dev kits anymore (at least ones that support NAND flash). The board vendor had contracted with a third party (TrygTech) to provide Linux support. I did try to contact them via both email and phone, but have received no response to date.

-Bill

Which recipe u-boot-fslc-fw-utils or u-boot-fw-utils to install u-boot-fw-utils package for iMX6ULL?

JH

#24326

Hi,

I want to use fw_printenv/setenv utilities on iMX6ULL Linux, the
u-boot version is different between meta-freescale and oe-core,
meta-freescale uses u-boot-imx_2018.03.bb and
u-boot-fslc-fw-utils_2019.07.bb, the oe-core uses u-boot_2019.07.bb
and u-boot-fw-utils_2019.07.bb. I think I need to use meta-freescale
not oe-core, but if I add u-boot-fslc-fw-utils to my package build, it
got many errors, is it a right recipe name for the u-boot-fw-utils
package?

Thank you.

Kind regards,

Jupiter

-- 
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs

Re: a bug of perf

leimaohui

#24325

OK, thank you for your reply.

Best regards
Lei

Show quoted text

-----Original Message-----
From: Zhenhua Luo <zhenhua.luo@...>
Sent: Tuesday, April 28, 2020 10:14 AM
To: Lei, Maohui <leimaohui@...>; Otavio Salvador
<otavio.salvador@...>
Cc: andrey.z@...; meta-freescale@...; Ting Liu
<ting.liu@...>
Subject: RE: [meta-freescale] a bug of perf

Sure, it would be helpful if you can submit the patch.


Best Regards,

Zhenhua

-----Original Message-----
From: Lei, Maohui <leimaohui@...>
Sent: Tuesday, April 28, 2020 10:11 AM
To: Otavio Salvador <otavio.salvador@...>; Zhenhua Luo
<zhenhua.luo@...>
Cc: andrey.z@...; meta-freescale@...; Ting
Liu <ting.liu@...>
Subject: RE: [meta-freescale] a bug of perf

Hi,

So, may I backport this patch to linux-qoriq_5.4.bb and send a PR?


Best regards
Lei Maohui




-----Original Message-----
From: Otavio Salvador <otavio.salvador@...>
Sent: Monday, April 27, 2020 9:20 PM
To: Zhenhua Luo <zhenhua.luo@...>
Cc: andrey.z@...; Lei, Maohui/雷 茂慧 <leimaohui@...>;
meta-freescale@...; Ting Liu <ting.liu@...>
Subject: Re: [meta-freescale] a bug of perf

Zhenhua,

June is too late; you need to send the fix soon or we should drop
dunfell release for QorIQ.

On Mon, Apr 27, 2020 at 9:55 AM Zhenhua Luo <zhenhua.luo@...>
wrote:
The new QorIQ SDK based on Zeus is being prepared and plan to be
availablein June, we will port the perf patch in this release.


Best Regards,

Zhenhua

-----Original Message-----
From: meta-freescale@... <meta-
freescale@...> On Behalf Of Andrey Zhizhikin
via lists.yoctoproject.org
Sent: Monday, April 27, 2020 3:00 PM
To: leimaohui <leimaohui@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] a bug of perf

On Mon, Apr 27, 2020 at 8:54 AM leimaohui
<leimaohui@...>wrote:

Hi,

I met perf bug by meta-freescale as following:
--------------------------------------------------------------
--
--
---
tmp/work/armv8-linux/perf/1.0-r9/perf-1.0/perf-in.o: in
function`find_address_in_section':
| /usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:
| 20
| 0: undefinedreference to `bfd_get_section_flags'
perf/1.0-r9/recipe-sysroot-native/usr/bin/aarch64-linux/../../
li
be
xec/aarch64-linux/gcc/aarch64-linux/9.3.0/ld:
/usr/src/debug/perf/1.0-r9/perf-
1.0/tools/perf/util/srcline.c:204: undefined reference to`bfd_get_section_vma'

I found that this bug has been fixed in upstream:
--------------------------------------------------------------
--
--
--- commit f4d7dbafb103e4f782323017c239c548871c1567
Author: Changbin Du <changbin.du@...>
Date:   Tue Jan 28 23:29:38 2020 +0800

    perf: Make perf able to build with latest libbfd

    libbfd has changed the bfd_section_* macros to inline functions
    bfd_section_<field> since 2019-09-18. See below two commits:
      ohttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2
Fw
ww
.sour
ceware.org%2Fml%2Fgdb-cvs%2F2019-
09%2Fmsg00064.html&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf
7
1fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c30163
5%
7C0%7C0%7C637235676418274147&amp;sdata=FwmBOoCsXBdzRuExOVTl6r
26
3T26N9hTw5f5igDsibc%3D&amp;reserved=0
      o
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
sourceware.org%2Fml%2Fgdb-cvs%2F2019-09%2Fmsg00072.html&amp;data=02%7C
01%7Czhenhua.luo%40nxp.com%7Cf71fca435a564dbe676308d7ea78b14f%7
C6
86ea1
d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637235676418274147&amp;s
dat
a=1MxK
Fc6pEwt0rlYQ0%2Fc1%2F%2FETpkOLRMyyC99FRh0aCpU%3D&amp;reserved=0

    This fix make perf able to build with both old and new libbfd.

    Signed-off-by: Changbin Du <changbin.du@...>
    Acked-by: Jiri Olsa <jolsa@...>
    Cc: Peter Zijlstra <peterz@...>
    Link:https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2
Fl
or
e.kerne
l.org%2Flkml%2F20200128152938.31413-1-
changbin.du%40gmail.com&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%
7Cf71fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c3
01
635%7C0%7C0%7C637235676418274147&amp;sdata=SWo0QUl5N%2F7HTYJ
Ur
Udyo4zgn%2BG844E4ZdB9cLcCEco%3D&amp;reserved=0
    Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
    Signed-off-by: Bruce Ashfield <bruce.ashfield@...>

 tools/perf/util/srcline.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

I want to know when linux-qoriq will be updated next time?I have this patch ported to linux-imx kernel [1], probably you
should do the same for linux-qoriq. Try to add it into the
recipe and if itwould work out - send a PR.


Best regards
Lei Maohui




[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
2F
gi
thub.co
m%2FFreescale%2Fmeta-freescale%2Fblob%2Fmaster%2Frecipes-
kernel%2Flinux%2Flinux-imx-5.4.3%2F0001-perf-Make-perf-able-to-b
ui
ld
-with-
latest-
libbfd.patch&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf71fca435a
5
64dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
C0
%7C637235676418274147&amp;sdata=7GeXcgw7qGut%2FI%2Bn%2Bq%2
B42A
8go1FaegAgzOzNVMPpwsk%3D&amp;reserved=0

--
Regards,
Andrey.

--
Otavio Salvador                             O.S. Systems
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.o
ssy
stems.com.br%2F&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7C30020
e3359094e7919d608d7eb1976ce%7C686ea1d3bc2b4c6fa92cd99c5c301635
%7C
0%7C0%7C637236366912969329&amp;sdata=8U%2BNwWIXqiFvSeRvWEWXB
U
eARA%2BM4qyI%2BIhbWeLx8eQ%3D&amp;reserved=0
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode.
ossy
stems.com.br%2F&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7C30020
e3359094e7919d608d7eb1976ce%7C686ea1d3bc2b4c6fa92cd99c5c301635
%7C
0%7C0%7C637236366912969329&amp;sdata=CQ7mUCam9qkJfNNEVuyxLajE
O
VSUFRf8sjYKaomopak%3D&amp;reserved=0
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: a bug of perf

Zhenhua Luo

#24324

Sure, it would be helpful if you can submit the patch. 

Best Regards, 

Zhenhua

Show quoted text

-----Original Message-----
From: Lei, Maohui <leimaohui@...>
Sent: Tuesday, April 28, 2020 10:11 AM
To: Otavio Salvador <otavio.salvador@...>; Zhenhua Luo
<zhenhua.luo@...>
Cc: andrey.z@...; meta-freescale@...; Ting Liu
<ting.liu@...>
Subject: RE: [meta-freescale] a bug of perf

Hi,

So, may I backport this patch to linux-qoriq_5.4.bb and send a PR?


Best regards
Lei Maohui




-----Original Message-----
From: Otavio Salvador <otavio.salvador@...>
Sent: Monday, April 27, 2020 9:20 PM
To: Zhenhua Luo <zhenhua.luo@...>
Cc: andrey.z@...; Lei, Maohui/雷 茂慧 <leimaohui@...>;
meta-freescale@...; Ting Liu <ting.liu@...>
Subject: Re: [meta-freescale] a bug of perf

Zhenhua,

June is too late; you need to send the fix soon or we should drop
dunfell release for QorIQ.

On Mon, Apr 27, 2020 at 9:55 AM Zhenhua Luo <zhenhua.luo@...>
wrote:
The new QorIQ SDK based on Zeus is being prepared and plan to be
availablein June, we will port the perf patch in this release.


Best Regards,

Zhenhua

-----Original Message-----
From: meta-freescale@... <meta-
freescale@...> On Behalf Of Andrey Zhizhikin
via lists.yoctoproject.org
Sent: Monday, April 27, 2020 3:00 PM
To: leimaohui <leimaohui@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] a bug of perf

On Mon, Apr 27, 2020 at 8:54 AM leimaohui
<leimaohui@...>wrote:

Hi,

I met perf bug by meta-freescale as following:
----------------------------------------------------------------
--
---
tmp/work/armv8-linux/perf/1.0-r9/perf-1.0/perf-in.o: in function`find_address_in_section':
| /usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:
| 20
| 0: undefinedreference to `bfd_get_section_flags'
perf/1.0-r9/recipe-sysroot-native/usr/bin/aarch64-linux/../../li
be
xec/aarch64-linux/gcc/aarch64-linux/9.3.0/ld: /usr/src/debug/perf/1.0-r9/perf-
1.0/tools/perf/util/srcline.c:204: undefined reference to`bfd_get_section_vma'

I found that this bug has been fixed in upstream:
----------------------------------------------------------------
--
--- commit f4d7dbafb103e4f782323017c239c548871c1567
Author: Changbin Du <changbin.du@...>
Date:   Tue Jan 28 23:29:38 2020 +0800

    perf: Make perf able to build with latest libbfd

    libbfd has changed the bfd_section_* macros to inline functions
    bfd_section_<field> since 2019-09-18. See below two commits:
      ohttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
ww
.sour
ceware.org%2Fml%2Fgdb-cvs%2F2019-
09%2Fmsg00064.html&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf
7
1fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c30163
5%
7C0%7C0%7C637235676418274147&amp;sdata=FwmBOoCsXBdzRuExOVTl6r
26
3T26N9hTw5f5igDsibc%3D&amp;reserved=0
      o
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
sourceware.org%2Fml%2Fgdb-cvs%2F2019-09%2Fmsg00072.html&amp;data=02%7C
01%7Czhenhua.luo%40nxp.com%7Cf71fca435a564dbe676308d7ea78b14f%7
C6
86ea1
d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637235676418274147&amp;s
dat
a=1MxK
Fc6pEwt0rlYQ0%2Fc1%2F%2FETpkOLRMyyC99FRh0aCpU%3D&amp;reserved=0

    This fix make perf able to build with both old and new libbfd.

    Signed-off-by: Changbin Du <changbin.du@...>
    Acked-by: Jiri Olsa <jolsa@...>
    Cc: Peter Zijlstra <peterz@...>
    Link:https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fl
or
e.kerne
l.org%2Flkml%2F20200128152938.31413-1-
changbin.du%40gmail.com&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%
7Cf71fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c3
01
635%7C0%7C0%7C637235676418274147&amp;sdata=SWo0QUl5N%2F7HTYJ
Ur
Udyo4zgn%2BG844E4ZdB9cLcCEco%3D&amp;reserved=0
    Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
    Signed-off-by: Bruce Ashfield <bruce.ashfield@...>

 tools/perf/util/srcline.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

I want to know when linux-qoriq will be updated next time?I have this patch ported to linux-imx kernel [1], probably you
should do the same for linux-qoriq. Try to add it into the recipe
and if itwould work out - send a PR.


Best regards
Lei Maohui




[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
gi
thub.co
m%2FFreescale%2Fmeta-freescale%2Fblob%2Fmaster%2Frecipes-
kernel%2Flinux%2Flinux-imx-5.4.3%2F0001-perf-Make-perf-able-to-bui
ld
-with-
latest-
libbfd.patch&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf71fca435a
5
64dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
C0
%7C637235676418274147&amp;sdata=7GeXcgw7qGut%2FI%2Bn%2Bq%2B42A
8go1FaegAgzOzNVMPpwsk%3D&amp;reserved=0

--
Regards,
Andrey.

--
Otavio Salvador                             O.S. Systems
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ossy
stems.com.br%2F&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7C30020
e3359094e7919d608d7eb1976ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
0%7C0%7C637236366912969329&amp;sdata=8U%2BNwWIXqiFvSeRvWEWXBU
eARA%2BM4qyI%2BIhbWeLx8eQ%3D&amp;reserved=0
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode.ossy
stems.com.br%2F&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7C30020
e3359094e7919d608d7eb1976ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
0%7C0%7C637236366912969329&amp;sdata=CQ7mUCam9qkJfNNEVuyxLajEO
VSUFRf8sjYKaomopak%3D&amp;reserved=0
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: a bug of perf

leimaohui

#24323

Hi,

So, may I backport this patch to linux-qoriq_5.4.bb and send a PR?

Best regards
Lei Maohui

Show quoted text

-----Original Message-----
From: Otavio Salvador <otavio.salvador@...>
Sent: Monday, April 27, 2020 9:20 PM
To: Zhenhua Luo <zhenhua.luo@...>
Cc: andrey.z@...; Lei, Maohui/雷 茂慧 <leimaohui@...>;
meta-freescale@...; Ting Liu <ting.liu@...>
Subject: Re: [meta-freescale] a bug of perf

Zhenhua,

June is too late; you need to send the fix soon or we should drop dunfell release
for QorIQ.

On Mon, Apr 27, 2020 at 9:55 AM Zhenhua Luo <zhenhua.luo@...>
wrote:
The new QorIQ SDK based on Zeus is being prepared and plan to be availablein June, we will port the perf patch in this release.


Best Regards,

Zhenhua

-----Original Message-----
From: meta-freescale@... <meta-
freescale@...> On Behalf Of Andrey Zhizhikin via
lists.yoctoproject.org
Sent: Monday, April 27, 2020 3:00 PM
To: leimaohui <leimaohui@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] a bug of perf

On Mon, Apr 27, 2020 at 8:54 AM leimaohui <leimaohui@...>wrote:

Hi,

I met perf bug by meta-freescale as following:
------------------------------------------------------------------
---
tmp/work/armv8-linux/perf/1.0-r9/perf-1.0/perf-in.o: in function`find_address_in_section':
| /usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:20
| 0: undefinedreference to `bfd_get_section_flags'
perf/1.0-r9/recipe-sysroot-native/usr/bin/aarch64-linux/../../libe
xec/aarch64-linux/gcc/aarch64-linux/9.3.0/ld: /usr/src/debug/perf/1.0-r9/perf-
1.0/tools/perf/util/srcline.c:204: undefined reference to`bfd_get_section_vma'

I found that this bug has been fixed in upstream:
------------------------------------------------------------------
--- commit f4d7dbafb103e4f782323017c239c548871c1567
Author: Changbin Du <changbin.du@...>
Date:   Tue Jan 28 23:29:38 2020 +0800

    perf: Make perf able to build with latest libbfd

    libbfd has changed the bfd_section_* macros to inline functions
    bfd_section_<field> since 2019-09-18. See below two commits:
      ohttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
.sour
ceware.org%2Fml%2Fgdb-cvs%2F2019-
09%2Fmsg00064.html&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf
7
1fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c30163
5%
7C0%7C0%7C637235676418274147&amp;sdata=FwmBOoCsXBdzRuExOVTl6r
26
3T26N9hTw5f5igDsibc%3D&amp;reserved=0
      o
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
sourceware.org%2Fml%2Fgdb-cvs%2F2019-09%2Fmsg00072.html&amp;data=02%7C
01%7Czhenhua.luo%40nxp.com%7Cf71fca435a564dbe676308d7ea78b14f%7
C6
86ea1
d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637235676418274147&amp;s
dat
a=1MxK
Fc6pEwt0rlYQ0%2Fc1%2F%2FETpkOLRMyyC99FRh0aCpU%3D&amp;reserved=0

    This fix make perf able to build with both old and new libbfd.

    Signed-off-by: Changbin Du <changbin.du@...>
    Acked-by: Jiri Olsa <jolsa@...>
    Cc: Peter Zijlstra <peterz@...>
    Link:https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flor
e.kerne
l.org%2Flkml%2F20200128152938.31413-1-
changbin.du%40gmail.com&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%
7Cf71fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c3
01
635%7C0%7C0%7C637235676418274147&amp;sdata=SWo0QUl5N%2F7HTYJ
Ur
Udyo4zgn%2BG844E4ZdB9cLcCEco%3D&amp;reserved=0
    Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
    Signed-off-by: Bruce Ashfield <bruce.ashfield@...>

 tools/perf/util/srcline.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

I want to know when linux-qoriq will be updated next time?I have this patch ported to linux-imx kernel [1], probably you
should do the same for linux-qoriq. Try to add it into the recipe and if itwould work out - send a PR.


Best regards
Lei Maohui




[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
thub.co
m%2FFreescale%2Fmeta-freescale%2Fblob%2Fmaster%2Frecipes-
kernel%2Flinux%2Flinux-imx-5.4.3%2F0001-perf-Make-perf-able-to-build
-with-
latest-
libbfd.patch&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf71fca435a
5
64dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
C0
%7C637235676418274147&amp;sdata=7GeXcgw7qGut%2FI%2Bn%2Bq%2B42A
8go1FaegAgzOzNVMPpwsk%3D&amp;reserved=0

--
Regards,
Andrey.

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

Re: a bug of perf

Otavio Salvador

#24322

Zhenhua,

June is too late; you need to send the fix soon or we should drop
dunfell release for QorIQ.

Show quoted text

On Mon, Apr 27, 2020 at 9:55 AM Zhenhua Luo <zhenhua.luo@...> wrote:
The new QorIQ SDK based on Zeus is being prepared and plan to be available in June, we will port the perf patch in this release.


Best Regards,

Zhenhua

-----Original Message-----
From: meta-freescale@... <meta-
freescale@...> On Behalf Of Andrey Zhizhikin via
lists.yoctoproject.org
Sent: Monday, April 27, 2020 3:00 PM
To: leimaohui <leimaohui@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] a bug of perf

On Mon, Apr 27, 2020 at 8:54 AM leimaohui <leimaohui@...> wrote:

Hi,

I met perf bug by meta-freescale as following:
---------------------------------------------------------------------
tmp/work/armv8-linux/perf/1.0-r9/perf-1.0/perf-in.o: in function`find_address_in_section':
| /usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:200: undefinedreference to `bfd_get_section_flags'
perf/1.0-r9/recipe-sysroot-native/usr/bin/aarch64-linux/../../libexec/aarch64-linux/gcc/aarch64-linux/9.3.0/ld: /usr/src/debug/perf/1.0-r9/perf-
1.0/tools/perf/util/srcline.c:204: undefined reference to `bfd_get_section_vma'

I found that this bug has been fixed in upstream:
---------------------------------------------------------------------
commit f4d7dbafb103e4f782323017c239c548871c1567
Author: Changbin Du <changbin.du@...>
Date:   Tue Jan 28 23:29:38 2020 +0800

    perf: Make perf able to build with latest libbfd

    libbfd has changed the bfd_section_* macros to inline functions
    bfd_section_<field> since 2019-09-18. See below two commits:
      ohttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sour
ceware.org%2Fml%2Fgdb-cvs%2F2019-
09%2Fmsg00064.html&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf7
1fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c301635%
7C0%7C0%7C637235676418274147&amp;sdata=FwmBOoCsXBdzRuExOVTl6r26
3T26N9hTw5f5igDsibc%3D&amp;reserved=0
      o
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
sourceware.org%2Fml%2Fgdb-cvs%2F2019-09%2Fmsg00072.html&amp;data=02%7C
01%7Czhenhua.luo%40nxp.com%7Cf71fca435a564dbe676308d7ea78b14f%7C6
86ea1
d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637235676418274147&amp;sdat
a=1MxK
Fc6pEwt0rlYQ0%2Fc1%2F%2FETpkOLRMyyC99FRh0aCpU%3D&amp;reserved=0

    This fix make perf able to build with both old and new libbfd.

    Signed-off-by: Changbin Du <changbin.du@...>
    Acked-by: Jiri Olsa <jolsa@...>
    Cc: Peter Zijlstra <peterz@...>
    Link:https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flore.kerne
l.org%2Flkml%2F20200128152938.31413-1-
changbin.du%40gmail.com&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%
7Cf71fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c301
635%7C0%7C0%7C637235676418274147&amp;sdata=SWo0QUl5N%2F7HTYJUr
Udyo4zgn%2BG844E4ZdB9cLcCEco%3D&amp;reserved=0
    Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
    Signed-off-by: Bruce Ashfield <bruce.ashfield@...>

 tools/perf/util/srcline.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

I want to know when linux-qoriq will be updated next time?I have this patch ported to linux-imx kernel [1], probably you should do the same
for linux-qoriq. Try to add it into the recipe and if it would work out - send a PR.


Best regards
Lei Maohui




[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2FFreescale%2Fmeta-freescale%2Fblob%2Fmaster%2Frecipes-
kernel%2Flinux%2Flinux-imx-5.4.3%2F0001-perf-Make-perf-able-to-build-with-
latest-
libbfd.patch&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf71fca435a5
64dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
%7C637235676418274147&amp;sdata=7GeXcgw7qGut%2FI%2Bn%2Bq%2B42A
8go1FaegAgzOzNVMPpwsk%3D&amp;reserved=0

--
Regards,
Andrey.

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

Re: a bug of perf

Zhenhua Luo

#24321

The new QorIQ SDK based on Zeus is being prepared and plan to be available in June, we will port the perf patch in this release. 

Best Regards, 

Zhenhua

Show quoted text

-----Original Message-----
From: meta-freescale@... <meta-
freescale@...> On Behalf Of Andrey Zhizhikin via
lists.yoctoproject.org
Sent: Monday, April 27, 2020 3:00 PM
To: leimaohui <leimaohui@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] a bug of perf

On Mon, Apr 27, 2020 at 8:54 AM leimaohui <leimaohui@...> wrote:

Hi,

I met perf bug by meta-freescale as following:
---------------------------------------------------------------------
tmp/work/armv8-linux/perf/1.0-r9/perf-1.0/perf-in.o: in function`find_address_in_section':
| /usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:200: undefinedreference to `bfd_get_section_flags'
perf/1.0-r9/recipe-sysroot-native/usr/bin/aarch64-linux/../../libexec/aarch64-linux/gcc/aarch64-linux/9.3.0/ld: /usr/src/debug/perf/1.0-r9/perf-
1.0/tools/perf/util/srcline.c:204: undefined reference to `bfd_get_section_vma'

I found that this bug has been fixed in upstream:
---------------------------------------------------------------------
commit f4d7dbafb103e4f782323017c239c548871c1567
Author: Changbin Du <changbin.du@...>
Date:   Tue Jan 28 23:29:38 2020 +0800

    perf: Make perf able to build with latest libbfd

    libbfd has changed the bfd_section_* macros to inline functions
    bfd_section_<field> since 2019-09-18. See below two commits:
      ohttps://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sour
ceware.org%2Fml%2Fgdb-cvs%2F2019-
09%2Fmsg00064.html&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf7
1fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c301635%
7C0%7C0%7C637235676418274147&amp;sdata=FwmBOoCsXBdzRuExOVTl6r26
3T26N9hTw5f5igDsibc%3D&amp;reserved=0
      o
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
sourceware.org%2Fml%2Fgdb-cvs%2F2019-09%2Fmsg00072.html&amp;data=02%7C
01%7Czhenhua.luo%40nxp.com%7Cf71fca435a564dbe676308d7ea78b14f%7C6
86ea1
d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637235676418274147&amp;sdat
a=1MxK
Fc6pEwt0rlYQ0%2Fc1%2F%2FETpkOLRMyyC99FRh0aCpU%3D&amp;reserved=0

    This fix make perf able to build with both old and new libbfd.

    Signed-off-by: Changbin Du <changbin.du@...>
    Acked-by: Jiri Olsa <jolsa@...>
    Cc: Peter Zijlstra <peterz@...>
    Link:https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flore.kerne
l.org%2Flkml%2F20200128152938.31413-1-
changbin.du%40gmail.com&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%
7Cf71fca435a564dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c301
635%7C0%7C0%7C637235676418274147&amp;sdata=SWo0QUl5N%2F7HTYJUr
Udyo4zgn%2BG844E4ZdB9cLcCEco%3D&amp;reserved=0
    Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
    Signed-off-by: Bruce Ashfield <bruce.ashfield@...>

 tools/perf/util/srcline.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

I want to know when linux-qoriq will be updated next time?I have this patch ported to linux-imx kernel [1], probably you should do the same
for linux-qoriq. Try to add it into the recipe and if it would work out - send a PR.


Best regards
Lei Maohui




[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2FFreescale%2Fmeta-freescale%2Fblob%2Fmaster%2Frecipes-
kernel%2Flinux%2Flinux-imx-5.4.3%2F0001-perf-Make-perf-able-to-build-with-
latest-
libbfd.patch&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cf71fca435a5
64dbe676308d7ea78b14f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
%7C637235676418274147&amp;sdata=7GeXcgw7qGut%2FI%2Bn%2Bq%2B42A
8go1FaegAgzOzNVMPpwsk%3D&amp;reserved=0

--
Regards,
Andrey.

Re: a bug of perf

Andrey Zhizhikin

#24320

On Mon, Apr 27, 2020 at 8:54 AM leimaohui <leimaohui@...> wrote:

Hi,

I met perf bug by meta-freescale as following:
---------------------------------------------------------------------
tmp/work/armv8-linux/perf/1.0-r9/perf-1.0/perf-in.o: in function `find_address_in_section':
| /usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:200: undefined reference to `bfd_get_section_flags'
perf/1.0-r9/recipe-sysroot-native/usr/bin/aarch64-linux/../../libexec/aarch64-linux/gcc/aarch64-linux/9.3.0/ld: /usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:204: undefined reference to `bfd_get_section_vma'

I found that this bug has been fixed in upstream:
---------------------------------------------------------------------
commit f4d7dbafb103e4f782323017c239c548871c1567
Author: Changbin Du <changbin.du@...>
Date:   Tue Jan 28 23:29:38 2020 +0800

    perf: Make perf able to build with latest libbfd

    libbfd has changed the bfd_section_* macros to inline functions
    bfd_section_<field> since 2019-09-18. See below two commits:
      o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html
      o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html

    This fix make perf able to build with both old and new libbfd.

    Signed-off-by: Changbin Du <changbin.du@...>
    Acked-by: Jiri Olsa <jolsa@...>
    Cc: Peter Zijlstra <peterz@...>
    Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
    Signed-off-by: Bruce Ashfield <bruce.ashfield@...>

 tools/perf/util/srcline.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

I want to know when linux-qoriq will be updated next time?I have this patch ported to linux-imx kernel [1], probably you should
do the same for linux-qoriq. Try to add it into the recipe and if it
would work out - send a PR.


Best regards
Lei Maohui




[1]: https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-imx-5.4.3/0001-perf-Make-perf-able-to-build-with-latest-libbfd.patch

-- 
Regards,
Andrey.

a bug of perf

leimaohui

#24319

Hi,

I met perf bug by meta-freescale as following:
---------------------------------------------------------------------
tmp/work/armv8-linux/perf/1.0-r9/perf-1.0/perf-in.o: in function `find_address_in_section':
| /usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:200: undefined reference to `bfd_get_section_flags'
perf/1.0-r9/recipe-sysroot-native/usr/bin/aarch64-linux/../../libexec/aarch64-linux/gcc/aarch64-linux/9.3.0/ld: /usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:204: undefined reference to `bfd_get_section_vma'

I found that this bug has been fixed in upstream: 
---------------------------------------------------------------------
commit f4d7dbafb103e4f782323017c239c548871c1567
Author: Changbin Du <changbin.du@...>
Date:   Tue Jan 28 23:29:38 2020 +0800

    perf: Make perf able to build with latest libbfd

    libbfd has changed the bfd_section_* macros to inline functions
    bfd_section_<field> since 2019-09-18. See below two commits:
      o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html
      o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html

    This fix make perf able to build with both old and new libbfd.

    Signed-off-by: Changbin Du <changbin.du@...>
    Acked-by: Jiri Olsa <jolsa@...>
    Cc: Peter Zijlstra <peterz@...>
    Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@...>
    Signed-off-by: Bruce Ashfield <bruce.ashfield@...>

 tools/perf/util/srcline.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

I want to know when linux-qoriq will be updated next time?

Best regards
Lei Maohui

Re: nitrogen6x machine config and imxpxp problems

Gary Bisson

#24318

Hi Carlos,

On Fri, Apr 24, 2020 at 09:41:26AM +0200, Carlos Rafael Giani wrote:
Two problems actually.

First, gstreamer1.0-plugins-imx has its PxP plugin enabled.Sure, that has been acceptable to us as as most customer don't use PxP
on i.MX6 but prefer GPU2D/3D features.

Second, libimxdmabuffer's PxP allocator is enabled. This allocator is then
tested for in the test-alloc program. This program is what's used by
libimxdmabuffer's ptest. test-alloc then detects a failure while trying to
use the PxP allocator (of course, since PxP is not actually present),
causing test-alloc to report a failure.How did that work on GStreamer-imx before? Because this issue has been
there all along.
Was there a runtime check to enable/disable features? (I don't recall)

I could change libimxdmabuffer's test-alloc to report success if at least
one tested allocator works, but I'm not sure if this is really the right way
to go. This would pave the way for run-time checks that enable/disable
features. From what I know, this kind of thing isn't considered good
practice in Yocto, since it tends to make builds less deterministic.I know the "build" has to be deterministic but is there "runtime"
recommendations from Yocto?

Regards,
Gary

Re: nitrogen6x machine config and imxpxp problems

Carlos Rafael Giani

#24317

Two problems actually.

First, gstreamer1.0-plugins-imx has its PxP plugin enabled.

Second, libimxdmabuffer's PxP allocator is enabled. This allocator is then tested for in the test-alloc program. This program is what's used by libimxdmabuffer's ptest. test-alloc then detects a failure while trying to use the PxP allocator (of course, since PxP is not actually present), causing test-alloc to report a failure.

I could change libimxdmabuffer's test-alloc to report success if at least one tested allocator works, but I'm not sure if this is really the right way to go. This would pave the way for run-time checks that enable/disable features. From what I know, this kind of thing isn't considered good practice in Yocto, since it tends to make builds less deterministic.

Carlos

Show quoted text

On 24.04.20 09:29, Gary Bisson wrote:
Hi Carlos,

On Fri, Apr 24, 2020 at 08:59:34AM +0200, Carlos Rafael Giani wrote:
The nitrogen6x machine config also supports other machines according to the
comment block inside the .conf file:

# Note that this machine configuration also supports the SABRE Lite
# reference design and the Nitrogen6X-SOM.
#
# By default, this machine will build for the standard Quad-Core, 1GB
# option.
#
# To build U-Boot for other CPU or memory combinations, you can set
# the UBOOT_MACHINE variable in your local.conf according to the
# following table:
#
# Processor           Memory    Configuration
# --------------      ------    --------------------
# i.MX6Quad/Dual        1GB     nitrogen6q_config
# i.MX6Quad/Dual        2GB     nitrogen6q2g_config
# i.MX6Quad/Dual        4GB     nitrogen6_max_config
# i.MX6Dual-Lite        1GB     nitrogen6dl_config
# i.MX6Dual-Lite        2GB     nitrogen6dl2g_config
# i.MX6Solo           512MB     nitrogen6s_config
# i.MX6Solo             1GB     nitrogen6s1g_configThis is the reason for this line in the config:

MACHINEOVERRIDES =. "mx6:mx6dl:mx6q:"

This is a problem, since the features between the different i.MX6 SoC
variants to differ. In particular, imxpxp is enabled because of this, even
though my nitrogen6x - which has an i.MX6 Quad - has no PxP support. As a
result, software whose recipes test for imxpxp presence incorrectly have
their PxP features enabled. This is especially bad if it affects ptest
packages, which then fail.Well the board itself (Nitrogen6x) is the same, only the CPU populated
changed (pin-to-pin compatible) so it made sense not to separate the
machine.

Then as the commit from Eric explained [1], the main reason was for the
firmware-imx vpu files, without "mx6dl" it wouldn't install the matching
firmware.

This isn't ideal but has worked for the past 6 years, so I'm not sure
what is the ptest packages error, can you copy it here?

I now wonder what to do here. Split nitrogen6x.conf into multiple individual
recipes? Or selectively remove machineoverrides somehow?At this stage of the product (entering legacy) we do not plan on
splitting its machine.

Also want to point out that even NXP SABRE SD machine does the same
thing [2] so I doubt the solution is splitting it or removing an
override.

Regards,
Gary

[1] https://github.com/Freescale/meta-freescale-3rdparty/commit/9d34fea1
[2] https://github.com/Freescale/meta-freescale/blob/zeus/conf/machine/imx6qdlsabresd.conf

Re: nitrogen6x machine config and imxpxp problems

Gary Bisson

#24316

Hi Carlos,

On Fri, Apr 24, 2020 at 08:59:34AM +0200, Carlos Rafael Giani wrote:
The nitrogen6x machine config also supports other machines according to the
comment block inside the .conf file:

# Note that this machine configuration also supports the SABRE Lite
# reference design and the Nitrogen6X-SOM.
#
# By default, this machine will build for the standard Quad-Core, 1GB
# option.
#
# To build U-Boot for other CPU or memory combinations, you can set
# the UBOOT_MACHINE variable in your local.conf according to the
# following table:
#
# Processor           Memory    Configuration
# --------------      ------    --------------------
# i.MX6Quad/Dual        1GB     nitrogen6q_config
# i.MX6Quad/Dual        2GB     nitrogen6q2g_config
# i.MX6Quad/Dual        4GB     nitrogen6_max_config
# i.MX6Dual-Lite        1GB     nitrogen6dl_config
# i.MX6Dual-Lite        2GB     nitrogen6dl2g_config
# i.MX6Solo           512MB     nitrogen6s_config
# i.MX6Solo             1GB     nitrogen6s1g_configThis is the reason for this line in the config:

MACHINEOVERRIDES =. "mx6:mx6dl:mx6q:"

This is a problem, since the features between the different i.MX6 SoC
variants to differ. In particular, imxpxp is enabled because of this, even
though my nitrogen6x - which has an i.MX6 Quad - has no PxP support. As a
result, software whose recipes test for imxpxp presence incorrectly have
their PxP features enabled. This is especially bad if it affects ptest
packages, which then fail.Well the board itself (Nitrogen6x) is the same, only the CPU populated
changed (pin-to-pin compatible) so it made sense not to separate the
machine.

Then as the commit from Eric explained [1], the main reason was for the
firmware-imx vpu files, without "mx6dl" it wouldn't install the matching
firmware.

This isn't ideal but has worked for the past 6 years, so I'm not sure
what is the ptest packages error, can you copy it here?

I now wonder what to do here. Split nitrogen6x.conf into multiple individual
recipes? Or selectively remove machineoverrides somehow?At this stage of the product (entering legacy) we do not plan on
splitting its machine.

Also want to point out that even NXP SABRE SD machine does the same
thing [2] so I doubt the solution is splitting it or removing an
override.

Regards,
Gary

[1] https://github.com/Freescale/meta-freescale-3rdparty/commit/9d34fea1
[2] https://github.com/Freescale/meta-freescale/blob/zeus/conf/machine/imx6qdlsabresd.conf

nitrogen6x machine config and imxpxp problems

Carlos Rafael Giani

#24315

The nitrogen6x machine config also supports other machines according to the comment block inside the .conf file:

# Note that this machine configuration also supports the SABRE Lite
# reference design and the Nitrogen6X-SOM.
#
# By default, this machine will build for the standard Quad-Core, 1GB
# option.
#
# To build U-Boot for other CPU or memory combinations, you can set
# the UBOOT_MACHINE variable in your local.conf according to the
# following table:
#
# Processor           Memory    Configuration
# --------------      ------    --------------------
# i.MX6Quad/Dual        1GB     nitrogen6q_config
# i.MX6Quad/Dual        2GB     nitrogen6q2g_config
# i.MX6Quad/Dual        4GB     nitrogen6_max_config
# i.MX6Dual-Lite        1GB     nitrogen6dl_config
# i.MX6Dual-Lite        2GB     nitrogen6dl2g_config
# i.MX6Solo           512MB     nitrogen6s_config
# i.MX6Solo             1GB     nitrogen6s1g_configThis is the reason for this line in the config:

MACHINEOVERRIDES =. "mx6:mx6dl:mx6q:"

This is a problem, since the features between the different i.MX6 SoC variants to differ. In particular, imxpxp is enabled because of this, even though my nitrogen6x - which has an i.MX6 Quad - has no PxP support. As a result, software whose recipes test for imxpxp presence incorrectly have their PxP features enabled. This is especially bad if it affects ptest packages, which then fail.

I now wonder what to do here. Split nitrogen6x.conf into multiple individual recipes? Or selectively remove machineoverrides somehow?

Re: drivers/net/nfc directory removed from imx-4.14.98-2.0.0_ga

nus1998

#24314

Sorry It's prefix is net but not drivers/net, so it is there...

Nus

Show quoted text

At 2020-04-20 10:03:56, "nus1998" <nus1998@...> wrote:

Hi All,

When I build NXP nfc driver, I got a error that some unknown symbol, after tracing the code, I found there is no nfc hci driver while in mailline linux kernel 4.14.98 contains it in net/drivers/nfc.
I want to know why iMX removed this directory and where these functions are implemented.

B.R.
Nus

drivers/net/nfc directory removed from imx-4.14.98-2.0.0_ga

nus1998

#24313

Hi All,

When I build NXP nfc driver, I got a error that some unknown symbol, after tracing the code, I found there is no nfc hci driver while in mailline linux kernel 4.14.98 contains it in net/drivers/nfc.

I want to know why iMX removed this directory and where these functions are implemented.

B.R.

Nus

Re: Error while trying to build a nitrogen8m image with yocto master

Carlos Rafael Giani

#24312

Thanks, that fixed it. I'll send a PR.

Show quoted text

On 19.04.20 10:45, Andrey Zhizhikin wrote:

On Sun, Apr 19, 2020 at 10:33 AM Carlos Rafael Giani
<crg7475@...> wrote:

I tried to build a nitrogen8m image with the current master branches of
poky, meta-freescale, meta-freescale-3rdparty, and meta-openembedded.
However, I immediately got this error:

 > Error, the PACKAGE_ARCHS variable (all any noarch
${PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto} nitrogen8m) for DEFAULTTUNE
(cortexa53-crypto) does not contain TUNE_PKGARCH
(${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64',
'${ARMPKGARCH_tune-cortexa53-crypto}' ,d)}).Toolchain tunings invalid:
 > Tuning 'cortexa53-crypto' has no defined features, and cannot be used.

This goes beyond my Yocto knowledge. Why are no features defined?
meta/conf/machine/include/tune-cortexa53.inc does define features.

It is that the nitrogen8m does not have that tune file included.
Instead, it uses a more generic
[conf/machine/include/arm/arch-arm64.inc] tune file, which should be
replaced with the [/conf/machine/include/tune-cortexa53.inc]. In fact,
all nitrogen8m* derivatives lacks this tune and uses generic.

You can replace the [require conf/machine/include/arm/arch-arm64.inc]
with [require conf/machine/include/tune-cortexa53.inc] for all
meta-freescale-3rdparty/conf/machine/nitrogen8m*.conf machines and
send a PR.

Has anybody else got this error?

I was successful with building an image for the imx8mmevk machine.

Re: Error while trying to build a nitrogen8m image with yocto master

Andrey Zhizhikin

#24311

On Sun, Apr 19, 2020 at 10:33 AM Carlos Rafael Giani
<crg7475@...> wrote:

I tried to build a nitrogen8m image with the current master branches of
poky, meta-freescale, meta-freescale-3rdparty, and meta-openembedded.
However, I immediately got this error:

 > Error, the PACKAGE_ARCHS variable (all any noarch
${PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto} nitrogen8m) for DEFAULTTUNE
(cortexa53-crypto) does not contain TUNE_PKGARCH
(${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64',
'${ARMPKGARCH_tune-cortexa53-crypto}' ,d)}).Toolchain tunings invalid:
 > Tuning 'cortexa53-crypto' has no defined features, and cannot be used.

This goes beyond my Yocto knowledge. Why are no features defined?
meta/conf/machine/include/tune-cortexa53.inc does define features.It is that the nitrogen8m does not have that tune file included.
Instead, it uses a more generic
[conf/machine/include/arm/arch-arm64.inc] tune file, which should be
replaced with the [/conf/machine/include/tune-cortexa53.inc]. In fact,
all nitrogen8m* derivatives lacks this tune and uses generic.

You can replace the [require conf/machine/include/arm/arch-arm64.inc]
with [require conf/machine/include/tune-cortexa53.inc] for all
meta-freescale-3rdparty/conf/machine/nitrogen8m*.conf machines and
send a PR.

Has anybody else got this error?

I was successful with building an image for the imx8mmevk machine.

-- 
Regards,
Andrey.

Error while trying to build a nitrogen8m image with yocto master

Carlos Rafael Giani

#24310

I tried to build a nitrogen8m image with the current master branches of poky, meta-freescale, meta-freescale-3rdparty, and meta-openembedded. However, I immediately got this error:

Error, the PACKAGE_ARCHS variable (all any noarch ${PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto} nitrogen8m) for DEFAULTTUNE (cortexa53-crypto) does not contain TUNE_PKGARCH (${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64', '${ARMPKGARCH_tune-cortexa53-crypto}' ,d)}).Toolchain tunings invalid:
Tuning 'cortexa53-crypto' has no defined features, and cannot be used.This goes beyond my Yocto knowledge. Why are no features defined? meta/conf/machine/include/tune-cortexa53.inc does define features.

Has anybody else got this error?

I was successful with building an image for the imx8mmevk machine.

Re: gst-play looks abnormal

nus1998

#24309

As I encountered severals issues on zeus, I decided to rollback and paid couple days to download/build sumo imx-4.14.98_2.0.0_ga.xml (actually 2.0.1_patch.xml), but I'm curious why it CANNOT pass the build in default settings.

First, I must modify SDCARD_ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.ext4" in sources/meta-fsl-bsp-release/imx/meta-bsp/conf/machine/include/imx-base.inc to generate image, otherwise error encountered.

Second issue is out of default setting but is common feature too, the linux-imx LOCALVERSION contains '_' which leading to build failure as deb package packing doesn't allow it.

Now I wonder which release should I choose to develop on...

B.R.

Nus

Show quoted text

At 2020-04-15 10:56:40, "nus1998" <nus1998@...> wrote:

Well, where can I found the known issues on this release? as for this gst issue, I found on it works normally on imxv4l2sink, on waylandsink the display looks OK but the performance is only 1.X frames/second. if there are few issues on the features what we used, we suppose to continue to use it, otherwise we might to turn to an old release.

BTW: is the last fully tested release imx-4.14.98-2.0.0_ga.xml?

B.R.
Nus

在 2020-04-15 00:17:42，"Tom Hochstein" <tom.hochstein@...> 写道：

Sorry, Nus, this is a known issue in this release. Please note that the 5.4.3-2.0.0 release was a targeted release for 8MP/8DXL Alpha and 8QXPC0 Beta. Due to resource constraints, 6DL was not fully tested.

The next release in Q2 will also be a targeted release but should have this fixed. We’re currently looking at Q3 for a fully tested release.

Tom

From: meta-freescale@... <meta-freescale@...> On Behalf Of nus1998 via lists.yoctoproject.org
Sent: Monday, April 13, 2020 9:35 PM
To: meta-freescale@...
Subject: Re: [meta-freescale] gst-play looks abnormal

Hi All,

Any tips that I can trace the issue? there are many binary libraries involved makes it difficult to debug...

PS: "alloc_contig_range: [X, Y) PFNs busy" is not the root issue as I changed a low profile test video, this message is disappeared but there is no difference on display. and I'm confused why stream shows the height is 1088? the source height is 1080.

B.R.

Nus

At 2020-04-13 20:55:12, "nus1998" <nus1998@...> wrote:

Hi All,

Today I tested video playback by gst-play, the sound is perfect without any lag, but the display looks abnormal. when sliding pictures, the display looks good and the same board is no problem to play video by burning android image. both of yocto and android share the same DDR initial code, so I think it doesn't matter of DDR crosstalk. the yocto branch I used is imx-linux-zeus/imx-5.4.3-2.0.0.xml, the print message and photos are attached as below:

root@imx6dlsabresd:~# ./gst-play 1080p_t1.mp4
Volume: 100%
Now playing /home/root/1080p_t1.mp4
State changed: buffering

====== AIUR: 4.5.4 build on Mar 30 2020 12:56:38. ======
        Core: MPEG4PARSER_06.16.03 build on Oct 16 2019 06:53:44
file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm11_elinux.so.3.2
------------------------
    Track 00 [video_0] Enabled
        Duration: 0:00:41.908333000
        Language: und
    Mime:
        video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)avc, width=(int)1920, height=(int)1080, framerate=(fraction)30000/1001, codec_data=(buffer)01640028ffe1001867640028acb403c0113f2e022000000c800002ed51e3065401000568cf32c8b0
------------------------
display(/dev/fb0) resolution is (800x480).
====== OVERLAYSINK: 4.5.4 build on Mar 30 2020 12:56:57. ======
display(/dev/fb0) resolution is (800x480).
[INFO] Product Info: i.MX6Q/D/S
[[10299.304378] alloc_contig_range: [72400, 728ff) PFNs busy
INFO]   Product Info: i.MX6Q/D/S
=[10299.311635] alloc_contig_range: [72400, 729ff) PFNs busy
===== VPUDEC: 4.5.4 build on Mar [10299.320940] alloc_contig_range: [72400, 72aff) PFNs busy
30 2020 12:57:01. ======
        wrappe[10299.328919] alloc_contig_range: [72400, 72bff) PFNs busy
r: 3.0.0 (VPUWRAPPER_ARM_LINUX Bu[10299.336682] alloc_contig_range: [72800, 72cff) PFNs busy
ild on Mar 27 2020 10:21:40)
        vpulib: 5.4.38
        firmware: 3.1.1.46076
[INFO] bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0
------------------------
    Track 01 [audio_0] Enabled
        Duration: 0:00:42.026666000
        Language: und
    Mime:
        audio/mpeg, mpegversion=(int)4, channels=(int)2, rate=(int)44100, bitrate=(int)124920, stream-format=(string)raw, codec_data=(buffer)1210
------------------------

====== BEEP: 4.5.4 build on Mar 30 2020 12:56:45. ======
        Core: AAC decoder Wrapper build on Dec 7 2017 18:13:49
file: /usr/lib/imx-mm/audio-codec/wrap/lib_aacd_wrap_arm12_elinux.so.3
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8 build on Sep 20 2017 15:02:14.
[WARN] VPU iram is less than needed, some parts don't use iram
display(/dev/fb0) resolution is ([10299.742796] mxc_v4l2_output v4l2_out: Bypass IC.
800x480).
[10299.750303] mxc_v4l2_output v4l2_out: Bypass IC.

===!!! Current pulsesink device is alsa_output.platform-sound.stereo-fallback !!!===

[10300.098134] alloc_contig_range: [72880, 72900) PFNs busy
[10300.107275] alloc_contig_range: [72880, 72900) PFNs busy
[10300.116202] alloc_contig_range: [72880, 72900) PFNs busy
[10300.125512] alloc_contig_range: [72880, 72900) PFNs busy
[10300.134782] alloc_contig_range: [72880, 72900) PFNs busy
URI : file:///home/root/1080p_t1.mp4
Duration: 0:00:00.000000000
Global taglist:
(nil)
All Stream information
Stream # 0
type : video_0
taglist :
    codec : H.264/AVC
    language-code : und
    container-format : MOV/MP4/3GP
    application-name : FormatFactory : www.pcfreetime.com
    video-codec : H.264 (High Profile)
    audio-codec : AAC
width : 1920
height : 1088
max_bitrate : -1
bitrate : -1
framerate : 29.97
pixel-aspect-ratio 1:1
Stream # 1
type : audio_0
taglist :
    codec : AAC
    language-code : und
    bitrate : 3268
    container-format : MOV/MP4/3GP
    application-name : FormatFactory : www.pcfreetime.com
    video-codec : H.264/AVC
    audio-codec : AAC decoder
    minimum-bitrate : 3100
    maximum-bitrate : 3100
sample rate : 44100
channels : 2
max_bitrate : 3100
bitrate : 3268
language : (null)

All video streams
video_0 #
width : 1920
height : 1088
max_bitrate : -1
bitrate : -1
framerate : 29.97
pixel-aspect-ratio 1:1

All audio streams:
audio_0 #
sample rate : 44100
channels : 2
max_bitrate : 3100
bitrate : 3268
language : (null)

Current video track:
width : 1920
height : 1088
max_bitrate : -1
bitrate : -1
framerate : 29.97
pixel-aspect-ratio 1:1
Current audio track:
sample rate : 44100
channels : 2
max_bitrate : 3100
bitrate : 3268
language : (null)
Current subtitle track:
State changed: playing
0:00:42.0 / 0:00:42.0
Reached end of play list.
State changed: stopped
Total showed frames (1257), display master blited (1257), playing for (0:00:42.031174000), fps (29.906).

On PC:

On i.MX6DL (2GB RAM)

B.R.

Nus