Re: [yocto] QA notification for completed autobuilder build (yocto-3.1.4.rc1)

[Sangeeta Jain]

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.4.rc1 We 
are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Tuesday, December 01.

Thanks,
Sangeeta

> -Original Message-
> From: Pokybuild User 
> Sent: Thursday, 26 November, 2020 12:14 PM
> To: yocto@lists.yoctoproject.org
> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
> ; Yeoh, Ee Peng ;
> Chan, Aaron Chun Yew ;
> richard.pur...@linuxfoundation.org; akuster...@gmail.com;
> sjolley.yp...@gmail.com; Jain, Sangeeta ;
> st...@sakoman.com
> Subject: QA notification for completed autobuilder build (yocto-3.1.4.rc1)
> 
> 
> A build flagged for QA (yocto-3.1.4.rc1) was completed on the autobuilder
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-3.1.4.rc1
> 
> 
> Build hash information:
> 
> bitbake: 89fc9450abefd682266efcbfa031d1ef115ff1a7
> meta-arm: e18ee052f75da60655fb434ff24a463a8fb36781
> meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
> meta-intel: 541c7256c1b6acba35d1116a1483b6594d189e3a
> meta-kernel: f9d30c65d08c9cef20d6487a7aff0fff40acc823
> meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
> oecore: b885888df67eb5cdb3b82f4f0a07369a449e223b
> poky: 424296bf9bb4bae27febf91bce0118df09ce5fa1
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51582): https://lists.yoctoproject.org/g/yocto/message/51582
Mute This Topic: https://lists.yoctoproject.org/mt/78515914/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] U-Boot sama5d3 xplained issue

[Federico Pellegrin]

Hi David,
If you change it directly, changes may not be taken into account for the
rebuild. And if the package build gets retriggered, then the whole
repository is deleted (including your local changes), redownloaded,
repatched and so on. So while it may by chance work by modifying locally in
certain conditions, it will most likely not.

I would see two ways:
1) Create a patch that does your changes and add it to the recipe (most
likely now in a custom layer) as a patch
2) Fork the repository, add all your customizations there, and point the
recipe (again most likely now in a custom layer) to that one.

Cheers,
F.



Il giorno ven 27 nov 2020 alle ore 01:35 David Novak 
ha scritto:

> We changed the file directly.
>
> Since it's a custom file, I don't think it is being downloaded. What is
> the easiest way to determine if it's being downloaded?
>
> Thanks,
> David
>
>
>
> On 11/23/2020 2:16 AM, Federico Pellegrin wrote:
>
>
> Hi,
> I think it would be interesting information to know "how" you change the
> value inside "u-boot-at91/sama5d3_xplained_nandflash_config".
>
> As every time you rebuild it may be redownloaded, you should do this via a
> patch to append to the recipe.
>
> Are you doing this? Or just changing it locally?
>
> If you give some more info probably we can better help!
>
> Cheers,
> Federico
>
> Il giorno lun 23 nov 2020 alle ore 08:06 Khem Raj  ha
> scritto:
>
>> perhaps asking it on https://github.com/linux4sam/u-boot-at91 via
>> github issues might be helpful too.
>>
>> On Sat, Nov 21, 2020 at 4:26 AM David Novak 
>> wrote:
>> >
>> > I'm working on this project with Pratham. Let me provide a few more
>> details.
>> >
>> > We've defined
>> >
>> > UBOOT_MACHINE ?= "sama5d3_xplained_nandflash_config"
>> >
>> > Inside
>> >
>> > u-boot-at91/sama5d3_xplained_nandflash_config
>> >
>> > we change CONFIG_BOOTDELAY, but it has no effect on the newly built
>> image. The boot delay remains the same as it was before we changed it.
>> >
>> > Based on the UBOOT_MACHINE, can we be certain we are changing the
>> correct file?
>> >
>> > How do we get the build process to include our changes?
>> >
>> > Thanks,
>> > David
>> >
>> >
>> >
>> > On 11/19/2020 5:37 PM, Prathamesh Ovalekar wrote:
>> >
>> > Hello everyone,
>> >
>> > System: sama5d3_xplained board
>> >
>> > I have a question regarding the configuration and build of u-boot.
>> > We have a build that was implemented earlier. I am trying to make some
>> changes to it.
>> >
>> > Change 1: Change the auto boot delay to 1 second.
>> > Change 2: Add an auto boot command to set a gpio.
>> >
>> > I am aware of the environment variables:  CONFIG_BOOTDELAY and
>> CONFIG_BOOTCOMMAND (needed for the changes above.)
>> > I tried modifying the  " configs/sama5d3_xplained_nandflash_defconfig "
>> >
>> > Question 1: Do I need to create an *.config file using the make
>> menuconfig?
>> >
>> > Question 2: How do I create the u-boot.bin . Does this  depend on the
>> Linux build?
>> > I know that there is an environment variable:
>> CONFIG_BOOTARGS that needs to be populated.
>> >
>> > --
>> > Pratham Ovalekar
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51581): https://lists.yoctoproject.org/g/yocto/message/51581
Mute This Topic: https://lists.yoctoproject.org/mt/78377165/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc] xlnx-soc: porting SDK patches to kernel v5.10

[quanyang.wang]

Hi Michal,

On 11/26/20 9:10 PM, Michal Simek wrote:


On 26. 11. 20 14:06, quanyang.wang wrote:

Hi Michal,

On 11/26/20 8:20 PM, Michal Simek wrote:

Hi,

On 26. 11. 20 11:19, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

Hi Bruce,

Would you please help remove the obsolete branch standard/xlnx-soc in
linux-yocto-dev
and apply these patches for v5.10 as below to the new branch
standard/xlnx-soc?

