[yocto] QA notification for completed autobuilder build (yocto-2.8_M3.rc1)
A build flagged for QA (yocto-2.8_M3.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-2.8_M3.rc1 Build hash information: bitbake: 797354d285f6d624d9adb52bab65823572da0e39 meta-gplv2: 1e2480e50f34e55bdfd5e06f98441e03a3752d5a meta-intel: 655dfaec95196b9c0e15d34f490e4a51a7d501e3 meta-mingw: 9df4e115ab9a7ab23f81fdbcc62b2a0269d6377f oecore: 95ad5626296380358c8a502a3e04879dab653d78 poky: 81f9e815d36848761a9dfa94b00ad998bb39a4a6 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH 0/2 v5.2] Add the RT support for the cn96xx
In message: [PATCH 0/2 v5.2] Add the RT support for the cn96xx
on 19/09/2019 Kevin Hao wrote:
> From: Kevin Hao
>
> This patch series adds the RT support for the Marvell cn96xx SoC. It
> includes the kernel and kernel cache patches. All the kernel patches
> except the following have already been merged into the v5.2/standard/cn96xx
> branch.
>
> 1. The patch 77eaa178a3f8 ("mmc: cavium: Drop the aligned check for the dma
> address")
>This is a new patch and also has been sent to the linux-yocto for the
>merging into v5.2/standard/cn96xx branch.
>
> 2. The patch 088d9e94823e ("arm64: Enlarge the FORCE_MAX_ZONEORDER on the
> Cavium SoC for RT:)
>This is a workaround for the bootloader setting a too big coheret_pool
>for the kernel.
My tree was in a slightly different state, so it was easier for me
to manually create the new branch, and then merge the standard kernel
BSP into it.
That included the patch you sent earlier, and I've cherry picked the
other from your github branch.
Cheers,
Bruce
>
> Thanks,
> Kevin
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/2] fix compile warning
In message: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 0/2] fix compile warning on 19/09/2019 quanyang.w...@windriver.com wrote: > From: Quanyang Wang > > Hi Bruce, > > Would you please help me merge the two patches into > linux-ycoto-5.2 kernel, branch v5.2/standard/xlnx-soc ? These are now merged. Bruce > > Thanks, > Quanyang > > Quanyang Wang (2): > mtd: spi-nor: change flash_info.flags from u16 to u32 to avoid compile > warning > spi: spi-mem: zynq-qspi: add is-dual support for zc706 board > > drivers/mtd/spi-nor/spi-nor.c | 2 +- > drivers/spi/spi-zynq-qspi.c | 43 +-- > 2 files changed, 42 insertions(+), 3 deletions(-) > > -- > 2.17.1 > -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH v5.2] mmc: cavium: Drop the aligned check for the dma address
In message: [PATCH v5.2] mmc: cavium: Drop the aligned check for the dma
address
on 19/09/2019 Kevin Hao wrote:
> From: Kevin Hao
>
> In commit 73c1489f17e8 ("mmc: cavium: forbid unaligned DMA"), the codes
> are added to check the unaligned dma request. But at that time,
> we still don't do the dma map for the scatterlist yet. So it is
> meaningless to check the dma address. So drop of it.
>
> Signed-off-by: Kevin Hao
> ---
>
> Hi Bruce,
>
> This targets for standard/cn96xx branch.
Merged to v5.2 and linux-yocto-dev
Bruce
>
> drivers/mmc/host/cavium.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c
> index fc6464957df9..d724155d7eb6 100644
> --- a/drivers/mmc/host/cavium.c
> +++ b/drivers/mmc/host/cavium.c
> @@ -853,7 +853,7 @@ static void cvm_mmc_dma_request(struct mmc_host *mmc,
> /* unaligned multi-block DMA has problems, so forbid all unaligned */
> for (seg = 0; seg < mrq->data->sg_len; seg++) {
> struct scatterlist *sg = >data->sg[seg];
> - u64 align = (sg->offset | sg->length | sg->dma_address);
> + u64 align = (sg->offset | sg->length);
>
> if (!(align & 7))
> continue;
> --
> 2.14.4
>
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [kernel-cache master] ti-am335x: add CPU freq/idle support and correct arch bits
In message: [linux-yocto] [kernel-cache master] ti-am335x: add CPU freq/idle support and correct arch bits on 16/09/2019 Jun Miao wrote: > > > Hi Bruce. >Please help me merge the two patches to master branch of yocto-kernel-cache merged to master. Bruce > >5721cc33a0511c5964e96f439b61b97d20e500d7 ti-am335x: add CPU Freq/Idle > support >15fed008b84b8ef7ae760227d750f8840d635e43 ti-am335x: correct the arch > 64-bit to 32-bit > > > Jun Miao (2): > ti-am335x: correct the arch 64-bit to 32-bit > ti-am335x: add CPU Freq/Idle support > > bsp/ti-am335x/ti-am335x-standard.scc | 2 +- > bsp/ti-am335x/ti-am335x.cfg | 21 + > 2 files changed, 22 insertions(+), 1 deletion(-) > > -- > 2.22.0 > -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] : [kernel-cache master/yocto-5.2]: bcm-2xxx-rpi: add configure file for bcm-2xxx-rpi BSP in kernel-cache
In message: [linux-yocto]: [kernel-cache master/yocto-5.2]: bcm-2xxx-rpi: add configure file for bcm-2xxx-rpi BSP in kernel-cache on 16/09/2019 meng...@windriver.com wrote: > From: Limeng > > Hi Bruce, > > I am working on BSP bcm-2xxx-rpi platform, and intend to merge this BSP > supporting into yocto community. > Below patch includes scc and cfg files for Raspberrypi 4b platform. > > Could you please merge this patch into yocto-kernel-cache, branch is master > and yocto-5.2? The baseline configuration looks sane to me (I checked for obvious errors and non hardware configs). So I've gone ahead and merged this to the 5.2 and master branches. Bruce > > 0001-bcm-2xxx-rpi-add-configure-file-for-bcm-2xxx-rpi-BSP.patch > > bcm-2xxx-rpi.cfg | 268 > +++ > bcm-2xxx-rpi.scc | 13 ++ > bcm-2xxx-rpi4-preempt-rt.scc |8 + > bcm-2xxx-rpi4-standard.scc |9 + > 4 files changed, 298 insertions(+) > > > thanks, > Limeng -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Awkward line wrapping in bash
How about using `tput smam'? Regards, Chen Qi On 09/19/2019 11:43 PM, phodina wrote: Hi, based on André recommendation I commented out the PS1 variable and now I get `-sh-4.4#` for the prompt. I also checked and nothing is overwriting the variable. But I tried to change the size of the shell by using `stty cols 100 rows 40` as well as different sizes (smaller and bigger than 80 columns), but the amount of characters I get on the line stays at 81 followed by carrige return. However if I record the session with `script` I get the correct amount of characters per line. Here is my `stty -a` output: speed 115200 baud; rows 24; columns 100; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc Best regards Petr hodina ‐‐‐ Original Message ‐‐‐ On Wednesday, September 18, 2019 4:13 PM, André Castro wrote: Hi Petr, I still don't think this is related to Yocto. Comments below. Best regards, André On Wed, 18 Sep 2019, at 02:17:01 PM (WEST+0100), Phodina wrote: Hi, so I tried the PS1 prompt as suggested by André and it worked at that time on the booted system. So I changed the configuration in /etc/profile, built and flashed the system. Unfortunately it’s not working and I get the same issue - the line wrapping. Can you get the value of the 'PS1' variable in the new system that you flashed, when you are using it and the problem is happening? Just run "echo $PS1" on the shell. Just want to make sure that nothing is overwriting the 'PS1' variable and causing the issue again. There are lots of scripts that can override it. Here is the content of the /etc/profile: /etc/profile: system-wide .profile file for the Bourne shell (sh(1)) = and Bourne compatible shells (bash(1), ksh(1), ash(1), ...). = PATH="/usr/local/bin:/usr/bin:/bin" EDITOR="vi" # needed for packages like cron, git-commit [ "$TERM" ] || TERM="vt100" # Basic terminal capab. For screen etc. Add /sbin & co to $PATH for the root user == [ "$HOME" != "/home/root" ] || PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin Set the prompt for bash and ash (no other shells known to be in use here) == [ -z "$PS1" ] || PS1="$(cat /etc/device/hwid)@\h:\w \001\033[96m\002# \001\033[0m\002" if [ -d /etc/profile.d ]; then for i in /etc/profile.d/*.sh; do if [ -f $i -a -r $i ]; then . $i fi done unset i fi Make sure we are on a serial console (i.e. the device used starts with === /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which tries do == use ssh case $(tty 2>/dev/null) in /dev/tty[A-z]*) [ -x /usr/bin/resize ] && /usr/bin/resize >/dev/null;; esac export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM umask 022 I also turned on `checkwinsize` using `shopt` but didn’t work. I also include the output of stty (over serial): speed 115200 baud; line = 0; -brkint ixoff iutf8 -iexten And over SSH: speed 38400 baud; line = 0; eol = M-^?; eol2 = M-^?; -brkint ixany iutf8 I connect to the board over serial using screen on Mac. In minicom I get the same issue as do my colleagues on Windows using putty or screen on Linux. Same happens over SSH. I also checked that the terming package and those files are installed correctly in /etc/terminfo. Kind regards Petr Hodina ‐‐‐ Original Message ‐‐‐ On Monday, September 16, 2019 1:02 PM, phodina phod...@protonmail.com wrote: Thanks André, the PS1 variable has been the cause. Now bash behaves as expected. Petr ‐‐‐ Original Message ‐‐‐ On Monday, September 16, 2019 12:14 PM, André Castro andre.castro...@gmail.com wrote: Hi Petr, On Mon, 16 Sep 2019, at 10:34:33 AM (WEST+0100), Phodina wrote: Hi, I would like to ask for a help with an awkward behavior of line wrap in bash built using Yocto (thud release). When I connect over serial line, I get strange line wrapping. This might not be related to Yocto. The line keeps wrapping on the first line. Here is the environment: guest@:ebox~ # printenv LANG=C EDITOR=vi HZ=100 HUSHLOGIN=FALSE USER=root PWD=/home/root HOME=/home/root SHELL=/bin/sh TERM=linux SHLVL=1 LOGNAME=root PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
Re: [yocto] Awkward line wrapping in bash
On 9/19/19 11:43 AM, phodina wrote: Hi, based on André recommendation I commented out the PS1 variable and now I get `-sh-4.4#` for the prompt. I also checked and nothing is overwriting the variable. But I tried to change the size of the shell by using `stty cols 100 rows 40` as well as different sizes (smaller and bigger than 80 columns), but the amount of characters I get on the line stays at 81 followed by carrige return. However if I record the session with `script` I get the correct amount of characters per line. If you are able to reproduce this proble on the master, or a stable (1) branch with one of the supported qemu or HW BSPs (2), please open a defect in: https://bugzilla.yoctoproject.org/ Please report the branch, what layers you are using (hopefully you can reproduce it with just oe-core/poky + a HW layer) and with a standard image. ../Randy (1) https://wiki.yoctoproject.org/wiki/Releases (2): The list here is a good start, I'm not sure about the FSL support and I suspect that minnow board is no longer relevant. https://bugzilla.yoctoproject.org/describecomponents.cgi?product=BSPs If your hardware isn't listed, and you can't reproduce the issue in qemu or supported HW, you should contact your HW supplier. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Awkward line wrapping in bash
Hi, based on André recommendation I commented out the PS1 variable and now I get `-sh-4.4#` for the prompt. I also checked and nothing is overwriting the variable. But I tried to change the size of the shell by using `stty cols 100 rows 40` as well as different sizes (smaller and bigger than 80 columns), but the amount of characters I get on the line stays at 81 followed by carrige return. However if I record the session with `script` I get the correct amount of characters per line. Here is my `stty -a` output: speed 115200 baud; rows 24; columns 100; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc Best regards Petr hodina ‐‐‐ Original Message ‐‐‐ On Wednesday, September 18, 2019 4:13 PM, André Castro wrote: > Hi Petr, > > I still don't think this is related to Yocto. > Comments below. > > Best regards, > André > On Wed, 18 Sep 2019, at 02:17:01 PM (WEST+0100), Phodina wrote: > > > Hi, > > so I tried the PS1 prompt as suggested by André and it worked at that time > > on the booted system. So I changed the configuration in /etc/profile, built > > and flashed the system. > > Unfortunately it’s not working and I get the same issue - the line wrapping. > > Can you get the value of the 'PS1' variable in the new system that you > flashed, > when you are using it and the problem is happening? > > Just run "echo $PS1" on the shell. > > Just want to make sure that nothing is overwriting the 'PS1' variable and > causing the issue again. There are lots of scripts that can override it. > > > Here is the content of the /etc/profile: > > > > /etc/profile: system-wide .profile file for the Bourne shell (sh(1)) > > > > = > > > > and Bourne compatible shells (bash(1), ksh(1), ash(1), ...). > > > > = > > > > PATH="/usr/local/bin:/usr/bin:/bin" > > EDITOR="vi" # needed for packages like cron, git-commit > > [ "$TERM" ] || TERM="vt100" # Basic terminal capab. For screen etc. > > > > Add /sbin & co to $PATH for the root user > > > > == > > > > [ "$HOME" != "/home/root" ] || PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin > > > > Set the prompt for bash and ash (no other shells known to be in use here) > > > > == > > > > [ -z "$PS1" ] || PS1="$(cat /etc/device/hwid)@\h:\w \001\033[96m\002# > > \001\033[0m\002" > > if [ -d /etc/profile.d ]; then > > for i in /etc/profile.d/*.sh; do > > if [ -f $i -a -r $i ]; then > > . $i > > fi > > done > > unset i > > fi > > > > Make sure we are on a serial console (i.e. the device used starts with > > > > === > > > > /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which tries > > do > > > > == > > > > use ssh > > > > > > > > case $(tty 2>/dev/null) in > > /dev/tty[A-z]*) [ -x /usr/bin/resize ] && /usr/bin/resize >/dev/null;; > > esac > > export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM > > umask 022 > > I also turned on `checkwinsize` using `shopt` but didn’t work. > > I also include the output of stty (over serial): > > speed 115200 baud; line = 0; > > -brkint ixoff iutf8 > > -iexten > > And over SSH: > > speed 38400 baud; line = 0; > > eol = M-^?; eol2 = M-^?; > > -brkint ixany iutf8 > > I connect to the board over serial using screen on Mac. In minicom I get the > > same issue as do my colleagues on Windows using putty or screen on Linux. > > Same happens over SSH. > > I also checked that the terming package and those files are installed > > correctly in /etc/terminfo. > > Kind regards > > Petr Hodina > > ‐‐‐ Original Message ‐‐‐ > > On Monday, September 16, 2019 1:02 PM, phodina phod...@protonmail.com wrote: > > > > > Thanks André, > > > the PS1 variable has been the cause. Now bash behaves as expected. > > > Petr > > > ‐‐‐ Original Message ‐‐‐ > > > On Monday, September 16, 2019 12:14 PM, André Castro > > > andre.castro...@gmail.com wrote: > > > > > > > Hi Petr, > > > > On Mon, 16 Sep 2019, at 10:34:33 AM (WEST+0100), Phodina wrote: > > > > > > > > > Hi, > > > > > I would like to ask for a help with an awkward behavior of line wrap > > > > > in bash built using Yocto (thud release). When I connect over serial > > > > > line, I get strange line
Re: [yocto] How to share files between recipes?
On 19.09.2019 15:39, Patrick Doyle wrote:
> I have a set of data files (cryptographic keys) that I would like to
> share among several recipes in my build. They won't go into the
> rootfs, but they will be used by multiple recipes that construct the
> rootfs. So, to the best of my understanding, it seems like I should
> put them in sysroot and somehow access them from there.
>
> I constructed the following recipe:
> SUMMARY = "Development keys used by my image"
> DESCRIPTION = "Install the development keys in the sysroot so that they \
> can be referenced by other recipes."
>
> LICENSE = "Proprietary"
> LIC_FILES_CHKSUM =
> "file://${COMMON_LICENSE_DIR}/Proprietary;md5=0557f9d92cf58f2ccdd50f62f8ac0b28"
>
> SRC_URI = "file://keys"
>
> do_install() {
> install -d ${D}/${datadir}
> install -m 755 -d ${WORKDIR}/keys ${D}/${datadir}
> }
>
> FILES_${PN} += "${datadir}/keys/"
>
> But when I attempt to bitbake this recipe, I get the following error:
> ERROR: development-keys-1.0-r0 do_package: QA Issue: development-keys:
> Files/directories were installed but not shipped in any package:
> /usr
> /usr/share
>
> Ummm I don't put anything in /usr or /usr/share.
> I don't inherit from anything (other than base.bbclass) that puts
> anything in /usr or /usr/share.
You do. datadir is /usr/share.
>
> Does base.bbclass put anything in /usr or /usr/share?
> Why?
> I suppose I could follow the advice given in the error message and
>
> rm -rf ${D}/usr
>
> in my do_install() task, but I'd like to understand why and how those
> directories are being created in the first place?
>
> --wpd
--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com
signature.asc
Description: OpenPGP digital signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gitlab-runner
On Thu, Sep 19, 2019 at 09:39:55AM -0400, Randy MacLeod wrote: > On 9/19/19 2:56 AM, Robert ber...@yocto.user wrote: > > Hi, > > > > Does someone happen to have a BitBake recipe for gitlab-runner?[1] > > > > [1] https://gitlab.com/gitlab-org/gitlab-runner > > > > A quick search did not show up anything;) > > There's nothing in the layer index: > > https://layers.openembedded.org/layerindex/branch/master/recipes/?q=runner > > (It wasn't clear if you knew about the index.) > > I did find: > https://gitlab.cern.ch/Caribou/meta-caribou/tree/master/misc/gitlab-ci > that mentions gitlab-runner but it doesn't seem like that layer provides > a recipe but you might want to check it out anyway and let us know if > it works for you. >... It just downloads an ARM binary from the internet. Any layer actually building gitlab-runner would have to provide 200 Go libraries. > ,./Randy cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to share files between recipes?
On Thu, Sep 19, 2019 at 9:48 AM wrote: > One possibility is to provide these keys as host native tools and data to > build of target recipes. This makes the files available in the build > environment > but does not expose them to target. > > Create a -native recipe which has and installs the files and use via DEPENDS > to > the -native recipe. > > Hope this helps, > > -Mikko Thank you. That feels like the better answer all around. Ultimately, that's where I was going, but hadn't thought of the fact that I only really need this data on my native build environment. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to share files between recipes?
On Thu, Sep 19, 2019 at 9:39 AM Patrick Doyle wrote:
> do_install() {
> install -d ${D}/${datadir}
> install -m 755 -d ${WORKDIR}/keys ${D}/${datadir}
> }
>
Oops... I just noticed the typo(s) in my recipe... I wasn't installing
the contents of my ${WORKDIR} in ${D}${datadir}/keys the way I thought
I was... all I was doing was creating empty directories.
That's why I ask questions like this... so that right after I ask
them, I can find the blatantly stupid mistake I made in my code.
Thanks for playing!
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gitlab-runner
On 9/19/19 2:56 AM, Robert ber...@yocto.user wrote: Hi, Does someone happen to have a BitBake recipe for gitlab-runner?[1] [1] https://gitlab.com/gitlab-org/gitlab-runner A quick search did not show up anything;) There's nothing in the layer index: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=runner (It wasn't clear if you knew about the index.) I did find: https://gitlab.cern.ch/Caribou/meta-caribou/tree/master/misc/gitlab-ci that mentions gitlab-runner but it doesn't seem like that layer provides a recipe but you might want to check it out anyway and let us know if it works for you. Also I CCed Simon who is the most recent active committer to meta-caribou. Simon, Do you want to add this layer to the index? See: https://layers.openembedded.org/layerindex/branch/master/layers/ and click the "Submit layer" button. ,./Randy Regards, Robert -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to share files between recipes?
On Thu, Sep 19, 2019 at 09:39:32AM -0400, Patrick Doyle wrote: > I have a set of data files (cryptographic keys) that I would like to > share among several recipes in my build. They won't go into the > rootfs, but they will be used by multiple recipes that construct the > rootfs. So, to the best of my understanding, it seems like I should > put them in sysroot and somehow access them from there. One possibility is to provide these keys as host native tools and data to build of target recipes. This makes the files available in the build environment but does not expose them to target. Create a -native recipe which has and installs the files and use via DEPENDS to the -native recipe. Hope this helps, -Mikko -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to share files between recipes?
I have a set of data files (cryptographic keys) that I would like to
share among several recipes in my build. They won't go into the
rootfs, but they will be used by multiple recipes that construct the
rootfs. So, to the best of my understanding, it seems like I should
put them in sysroot and somehow access them from there.
I constructed the following recipe:
SUMMARY = "Development keys used by my image"
DESCRIPTION = "Install the development keys in the sysroot so that they \
can be referenced by other recipes."
LICENSE = "Proprietary"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/Proprietary;md5=0557f9d92cf58f2ccdd50f62f8ac0b28"
SRC_URI = "file://keys"
do_install() {
install -d ${D}/${datadir}
install -m 755 -d ${WORKDIR}/keys ${D}/${datadir}
}
FILES_${PN} += "${datadir}/keys/"
But when I attempt to bitbake this recipe, I get the following error:
ERROR: development-keys-1.0-r0 do_package: QA Issue: development-keys:
Files/directories were installed but not shipped in any package:
/usr
/usr/share
Ummm I don't put anything in /usr or /usr/share.
I don't inherit from anything (other than base.bbclass) that puts
anything in /usr or /usr/share.
Does base.bbclass put anything in /usr or /usr/share?
Why?
I suppose I could follow the advice given in the error message and
rm -rf ${D}/usr
in my do_install() task, but I'd like to understand why and how those
directories are being created in the first place?
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 2/2] spi: spi-mem: zynq-qspi: add is-dual support for zc706 board
From: Quanyang Wang
There are 2 SPI flash memories in zc706 board and it use the
configuration "Dual SS, 8-bit Parallel" which means separate
Slave-Select lines and separate 4 data lines. So add the is-dual
support for zc706 board according to the spi driver in SDK.
Refer to bd2c1810ae87 ("spi: zynq-qspi: Add driver for zynq qspi")
in https://github.com/Xilinx/linux-xlnx.git xlnx_rebase_v4.19
Signed-off-by: Quanyang Wang
---
drivers/spi/spi-zynq-qspi.c | 43 +++--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
index c6bee67decb5..2041d5dcf294 100644
--- a/drivers/spi/spi-zynq-qspi.c
+++ b/drivers/spi/spi-zynq-qspi.c
@@ -129,6 +129,9 @@
* @rxbuf: Pointer to the RX buffer
* @tx_bytes: Number of bytes left to transfer
* @rx_bytes: Number of bytes left to receive
+ * @is_dual: Flag to indicate whether dual flash memories are used
+ * @is_instr: Flag to indicate if transfer contains an instruction
+ * (Used in dual parallel configuration)
* @data_completion: completion structure
*/
struct zynq_qspi {
@@ -141,6 +144,8 @@ struct zynq_qspi {
u8 *rxbuf;
int tx_bytes;
int rx_bytes;
+ u32 is_dual;
+ u8 is_instr;
struct completion data_completion;
};
@@ -213,6 +218,14 @@ static void zynq_qspi_init_hw(struct zynq_qspi *xqspi)
zynq_qspi_write(xqspi, ZYNQ_QSPI_TX_THRESH_OFFSET,
ZYNQ_QSPI_TX_THRESHOLD);
+ if (xqspi->is_dual)
+ /* Enable two memories on separate buses */
+ zynq_qspi_write(xqspi, ZYNQ_QSPI_LINEAR_CFG_OFFSET,
+ (ZYNQ_QSPI_LCFG_TWO_MEM_MASK |
+ ZYNQ_QSPI_LCFG_SEP_BUS_MASK |
+ (1 << ZYNQ_QSPI_LCFG_DUMMY_SHIFT) |
+ ZYNQ_QSPI_FAST_READ_QOUT_CODE));
+
zynq_qspi_write(xqspi, ZYNQ_QSPI_ENABLE_OFFSET,
ZYNQ_QSPI_ENABLE_ENABLE_MASK);
}
@@ -236,15 +249,23 @@ static bool zynq_qspi_supports_op(struct spi_mem *mem,
* zynq_qspi_rxfifo_op - Read 1..4 bytes from RxFIFO to RX buffer
* @xqspi: Pointer to the zynq_qspi structure
* @size: Number of bytes to be read (1..4)
+ *
+ * Note: In case of dual parallel connection, even number of bytes are read
+ * when odd bytes are requested to avoid transfer of a nibble to each flash.
+ * The receive buffer though, is populated with the number of bytes requested.
*/
static void zynq_qspi_rxfifo_op(struct zynq_qspi *xqspi, unsigned int size)
{
+ unsigned int xsize;
u32 data;
data = zynq_qspi_read(xqspi, ZYNQ_QSPI_RXD_OFFSET);
if (xqspi->rxbuf) {
- memcpy(xqspi->rxbuf, ((u8 *)) + 4 - size, size);
+ xsize = size;
+ if (xqspi->is_dual && !xqspi->is_instr && (size % 2))
+ xsize++;
+ memcpy(xqspi->rxbuf, ((u8 *)) + 4 - xsize, size);
xqspi->rxbuf += size;
}
@@ -257,12 +278,19 @@ static void zynq_qspi_rxfifo_op(struct zynq_qspi *xqspi,
unsigned int size)
* zynq_qspi_txfifo_op - Write 1..4 bytes from TX buffer to TxFIFO
* @xqspi: Pointer to the zynq_qspi structure
* @size: Number of bytes to be written (1..4)
+ *
+ * In dual parallel configuration, when read/write data operations
+ * are performed, odd data bytes have to be converted to even to
+ * avoid a nibble (of data when programming / dummy when reading)
+ * going to individual flash devices, where a byte is expected.
+ * This check is only for data and will not apply for commands.
*/
static void zynq_qspi_txfifo_op(struct zynq_qspi *xqspi, unsigned int size)
{
static const unsigned int offset[4] = {
ZYNQ_QSPI_TXD_00_01_OFFSET, ZYNQ_QSPI_TXD_00_10_OFFSET,
ZYNQ_QSPI_TXD_00_11_OFFSET, ZYNQ_QSPI_TXD_00_00_OFFSET };
+ unsigned int xsize;
u32 data;
if (xqspi->txbuf) {
@@ -274,7 +302,11 @@ static void zynq_qspi_txfifo_op(struct zynq_qspi *xqspi,
unsigned int size)
}
xqspi->tx_bytes -= size;
- zynq_qspi_write(xqspi, offset[size - 1], data);
+
+ xsize = size;
+ if (xqspi->is_dual && !xqspi->is_instr && (size % 2))
+ xsize++;
+ zynq_qspi_write(xqspi, offset[xsize - 1], data);
}
/**
@@ -295,6 +327,7 @@ static void zynq_qspi_chipselect(struct spi_device *spi,
bool assert)
config_reg |= (((~(BIT(spi->chip_select))) <<
ZYNQ_QSPI_SS_SHIFT) &
ZYNQ_QSPI_CONFIG_SSCTRL_MASK);
+ xqspi->is_instr = 1;
} else {
config_reg |= ZYNQ_QSPI_CONFIG_SSCTRL_MASK;
}
@@ -637,6 +670,12 @@ static int zynq_qspi_probe(struct platform_device *pdev)
goto remove_master;
}
+
[linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 1/2] mtd: spi-nor: change flash_info.flags from u16 to u32 to avoid compile warning
From: Quanyang Wang
Because SST_GLOBAL_PROT_UNLK is BIT(16) which exceed the extent of
u16, so change it to u32.
drivers/mtd/spi-nor/spi-nor.c:2076:12: warning: large integer implicitly
truncated to
unsigned type [-Woverflow]
.flags = (_flags),
^
drivers/mtd/spi-nor/spi-nor.c:2385:19: note: in expansion of macro ‘INFO’
{ "sst26wf016B", INFO(0xbf2651, 0, 64 * 1024, 32, SECT_4K |
SST_GLOBAL_PROT_UNLK) },
^~~~
Signed-off-by: Quanyang Wang
---
drivers/mtd/spi-nor/spi-nor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d3b287e851cf..0c412b77597a 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -268,7 +268,7 @@ struct flash_info {
u16 page_size;
u16 addr_width;
- u16 flags;
+ u32 flags;
#define SECT_4KBIT(0) /* SPINOR_OP_BE_4K works
uniformly */
#define SPI_NOR_NO_ERASE BIT(1) /* No erase command needed */
#define SST_WRITE BIT(2) /* use SST byte programming */
--
2.17.1
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/2] fix compile warning
From: Quanyang Wang Hi Bruce, Would you please help me merge the two patches into linux-ycoto-5.2 kernel, branch v5.2/standard/xlnx-soc ? Thanks, Quanyang Quanyang Wang (2): mtd: spi-nor: change flash_info.flags from u16 to u32 to avoid compile warning spi: spi-mem: zynq-qspi: add is-dual support for zc706 board drivers/mtd/spi-nor/spi-nor.c | 2 +- drivers/spi/spi-zynq-qspi.c | 43 +-- 2 files changed, 42 insertions(+), 3 deletions(-) -- 2.17.1 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [PATCH] kernel.fitimage.bbclass: remove ramdisk_ctype
This should go to the oe-core list,
openembedded-c...@lists.openembedded.org.
Thanks,
Ross
On 19/09/2019 09:13, Heiko Schocher wrote:
set in the ramdisk node the compression property
always to "none", as U-Boot nowadays since commit:
b1307f884a91 ("fit: Support compression for non-kernel components (e.g. FDT)")
decompress non kernel components. Setting compression
to the used comression algorithm now, will end in
fail of your kernel boot with the ramdisk.
This issue is fixed since commit:
bddd98573465 ("fit: Do not automatically decompress ramdisk images")
which now prints a warning in U-Boot, instead of decompressing
the ramdisk, but we should setup compression property correct.
Signed-off-by: Heiko Schocher
---
meta/classes/kernel-fitimage.bbclass | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index b51882dce4..1bcb09c598 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -207,7 +207,6 @@ EOF
fitimage_emit_section_ramdisk() {
ramdisk_csum="${FIT_HASH_ALG}"
- ramdisk_ctype="none"
ramdisk_loadline=""
ramdisk_entryline=""
@@ -218,24 +217,6 @@ fitimage_emit_section_ramdisk() {
ramdisk_entryline="entry = <${UBOOT_RD_ENTRYPOINT}>;"
fi
- case $3 in
- *.gz)
- ramdisk_ctype="gzip"
- ;;
- *.bz2)
- ramdisk_ctype="bzip2"
- ;;
- *.lzma)
- ramdisk_ctype="lzma"
- ;;
- *.lzo)
- ramdisk_ctype="lzo"
- ;;
- *.lz4)
- ramdisk_ctype="lz4"
- ;;
- esac
-
cat << EOF >> ${1}
ramdisk@${2} {
description = "${INITRAMFS_IMAGE}";
@@ -243,7 +224,7 @@ fitimage_emit_section_ramdisk() {
type = "ramdisk";
arch = "${UBOOT_ARCH}";
os = "linux";
-compression = "${ramdisk_ctype}";
+compression = "none";
${ramdisk_loadline}
${ramdisk_entryline}
hash@1 {
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] kernel.fitimage.bbclass: remove ramdisk_ctype
set in the ramdisk node the compression property
always to "none", as U-Boot nowadays since commit:
b1307f884a91 ("fit: Support compression for non-kernel components (e.g. FDT)")
decompress non kernel components. Setting compression
to the used comression algorithm now, will end in
fail of your kernel boot with the ramdisk.
This issue is fixed since commit:
bddd98573465 ("fit: Do not automatically decompress ramdisk images")
which now prints a warning in U-Boot, instead of decompressing
the ramdisk, but we should setup compression property correct.
Signed-off-by: Heiko Schocher
---
meta/classes/kernel-fitimage.bbclass | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index b51882dce4..1bcb09c598 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -207,7 +207,6 @@ EOF
fitimage_emit_section_ramdisk() {
ramdisk_csum="${FIT_HASH_ALG}"
- ramdisk_ctype="none"
ramdisk_loadline=""
ramdisk_entryline=""
@@ -218,24 +217,6 @@ fitimage_emit_section_ramdisk() {
ramdisk_entryline="entry = <${UBOOT_RD_ENTRYPOINT}>;"
fi
- case $3 in
- *.gz)
- ramdisk_ctype="gzip"
- ;;
- *.bz2)
- ramdisk_ctype="bzip2"
- ;;
- *.lzma)
- ramdisk_ctype="lzma"
- ;;
- *.lzo)
- ramdisk_ctype="lzo"
- ;;
- *.lz4)
- ramdisk_ctype="lz4"
- ;;
- esac
-
cat << EOF >> ${1}
ramdisk@${2} {
description = "${INITRAMFS_IMAGE}";
@@ -243,7 +224,7 @@ fitimage_emit_section_ramdisk() {
type = "ramdisk";
arch = "${UBOOT_ARCH}";
os = "linux";
-compression = "${ramdisk_ctype}";
+compression = "none";
${ramdisk_loadline}
${ramdisk_entryline}
hash@1 {
--
2.21.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] gitlab-runner
Hi, Does someone happen to have a BitBake recipe for gitlab-runner?[1] [1] https://gitlab.com/gitlab-org/gitlab-runner A quick search did not show up anything;) Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
