|
Writing do_compile in python and importing modules
Patrick Doyle <wpdster@...>
i was just reviewing a recipe I wrote a month or two ago and saw that I wrote:
do_compile() { python3 ${WORKDIR}/assemble-tsk-blob.py -o tsk-blob -d ${DEPLOY_DIR_IMAGE}/foo -t ${DEPLOY_DIR_IMAGE}/bar } and I thought to myself, why did I write assemble-tsk-blob.py (which is a fairly trivial python 10 line script) instead of embedding it inline in my bitbake recipe? The answer is: because I could iterate on that 10 line script and test it much more quickly as a standalone python script than I could if I embedded it in a recipe. (There are another 10-15 lines of argparse and if __name__ == '__main__' stuff beyond the 10 lines of actual code). Since I'm in a cleaning-up mood, I started wondering if I could change my do_compile() function to a python function and then embed the 10 lines in there. Of course I can. But then I started wondering if I could change do_compile to python, have it import assemble-tsk-blob, and get the best of both worlds -- the ability to test assemble-tsk-blob outside of bitbake, and the efficiency of including its core operation directly within do_compile() and not requring that I spin up another python instance. Aside... there is nothing python3-ish about this code, I am just in the habit of unquestioningly using python3 for all new development. Any thoughts? --wpd
|
|
|
|
[OE-core] [PATCH 0/2] fix can't login when debug-tweaks is not in IMAGE_FEATURES
Varun A <vashok890@...>
Was going through this thread. I see root password defined as root explicitly in the base-passwd master file I am using which is of security concern. Has any development come about this?Is there a patch to get around this issue?
|
|
|
|
Kernel modules build fails with bitbake but not host toolchain
Dimitris Tassopoulos
Hi all. I'm having difficult to debug an issue I have. Although I'm able to build my kernel, overlays, dtb and modules without any errors using a specific git repo and my toolchain on my host, the bitbake fails to build in the `do_compile_kernelmodules` step and the error I get is: ``` | /docker/build/tmp/work-shared/nanopi-duo2/kernel-source/drivers/net/wireless/realtek/rtl8189fs/core/rtw_cmd.c:22:10: fatal error: drv_types.h: No such file or directory | 22 | #include <drv_types.h> | | ^~~~~~~~~~~~~ | compilation terminated. | /docker/build/tmp/work-shared/nanopi-duo2/kernel-source/scripts/Makefile.build:280: recipe for target 'drivers/net/wireless/realtek/rtl8189fs/core/rtw_cmd.o' failed | make[6]: *** [drivers/net/wireless/realtek/rtl8189fs/core/rtw_cmd.o] Error 1 | /docker/build/tmp/work-shared/nanopi-duo2/kernel-source/scripts/Makefile.build:497: recipe for target 'drivers/net/wireless/realtek/rtl8189fs' failed | make[5]: *** [drivers/net/wireless/realtek/rtl8189fs] Error 2 | /docker/build/tmp/work-shared/nanopi-duo2/kernel-source/scripts/Makefile.build:497: recipe for target 'drivers/net/wireless/realtek' failed | make[4]: *** [drivers/net/wireless/realtek] Error 2 | make[4]: *** Waiting for unfinished jobs.... ``` Of course the drv_types.h file is there and I've said the kernel builds fine using any toolchain from version 7.2 up to 8, I've tried locally on my workstation. The kernel recipe is located here: I've also tried to override the default do_compile_kernelmodules and simplify it down to this, but it still fails with the same error: ``` oe_runmake modules ``` Any good ideas? Thanks!
|
|
|
|
[meta-selinux][PATCH] support policy module configuration at recipe level
Joe MacDonald
On highly storage-limited machines it may be beneficial to completely
remove some or all non-essential policy modules. refpolicy already supports this with the 'no' option in modules.conf, so we'll just expose this feature (with an appropriate warning) at the recipe-level. Signed-off-by: Joe MacDonald <joe_macdonald@...> --- .../refpolicy/refpolicy-minimum_2.20190201.bb | 10 ++++++++++ recipes-security/refpolicy/refpolicy-minimum_git.bb | 11 +++++++++++ recipes-security/refpolicy/refpolicy_common.inc | 10 ++++++++++ 3 files changed, 31 insertions(+) diff --git a/recipes-security/refpolicy/refpolicy-minimum_2.20190201.bb b= /recipes-security/refpolicy/refpolicy-minimum_2.20190201.bb index 40abe35..01c9fc0 100644 --- a/recipes-security/refpolicy/refpolicy-minimum_2.20190201.bb +++ b/recipes-security/refpolicy/refpolicy-minimum_2.20190201.bb @@ -44,6 +44,16 @@ EXTRA_POLICY_MODULES +=3D "mta" # hostname_t, ping_t, netutils_t) from modules: EXTRA_POLICY_MODULES +=3D "modutils consoletype hostname netutils" =20 +# Add specific policy modules here that should be purged from the system +# policy. Purged modules will not be built and will not be installed on= the +# target. To use them at some later time you must specifically build an= d load +# the modules by hand on the target. +# +# USE WITH CARE! With this feature it is easy to break your policy by p= urging +# core modules (eg. userdomain) +#=20 +# PURGE_POLICY_MODULES +=3D "xdg xen" + POLICY_MODULES_MIN =3D "${CORE_POLICY_MODULES} ${EXTRA_POLICY_MODULES}" =20 # re-write the same func from refpolicy_common.inc diff --git a/recipes-security/refpolicy/refpolicy-minimum_git.bb b/recipe= s-security/refpolicy/refpolicy-minimum_git.bb index 40abe35..3b3ca15 100644 --- a/recipes-security/refpolicy/refpolicy-minimum_git.bb +++ b/recipes-security/refpolicy/refpolicy-minimum_git.bb @@ -44,6 +44,17 @@ EXTRA_POLICY_MODULES +=3D "mta" # hostname_t, ping_t, netutils_t) from modules: EXTRA_POLICY_MODULES +=3D "modutils consoletype hostname netutils" =20 +# Add specific policy modules here that should be purged from the system +# policy. Purged modules will not be built and will not be installed on= the +# target. To use them at some later time you must specifically build an= d load +# the modules by hand on the target. +# +# USE WITH CARE! With this feature it is easy to break your policy by p= urging +# core modules (eg. userdomain) +#=20 +# PURGE_POLICY_MODULES +=3D "xdg xen" + + POLICY_MODULES_MIN =3D "${CORE_POLICY_MODULES} ${EXTRA_POLICY_MODULES}" =20 # re-write the same func from refpolicy_common.inc diff --git a/recipes-security/refpolicy/refpolicy_common.inc b/recipes-se= curity/refpolicy/refpolicy_common.inc index 137ccee..2d9ace5 100644 --- a/recipes-security/refpolicy/refpolicy_common.inc +++ b/recipes-security/refpolicy/refpolicy_common.inc @@ -122,8 +122,18 @@ python __anonymous () { d.setVar('DEFAULT_ENFORCING', 'permissive') } =20 +disable_policy_modules () { + for module in ${PURGE_POLICY_MODULES} ; do + sed -i "s/^\(\<${module}\>\) *=3D *.*$/\1 =3D off/" ${S}/policy/module= s.conf + done +} + do_compile() { + if [ -f "${WORKDIR}/modules.conf" ] ; then + cp -f ${WORKDIR}/modules.conf ${S}/policy/modules.conf + fi oe_runmake conf + disable_policy_modules oe_runmake policy } =20 --=20 2.20.1
|
|
|
|
Fixing vulnerabilities in glibc
#yocto
Milun Jovanovic
My greeting to all
I am new on yocto project and yocto build environment is also new to me ... My working task is removing vulnerabilities from libc library... The processor is based on arm5 while newer yoctos 2.7.x and 3.x. do not provide environment support for arm5 based processors. The glibc vulnerabilities are fixed in the latest glibc 2.30 released. package while yocto 2.6.x includes 2.28 package. Also some of glibc vulnerabilities are patched in 2.6.4 (\oecore-thud-20.0.4.tar\oecore-thud-20.0.4\meta\recipes-core\glibc\glibc): CVE-2016-10739 CVE-2018-19591 CVE-2019-6488 CVE-2019-7309 CVE-2019-9169 while there are some others those have not been patched: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-3590 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-7254
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-20796
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-9192
Does anyone know whether new vulnerability patches will be applied for yocto 2.6.5 and when will be released yocto 2.6.5 ? Thank you in advance Milun
|
|
|
|
Re: Issues with alsa-state
Quentin wrote...
There are a lot of paths that it searched in for the file. I’ve moved the file in the file system changed the value of FILESEXTRAPATHS_prepend_mx6 from: FILESEXTRAPATHS_prepend_mx6 := "${THISDIR}/${PN}/imx:” to: FILESEXTRAPATHS_prepend_mx6 := "${THISDIR}/${PN}:” That has made the build process find my version of asound.state first. Thanks, -Andy.
|
|
|
|
Re: Unable to build core-image-full-cmdline on openSUSE Leap 15.1: dnf can't find _curses module in do_rootfs task
Alexander Kanavin
This error means native python3 was somehow built without curses, or isn't able to use the curses module that was built, so installing host packages isn't going to help. You need to look into how python3 was built and installed into recipe-sysroot-native. I can't offer more specific guidance than that unfortunately. Alex
On Sun, 8 Dec 2019 at 22:33, Rebecca Cran <rebecca@...> wrote: I recently switched from Ubuntu 19.10 to openSUSE Leap 15.1, but I'm having problems building core-image-full-cmdline on it. I've installed all the host packages I can think of, including python-curses and python3-curses, with no success.
|
|
|
|
Re: Issues with alsa-state
Quentin Schulz
Hi Andy,
On Mon, Dec 09, 2019 at 10:40:49AM +0000, Andy Pont wrote: Hello!Have a look at the paths traversed by Yocto to find your asound.state in log.do_fetch in the WORKDIR. You'll have the following: DEBUG: Searching for asound.state in paths: The first path to have asound.state in it will be the provider for that file. This order is derived from OVERRIDES variable (rightmost to leftmost for priority order). Basically, rightmost in OVERRIDES is taken, then looked for in all FILESPATHS paths. Then the second rightmost. What people usually do is that they use a lower priority OVERRIDES for subdirectory filename and then the original one or one in a higher priority OVERRIDES is taken. Quentin
|
|
|
|
Issues with alsa-state
Hello! I am trying to add a custom asound.state file into my Zeus based i.MX6 image. I have created a custom .bbappend file with the following contents: FILESEXTRAPATHS_prepend_mx6 := "${THISDIR}/${PN}/imx:” PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}” The output from: $ bitbake-layers show-appends | grep alsa is (some names changed to protect the guilty): alsa-state.bb: /home/.../sources/meta-freescale/recipes-bsp/alsa-state/alsa-state.bbappend /home/.../sources/meta-boundary/recipes-bsp/alsa-state/alsa-state.bbappend /home/.../sources/meta-project/recipes-bsp/alsa-state/alsa-state.bbappend The file that is included in the image is the one from the meta-boundary layer and not the one from my “meta-project” layer. Is there some way to make my layer take priority or do I need to try to exclude the alsa-state recipes from the meta-freescale and meta-boundary layers using BBMASK? -Andy.
|
|
|
|
Re: [meta-security][PATCH] meta-security: add layer index callouts
Diego Santa Cruz
toggle quoted messageShow quoted text
-----Original Message-----This looks like a copy & paste typo, shouldn't this be +BBLAYERS_LAYERINDEX_NAME_scanners-layer = "meta-security-compliance" diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf-- Diego Santa Cruz, PhD Technology Architect spinetix.com
|
|
|
|
Dhcp-server rpm dependent on base-passwd rpm
Varun A <vashok890@...>
Wanted to know if dhcp-server has an actual dependency with base-passwd rpm or is it an optional dependency. I am using dhcp-server 4.3.2 rpm and when I try rpm -qpR dhcp-server 4.3.2.rpm I see base-passwd in it. Can I remove the dependency using a bbappend file?
|
|
|
|
dishant.arora1996@...
Recipe --> python3-psycopg2-native --> https://layers.openembedded.org/layerindex/recipe/72275/
Added this recipe using `IMAGE_INSTALL` variable in `sjpl-image.bb` file
Got following errors while building the image :
How can this error be resolved ?
|
|
|
|
[meta-selinux][PATCH] rename sed_4.2.2.bbappend to sed_4.%.bbappend
hongxu
Since upstream oe-core [bd40260cba sed: upgrade to 4.7],
renme bbappend to match the new version Signed-off-by: Hongxu Jia <hongxu.jia@...> --- recipes-extended/sed/{sed_4.2.2.bbappend => sed_4.%.bbappend} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename recipes-extended/sed/{sed_4.2.2.bbappend => sed_4.%.bbappend} (100%) diff --git a/recipes-extended/sed/sed_4.2.2.bbappend b/recipes-extended/sed/sed_4.%.bbappend similarity index 100% rename from recipes-extended/sed/sed_4.2.2.bbappend rename to recipes-extended/sed/sed_4.%.bbappend -- 2.21.0
|
|
|
|
[layerindex-web][PATCH 0/5] Misc bug fixes [cover letter only]
Paul Eggleton
Updates some bundled components (jQuery, Chart.js, Bootstrap) and fixes
a couple of bugs in the layer update script and background task display for admins. The following changes since commit f84223f4730cd171d25c980b43f07d89950f46= bd: README.devel: mention python SMTP server (2019-11-26 10:44:37 +1300) are available in the Git repository at: git://git.yoctoproject.org/layerindex-web paule/fixes15 http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=3Dpaule/fixe= s15 Paul Eggleton (5): Upgrade Bootstrap to 3.4.1 Upgrade jquery to 3.4.1 Upgrade Chart.js to 2.9.3 update: ensure removed recipe dependencies are removed from db tasks: squash out CRs in task logs to avoid huge transfers layerindex/recipeparse.py | 12 +- layerindex/static/css/bootstrap-theme.css | 200 +- layerindex/static/css/bootstrap-theme.css.map | 2 +- layerindex/static/css/bootstrap-theme.min.css | 6 +- .../static/css/bootstrap-theme.min.css.map | 2 +- layerindex/static/css/bootstrap.css | 985 +- layerindex/static/css/bootstrap.css.map | 2 +- layerindex/static/css/bootstrap.min.css | 6 +- layerindex/static/css/bootstrap.min.css.map | 2 +- layerindex/static/js/Chart.js | 25319 +++++++++------- layerindex/static/js/Chart.min.js | 13 +- layerindex/static/js/bootstrap.js | 397 +- layerindex/static/js/bootstrap.min.js | 7 +- .../js/{jquery-3.3.1.js =3D> jquery-3.4.1.js} | 596 +- layerindex/update_layer.py | 2 +- layerindex/views.py | 7 +- templates/base.html | 2 +- 17 files changed, 14925 insertions(+), 12635 deletions(-) rename layerindex/static/js/{jquery-3.3.1.js =3D> jquery-3.4.1.js} (94%) --=20 2.20.1
|
|
|
|
Unable to build core-image-full-cmdline on openSUSE Leap 15.1: dnf can't find _curses module in do_rootfs task
Rebecca Cran <rebecca@...>
I recently switched from Ubuntu 19.10 to openSUSE Leap 15.1, but I'm having problems building core-image-full-cmdline on it. I've installed all the host packages I can think of, including python-curses and python3-curses, with no success.
I'm on the zeus branch, and running "bitbake core-image-full-cmdline" results in the following error when running the do_rootfs task: ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Could not invoke dnf. Command '/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/rootfs/etc/yum.repos.d --installroot=/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/rootfs --setopt=logdir=/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp --repofrompath=oe-repo,/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/oe-rootfs-repo makecache --refresh' returned 1: Traceback (most recent call last): File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/dnf.real", line 57, in <module> from dnf.cli import main File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/__init__.py", line 30, in <module> from dnf.cli.cli import Cli # :api File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 44, in <module> from . import output File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/output.py", line 34, in <module> import dnf.cli.progress File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/progress.py", line 19, in <module> from dnf.cli.term import _term_width File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/term.py", line 21, in <module> import curses File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/curses/__init__.py", line 13, in <module> from _curses import * ModuleNotFoundError: No module named '_curses' ERROR: Logfile of failure stored in: /home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.40254 ERROR: Task (/home/bcran/src/fsl-community-bsp/sources/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_rootfs) failed with exit code '1' -- Rebecca Cran
|
|
|
|
Re: [meta-security][PATCH 0/2] tpm2-abrmd: startup fixes
merged.
toggle quoted messageShow quoted text
thanks, Armin
On 12/6/19 2:13 AM, Diego Santa Cruz
via Lists.Yoctoproject.Org wrote:
This ports patches from the meta-measured layer that fix tpm2-abrmd not starting up. The first patch is necessary on kernels 4.12 and later. The second patch is necessary after the update to 2.3.0. Philip Tricca (1): tpm2-abrmd: Port command line options to new version. Trevor Woerner (1): tpm2-abrmd-init.sh: fix for /dev/tpmrmX meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd-init.sh | 2 +- meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd.default | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
|
|
|
|
Re: What should I expect when using SSTATE_MIRROR?
Mans Zigher <mans.zigher@...>
Hi, I am also using docker when building but good point I will make sure that we are using the same version of the docker image. Thanks
On Fri, Dec 6, 2019, 17:06 <Mikko.Rapeli@...> wrote: Hi,
|
|
|
|
[meta-mingw][PATCH] wayland: Disable DTD validation on i686 MinGW
Joshua Watt
DTD validation can't be built for i686 MinGW because the assembly file
used to encode the DTD string is incompatible (it works fine for x86_64 MinGW though). Signed-off-by: Joshua Watt <JPEWhacker@...> --- recipes-graphics/wayland/wayland_%.bbappend | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/recipes-graphics/wayland/wayland_%.bbappend b/recipes-graphics/wayland/wayland_%.bbappend index 3713f2d..bbb1c52 100644 --- a/recipes-graphics/wayland/wayland_%.bbappend +++ b/recipes-graphics/wayland/wayland_%.bbappend @@ -1,2 +1,6 @@ +# The assembly file that encodes the DTD string into wayland-scanner is not +# compatible with i686 MinGW +PACKAGECONFIG_remove_mingw32_i686 = "dtd-validation" + EXTRA_OECONF_class-nativesdk_mingw32 = "--disable-documentation --disable-libraries" -- 2.23.0
|
|
|
|
[meta-security][PATCH] meta-security: add layer index callouts
Signed-off-by: Armin Kuster <akuster808@...>
--- meta-integrity/conf/layer.conf | 2 ++ meta-security-compliance/conf/layer.conf | 2 ++ meta-tpm/conf/layer.conf | 1 + 3 files changed, 5 insertions(+) diff --git a/meta-integrity/conf/layer.conf b/meta-integrity/conf/layer.conf index 962424c..bfc9c6f 100644 --- a/meta-integrity/conf/layer.conf +++ b/meta-integrity/conf/layer.conf @@ -24,3 +24,5 @@ OE_TERMINAL_EXPORTS += "INTEGRITY_BASE" LAYERSERIES_COMPAT_integrity = "zeus" # ima-evm-utils depends on keyutils from meta-oe LAYERDEPENDS_integrity = "core openembedded-layer" + +BBLAYERS_LAYERINDEX_NAME_integrity = "meta-integrity" diff --git a/meta-security-compliance/conf/layer.conf b/meta-security-compliance/conf/layer.conf index 0e93bd0..e346bf3 100644 --- a/meta-security-compliance/conf/layer.conf +++ b/meta-security-compliance/conf/layer.conf @@ -11,3 +11,5 @@ BBFILE_PRIORITY_scanners-layer = "10" LAYERSERIES_COMPAT_scanners-layer = "zeus" LAYERDEPENDS_scanners-layer = "core openembedded-layer meta-python" + +BBLAYERS_LAYERINDEX_NAME_integrity = "meta-security-compliance" diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf index 3af2d95..175eba8 100644 --- a/meta-tpm/conf/layer.conf +++ b/meta-tpm/conf/layer.conf @@ -14,3 +14,4 @@ LAYERDEPENDS_tpm-layer = " \ core \ openembedded-layer \ " +BBLAYERS_LAYERINDEX_NAME_tpm-layer = "meta-tpm" -- 2.17.1
|
|
|
|
sdk rpi3 & rpi4 different sysroot
Ed Vidal
Hi, Any and all help is appreciated. Thanks in advance. Question 1 I tried using the sdk to build icestorm (a makefile project). The sysroot for rpi3 sdk & rpi4 sdk are missing a ftdi.h header. The target rpi4 builds icestorm okay. see steps below. Question 2 What is the procedure to update the meta-raspberrypi repo? An issue with core-image-sato for rpi3 required adding vidal@ws009:~/wkg/yocto-zeus-3.0/raspberrypi4/poky/meta-raspberrypi$ git diff diff --git a/conf/machine/raspberrypi3.conf b/conf/machine/raspberrypi3.conf index 581e47c..43a0a25 100644 --- a/conf/machine/raspberrypi3.conf +++ b/conf/machine/raspberrypi3.conf @@ -18,3 +18,4 @@ UBOOT_MACHINE = "rpi_3_32b_config" SERIAL_CONSOLES ?= "115200;ttyS0" ARMSTUB ?= "armstub7.bin" +ENABLE_UART = "1" For rpi4 build I made the same in raspberrypi4.conf diff --git a/conf/machine/raspberrypi4.conf b/conf/machine/raspberrypi4.conf index 1bcf931..0b91515 100644 --- a/conf/machine/raspberrypi4.conf +++ b/conf/machine/raspberrypi4.conf @@ -18,3 +18,4 @@ SERIAL_CONSOLES ?= "115200;ttyS0" VC4DTBO ?= "vc4-fkms-v3d" ARMSTUB ?= "armstub7.bin" +ENABLE_UART = "1" Question 3 Why is the header file ftdi.h missing in rpi4 sdk and not used in rpi3 sdk? vidal@ws009:~/wkg/test-yocto-sdk$ git clone https://github.com/develone/icestorm.git vidal@ws009:~/wkg/test-yocto-sdk$ . /opt/poky/3.0.1/rpi4/environment-setup-cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi vidal@ws009:~/wkg/test-yocto-sdk$ cd icestorm/ vidal@ws009:~/wkg/test-yocto-sdk$ echo ${CC} arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/opt/poky/3.0.1/rpi4/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ time make -e The following error: make[1]: Entering directory '/home/vidal/wkg/test-yocto-sdk/icestorm/iceprog' arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/opt/poky/3.0.1/rpi4/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi -O2 -pipe -g -feliminate-unused-debug-types -c -o iceprog.o iceprog.c iceprog.c:27:10: fatal error: ftdi.h: No such file or directory 27 | #include <ftdi.h> | ^~~~~~~~ compilation terminated. Tried to locate ftdi.h using the command below none was found in my rpi4 sdk sysroot. vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ find /opt/poky/3.0.1/rpi4/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/ -name ftdi.h A ftdi.h file was found in my rpi3 sdk sysroot. vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ find /opt/poky/3.0.1/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/ -name ftdi.h /opt/poky/3.0.1/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/usr/include/libftdi1/ftdi.h The only difference between the raspberrypi3 & raspberrypi4 builds are below. vidal@ws009:~/wkg/yocto-zeus-3.0/raspberrypi4/build$ diff ../../build/conf/local.conf conf/local.conf 39c39 < MACHINE ??= "raspberrypi3" --- > MACHINE ??= "raspberrypi4" 66a67 > DL_DIR ?= "/home/vidal//wkg/yocto-zeus-3.0/build/downloads" Testing rpi3 sdk vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ . /opt/poky/3.0.1/environment-setup-cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ echo ${CC} arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/opt/poky/3.0.1/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ make -e The rpi3 sdk gets the same error as the rpi4 sdk (see above). target rpi4 real 23m38.686s user 23m16.332s sys 0m9.949s AMD 6 core sdk real 3m33.809s user 3m33.304s sys 0m0.556s Let me know if I can provide additional information, Regards Edward Vidal Jr. e-mail develone@... 915-595-1613
|
|
|