There are 1451 patches in this pull request.

Among them, 1443 patches are picked from
https://github.com/Xilinx/linux-xlnx.git xlnx_rebase_v5.4 (tag
xlnx_rebase_v5.4_2020.2).
and some of them are modified to adapt to the v5.10. And there are 4
new patches.

I took at look at your branch and there are some interesting things.
First of all thanks for your work.

Do you use any script of it because I see you keep references to origin
sha1 which is quite nice?

yes, the script is as below:

---

#!/bin/sh
add_sdk_commit ()
{
for each in `ls *.patch`; do title=`grep -m 1 -n "From " $each`;
     echo $title
     num=`grep -m 1 -n ^$ $each | awk -F : '{print$1}'`;
     commit=`echo $title | cut -c 7-47`;
     echo $commit
     echo $num
     sed "$num a\https://github.com/Xilinx/linux-xlnx.git
xlnx_rebase_v5.4\n" -i $each;
     sed "$num a\commit $commit from" -i $each;
done
}
add_sdk_commit

---


Then obviously we need to switch to psgtr mainline driver and add
missing features because that's the only way to go in long run. I tested
yesterday sata and it worked. I expect DP should be also fine and others
needs to be checked. Yesterday I have sent email to Laurent to check
some details about it.

The DP driver can't work in mainline v5.9 and v5.10 now. I tried to make
it work

but failed. I modified the dts (xilinx_dpsub.patch in attachment) to
make the DP driver get through

the initialization but the DP monitor has no signal.  I don't know if
this is a DP issue or psgtr phy issue.

So for v5.10 yocto kernel,  I gave up using mainline DP driver and
reverted  DP/psgtr/dpdma mainline

drivers to use SDK drivers instead.

If the DP driver can work in the near future, I would like switch to
mainline DP/psgtr/dpdma driver.


Xilinx is going to prepare v5.10 rebase tree with fixing these problems.

Is there any developing version based on v5.10 at Xilinx now? Wish for
some reference.

I am just starting to work on that. And checking these stuff one by one
to address them properly ahead.


Got it. Thanks for the info.

Thanks,

Quanyang



Thanks,
Michal




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9196): 
https://lists.yoctoproject.org/g/linux-yocto/message/9196
Mute This Topic: https://lists.yoctoproject.org/mt/78526815/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] U-Boot sama5d3 xplained issue

[David Novak]

We changed the file directly.

Since it's a custom file, I don't think it is being downloaded. What is 
the easiest way to determine if it's being downloaded?


Thanks,
David




On 11/23/2020 2:16 AM, Federico Pellegrin wrote:


Hi,
I think it would be interesting information to know "how" you change 
the value inside "u-boot-at91/sama5d3_xplained_nandflash_config".


As every time you rebuild it may be redownloaded, you should do this 
via a patch to append to the recipe.


Are you doing this? Or just changing it locally?

If you give some more info probably we can better help!

Cheers,
Federico

Il giorno lun 23 nov 2020 alle ore 08:06 Khem Raj > ha scritto:


perhaps asking it on https://github.com/linux4sam/u-boot-at91
 via
github issues might be helpful too.

On Sat, Nov 21, 2020 at 4:26 AM David Novak mailto:david.no...@dajac.com>> wrote:
>
> I'm working on this project with Pratham. Let me provide a few
more details.
>
> We've defined
>
> UBOOT_MACHINE ?= "sama5d3_xplained_nandflash_config"
>
> Inside
>
> u-boot-at91/sama5d3_xplained_nandflash_config
>
> we change CONFIG_BOOTDELAY, but it has no effect on the newly
built image. The boot delay remains the same as it was before we
changed it.
>
> Based on the UBOOT_MACHINE, can we be certain we are changing
the correct file?
>
> How do we get the build process to include our changes?
>
> Thanks,
> David
>
>
>
> On 11/19/2020 5:37 PM, Prathamesh Ovalekar wrote:
>
> Hello everyone,
>
> System: sama5d3_xplained board
>
> I have a question regarding the configuration and build of u-boot.
> We have a build that was implemented earlier. I am trying to
make some changes to it.
>
> Change 1: Change the auto boot delay to 1 second.
> Change 2: Add an auto boot command to set a gpio.
>
> I am aware of the environment variables: CONFIG_BOOTDELAY and
CONFIG_BOOTCOMMAND (needed for the changes above.)
> I tried modifying the  "
configs/sama5d3_xplained_nandflash_defconfig "
>
> Question 1: Do I need to create an *.config file using the make
menuconfig?
>
> Question 2: How do I create the u-boot.bin . Does this depend on
the Linux build?
>                     I know that there is an environment
variable: CONFIG_BOOTARGS that needs to be populated.
>
> --
> Pratham Ovalekar
>
>
>
>
>
>
>







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51580): https://lists.yoctoproject.org/g/yocto/message/51580
Mute This Topic: https://lists.yoctoproject.org/mt/78377165/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] How to Add Packages to Python3

[Konrad Weihmann]

Just add RDEPENDS_${PN] += "python3-json" to the recipe that creates the 
package, that contains the mentioned python script.


Alternatively add IMAGE_INSTALL += "python3-json" to the image the 
script is in.


As this is a core module (shipped by python3) the mapping is purely 
based on the python3-manifest.json


On 26.11.20 12:22, vijayrakeshmunga...@gmail.com wrote:

Hi,

I had installed a python file into the rootfs and when I tried to run, 
it throws an error as "ModuleNotFoundError: No module named 'json'". I 
tried to find bb file for jsonlib, but I couldn't find at 
https://layers.openembedded.org/layerindex/branch/master/recipes/?q=python+json. 
Also some sources suggest to add packages via python3-manifest.json. 
Kindly please help me in this regard.


Thanks,
VR





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51579): https://lists.yoctoproject.org/g/yocto/message/51579
Mute This Topic: https://lists.yoctoproject.org/mt/78527355/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core][PATCH v2] kernel-dummy: fix executing unexpected tasks

[Andrej Valek]

No problem, you can keep the deploy task dependency, like it was.

Regards,
Andrej

> On Thu, 2020-11-26 at 14:44 +, Valek, Andrej wrote:
>> No it's not a leftover. I've just copied it from kernel.bbclass, where 
>> this task is written correctly. But you can change it to previous 
>> version I guess.
>
> I'm trying to work out why we need the extra dependencies when the tasks are 
> empty.
>
> I can see how adding the inherit would help, I'm less sure how adding the 
> deploy task after the others does though.
>
> Cheers,
>
> Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51578): https://lists.yoctoproject.org/g/yocto/message/51578
Mute This Topic: https://lists.yoctoproject.org/mt/78504527/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core][PATCH v2] kernel-dummy: fix executing unexpected tasks

[Richard Purdie]

On Thu, 2020-11-26 at 14:44 +, Valek, Andrej wrote:
> No it's not a leftover. I've just copied it from kernel.bbclass,
> where this task is written correctly. But you can change it to
> previous version I guess.

I'm trying to work out why we need the extra dependencies when the
tasks are empty.

I can see how adding the inherit would help, I'm less sure how adding
the deploy task after the others does though.

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51577): https://lists.yoctoproject.org/g/yocto/message/51577
Mute This Topic: https://lists.yoctoproject.org/mt/78504527/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core][PATCH v2] kernel-dummy: fix executing unexpected tasks

[Andrej Valek]

Hello Richard,

No it's not a leftover. I've just copied it from kernel.bbclass, where this 
task is written correctly. But you can change it to previous version I guess.

Regards,
Andrej

> On Wed, 2020-11-25 at 18:20 +0100, Andrej Valek wrote:
>>  - correctly save files into sstate
>>   - fix: ERROR: Task linux-dummy.do_fetch attempted to execute 
>> unexpectedly
>> 
>> Signed-off-by: Andrej Valek 
>> ---
>>  meta/recipes-kernel/linux/linux-dummy.bb | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/meta/recipes-kernel/linux/linux-dummy.bb b/meta/recipes- 
>> kernel/linux/linux-dummy.bb index 62cf6f5ea6..1498da392c 100644
>> --- a/meta/recipes-kernel/linux/linux-dummy.bb
>> +++ b/meta/recipes-kernel/linux/linux-dummy.bb
>> @@ -5,10 +5,12 @@ where you wish to build the kernel externally from 
>> the build system."
>>  SECTION = "kernel"
>>  
>>  LICENSE = "GPLv2"
>> -LIC_FILES_CHKSUM =
>> "file://${WORKDIR}/COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe"
>> +LIC_FILES_CHKSUM =
>> "file://COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe"
>>  
>>  PROVIDES += "virtual/kernel"
>>  
>> +inherit deploy
>> +
>>  PACKAGES_DYNAMIC += "^kernel-module-.*"
>>  PACKAGES_DYNAMIC += "^kernel-image-.*"
>>  PACKAGES_DYNAMIC += "^kernel-firmware-.*"
>> @@ -60,6 +62,6 @@ do_deploy() {
>>  }
>>  
>>  addtask bundle_initramfs after do_install before do_deploy -addtask 
>> deploy after do_install
>> +addtask deploy after do_populate_sysroot do_packagedata
>
> Is this a leftover from the previous version of the patch? We don't normally 
> need those constraints?
>
> Cheers,
>
> Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51576): https://lists.yoctoproject.org/g/yocto/message/51576
Mute This Topic: https://lists.yoctoproject.org/mt/78504527/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core][PATCH v2] kernel-dummy: fix executing unexpected tasks

[Richard Purdie]

On Wed, 2020-11-25 at 18:20 +0100, Andrej Valek wrote:
>  - correctly save files into sstate
>   - fix: ERROR: Task linux-dummy.do_fetch attempted to execute
> unexpectedly
> 
> Signed-off-by: Andrej Valek 
> ---
>  meta/recipes-kernel/linux/linux-dummy.bb | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-kernel/linux/linux-dummy.bb b/meta/recipes-
> kernel/linux/linux-dummy.bb
> index 62cf6f5ea6..1498da392c 100644
> --- a/meta/recipes-kernel/linux/linux-dummy.bb
> +++ b/meta/recipes-kernel/linux/linux-dummy.bb
> @@ -5,10 +5,12 @@ where you wish to build the kernel externally from
> the build system."
>  SECTION = "kernel"
>  
>  LICENSE = "GPLv2"
> -LIC_FILES_CHKSUM =
> "file://${WORKDIR}/COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe"
> +LIC_FILES_CHKSUM =
> "file://COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe"
>  
>  PROVIDES += "virtual/kernel"
>  
> +inherit deploy
> +
>  PACKAGES_DYNAMIC += "^kernel-module-.*"
>  PACKAGES_DYNAMIC += "^kernel-image-.*"
>  PACKAGES_DYNAMIC += "^kernel-firmware-.*"
> @@ -60,6 +62,6 @@ do_deploy() {
>  }
>  
>  addtask bundle_initramfs after do_install before do_deploy
> -addtask deploy after do_install
> +addtask deploy after do_populate_sysroot do_packagedata

Is this a leftover from the previous version of the patch? We don't
normally need those constraints?

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51575): https://lists.yoctoproject.org/g/yocto/message/51575
Mute This Topic: https://lists.yoctoproject.org/mt/78504527/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc] xlnx-soc: porting SDK patches to kernel v5.10

[Michal Simek]

On 26. 11. 20 14:06, quanyang.wang wrote:
> Hi Michal,
> 
> On 11/26/20 8:20 PM, Michal Simek wrote:
>> Hi,
>>
>> On 26. 11. 20 11:19, quanyang.w...@windriver.com wrote:
>>> From: Quanyang Wang 
>>>
>>> Hi Bruce,
>>>
>>> Would you please help remove the obsolete branch standard/xlnx-soc in
>>> linux-yocto-dev
>>> and apply these patches for v5.10 as below to the new branch
>>> standard/xlnx-soc?
>>>
>>> There are 1451 patches in this pull request.
>>>
>>> Among them, 1443 patches are picked from
>>> https://github.com/Xilinx/linux-xlnx.git xlnx_rebase_v5.4 (tag
>>> xlnx_rebase_v5.4_2020.2).
>>> and some of them are modified to adapt to the v5.10. And there are 4
>>> new patches.
>> I took at look at your branch and there are some interesting things.
>> First of all thanks for your work.
>>
>> Do you use any script of it because I see you keep references to origin
>> sha1 which is quite nice?
> 
> yes, the script is as below:
> 
> ---
> 
> #!/bin/sh
> add_sdk_commit ()
> {
> for each in `ls *.patch`; do title=`grep -m 1 -n "From " $each`;
>     echo $title
>     num=`grep -m 1 -n ^$ $each | awk -F : '{print$1}'`;
>     commit=`echo $title | cut -c 7-47`;
>     echo $commit
>     echo $num
>     sed "$num a\https://github.com/Xilinx/linux-xlnx.git
> xlnx_rebase_v5.4\n" -i $each;
>     sed "$num a\commit $commit from" -i $each;
> done
> }
> add_sdk_commit
> 
> ---
> 
>>
>> Then obviously we need to switch to psgtr mainline driver and add
>> missing features because that's the only way to go in long run. I tested
>> yesterday sata and it worked. I expect DP should be also fine and others
>> needs to be checked. Yesterday I have sent email to Laurent to check
>> some details about it.
> 
> The DP driver can't work in mainline v5.9 and v5.10 now. I tried to make
> it work
> 
> but failed. I modified the dts (xilinx_dpsub.patch in attachment) to
> make the DP driver get through
> 
> the initialization but the DP monitor has no signal.  I don't know if
> this is a DP issue or psgtr phy issue.
> 
> So for v5.10 yocto kernel,  I gave up using mainline DP driver and
> reverted  DP/psgtr/dpdma mainline
> 
> drivers to use SDK drivers instead.
> 
> If the DP driver can work in the near future, I would like switch to
> mainline DP/psgtr/dpdma driver.
> 
>> Xilinx is going to prepare v5.10 rebase tree with fixing these problems.
> 
> Is there any developing version based on v5.10 at Xilinx now? Wish for
> some reference.

I am just starting to work on that. And checking these stuff one by one
to address them properly ahead.

Thanks,
Michal




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9194): 
https://lists.yoctoproject.org/g/linux-yocto/message/9194
Mute This Topic: https://lists.yoctoproject.org/mt/78526815/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc] xlnx-soc: porting SDK patches to kernel v5.10

[quanyang.wang]

Hi Michal,

On 11/26/20 8:20 PM, Michal Simek wrote:

Hi,

On 26. 11. 20 11:19, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

Hi Bruce,

Would you please help remove the obsolete branch standard/xlnx-soc in 
linux-yocto-dev
and apply these patches for v5.10 as below to the new branch standard/xlnx-soc?

There are 1451 patches in this pull request.

Among them, 1443 patches are picked from 
https://github.com/Xilinx/linux-xlnx.git xlnx_rebase_v5.4 (tag 
xlnx_rebase_v5.4_2020.2).
and some of them are modified to adapt to the v5.10. And there are 4 new 
patches.

I took at look at your branch and there are some interesting things.
First of all thanks for your work.

Do you use any script of it because I see you keep references to origin
sha1 which is quite nice?


yes, the script is as below:

---

#!/bin/sh
add_sdk_commit ()
{
for each in `ls *.patch`; do title=`grep -m 1 -n "From " $each`;
    echo $title
    num=`grep -m 1 -n ^$ $each | awk -F : '{print$1}'`;
    commit=`echo $title | cut -c 7-47`;
    echo $commit
    echo $num
    sed "$num a\https://github.com/Xilinx/linux-xlnx.git 
xlnx_rebase_v5.4\n" -i $each;

    sed "$num a\commit $commit from" -i $each;
done
}
add_sdk_commit

---



Then obviously we need to switch to psgtr mainline driver and add
missing features because that's the only way to go in long run. I tested
yesterday sata and it worked. I expect DP should be also fine and others
needs to be checked. Yesterday I have sent email to Laurent to check
some details about it.


The DP driver can't work in mainline v5.9 and v5.10 now. I tried to make 
it work


but failed. I modified the dts (xilinx_dpsub.patch in attachment) to 
make the DP driver get through


the initialization but the DP monitor has no signal.  I don't know if 
this is a DP issue or psgtr phy issue.


So for v5.10 yocto kernel,  I gave up using mainline DP driver and 
reverted  DP/psgtr/dpdma mainline


drivers to use SDK drivers instead.

If the DP driver can work in the near future, I would like switch to 
mainline DP/psgtr/dpdma driver.



Xilinx is going to prepare v5.10 rebase tree with fixing these problems.


Is there any developing version based on v5.10 at Xilinx now? Wish for 
some reference.


Thanks,

Quanyang


It should be available in Q1/2021.

Thanks,
Michal
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
index 9868ca15dfc5..50d027d20239 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
@@ -43,6 +43,34 @@
 		#clock-cells = <0>;
 		clock-frequency = <2700>;
 	};
+
+	dp_aclk: dp_aclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1>;
+		clock-accuracy = <100>;
+	};
+
+};
+
+_firmware {
+zynqmp_clk: clock-controller {
+u-boot,dm-pre-reloc;
+#clock-cells = <1>;
+compatible = "xlnx,zynqmp-clk";
+clocks = <_ref_clk>, <_clk>, <_alt_ref_clk>,
+ <_ref_clk>, <_crx_ref_clk>;
+clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk",
+  "aux_ref_clk", "gt_crx_ref_clk";
+};
+};
+
+_dpdma {
+	clocks = <_clk DPDMA_REF>;
+};
+
+ {
+	clocks = <_clk>, <_clk>, <_clk>, <_clk>;
 };
 
  {
@@ -220,3 +248,7 @@
  {
 	clocks = <_clk WDT>;
 };
+
+_dpsub {
+clocks = <_aclk>, <_clk DP_AUDIO_REF>, <_clk DP_VIDEO_REF>;
+};
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
index 4f801721564f..7f0f5a698fe2 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
@@ -13,6 +13,7 @@
 #include "zynqmp-clk-ccf.dtsi"
 #include 
 #include 
+#include 
 
 / {
 	model = "ZynqMP ZCU102 RevA";
@@ -138,6 +139,14 @@
 	status = "okay";
 };
 
+ {
+	status = "okay";
+};
+
+_dpdma {
+	status = "okay";
+};
+
  {
 	status = "okay";
 };
@@ -619,6 +628,12 @@
 	status = "okay";
 };
 
+_dpsub {
+status = "okay";
+phy-names = "dp-phy0";
+	phys = < 1 PHY_TYPE_DP 0 3>;
+};
+
  {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 3ec99f13c259..fe88a22baeb8 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -146,6 +146,11 @@
 	  "gt_crx_ref_clk";
 			};
 
+			zynqmp_reset: reset-controller {
+compatible = "xlnx,zynqmp-reset";
+#reset-cells = <1>;
+			};
+
 			nvmem_firmware {
 compatible = "xlnx,zynqmp-nvmem-fw";
 #address-cells = <1>;
@@ -566,6 +571,21 @@
 			  <0x0 0xfd3d 0x0 0x1000>;
 			reg-names = "serdes", "siou";
 			#phy-cells = <4>;
+
+			clock-names = "ref0", "ref1", "ref2", "ref3";
+
+			lane0: lane0 {
+#phy-cells = <4>;
+};
+lane1: lane1 {
+#phy-cells = <4>;
+};
+lane2: lane2 {
+#phy-cells = 

Re: [yocto] Error during do_install for linux-libc-headers_5.8 recipe during 'bitbake core-image-minimal'

[Quentin Schulz]

Hi,

On Thu, Nov 26, 2020 at 04:26:34AM -0800, aloofbynat...@gmail.com wrote:
> Hello,
> 
> I am just starting using Yocto Project and I've been following along with the 
> getting started section of the mega manual. I am working on Ubuntu 20.04 LTS 
> through WSL2 on Windows 10 (not sure if it matters but I'm running OS build 
> 20231) trying to create an image using poky-yocto-3.2.
> 
> I've followed all setup steps and made sure the host has all necessary 
> packages before cloning poky (I kept running into an error when trying to 
> clone the repo because the connection was refused so I just extracted the 
> poky-yocto-3.2 tarball). When I try to run 'bitbake core-image-minimal' I get 
> an error saying the following task failed with exit code 134:
> 'poky-yocto-3.2/meta/recipes- kernel/linux-libc-headers/ 
> linux-libc-headers_5.8.bb:do_ install'
> All the other recipes are installed with no problems.
> 

To be able to help you we'd need the logs of this task.
You can either paste the whole output on the console or send us the task
log you can find if you carefully read the console output.

Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51573): https://lists.yoctoproject.org/g/yocto/message/51573
Mute This Topic: https://lists.yoctoproject.org/mt/78528061/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Error during do_install for linux-libc-headers_5.8 recipe during 'bitbake core-image-minimal'

[Paul Barker]

On Thu, 26 Nov 2020 at 12:26,  wrote:
>
> Hello,
>
> I am just starting using Yocto Project and I've been following along with the 
> getting started section of the mega manual. I am working on Ubuntu 20.04 LTS 
> through WSL2 on Windows 10 (not sure if it matters but I'm running OS build 
> 20231) trying to create an image using poky-yocto-3.2.
>
> I've followed all setup steps and made sure the host has all necessary 
> packages before cloning poky (I kept running into an error when trying to 
> clone the repo because the connection was refused so I just extracted the 
> poky-yocto-3.2 tarball). When I try to run 'bitbake core-image-minimal' I get 
> an error saying the following task failed with exit code 134:
> 'poky-yocto-3.2/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.8.bb:do_install'
> All the other recipes are installed with no problems.
>
> The first time I tried this I changed local.conf in my build dir to build for 
> qemuarm and next try I left everything as the default configuration but still 
> got the same result. Any help fixing this issue is appreciated, thanks!

Could you share the command that you executed along with the full
output that was printed? There's not really enough information here to
diagnose the issue.

Thanks,

-- 
Paul Barker
Konsulko Group

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51572): https://lists.yoctoproject.org/g/yocto/message/51572
Mute This Topic: https://lists.yoctoproject.org/mt/78528061/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Error during do_install for linux-libc-headers_5.8 recipe during 'bitbake core-image-minimal'

[aloofbynature]

Hello,

I am just starting using Yocto Project and I've been following along with the 
getting started section of the mega manual. I am working on Ubuntu 20.04 LTS 
through WSL2 on Windows 10 (not sure if it matters but I'm running OS build 
20231) trying to create an image using poky-yocto-3.2.

I've followed all setup steps and made sure the host has all necessary packages 
before cloning poky (I kept running into an error when trying to clone the repo 
because the connection was refused so I just extracted the poky-yocto-3.2 
tarball). When I try to run 'bitbake core-image-minimal' I get an error saying 
the following task failed with exit code 134:
'poky-yocto-3.2/meta/recipes- kernel/linux-libc-headers/ 
linux-libc-headers_5.8.bb:do_ install'
All the other recipes are installed with no problems.

The first time I tried this I changed local.conf in my build dir to build for 
qemuarm and next try I left everything as the default configuration but still 
got the same result. Any help fixing this issue is appreciated, thanks!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51571): https://lists.yoctoproject.org/g/yocto/message/51571
Mute This Topic: https://lists.yoctoproject.org/mt/78528061/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc] xlnx-soc: porting SDK patches to kernel v5.10

[Michal Simek]

Hi,

On 26. 11. 20 11:19, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang 
> 
> Hi Bruce,
> 
> Would you please help remove the obsolete branch standard/xlnx-soc in 
> linux-yocto-dev
> and apply these patches for v5.10 as below to the new branch 
> standard/xlnx-soc?
> 
> There are 1451 patches in this pull request.
> 
> Among them, 1443 patches are picked from 
> https://github.com/Xilinx/linux-xlnx.git xlnx_rebase_v5.4 (tag 
> xlnx_rebase_v5.4_2020.2).
> and some of them are modified to adapt to the v5.10. And there are 4 new 
> patches.

I took at look at your branch and there are some interesting things.
First of all thanks for your work.

Do you use any script of it because I see you keep references to origin
sha1 which is quite nice?

Then obviously we need to switch to psgtr mainline driver and add
missing features because that's the only way to go in long run. I tested
yesterday sata and it worked. I expect DP should be also fine and others
needs to be checked. Yesterday I have sent email to Laurent to check
some details about it.
Xilinx is going to prepare v5.10 rebase tree with fixing these problems.
It should be available in Q1/2021.

Thanks,
Michal

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9192): 
https://lists.yoctoproject.org/g/linux-yocto/message/9192
Mute This Topic: https://lists.yoctoproject.org/mt/78526815/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [linux-yocto-dev standard/xlnx-soc] xlnx-soc: porting SDK patches to kernel v5.10

[Michal Simek]

Hi,


On 26. 11. 20 11:19, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang 
> 
> Hi Bruce,
> 
> Would you please help remove the obsolete branch standard/xlnx-soc in 
> linux-yocto-dev
> and apply these patches for v5.10 as below to the new branch 
> standard/xlnx-soc?
> 
> There are 1451 patches in this pull request.
> 
> Among them, 1443 patches are picked from 
> https://github.com/Xilinx/linux-xlnx.git xlnx_rebase_v5.4 (tag 
> xlnx_rebase_v5.4_2020.2).
> and some of them are modified to adapt to the v5.10. And there are 4 new 
> patches.
> 
> Hi Michal,
> Would you please help review these 4 patches as below?
> The new 4 patches are made to fix issues in mainline zynqmp gqspi driver in 
> v5.10 since
> the driver has changed the framework from spi master to spi mem.
> 
> 0001-spi-spi-zynqmp-gqspi-transmit-dummy-circles-by-using.patch
> 0002-spi-spi-zynqmp-gqspi-add-mutex-locking-for-exec_op.patch
> 0003-spi-spi-zynqmp-gqspi-use-wait_for_completion_timeout.patch
> 0004-spi-spi-zynqmp-gqspi-fix-zynqmp_qspi_read_op-assign-.patch


Amit: Can you please take a look at them?

Thanks,
Michal

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9191): 
https://lists.yoctoproject.org/g/linux-yocto/message/9191
Mute This Topic: https://lists.yoctoproject.org/mt/78526815/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] How to Add Packages to Python3

[vijayrakeshmunganda]

Hi,

I had installed a python file into the rootfs and when I tried to run, it 
throws an error as "ModuleNotFoundError: No module named 'json'". I tried to 
find bb file for jsonlib, but I couldn't find at 
https://layers.openembedded.org/layerindex/branch/master/recipes/?q=python+json.
 Also some sources suggest to add packages via python3-manifest.json. Kindly 
please help me in this regard.

Thanks,
VR

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51570): https://lists.yoctoproject.org/g/yocto/message/51570
Mute This Topic: https://lists.yoctoproject.org/mt/78527355/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 4/4] spi: spi-zynqmp-gqspi: fix zynqmp_qspi_read_op assign wrong transfer_len

[quanyang.wang]

From: Quanyang Wang 

For some scenarios, the wrong transfer_len is written to genfifoentry.
Take 10 bytes data reading operation for instance, 8 bytes will be read
from the flash by using DMA mode and 2 bytes left in IO mode. Thus we need
to create an 8-byte size transfer genfifoentry in zynqmp_qspi_fillgenfifo
and 2-byte size transfer genfifoentry in zynqmp_process_dma_irq. But in
zynqmp_qspi_read_op, because zynqmp_qspi_fillgenfifo is running before
zynqmp_qspi_setuprxdma, xqspi->mode is wrong and the transfer_len in
zynqmp_qspi_fillgenfifo will be wrongly assigned to be 10. This results
that data corruption in the reading operation.

Running zynqmp_qspi_setuprxdma before zynqmp_qspi_fillgenfifo can
fix this error.

Signed-off-by: Quanyang Wang 
---
 drivers/spi/spi-zynqmp-gqspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index b66144c15153..83467812d89f 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -826,8 +826,8 @@ static void zynqmp_qspi_write_op(struct zynqmp_qspi *xqspi, 
u8 tx_nbits,
 static void zynqmp_qspi_read_op(struct zynqmp_qspi *xqspi, u8 rx_nbits,
u32 genfifoentry)
 {
-   zynqmp_qspi_fillgenfifo(xqspi, rx_nbits, genfifoentry);
zynqmp_qspi_setuprxdma(xqspi);
+   zynqmp_qspi_fillgenfifo(xqspi, rx_nbits, genfifoentry);
 }
 
 /**
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9190): 
https://lists.yoctoproject.org/g/linux-yocto/message/9190
Mute This Topic: https://lists.yoctoproject.org/mt/78526818/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 3/4] spi: spi-zynqmp-gqspi: use wait_for_completion_timeout instead of wait_for_completion_interruptible_timeout

[quanyang.wang]

From: Quanyang Wang 

The function wait_for_completion_interruptible_timeout will return
a non-zero value -ERESTARTSYS when the current process receives
a signal "SIGKILL". So there is a scene that the function
wait_for_completion_interruptible_timeout exits not because the handler
zynqmp_qspi_irq calls complete() function but for receiving a SIGKILL
signal. This will result that data transmitting has begun before the
command or address transmitting completes.

Using wait_for_completion_timeout to avoid it.

Signed-off-by: Quanyang Wang 
---
 drivers/spi/spi-zynqmp-gqspi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index bdc21a23558e..b66144c15153 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -979,7 +979,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
zynqmp_gqspi_write(xqspi, GQSPI_IER_OFST,
   GQSPI_IER_GENFIFOEMPTY_MASK |
   GQSPI_IER_TXNOT_FULL_MASK);
-   if (!wait_for_completion_interruptible_timeout
+   if (!wait_for_completion_timeout
(>data_completion, msecs_to_jiffies(1000))) {
err = -ETIMEDOUT;
kfree(tmpbuf);
@@ -1007,7 +1007,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
   GQSPI_IER_TXEMPTY_MASK |
   GQSPI_IER_GENFIFOEMPTY_MASK |
   GQSPI_IER_TXNOT_FULL_MASK);
-   if (!wait_for_completion_interruptible_timeout
+   if (!wait_for_completion_timeout
(>data_completion, msecs_to_jiffies(1000))) {
err = -ETIMEDOUT;
goto return_err;
@@ -1074,7 +1074,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
   GQSPI_IER_RXEMPTY_MASK);
}
}
-   if (!wait_for_completion_interruptible_timeout
+   if (!wait_for_completion_timeout
(>data_completion, msecs_to_jiffies(1000)))
err = -ETIMEDOUT;
}
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9189): 
https://lists.yoctoproject.org/g/linux-yocto/message/9189
Mute This Topic: https://lists.yoctoproject.org/mt/78526817/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 2/4] spi: spi-zynqmp-gqspi: add mutex locking for exec_op

[quanyang.wang]

From: Quanyang Wang 

The spi-mem framework has no locking to prevent ctlr->mem_ops->exec_op
from concurrency. So add the locking to zynqmp_qspi_exec_op.

Signed-off-by: Quanyang Wang 
---
 drivers/spi/spi-zynqmp-gqspi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 6dfaf968be5c..bdc21a23558e 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -173,6 +173,7 @@ struct zynqmp_qspi {
u32 genfifoentry;
enum mode_type mode;
struct completion data_completion;
+   struct mutex op_lock;
 };
 
 /**
@@ -955,6 +956,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
op->dummy.buswidth, op->data.buswidth);
 
+   mutex_lock(>op_lock);
zynqmp_qspi_config_op(xqspi, mem->spi);
zynqmp_qspi_chipselect(mem->spi, false);
genfifoentry |= xqspi->genfifocs;
@@ -1080,6 +1082,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 return_err:
 
zynqmp_qspi_chipselect(mem->spi, true);
+   mutex_unlock(>op_lock);
 
return err;
 }
@@ -1152,6 +1155,8 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
goto clk_dis_pclk;
}
 
+   mutex_init(>op_lock);
+
pm_runtime_use_autosuspend(>dev);
pm_runtime_set_autosuspend_delay(>dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_set_active(>dev);
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9188): 
https://lists.yoctoproject.org/g/linux-yocto/message/9188
Mute This Topic: https://lists.yoctoproject.org/mt/78526816/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 1/4] spi: spi-zynqmp-gqspi: transmit dummy circles by using controller's internal functionality

[quanyang.wang]

From: Quanyang Wang 

When reading from mt25qu512a on zcu102 board, it will return wrong data.

There are two problems:

1. The gqspi controller has a functionality to send dummy clock circles.
When write data with the fields [receive, transmit, data_xfer] = [0,0,1]
to the Generic FIFO, the controller will transmit dummy circles.
Writing common data as dummy circles will result in data corruption.

2. The flash mt25qu512a support SNOR_PROTO_1_1_4, which means that the
command and address will be sent in DQ0 and data in DQ[0:3]. In function
spi_nor_spimem_read_data, op.dummy.buswidth is assigned to op.addr.buswidth
which is 1. This results that the controller sends dummy circles in SPI
mode. But Zynq UltraScale+ Device TRM P683 suggests that Quad I/O Read
should send dummy circles in Quad SPI mode.

Make modifications that sending dummy circles by using the controller's
internal functionality in Quad SPI mode to fix the two problems above.

Signed-off-by: Quanyang Wang 
---
 drivers/spi/spi-zynqmp-gqspi.c | 40 +++---
 1 file changed, 18 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index c8fa6ee18ae7..6dfaf968be5c 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -520,7 +520,7 @@ static void zynqmp_qspi_filltxfifo(struct zynqmp_qspi 
*xqspi, int size)
 {
u32 count = 0, intermediate;
 
-   while ((xqspi->bytes_to_transfer > 0) && (count < size)) {
+   while ((xqspi->bytes_to_transfer > 0) && (count < size) && 
(xqspi->txbuf)) {
memcpy(, xqspi->txbuf, 4);
zynqmp_gqspi_write(xqspi, GQSPI_TXD_OFST, intermediate);
 
@@ -579,7 +579,7 @@ static void zynqmp_qspi_fillgenfifo(struct zynqmp_qspi 
*xqspi, u8 nbits,
genfifoentry |= GQSPI_GENFIFO_DATA_XFER;
genfifoentry |= GQSPI_GENFIFO_TX;
transfer_len = xqspi->bytes_to_transfer;
-   } else {
+   } else if (xqspi->rxbuf) {
genfifoentry &= ~GQSPI_GENFIFO_TX;
genfifoentry |= GQSPI_GENFIFO_DATA_XFER;
genfifoentry |= GQSPI_GENFIFO_RX;
@@ -587,6 +587,10 @@ static void zynqmp_qspi_fillgenfifo(struct zynqmp_qspi 
*xqspi, u8 nbits,
transfer_len = xqspi->dma_rx_bytes;
else
transfer_len = xqspi->bytes_to_receive;
+   } else {
+   genfifoentry &= ~(GQSPI_GENFIFO_TX | GQSPI_GENFIFO_RX);
+   genfifoentry |= GQSPI_GENFIFO_DATA_XFER;
+   transfer_len = xqspi->bytes_to_transfer;
}
genfifoentry |= zynqmp_qspi_selectspimode(xqspi, nbits);
xqspi->genfifoentry = genfifoentry;
@@ -1009,32 +1013,24 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
}
 
if (op->dummy.nbytes) {
-   tmpbuf = kzalloc(op->dummy.nbytes, GFP_KERNEL | GFP_DMA);
-   if (!tmpbuf)
-   return -ENOMEM;
-   memset(tmpbuf, 0xff, op->dummy.nbytes);
-   reinit_completion(>data_completion);
-   xqspi->txbuf = tmpbuf;
+   xqspi->txbuf = NULL;
xqspi->rxbuf = NULL;
-   xqspi->bytes_to_transfer = op->dummy.nbytes;
+   /*
+* xqspi->bytes_to_transfer here represents the dummy circles
+* per data line.
+*/
+   xqspi->bytes_to_transfer = op->dummy.nbytes * 8 / 
op->dummy.buswidth;
xqspi->bytes_to_receive = 0;
-   zynqmp_qspi_write_op(xqspi, op->dummy.buswidth,
+   /*
+* Using op->data.buswidth instead of op->dummy.buswidth since
+* the specification requires that the dummy.buswidth should
+* be the same as data.buswidth.
+*/
+   zynqmp_qspi_write_op(xqspi, op->data.buswidth,
 genfifoentry);
zynqmp_gqspi_write(xqspi, GQSPI_CONFIG_OFST,
   zynqmp_gqspi_read(xqspi, GQSPI_CONFIG_OFST) |
   GQSPI_CFG_START_GEN_FIFO_MASK);
-   zynqmp_gqspi_write(xqspi, GQSPI_IER_OFST,
-  GQSPI_IER_TXEMPTY_MASK |
-  GQSPI_IER_GENFIFOEMPTY_MASK |
-  GQSPI_IER_TXNOT_FULL_MASK);
-   if (!wait_for_completion_interruptible_timeout
-   (>data_completion, msecs_to_jiffies(1000))) {
-   err = -ETIMEDOUT;
-   kfree(tmpbuf);
-   goto return_err;
-   }
-
-   kfree(tmpbuf);
}
 
if (op->data.nbytes) {
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9186): 
https://lists.yoctoproject.org/g/linux-yocto/message/9186
Mute This Topic: 

Re: [yocto] Use of USERADD_PACKAGES with out recipe package files

[Paul Barker]

On Thu, 26 Nov 2020 at 03:21,  wrote:
>
> I have for an image append which I would like to add some users to but I do 
> not want to add any files as part of the package
> so I  have a layer which contains a recipe called user-config-0.1.bb which 
> has a useradd package USERADD_PACKAGES = " ${PN}-user-sys "  . then I have a 
> USERADD_PARAM_${PN}-user-sys = " .."
> which adds some users not shown and I also have an add group param as well 
> not shown
> I declare the package as  PACKAGES += "${PN}-user-sys" but do not set the 
> package files because i do not want any
> and in my image bbappend file I install the package  IMAGE_INSTALL_append += 
> "user-config-user-sys"
> The recipe builds but does not create a package and the do-rootfs cannot find 
> the package  and fails with
>
> No match for argument: user-config-user-sys
> Error: Unable to find a match
>
> well that seems to be the meaningful part I guess
>
> How do i get yocto to generate a package which only contains user group 
> creation part which can then be installed in my image
> I have added uses and groups before with files with out a problem, also this 
> is greatly simplified but still shows the core problem

You probably need to set `ALLOW_EMPTY_${PN}-user-sys`. See
https://docs.yoctoproject.org/ref-manual/ref-variables.html?highlight=allow_empty#term-ALLOW_EMPTY.

Thanks,

-- 
Paul Barker
Konsulko Group

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51569): https://lists.yoctoproject.org/g/yocto/message/51569
Mute This Topic: https://lists.yoctoproject.org/mt/78515331/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-