[yocto] nativesdk-expect configure error
Hi, I'm seeing the following do_configure error when building nativesdk-expect, this is in Rocko but the recipe doesn't look like it's changed much in master. checking for Tcl public headers... configure: error: tcl.h not found. Please specify its location with --with-tclinclude | NOTE: The following config.log files may provide further information. | NOTE: /ws/rufilla/curtisswright/yocto-rocko/build/tmp/work/x86_64-nativesdk-cwrsdk-linux/nativesdk-expect/5.45-r1/build/config.log | ERROR: configure failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /ws/rufilla/curtisswright/yocto-rocko/build/tmp/work/x86_64-nativesdk-cwrsdk-linux/nativesdk-expect/5.45-r1/temp/log.do_configure.31445) ERROR: Task (virtual:nativesdk:/ws/rufilla/curtisswright/yocto-rocko/sources/poky/meta/recipes-devtools/expect/expect_5.45.bb:do_configure) failed with exit code '1' To fix it I added TCL_INCLUDE_PATH_class-nativesdk = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6" Is anyone else seeing this with newer Yocto versions? if so shall I submit a patch for this? Best Regards, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mono: QA Error building mono-5.12.0.226
On Fri, Nov 23, 2018 at 10:45 AM Alex Lennon wrote: > > > > On 23/11/2018 08:55, Martin Townsend wrote: > > Hi Alex, > > On Thu, Nov 22, 2018 at 3:49 PM Alex J Lennon wrote: > >> > >> On 22/11/2018 15:46, Martin Townsend wrote: > >>> Hi, > >>> > >>> This one is probably for the meta-mono maintainer > >>> > >>> I was getting quite a few file-rdeps QA errors. > >>> I managed to get rid of them all except 1 using > >>> RDEPENDS_${PN}-libs-2.0 += "mono" > >>> RDEPENDS_${PN}-libs-3.5 += "mono" > >>> RDEPENDS_${PN}-libs-4.0 += "mono" > >>> RDEPENDS_${PN}-libs-4.5 += "mono" > >>> RDEPENDS_${PN}-gac += "mono" > >>> RDEPENDS_${PN}-configuration-crypto += "mono" > >>> RDEPENDS_${PN}-xbuild += "mono" > >>> RDEPENDS_${PN}-api-4.5.1 += "mono" > >>> RDEPENDS_${PN}-api-4.5.2 += "mono" > >>> RDEPENDS_${PN}-api-4.6 += "mono" > >>> RDEPENDS_${PN}-api-4.6.1 += "mono" > >>> RDEPENDS_${PN}-api-4.6.2 += "mono" > >>> RDEPENDS_${PN}-api-4.7 += "mono" > >>> > >>> The one remaining is > >>> > >>> ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue: > >>> /usr/lib/mono/4.5/Microsoft.CodeAnalysis.Scripting.dll contained in > >>> package mono-libs-4.5 requires mono(System.Runtime.Loader), but no > >>> providers found in RDEPENDS_mono-libs-4.5? [file-rdeps] > >>> ERROR: mono-5.12.0.226-r0 do_package_qa: QA run found fatal errors. > >>> Please consider fixing them. > >>> ERROR: mono-5.12.0.226-r0 do_package_qa: Function failed: do_package_qa > >>> ERROR: Logfile of failure stored in: > >>> /ws/rufilla/oina/tools-oina-build-local/build_oxinst/tmp/work/armv7ahf-neon-poky-linux-gnueabi/mono/5.12.0.226-r0/temp/log.do_package_qa.15001 > >>> ERROR: Task > >>> (/ws/rufilla/oina/tools-oina-build-local/build_oxinst/../meta-mono/recipes-mono/mono/mono_5.12.0.226.bb:do_package_qa) > >>> failed with exit code '1' > >>> > >>> It looks like the 4.5 lib package requires the System.Runtime.Loader > >>> library but I'm not sure how to get it to build this or I see there is > >>> an external directory which looks like it contains all the 4.5 libs so > >>> maybe it hasn't been included in here? > >>> > >>> Any Help appreciated, > >>> Martin. > >> Hi Martin, > >> > >> I've been doing some recent work here which might help > >> > >> https://github.com/dynamicdevices/meta-mono/tree/master > >> > >> Cheers, > >> > >> Alex > >> > >> > > Thanks for the reply Alex. > > > > I tried this meta-mono layer too but it failed to compile/link > > | > > ../../external/corefx/src/Native/Unix/System.Native/.libs/libmono_system_native_la-pal_errno.o: > > file not recognized: File format not recognized > > | collect2: error: ld returned 1 exit status > > | Makefile:1355: recipe for target 'libmono-system-native.la' failed > > > > > > I managed to get the recipe in the normal meta-mono to compile by > > installing System.Runtime.Loader.dll into the image but as soon as it > > tried to create the rootfs I get the following error > > Total size: 75 M > > Installed size: 301 M > > Downloading Packages: > > Running transaction check > > Error: transaction check vs depsolve: > > mono(System.Collections.Immutable) = 1.2.0.0 is needed by > > mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon > > mono(System.Diagnostics.StackTrace) = 4.0.2.0 is needed by > > mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon > > mono(System.IO) = 4.0.10.0 is needed by > > mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon > > mono(System.IO.Compression) = 4.1.1.0 is needed by > > mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon > > mono(System.Linq.Expressions) = 4.0.10.0 is needed by > > mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon > > mono(System.Reflection) = 4.0.10.0 is needed by > > mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon > > mono(System.Runtime) = 4.0.20.0 is needed by > > mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon > > mono(System.Runtime.Extensions) = 4.0.10.0 is needed by > > mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon > > mono(System.Runtime.InteropServices) = 4.0.20.0 is needed by > > mono-libs
Re: [yocto] meta-mono: QA Error building mono-5.12.0.226
Hi Alex, On Thu, Nov 22, 2018 at 3:49 PM Alex J Lennon wrote: > > > On 22/11/2018 15:46, Martin Townsend wrote: > > Hi, > > > > This one is probably for the meta-mono maintainer > > > > I was getting quite a few file-rdeps QA errors. > > I managed to get rid of them all except 1 using > > RDEPENDS_${PN}-libs-2.0 += "mono" > > RDEPENDS_${PN}-libs-3.5 += "mono" > > RDEPENDS_${PN}-libs-4.0 += "mono" > > RDEPENDS_${PN}-libs-4.5 += "mono" > > RDEPENDS_${PN}-gac += "mono" > > RDEPENDS_${PN}-configuration-crypto += "mono" > > RDEPENDS_${PN}-xbuild += "mono" > > RDEPENDS_${PN}-api-4.5.1 += "mono" > > RDEPENDS_${PN}-api-4.5.2 += "mono" > > RDEPENDS_${PN}-api-4.6 += "mono" > > RDEPENDS_${PN}-api-4.6.1 += "mono" > > RDEPENDS_${PN}-api-4.6.2 += "mono" > > RDEPENDS_${PN}-api-4.7 += "mono" > > > > The one remaining is > > > > ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue: > > /usr/lib/mono/4.5/Microsoft.CodeAnalysis.Scripting.dll contained in > > package mono-libs-4.5 requires mono(System.Runtime.Loader), but no > > providers found in RDEPENDS_mono-libs-4.5? [file-rdeps] > > ERROR: mono-5.12.0.226-r0 do_package_qa: QA run found fatal errors. > > Please consider fixing them. > > ERROR: mono-5.12.0.226-r0 do_package_qa: Function failed: do_package_qa > > ERROR: Logfile of failure stored in: > > /ws/rufilla/oina/tools-oina-build-local/build_oxinst/tmp/work/armv7ahf-neon-poky-linux-gnueabi/mono/5.12.0.226-r0/temp/log.do_package_qa.15001 > > ERROR: Task > > (/ws/rufilla/oina/tools-oina-build-local/build_oxinst/../meta-mono/recipes-mono/mono/mono_5.12.0.226.bb:do_package_qa) > > failed with exit code '1' > > > > It looks like the 4.5 lib package requires the System.Runtime.Loader > > library but I'm not sure how to get it to build this or I see there is > > an external directory which looks like it contains all the 4.5 libs so > > maybe it hasn't been included in here? > > > > Any Help appreciated, > > Martin. > > Hi Martin, > > I've been doing some recent work here which might help > > https://github.com/dynamicdevices/meta-mono/tree/master > > Cheers, > > Alex > > Thanks for the reply Alex. I tried this meta-mono layer too but it failed to compile/link | ../../external/corefx/src/Native/Unix/System.Native/.libs/libmono_system_native_la-pal_errno.o: file not recognized: File format not recognized | collect2: error: ld returned 1 exit status | Makefile:1355: recipe for target 'libmono-system-native.la' failed I managed to get the recipe in the normal meta-mono to compile by installing System.Runtime.Loader.dll into the image but as soon as it tried to create the rootfs I get the following error Total size: 75 M Installed size: 301 M Downloading Packages: Running transaction check Error: transaction check vs depsolve: mono(System.Collections.Immutable) = 1.2.0.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.Diagnostics.StackTrace) = 4.0.2.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.IO) = 4.0.10.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.IO.Compression) = 4.1.1.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.Linq.Expressions) = 4.0.10.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.Reflection) = 4.0.10.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.Runtime) = 4.0.20.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.Runtime.Extensions) = 4.0.10.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.Runtime.InteropServices) = 4.0.20.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.Security.Cryptography.Algorithms) = 4.0.0.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.Text.Encoding.CodePages) = 4.0.2.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.ValueTuple) = 4.0.1.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon mono(System.Xml.XPath.XDocument) = 4.0.1.0 is needed by mono-libs-4.5-5.12.0.226-r0.13.armv7ahf_neon To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'. You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the issue. I think I need to understand more about the mono packaging, any pointers would be greatly appreciated. Cheers, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-mono: QA Error building mono-5.12.0.226
Hi, This one is probably for the meta-mono maintainer I was getting quite a few file-rdeps QA errors. I managed to get rid of them all except 1 using RDEPENDS_${PN}-libs-2.0 += "mono" RDEPENDS_${PN}-libs-3.5 += "mono" RDEPENDS_${PN}-libs-4.0 += "mono" RDEPENDS_${PN}-libs-4.5 += "mono" RDEPENDS_${PN}-gac += "mono" RDEPENDS_${PN}-configuration-crypto += "mono" RDEPENDS_${PN}-xbuild += "mono" RDEPENDS_${PN}-api-4.5.1 += "mono" RDEPENDS_${PN}-api-4.5.2 += "mono" RDEPENDS_${PN}-api-4.6 += "mono" RDEPENDS_${PN}-api-4.6.1 += "mono" RDEPENDS_${PN}-api-4.6.2 += "mono" RDEPENDS_${PN}-api-4.7 += "mono" The one remaining is ERROR: mono-5.12.0.226-r0 do_package_qa: QA Issue: /usr/lib/mono/4.5/Microsoft.CodeAnalysis.Scripting.dll contained in package mono-libs-4.5 requires mono(System.Runtime.Loader), but no providers found in RDEPENDS_mono-libs-4.5? [file-rdeps] ERROR: mono-5.12.0.226-r0 do_package_qa: QA run found fatal errors. Please consider fixing them. ERROR: mono-5.12.0.226-r0 do_package_qa: Function failed: do_package_qa ERROR: Logfile of failure stored in: /ws/rufilla/oina/tools-oina-build-local/build_oxinst/tmp/work/armv7ahf-neon-poky-linux-gnueabi/mono/5.12.0.226-r0/temp/log.do_package_qa.15001 ERROR: Task (/ws/rufilla/oina/tools-oina-build-local/build_oxinst/../meta-mono/recipes-mono/mono/mono_5.12.0.226.bb:do_package_qa) failed with exit code '1' It looks like the 4.5 lib package requires the System.Runtime.Loader library but I'm not sure how to get it to build this or I see there is an external directory which looks like it contains all the 4.5 libs so maybe it hasn't been included in here? Any Help appreciated, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] System recovery
Hi Enrico, Then I would use a tar.gz image type and then extract that onto the formatted partition of the SD card or if the partition is ext then I think you can generate an image type for this. There is also wic for generating partitioned images, I've not used it so can't really comment on it but is described in the Yocto manual. -Martin On Thu, May 10, 2018 at 7:14 AM, Enrico Bonomi wrote: > Hi Martin, > > I know that i can create multiple images types, but i don't want an sdcard > bootable image. On my first try, the image on sdcard was ubi type because i > want to obtain i kind of recovery partition directly on the sdcard. Do you > suggest to put the recovery partition directly on the raw NAND? in that case > how could i create a compressed image (because i don't have enough space on > my device to keep 2 images)? > > thanks > > Enrico > > 2018-05-09 12:37 GMT+02:00 Martin Townsend : >> >> On Wed, May 9, 2018 at 11:21 AM, Enrico Bonomi >> wrote: >> > Hi Martin, >> > >> > I'm newbie in yocto, but i used IMAGE_FSTYPES ="sdcard" to boot the >> > system >> > from SD card. What i want to obtain is to replace the broken file system >> > that is located on the NAND with another one that works. A kind of >> > recovery >> > partition. is it possible from SD or should i create a recovery >> > partition >> > over the NAND? >> > >> > thanks >> > >> > Enrico >> > >> > 2018-05-09 11:25 GMT+02:00 Martin Townsend : >> >> >> >> Hi Enrico, >> >> >> >> UBI is only designed to work on raw NAND using the MTD subsystem. MMC >> >> will be a standard block device as the SD card will have Flash >> >> Translation layer. See the excellent MTD website for more info >> >> http://www.linux-mtd.infradead.org/doc/ubi.html >> >> >> >> In Yocto I believe you can use "sdcard" in the IMAGE_FSTYPES for a >> >> flashable image for SD cards that can be used with U-Boot. >> >> >> >> -Martin. >> >> >> >> >> >> On Wed, May 9, 2018 at 9:31 AM, Enrico Bonomi >> >> >> >> wrote: >> >> > Hi, >> >> > >> >> > I work with Yocto Poky 1.7.3 on an imx6 dual lite SOM. I recently >> >> > came >> >> > across a problem with a preexisting system. Infact in a couple of >> >> > cases, >> >> > after about one year of work with no problems, file system results >> >> > corrupted >> >> > and the machine can't work. So i decide to implement a recovery >> >> > system >> >> > that >> >> > can intervene in theese cases. An sd card is mounted on my board, so >> >> > i >> >> > think >> >> > that i can use it to act this process. Using gparted i create a >> >> > partition on >> >> > sd card that can store my recovery file system. >> >> > This partition starts at block 1581056 (so 0x00182000), every block >> >> > has >> >> > a >> >> > size of 512 bytes and the file system size is 370262016 bytes (so >> >> > 0x1611c000) that are 723168 blocks (so 0x000b08e0). >> >> > In the u-boot i do the following instructions: >> >> > >> >> > nand erase.part rootfs >> >> > ubi part rootfs >> >> > ubi create rootfs >> >> > mmc dev 0 >> >> > mmc read 1200 0x00182000 0x000b08e0 >> >> > ubi write 1200 rootfs 0x1611c000 >> >> > ubifsmount ubi0:rootfs >> >> > >> >> > and this instruction results in the following errors: >> >> > >> >> > UBIFS error (pid 0): ubifs_read_node: bad node type (0 but expected >> >> > 6) >> >> > UBIFS error (pid 0): ubifs_read_node: bad node at LEB 0:0 >> >> > UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume >> >> > 'ubi0:rootfs' errno=-22! >> >> > >> >> > ubifsmount - mount UBIFS volume >> >> > >> >> > Usage: >> >> > ubifsmount >> >> >- mount 'volume-name' volume >> >> > >> >> > the strange thing is that when i first program all new devices i use >> >> > the >> >> > following instruction: >> >> > >> >> > tftpboot prall >> >> > >> >> > and prall is the compiled of a txt file which, when programming file >> >> > system >> >> > use the same instructions, obviously except for >> >> > >> >> > tftp 1200 rootfs.ubifs >> >> > >> >> > instead of my mmc instructions, and >> >> > >> >> > ubi write 1200 rootfs ${filesize} >> >> > >> >> > but from what i understand the "filesize" variable is set from the >> >> > tftp >> >> > instruction >> >> > >> >> > Where do i fail? >> >> > >> >> > Thanks >> >> > >> >> > Enrico >> >> > >> >> > -- >> >> > ___ >> >> > yocto mailing list >> >> > yocto@yoctoproject.org >> >> > https://lists.yoctoproject.org/listinfo/yocto >> >> > >> > >> > >> >> You forgot to reply to all so added the Yocto mailing list back in again. >> >> You can create multiple images by specifying ubi and sdcard in >> IMAGE_FSTYPES and then flash ubi to the raw NAND and then the sdcard >> image to the SD then write the logic to perform the switch. >> >> -Martin. > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] System recovery
On Wed, May 9, 2018 at 11:21 AM, Enrico Bonomi wrote: > Hi Martin, > > I'm newbie in yocto, but i used IMAGE_FSTYPES ="sdcard" to boot the system > from SD card. What i want to obtain is to replace the broken file system > that is located on the NAND with another one that works. A kind of recovery > partition. is it possible from SD or should i create a recovery partition > over the NAND? > > thanks > > Enrico > > 2018-05-09 11:25 GMT+02:00 Martin Townsend : >> >> Hi Enrico, >> >> UBI is only designed to work on raw NAND using the MTD subsystem. MMC >> will be a standard block device as the SD card will have Flash >> Translation layer. See the excellent MTD website for more info >> http://www.linux-mtd.infradead.org/doc/ubi.html >> >> In Yocto I believe you can use "sdcard" in the IMAGE_FSTYPES for a >> flashable image for SD cards that can be used with U-Boot. >> >> -Martin. >> >> >> On Wed, May 9, 2018 at 9:31 AM, Enrico Bonomi >> wrote: >> > Hi, >> > >> > I work with Yocto Poky 1.7.3 on an imx6 dual lite SOM. I recently came >> > across a problem with a preexisting system. Infact in a couple of cases, >> > after about one year of work with no problems, file system results >> > corrupted >> > and the machine can't work. So i decide to implement a recovery system >> > that >> > can intervene in theese cases. An sd card is mounted on my board, so i >> > think >> > that i can use it to act this process. Using gparted i create a >> > partition on >> > sd card that can store my recovery file system. >> > This partition starts at block 1581056 (so 0x00182000), every block has >> > a >> > size of 512 bytes and the file system size is 370262016 bytes (so >> > 0x1611c000) that are 723168 blocks (so 0x000b08e0). >> > In the u-boot i do the following instructions: >> > >> > nand erase.part rootfs >> > ubi part rootfs >> > ubi create rootfs >> > mmc dev 0 >> > mmc read 1200 0x00182000 0x000b08e0 >> > ubi write 1200 rootfs 0x1611c000 >> > ubifsmount ubi0:rootfs >> > >> > and this instruction results in the following errors: >> > >> > UBIFS error (pid 0): ubifs_read_node: bad node type (0 but expected 6) >> > UBIFS error (pid 0): ubifs_read_node: bad node at LEB 0:0 >> > UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume >> > 'ubi0:rootfs' errno=-22! >> > >> > ubifsmount - mount UBIFS volume >> > >> > Usage: >> > ubifsmount >> >- mount 'volume-name' volume >> > >> > the strange thing is that when i first program all new devices i use the >> > following instruction: >> > >> > tftpboot prall >> > >> > and prall is the compiled of a txt file which, when programming file >> > system >> > use the same instructions, obviously except for >> > >> > tftp 1200 rootfs.ubifs >> > >> > instead of my mmc instructions, and >> > >> > ubi write 1200 rootfs ${filesize} >> > >> > but from what i understand the "filesize" variable is set from the tftp >> > instruction >> > >> > Where do i fail? >> > >> > Thanks >> > >> > Enrico >> > >> > -- >> > ___ >> > yocto mailing list >> > yocto@yoctoproject.org >> > https://lists.yoctoproject.org/listinfo/yocto >> > > > You forgot to reply to all so added the Yocto mailing list back in again. You can create multiple images by specifying ubi and sdcard in IMAGE_FSTYPES and then flash ubi to the raw NAND and then the sdcard image to the SD then write the logic to perform the switch. -Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] System recovery
Hi Enrico, UBI is only designed to work on raw NAND using the MTD subsystem. MMC will be a standard block device as the SD card will have Flash Translation layer. See the excellent MTD website for more info http://www.linux-mtd.infradead.org/doc/ubi.html In Yocto I believe you can use "sdcard" in the IMAGE_FSTYPES for a flashable image for SD cards that can be used with U-Boot. -Martin. On Wed, May 9, 2018 at 9:31 AM, Enrico Bonomi wrote: > Hi, > > I work with Yocto Poky 1.7.3 on an imx6 dual lite SOM. I recently came > across a problem with a preexisting system. Infact in a couple of cases, > after about one year of work with no problems, file system results corrupted > and the machine can't work. So i decide to implement a recovery system that > can intervene in theese cases. An sd card is mounted on my board, so i think > that i can use it to act this process. Using gparted i create a partition on > sd card that can store my recovery file system. > This partition starts at block 1581056 (so 0x00182000), every block has a > size of 512 bytes and the file system size is 370262016 bytes (so > 0x1611c000) that are 723168 blocks (so 0x000b08e0). > In the u-boot i do the following instructions: > > nand erase.part rootfs > ubi part rootfs > ubi create rootfs > mmc dev 0 > mmc read 1200 0x00182000 0x000b08e0 > ubi write 1200 rootfs 0x1611c000 > ubifsmount ubi0:rootfs > > and this instruction results in the following errors: > > UBIFS error (pid 0): ubifs_read_node: bad node type (0 but expected 6) > UBIFS error (pid 0): ubifs_read_node: bad node at LEB 0:0 > UBIFS error (pid 0): ubifs_mount: Error reading superblock on volume > 'ubi0:rootfs' errno=-22! > > ubifsmount - mount UBIFS volume > > Usage: > ubifsmount >- mount 'volume-name' volume > > the strange thing is that when i first program all new devices i use the > following instruction: > > tftpboot prall > > and prall is the compiled of a txt file which, when programming file system > use the same instructions, obviously except for > > tftp 1200 rootfs.ubifs > > instead of my mmc instructions, and > > ubi write 1200 rootfs ${filesize} > > but from what i understand the "filesize" variable is set from the tftp > instruction > > Where do i fail? > > Thanks > > Enrico > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't compile out of tree kernel module when CONFIG_SYSTEM_TRUSTED_KEYRING is set in the kernel configuration
Hi Bruce, On Thu, May 3, 2018 at 3:27 AM, Bruce Ashfield wrote: > > > On Wed, May 2, 2018 at 5:05 PM, Martin Townsend > wrote: >> >> Hi, >> >> I get the following error when compiling a kernel module using the >> latest version of Rocko (The kernel is not linux-yocto but NXP's >> freescale linux-imx, maybe this could be a factor) : >> >> ERROR: kernel-module-driver-0.1-r0 do_make_scripts: Function failed: >> do_make_scripts (log file is located at >> >> /ws/yocto-rocko/build/tmp/work/mach_1717-linux-gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703) >> ERROR: Logfile of failure stored in: >> >> /ws/yocto-rocko/build/tmp/work/mach_1717-cwr-linux-gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703 >> Log data follows: >> | DEBUG: Executing shell function do_make_scripts >> | make: Entering directory >> '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source' >> | make[1]: Entering directory >> >> '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-build-artifacts' >> | HOSTCC scripts/extract-cert >> | >> /ws/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source/scripts/extract-cert.c:21:25: >> fatal error: openssl/bio.h: No such file or directory >> | compilation terminated. >> | scripts/Makefile.host:107: recipe for target 'scripts/extract-cert' >> failed >> | make[2]: *** [scripts/extract-cert] Error 1 >> | >> /ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source/Makefile:560: >> recipe for target 'scripts' failed >> | >> >> I checked the makefile and extract-cert is only compiled if >> CONFIG_SYSTEM_TRUSTED_KEYRING is set which we have. >> >> I could install libssl-dev but it doesn't feel right installing this >> and it's not in the system requirements plus the file openssl/bio.h is >> in the recipe-sysroot-native directory of the kernel module WORK_DIR. > > > I've run into this plenty of times with newer kernels (4.14+), which is why > all the linux-yocto recipes have: > > DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}" > DEPENDS += "openssl-native util-linux-native" > > As does my re-worked kernel-devsrc. > > So yah, you can just add the dependency to fix the problem. > > Bruce > Thanks for the swift reply and I tried the suggestions but I'm afraid the end result is still the same. The actual kernel builds fine so I'll take a look at this to see if there are any clues. I'm guessing do_make_scripts needs tweaking for an out of tree kernel module recipe to use the recipe_sysroot_native directory somehow. Cheers, Martin >> >> >> >> Any help would be greatly appreciated, >> Marin. >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at > its end" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Can't compile out of tree kernel module when CONFIG_SYSTEM_TRUSTED_KEYRING is set in the kernel configuration
Hi, I get the following error when compiling a kernel module using the latest version of Rocko (The kernel is not linux-yocto but NXP's freescale linux-imx, maybe this could be a factor) : ERROR: kernel-module-driver-0.1-r0 do_make_scripts: Function failed: do_make_scripts (log file is located at /ws/yocto-rocko/build/tmp/work/mach_1717-linux-gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703) ERROR: Logfile of failure stored in: /ws/yocto-rocko/build/tmp/work/mach_1717-cwr-linux-gnueabi/kernel-module-driver/0.1-r0/temp/log.do_make_scripts.23703 Log data follows: | DEBUG: Executing shell function do_make_scripts | make: Entering directory '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source' | make[1]: Entering directory '/ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-build-artifacts' | HOSTCC scripts/extract-cert | /ws/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source/scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory | compilation terminated. | scripts/Makefile.host:107: recipe for target 'scripts/extract-cert' failed | make[2]: *** [scripts/extract-cert] Error 1 | /ws/rufilla/yocto-rocko/build/tmp/work-shared/mach-1717/kernel-source/Makefile:560: recipe for target 'scripts' failed | I checked the makefile and extract-cert is only compiled if CONFIG_SYSTEM_TRUSTED_KEYRING is set which we have. I could install libssl-dev but it doesn't feel right installing this and it's not in the system requirements plus the file openssl/bio.h is in the recipe-sysroot-native directory of the kernel module WORK_DIR. Any help would be greatly appreciated, Marin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] U-Boot networking broken in Rocko
Hi, I've discovered that U-Boot in Rocko for several builds that I maintain is broken when performing various network related operations like tftp, dhcp and ping. You get a data abort and it resets. I found that this has already been fixed in U-Boot with the commit below. I think it has something to do with the way GCC 7.1 onwards is now handling memory alignment. Anyway the problems have gone away when I apply this patch and was wondering if it should be included in the U-Boot recipes in Rocko, or is no-one else seeing this problem? Many Thanks, Martin. commit 704f3acfcf55343043bbed01c5fb0a0094a68e8a Author: Denis Pynkin Date: Fri Jul 21 19:28:42 2017 +0300 net: Use packed structures for networking PXE boot is broken with GCC 7.1 due option '-fstore-merging' enabled by default for '-O2': BOOTP broadcast 1 data abort pc : [<8ff8bb30>] lr : [<4f1f>] reloc pc : [<17832b30>]lr : [<878abf1f>] sp : 8f558bc0 ip : fp : 8ffef5a4 r10: 8ffed248 r9 : 8f558ee0 r8 : 8ffef594 r7 : 000e r6 : 8ffed700 r5 : r4 : 8ffed74e r3 : 00060101 r2 : 8ffed230 r1 : 8ffed706 r0 : 0ddd Flags: nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ... Core reason is usage of structures for network headers without packed attribute. Reviewed-by: Yauheni Kaliuta Signed-off-by: Denis Pynkin Acked-by: Joe Hershberger -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] chrpath error: Building SDK fails after porting to Rocko
Hi, I've just ported my build to Rocko but I now can't build the SDK, the offending package is u-boot-tools which I have based on u-boot-mkimage (which also fails with the same error message). Does anyone have any idea on how to debug/fix this? Build Configuration: BB_VERSION = "1.36.0" BUILD_SYS= "x86_64-linux" NATIVELSBSTRING = "universal-4.8" TARGET_SYS = "arm-bia-linux-gnueabi" MACHINE = "varsomam43" DISTRO = "bia" DISTRO_VERSION = "20180207-requiem-r11029" TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard cortexa9" TARGET_FPU = "hard" meta-bia-distro meta-martin meta-martin-bsp = ":" meta-python meta-oe meta-webserver meta-filesystems = "rocko:a65c1acb1822966c3553de9fc98d8bb6be705c4e" meta-ti = "rocko:4a746c78c3b7060a51cd6a876f69eead363c757c" meta-networking = "rocko:a65c1acb1822966c3553de9fc98d8bb6be705c4e" meta meta-poky= "rocko:1648bcafa3d0e46acee61a34d0a07fabb85b1f8d" meta-security-isafw = "HEAD:489abdc65cefb566d696c8b218aa0b9b99a350ae" NOTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/1.8/x86_64-nativesdk-libc.tar.bz2;sha256sum=de4947e98e09e1432d069311cc2093974ecb9138a714fd5466f73524de66a693 Initialising tasks: 100% || Time: 0:00:01 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: nativesdk-u-boot-tools-v2016.03+gitAUTOINC+df61a74e68-r0 do_package: nativesdk-u-boot-tools: chrpath command failed with exit code 7: b'/home/martin/bia-precision-rocko/build/tmp/work/x86_64-nativesdk-biasdk-linux/nativesdk-u-boot-tools/v2016.03+gitAUTOINC+df61a74e68-r0/package/opt/bia/20180207-requiem-r11029/sysroots/x86_64-biasdk-linux/usr/bin/uboot-dumpimage: RPATH=/home/martin/bia-precision-rocko/build/tmp/work/x86_64-nativesdk-biasdk-linux/nativesdk-u-boot-tools/v2016.03+gitAUTOINC+df61a74e68-r0/recipe-sysroot-native/usr/lib:/home/martin/bia-precision-rocko/build/tmp/work/x86_64-nativesdk-biasdk-linux/nativesdk-u-boot-tools/v2016.03+gitAUTOINC+df61a74e68-r0/recipe-sysroot-native/lib\n'b"new rpath '$ORIGIN/../../../../../../../home/martin/bia-precision-rocko/build/tmp/work/x86_64-nativesdk-biasdk-linux/nativesdk-u-boot-tools/v2016.03+gitAUTOINC+df61a74e68-r0/recipe-sysroot-native/usr/lib:$ORIGIN/../../../../../../../home/martin/bia-precision-rocko/build/tmp/work/x86_64-nativesdk-biasdk-linux/nativesdk-u-boot-tools/v2016.03+gitAUTOINC+df61a74e68-r0/recipe-sysroot-native/lib' too large; maximum length 333\n" ERROR: nativesdk-u-boot-tools-v2016.03+gitAUTOINC+df61a74e68-r0 do_package: Function failed: perform_packagecopy ERROR: Logfile of failure stored in: /home/martin/bia-precision-rocko/build/tmp/work/x86_64-nativesdk-biasdk-linux/nativesdk-u-boot-tools/v2016.03+gitAUTOINC+df61a74e68-r0/temp/log.do_package.9810 ERROR: Task (virtual:nativesdk:/home/martin/bia-precision-rocko/build/../yocto/martin/meta-martin-bsp/recipes-bsp/u-boot/u-boot-tools_2016.03.bb:do_package) failed with exit code '1'SUMMARY = "U-Boot native tools" Here's the recipe LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6" SECTION = "bootloader" DEPENDS = "openssl" # This revision corresponds to the tag "v2016.03" # We use the revision in order to avoid having to fetch it from the # repo during parse SRCREV = "df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa" PV = "v2016.03+git${SRCPV}" SRC_URI = "git://git.denx.de/u-boot.git;branch=master" S = "${WORKDIR}/git" EXTRA_OEMAKE_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} ${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" STRIP=true V=1' EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" STRIP=true V=1' EXTRA_OEMAKE_class-nativesdk = 'CROSS_COMPILE="${HOST_PREFIX}" CC="${CC} ${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" STRIP=true V=1' do_compile () { oe_runmake sandbox_defconfig oe_runmake cross_tools NO_SDL=1 } do_install () { install -d ${D}${bindir} # MJT: Looks like these are now part of U-Boot native package so commenting out # Can remove once this is confirmed. # install -m 0755 tools/mkimage ${D}${bindir}/uboot-mkimage # ln -sf uboot-mkimage ${D}${bindir}/mkimage install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage install -m 0755 tools/dumpimage ${D}${bindir}/uboot-dumpimage ln -sf uboot-dumpimage ${D}${bindir}/dumpimage install -m 0755 tools/img2brec.sh ${D}${bindir}/uboot-img2brec.sh ln -sf uboot-img2brec.sh ${D}${bindir}/img2brec.sh install -m 0755 tools/img2srec ${D}${bindir}/uboot-img2srec ln -sf uboot-img2srec ${D}${bindir}/img2srec install -m 0755 tools/jtagconsole ${D}${bindir}/uboot-jtagconsole
Re: [yocto] image inheritance problem
On Fri, Jan 26, 2018 at 7:17 PM, Martin Townsend wrote: > Hi Khem, > > On Fri, Jan 26, 2018 at 6:57 PM, Khem Raj wrote: >> On 1/26/18 10:52 AM, Martin Townsend wrote: >>> Hi, >>> >>> I have an image say >>> >>> my-image-minimal.bb in one layer and and append this >>> (my-image-minimal.bbappend) in another layer. In this append I'm adding >>> IMAGE_INSTALL += "kernel-modules" >>> for example. >>> >>> Now if I run >>> bitbake my-image-minimal -e | grep ^IMAGE_INSTALL >>> I see kernel-modules >>> >>> So bbappend is working, now I have another image >>> >>> my-image which has >>> requires /core/images/my-image-minimal.bb >>> ... >>> >>> But kernel-modules is not appearing in this image and >>> bitbake my-image -e | grep ^IMAGE_INSTALL >>> >>> confirms this. >>> >>> Any ideas as to what I'm doing wrong, I assume bitbake supports this. >>> >> >> in second case you are including the .bb file so its behaving as an >> include file. >> bbappend only applies to parsed recipes not include files. >> > > Thanks for the swift reply and clarifications on how requires/include works. > > Don't suppose you know of the best way of handling this situation? Not sure if it's the best way but I converted the bbappend to an image recipe my-minimal-image-xxx.bb and then include this as well as include will ignore it if the layer doesn't exist. Seems to work :) > >>> I'm using the Krogoth release. >>> >>> Many Thanks in advance, >>> Martin. >>> >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] image inheritance problem
Hi Khem, On Fri, Jan 26, 2018 at 6:57 PM, Khem Raj wrote: > On 1/26/18 10:52 AM, Martin Townsend wrote: >> Hi, >> >> I have an image say >> >> my-image-minimal.bb in one layer and and append this >> (my-image-minimal.bbappend) in another layer. In this append I'm adding >> IMAGE_INSTALL += "kernel-modules" >> for example. >> >> Now if I run >> bitbake my-image-minimal -e | grep ^IMAGE_INSTALL >> I see kernel-modules >> >> So bbappend is working, now I have another image >> >> my-image which has >> requires /core/images/my-image-minimal.bb >> ... >> >> But kernel-modules is not appearing in this image and >> bitbake my-image -e | grep ^IMAGE_INSTALL >> >> confirms this. >> >> Any ideas as to what I'm doing wrong, I assume bitbake supports this. >> > > in second case you are including the .bb file so its behaving as an > include file. > bbappend only applies to parsed recipes not include files. > Thanks for the swift reply and clarifications on how requires/include works. Don't suppose you know of the best way of handling this situation? >> I'm using the Krogoth release. >> >> Many Thanks in advance, >> Martin. >> > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] image inheritance problem
Hi, I have an image say my-image-minimal.bb in one layer and and append this (my-image-minimal.bbappend) in another layer. In this append I'm adding IMAGE_INSTALL += "kernel-modules" for example. Now if I run bitbake my-image-minimal -e | grep ^IMAGE_INSTALL I see kernel-modules So bbappend is working, now I have another image my-image which has requires /core/images/my-image-minimal.bb ... But kernel-modules is not appearing in this image and bitbake my-image -e | grep ^IMAGE_INSTALL confirms this. Any ideas as to what I'm doing wrong, I assume bitbake supports this. I'm using the Krogoth release. Many Thanks in advance, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem building kernel FIT image with initramfs
Sorry hit send before finishing email. So it looks like do_install and do_deploy are expecting fitImage-${INITRAMFS_IMAGE} so is this renaming required anymore? and if so is this a problem with the freescale kernel? Many Thanks, Martin. On Tue, Jul 18, 2017 at 1:58 PM, Martin Townsend wrote: > Hi, > > Using Yocto 2.3 (pyro) I was trying to create a FIT image with the 4.9 > linux-fslc kernel and an initramfs image. following the instructions > it failed during do_bundle_initramfs. After debugging I found that it > moves the fitImage file to fitImage.bak and then runs a second pass > and renames the new fitImage to fitImage.initramfs but fitImage is > never created on this second pass but fitImage-${INITRAMFS_IMAGE} is > created. > > If I comment out the line that does this rename every builds fine > > echo "Resoring Kernel Image" > for tp in $tmp_path ; do > type=`echo $tp|cut -d "#" -f 1` > linkpath=`echo $tp|cut -d "#" -f 2` > realpath=`echo $tp|cut -d "#" -f 3` > if [ -n "$realpath" ]; then > mv -f $realpath $realpath.initramfs > mv -f $realpath.bak $realpath > ln -sf $linkpath.initramfs ${B}/${KERNEL_OUTPUT_DIR}/$type.initramfs > else > > #mv -f ${KERNEL_OUTPUT_DIR}/$type ${KERNEL_OUTPUT_DIR}/$type.initramfs > mv -f ${KERNEL_OUTPUT_DIR}/$type.bak ${KERNEL_OUTPUT_DIR}/$type > fi > done -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem building kernel FIT image with initramfs
Hi, Using Yocto 2.3 (pyro) I was trying to create a FIT image with the 4.9 linux-fslc kernel and an initramfs image. following the instructions it failed during do_bundle_initramfs. After debugging I found that it moves the fitImage file to fitImage.bak and then runs a second pass and renames the new fitImage to fitImage.initramfs but fitImage is never created on this second pass but fitImage-${INITRAMFS_IMAGE} is created. If I comment out the line that does this rename every builds fine echo "Resoring Kernel Image" for tp in $tmp_path ; do type=`echo $tp|cut -d "#" -f 1` linkpath=`echo $tp|cut -d "#" -f 2` realpath=`echo $tp|cut -d "#" -f 3` if [ -n "$realpath" ]; then mv -f $realpath $realpath.initramfs mv -f $realpath.bak $realpath ln -sf $linkpath.initramfs ${B}/${KERNEL_OUTPUT_DIR}/$type.initramfs else #mv -f ${KERNEL_OUTPUT_DIR}/$type ${KERNEL_OUTPUT_DIR}/$type.initramfs mv -f ${KERNEL_OUTPUT_DIR}/$type.bak ${KERNEL_OUTPUT_DIR}/$type fi done -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] RNDIS Broken in linux-yocto 4.1.39, working in 4.1.37
Hi, I recently upgraded to 4.1.39 linux-yocto and Ethernet Gadget stopped working with Windows hosts, here's the output from the Journal: Jun 22 20:31:37 varsomam43-bb5eda kernel: g_ether gadget: rndis reqa1.01 v i l4096 Jun 22 20:31:37 varsomam43-bb5eda kernel: g_ether gadget: rndis req21.00 v i l28 Jun 22 20:31:37 varsomam43-bb5eda kernel: gen_ndis_query_resp: RNDIS_OID_GEN_SUPPORTED_LIST Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.457796] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.481614] g_ether gadget: rndis req21.00 v i l24 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.481946] rndis_msg_parser: RNDIS_MSG_INIT Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.528733] g_ether gadget: rndis reqa1.01 v i l4096 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.530206] g_ether gadget: rndis req21.00 v i l28 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.530322] gen_ndis_query_resp: RNDIS_OID_GEN_SUPPORTED_LIST Jun 22 20:31:37 varsomam43-bb5eda kernel: g_ether gadget: rndis reqa1.01 v i l4096 Jun 22 20:31:37 varsomam43-bb5eda kernel: g_ether gadget: rndis req21.00 v i l32 Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser: unknown RNDIS message 0x8004 len 136 Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser: 04 00 00 80 88 00 00 00 03 00 00 00 00 00 00 00 Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser0010: 70 00 00 00 10 00 00 00 01 01 01 00 02 01 01 00 p... Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser0020: 03 01 01 00 04 01 01 00 06 01 01 00 07 01 01 00 Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser0030: 0a 01 01 00 0b 01 01 00 0c 01 01 00 0d 01 01 00 Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser0040: 16 01 01 00 0e 01 01 00 11 01 01 00 14 01 01 00 Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser0050: 02 02 01 00 01 01 02 00 02 01 02 00 03 01 02 00 Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser0060: 04 01 02 00 05 01 02 00 01 01 01 01 02 01 01 01 Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser0070: 03 01 01 01 05 01 01 01 04 01 01 01 01 01 02 01 Jun 22 20:31:37 varsomam43-bb5eda kernel: rndis_msg_parser0080: 02 01 02 01 03 01 02 01 Jun 22 20:31:37 varsomam43-bb5eda kernel: RNDIS command error -524, 32/32 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.592722] g_ether gadget: rndis reqa1.01 v i l4096 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.594360] g_ether gadget: rndis req21.00 v i l32 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.594699] rndis_msg_parser: unknown RNDIS message 0x8004 len 136 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601671] rndis_msg_parser: 04 00 00 80 88 00 00 00 03 00 00 00 00 00 00 00 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601697] rndis_msg_parser0010: 70 00 00 00 10 00 00 00 01 01 01 00 02 01 01 00 p... Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601718] rndis_msg_parser0020: 03 01 01 00 04 01 01 00 06 01 01 00 07 01 01 00 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601739] rndis_msg_parser0030: 0a 01 01 00 0b 01 01 00 0c 01 01 00 0d 01 01 00 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601759] rndis_msg_parser0040: 16 01 01 00 0e 01 01 00 11 01 01 00 14 01 01 00 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601779] rndis_msg_parser0050: 02 02 01 00 01 01 02 00 02 01 02 00 03 01 02 00 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601800] rndis_msg_parser0060: 04 01 02 00 05 01 02 00 01 01 01 01 02 01 01 01 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601820] rndis_msg_parser0070: 03 01 01 01 05 01 01 01 04 01 01 01 01 01 02 01 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601839] rndis_msg_parser0080: 02 01 02 01 03 01 02 01 Jun 22 20:31:37 varsomam43-bb5eda kernel[242]: [ 7459.601858] RNDIS command error -524, 32/32 Not only has it stopped working but it often locks up the Windows host when you try things like re-installing the Windows RNDIS driver, or enabling the RNDIS/Ethernet Gadget Network adapter. I reverted back to 4.1.37 and everything is fine again. I'm using a TI AM4378 based board. Has anyone else seen this problem? Many Thanks, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Systemd recipe breaks resolvconf
Hi, I've just tracked down a problem with resolvconf not working on my board and it was due to the systemd recipe creating the resolv.conf link and patching etc.conf. Here's the snippet (I've taken it from krogoth but it is still there in morty). if ! ${@bb.utils.contains('PACKAGECONFIG', 'resolved', 'true', 'false', d)}; then # if resolved is disabled, it won't handle the link of resolv.conf, so # set it up ourselves ln -s ../run/resolv.conf ${D}${sysconfdir}/resolv.conf echo 'L! ${sysconfdir}/resolv.conf - - - - ../run/resolv.conf' >>${D}${exec_prefix}/lib/tmpfiles.d/etc.conf echo 'f /run/resolv.conf 0644 root root' >>${D}${exec_prefix}/lib/tmpfiles.d/systemd.conf fi As systemd's resolved is not enabled by default the above is happening. The problem is that it breaks resolvconf which setsup /etc/resolv.conf to link to /etc/resolvconf/run/resolv.conf and doesn't seem to work when it's not. I've put an ugly hack in a systemd append that undoes the changes above and resolvconf works fine. Not sure what the best way to fix this, the if statement above should say is if ! resolved && image doesn't contain resolvconf but I don't think you can do this in do_install. A DISTRO_FEATURE of resolvconf could be added to state that you are going to manage the DNS resolver configuration. The other option is to remove the above if statement. Should systemd be setting up /etc/resolv.conf if resolved is not used? If you not going to use resolved then you are probably going to use something else. Or is this because systemd stops resolv.conf from being created? but wouldn't that only happen if you disable SysV Init altogether? I can create a bug report if you think this is a genuine problem. Cheers, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SDK Problems for SuperH 4
On Fri, Oct 7, 2016 at 8:46 AM, Martin Townsend wrote: > On Fri, Oct 7, 2016 at 5:32 AM, Khem Raj wrote: >> >>> On Oct 6, 2016, at 12:09 PM, Martin Townsend >>> wrote: >>> >>> On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend >>> wrote: >>>> Hi, >>>> >>>> We have a poky sato distributions successfully built and running for >>>> our SuperH 4 processor board. The problem is the SDK that is built >>>> when using -cpopulate_sdk doesn't. >>>> >>>> The simple Makefile: >>>> hellomake: HelloWorld.c >>>> $(CC) -o HelloWorld HelloWorld.c >>> >>> Hit send before I had chance to finish :) >>> >>> ignore the missing tab but when trying to compile (after sourcing the >>> SDK environment) I get >>> sh4-poky-linux-gcc -ml -m4 >>> --sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld >>> HelloWorld.o >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find crt1.o: No such file or directory >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find crti.o: No such file or directory >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find crtbegin.o: No such file or directory >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find -lgcc >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find -lgcc_s >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find -lc >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find -lgcc >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find -lgcc_s >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find crtend.o: No such file or directory >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >>> cannot find crtn.o: No such file or directory >>> >>> So I tried the compiler and sysroot from the build >>> CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc >>> SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760 >>> >>> hellomake: HelloWorld.c >>> $(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c >>> >>> and it compiles fine. >>> >>> So I ran $CC -print-search-dirs >>> install: >>> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/ >>> programs: >>> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/ >>> libraries: >>> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/ >>> >>> Then I checked that these files exist: >>> martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.
Re: [yocto] SDK Problems for SuperH 4
On Fri, Oct 7, 2016 at 5:32 AM, Khem Raj wrote: > >> On Oct 6, 2016, at 12:09 PM, Martin Townsend wrote: >> >> On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend >> wrote: >>> Hi, >>> >>> We have a poky sato distributions successfully built and running for >>> our SuperH 4 processor board. The problem is the SDK that is built >>> when using -cpopulate_sdk doesn't. >>> >>> The simple Makefile: >>> hellomake: HelloWorld.c >>> $(CC) -o HelloWorld HelloWorld.c >> >> Hit send before I had chance to finish :) >> >> ignore the missing tab but when trying to compile (after sourcing the >> SDK environment) I get >> sh4-poky-linux-gcc -ml -m4 >> --sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld >> HelloWorld.o >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find crt1.o: No such file or directory >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find crti.o: No such file or directory >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find crtbegin.o: No such file or directory >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find -lgcc >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find -lgcc_s >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find -lc >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find -lgcc >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find -lgcc_s >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find crtend.o: No such file or directory >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: >> cannot find crtn.o: No such file or directory >> >> So I tried the compiler and sysroot from the build >> CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc >> SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760 >> >> hellomake: HelloWorld.c >> $(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c >> >> and it compiles fine. >> >> So I ran $CC -print-search-dirs >> install: >> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/ >> programs: >> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/ >> libraries: >> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/ >> >> Then I checked that these files exist: >> martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$ >> find $SDKTARGETSYSROOT -name "crt*" >> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crtn.o >> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crti.o >> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crt1.o >> /opt/sdk/vms/2.0.2/sysroots/sh4-po
Re: [yocto] SDK Problems for SuperH 4
On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend wrote: > Hi, > > We have a poky sato distributions successfully built and running for > our SuperH 4 processor board. The problem is the SDK that is built > when using -cpopulate_sdk doesn't. > > The simple Makefile: > hellomake: HelloWorld.c > $(CC) -o HelloWorld HelloWorld.c Hit send before I had chance to finish :) ignore the missing tab but when trying to compile (after sourcing the SDK environment) I get sh4-poky-linux-gcc -ml -m4 --sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld HelloWorld.o /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find crt1.o: No such file or directory /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find crti.o: No such file or directory /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find crtbegin.o: No such file or directory /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find -lgcc /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find -lgcc_s /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find -lc /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find -lgcc /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find -lgcc_s /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find crtend.o: No such file or directory /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld: cannot find crtn.o: No such file or directory So I tried the compiler and sysroot from the build CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760 hellomake: HelloWorld.c $(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c and it compiles fine. So I ran $CC -print-search-dirs install: /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/ programs: =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/ libraries: =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/ Then I checked that these files exist: martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$ find $SDKTARGETSYSROOT -name "crt*" /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crtn.o /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crti.o /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crt1.o /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtendS.o /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtend.o /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginT.o /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginS.o /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbegin.o Putting the library search directories on a separate line martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$ $CC -print-search-dirs | grep "^libraries:" | tr ':' '\n' libraries =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gc
[yocto] SDK Problems for SuperH 4
Hi, We have a poky sato distributions successfully built and running for our SuperH 4 processor board. The problem is the SDK that is built when using -cpopulate_sdk doesn't. The simple Makefile: hellomake: HelloWorld.c $(CC) -o HelloWorld HelloWorld.c -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FrameBuffer support
Hi Jonathan, On Mon, Sep 19, 2016 at 11:01 AM, Jonathan Vervaeke wrote: > Hi, > > > > I'm trying to make framebuffers work on imx6(ul) using yocto. > > > > I suppose I need to make changes in the following: > > 1) Kernel modules > > 2) Device tree > > 3) U-Boot bootargs > > > > I've build my kernel with the following modules > > > > > FB_TFT=y > > CONFIG_FB_TFT_ILI9325=m > > > > > I added the following to the device tree > > > > > > / { > itdb28 { > compatible = "ilitek,ili9325"; > status = "okay"; > > rotate = <0>; > bgr; > buswidth = <8>; > reset-gpios = <&gpio3 23 0>; > dc-gpios = <&gpio3 5 0>; > cs-gpios = <&gpio3 1 0>; > wr-gpios = <&gpio3 0 0>; > db-gpios = <&gpio3 7 0>, ><&gpio3 8 0>, ><&gpio3 9 0>, ><&gpio3 10 0>, ><&gpio3 11 0>, ><&gpio3 15 0>, ><&gpio3 16 0>, ><&gpio3 17 0>; > /* LED pin drives backlight directly. Use transistor (50mA) */ > /* led-gpios = <&gpio 4 1>; */ > debug = <7>; > }; > > > framebuffer { > compatible = "simple-framebuffer"; > reg = <0x1d385000 (240 * 320 * 2)>; > width = <240>; > height = <320>; > stride = <(240 * 2)>; > format = "r5g6b5"; > }; > }; > > > > > When I boot, I get the following error: > > > > > > Error opening /dev/fb0: No such file or directory > > > > > Did I forget something or is there a decent manual available? > > Thanks! > > Jonathan. > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > Looks to me like the driver hasn't loaded due to error or maybe compatible string mismatch. Have you included the simple framebuffer in the kernel configuration? Is there anything in dmesg? Cheers, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Multiple images/filesystems
Hi, I currently have a read only filesystem image. What I would like to do is have part of the filesystem read/write which is basically a particular user account, say /home/scratch To complicate things we have two flash devices, 1) eMMC with ext3 filesystem 2) NAND with ubifs filesystem So I would have 2 partitions for eMMC one for /home/scratch and the other for the rest of the rootfs. For NAND I think I need 2 UBI volumes one contains a UBIFS with /home/scratch the other with the remaining rootfs. I think I have to create my own image_type.bbclass file to create the ubifs and ext3 filesystems but I don't see how I separate out the /home/scratch from the image's rootfs. Anyone know what the best way to do this is. Many Thanks, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] mount bind /var/lib and package management
Hi, When using a read only rootfs it mount --binds /var/lib into /var/volatile/lib which lives in tmpfs and makes sense. The problem is that I use dpkg but I'm assuming other package management tools use /var/lib as their admin dir. Wouldn't this break package updates as the dpkg database files etc will then be updated in tmpfs so a power cycle would means the changes are lost? Or am I missing something? I tried to mount bind all directories except dpkg which I managed to get working but other systemd services failed as they expected /var/lib to be writeable (the service that creates /var/lib/machines). I suppose I could alter this to remount / rw first but gave up at this point. The next thing I tried was to use a new admindir for dpkg, ie /lib/dpkg which I have working but I had to hack a lot of files changing /var/lib to /lib including files for apt-get native. I'm not confident that I've got them all. Is there another solution I haven't thought of? Thanks in advance, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] systemd, dpkg and read-only-rootfs
Hi, I'm using the Jethro branch to build a system that uses dpkg for a package installer and systemd for the init manager. Recently I took the plunge and added read-only-rootfs and have found a few "features" that I thought I would share. 1) dpkg-configure service fails. This service looks like it's a first time boot action that runs dpkg --configure -a which I assume is to finish all half installed packages that needed to be finished on the real target because it couldn't be installed during do_rootfs. This actually succeeds as none of my packages are half configured, otherwise this would fail. The problem lies when it tries to disable itself, it looks like systemctl disable call tries to update symlink in /etc/systemd. I have tried remounting rw then disabling and then remount ro which I'm hoping will work, if not I will remove as I have a first boot script for factory builds and will move to there. 2) There are a bunch of configuration files in /usr/lib/tmpfiles.d that clash with files/directories that have already been created by Yocto which only throws warnings but the files/directories that it tries to create in a read-only rootfs cause the systemd-tmpfiles-setup.service to fail. I've patched the files in the systemd source directory to work around this, just testing now. 3) It looks like Yocto mount binds /var/lib into tmpfs (/var/volatile/lib), base-files recipe. Now the dpkg database files are in this directory so I'm guessing this will stop me from doing upgrades. We don't use apt-get but implement our own package manager so I was hoping to stop all services remount rootfs as rw, perform upgrade, remount rootfs as ro. Not sure what to do about this one, I could try and move dpkg database files to somewhere else, might throw up other problems. Or mount bind all directories in /var/lib except dpkg?? Thoughts appreciated. Best Regards, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: busybox-udhcpd not found in the base feeds
Hi, I think I understand what has happened. It's just occured to me that the udhcpd code is probably part of busybox by default and is in the busybox package, so I checked the defconfig and CONFIG_UDHCPD is set to y. I'm assuming that the busybox-udhcpd package contains just the init script which of course doesn't get installed as DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" has been set which means I have an empty package which then results in the not found in base feeds error. Does this sound right?? I can remove busybox-udhcpd from the image but it does seem wrong to remove this from the image when in fact all I'm removing is in the initscript. Maybe something like IMAGE_REMOVE += " ${@bb.utils.contains('DISTRO_FEATURES','systemd','busybox-udhcpd','',d)}" in busybox recipe, if there is such a thing to stop people like me hitting this problem again One question that springs to mind is that if udhcpd is part of busybox by default how do you override this with another DHCP server? Which is something I may have to look into. Many Thanks, Martin. On Thu, Feb 11, 2016 at 5:57 PM, Martin Townsend wrote: > Hi, > > I've just moved over to using systemd on a project but am seeing the error > listed in the subject. > I added the following to local.conf as there is no distribution config > file. > > VIRTUAL-RUNTIME_init_manager = "systemd" > DISTRO_FEATURES_append = " systemd" > # Prevent the SysVinit distribution feature from being automatically > enabled > # Breaks busybox-udhcpd for some reason. > DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" > > My understanding is that the last line will stop init scripts being > installed if the recipe has systemd support. Adding > VIRTUAL-RUNTIME_initscripts = "" would completely disable init scripts I > think so I didn't put this in. So the above should use systemd where > appropriate otherwise use sysV init scripts. > > I then blew away all sstate, cache and tmp directories and rebuilt and get > the error. If I comment out the last line the error goes away but I get > all the sys V init scripts. I checked the recipe and it inherits systemd > and update-rc.d and I think the problem may be that busybox builds syslog > with a systemd service but all the remaining components use init scripts as > far as I can see, including udhcpd. I looked in packages-split and > busybox-udhcpd is empty. > > Any help appreciated, > Martin. > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ERROR: busybox-udhcpd not found in the base feeds
Hi, I've just moved over to using systemd on a project but am seeing the error listed in the subject. I added the following to local.conf as there is no distribution config file. VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_append = " systemd" # Prevent the SysVinit distribution feature from being automatically enabled # Breaks busybox-udhcpd for some reason. DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" My understanding is that the last line will stop init scripts being installed if the recipe has systemd support. Adding VIRTUAL-RUNTIME_initscripts = "" would completely disable init scripts I think so I didn't put this in. So the above should use systemd where appropriate otherwise use sysV init scripts. I then blew away all sstate, cache and tmp directories and rebuilt and get the error. If I comment out the last line the error goes away but I get all the sys V init scripts. I checked the recipe and it inherits systemd and update-rc.d and I think the problem may be that busybox builds syslog with a systemd service but all the remaining components use init scripts as far as I can see, including udhcpd. I looked in packages-split and busybox-udhcpd is empty. Any help appreciated, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Toaster Problem
Hi, I'm trying out a production instance of toaster, I'm following the instructions from here http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#toaster-setting-up-a-production-instance-of-toaster I managed to get toaster up and running but had to adjust a few things which you might want to correct in the documentation: 1) virtualenv package doesn't exist in Ubuntu 14.04 had to use python-virtualenv 2) You need python headers later so add python-dev to list of packages to install 3) After cloning poky there should be a cd poky before checking out a branch. 4) SECRET_KEY, it would be nice to know what this is used for, what characters is can contain, ie can it contain spaces. 5) In the mysql part is states we are creating a database called toaster but in the settings.py we specify toaster_main one of them needs correcting. 6) Before calling ./bitbake/lib/toaster/manage.py syncdb --migrate maybe it should link to 3.5 and state that you should create a Django super user first. 7)There's a typo in the Apache toaster.conf s/toastern_wsgi/toaster_wsgi/ 8) Build runner service is wrong, there needs to be the poky directory involved somewhere, either cd /var/www/toaster/poky or we call ./poky/bitbake/toaster/manage.py Even with all this I can't get it to build, creating a project based on fido 1.8 and trying to build core-image-lsb I get 2015-12-08 10:27:57,705 DEBUG localhostbecontroller, our git repos are {(u'git://git.yoctoproject.org/meta-yocto', u'fido'): [(u'meta-yocto', u'meta-yocto'), (u'meta-yocto-bsp', u'meta-yocto-bsp')], (u'git://git.yoctoproject.org/poky', u'fido'): [('bitbake', u'bitbake'), (u'openembedded-core', u'meta')]} 2015-12-08 10:27:57,705 DEBUG lbc_shellcmmd: () git remote -v Traceback (most recent call last): File "/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/management/commands/runbuilds.py", line 60, in schedule bec.triggerBuild(br.brbitbake_set.all(), br.brlayer_set.all(), br.brvariable_set.all(), br.brtarget_set.all()) File "/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py", line 282, in triggerBuild self.setLayers(bitbake, layers, targets) File "/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py", line 150, in setLayers for remotes in self._shellcmd("git remote -v", self.be.sourcedir).split("\n"): File "/var/www/toaster/poky/bitbake/lib/toaster/bldcontrol/localhostbecontroller.py", line 59, in _shellcmd p = subprocess.Popen(command, cwd = cwd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) File "/usr/lib/python2.7/subprocess.py", line 710, in __init__ errread, errwrite) File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory: '' in the console. Any idea whats going wrong? Cheers, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] aclocal warnings
Hi, It's just a warning which I can suppress with export LANG=C, autotools is working fine with the SDK after a bit of tweaking in the ac and am files. Cheers, Martin. On Thu, Nov 19, 2015 at 7:03 AM, Khem Raj wrote: > On Wed, Nov 18, 2015 at 1:23 AM, Martin Townsend > wrote: > > Hi, > > > > I've created an autotools project to test out my SDK I've generated. The > > SDK was generated from a Yocto build system based the Fido branch. > > After souring the environment setup file in the SDK, running aclocal I > get > > the following warnings > > perl: warning: Setting locale failed. > > perl: warning: Please check that your locale settings: > > LANGUAGE = "en_GB:en", > > LC_ALL = (unset), > > LANG = "en_GB.UTF-8" > > are supported and installed on your system. > > perl: warning: Falling back to the standard locale ("C"). > > perl: warning: Setting locale failed. > > perl: warning: Please check that your locale settings: > > LANGUAGE = "en_GB:en", > > LC_ALL = (unset), > > LANG = "en_GB.UTF-8" > > are supported and installed on your system. > > perl: warning: Falling back to the standard locale ("C"). > > > > If I take the same project and build for the host aclocal works fine. > > > > Does anyone know what I can do to fix this in the SDK? even a hint as to > > where to look would be appreciated. > > its using perl from SDK it seems and we dont have all locales > installed in SDK. Do you see any problems due to this ? > or is it just a warning > > > > > Many Thanks, > > Martin. > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] aclocal
Hi, Just after sending the email I came across a posting on perl causing this error so it's not aclocal, ie running perl -e exit shows the warning, as per the post env LANG=C perl -e exit fixes things or export LANG=C after sourcing the environment works too. I don't know much about locales so I don't know if this is a valid fix or not, I'll carry on and see how it works out. Cheers, Martion. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] aclocal warnings
Hi, I've created an autotools project to test out my SDK I've generated. The SDK was generated from a Yocto build system based the Fido branch. After souring the environment setup file in the SDK, running aclocal I get the following warnings perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "en_GB:en", LC_ALL = (unset), LANG = "en_GB.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "en_GB:en", LC_ALL = (unset), LANG = "en_GB.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). If I take the same project and build for the host aclocal works fine. Does anyone know what I can do to fix this in the SDK? even a hint as to where to look would be appreciated. Many Thanks, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SDK
Hi Bryan, Thank you for the reply. I'm just doing a dry run with some sample applications using the SDK and the command line and all is looking good. I didn't know about the "eclipse-debug" so I'll take a look at this. Sadly all the dev and dbg packages are probably not going to fit into the flash but I'll keep a copy of the dbg packages somewhere in case a developer wants to debug into a library. They can scp it onto their board and install it. If I also include gdbserver and lttng packages for the target then hopefully this should be a good start. Regards, Martin. On Mon, Nov 16, 2015 at 6:25 PM, Bryan Evenson wrote: > Martin, > > > -Original Message- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of Martin Townsend > > Sent: Saturday, November 14, 2015 9:27 AM > > To: yocto@yoctoproject.org > > Subject: [yocto] SDK > > > > Hi, > > > > > > > > I want to provide an SDK to the app developers that is a self contained > > installation. The ADT looked like just the thing except I don't want to > have to > > setup an ADT Repo. I would like it to include: > > > > > > The cross development toolchain. > > > > The target sysroot to build against. I would like them to be able to > > dynamically link and statically link against everything in the Image. > > > > They may want to develop kernel modules so I would want the kernel > > header files etc in the target sysroot. > > > > The Eclipse IDE Yocto plug-in or another way of using Eclipse to build > and > > debug for the target. > > I Would also like to use things like the LTTNG and Valgrind integration > in > > Eclipse. > > > > QEMU would be a nice to have and with integration into Eclipse. > > > > > > I have my own distro and image files which aren't a million miles away > from > > poky and core-image-minimal :) > > > > > > From what I've read I think the best thing for me to do is > > > > bitbake my-image -cpopulate_sdk > > > > which gives my an installer for the toolchain, target sysroot and qemu (I > > think). > > You need to make sure your image includes the features for debugging. If > you have an image that is based upon core-image-minimal, the image will be > missing some features and you'll never be able to debug an application > through Eclipse or use Lttng. > > I'd suggest making a development image recipe (i.e. " > my-custom-image-dev.bb") based on your image with the following changes: > 1. Add "dev-pkgs eclipse-debug" to IMAGE_FEATURES > 2. Add a "-dbg" package to IMAGE_INSTALL for each userspace application > you are writing which you plan to debug with GDB. > 3. Add "gdbserver" to IMAGE_INSTALL for GDB support. > 4. Add "lttng-tools lttng-modules lttng-ust" to IMAGE_INSTALL for Lttng > support. > > Once you've built and verified the new image runs on your hardware, I'd > then create the SDK as you described above. I don't use QEMU so I can't > speak to whether that gets included in the SDK or not. But, if you have a > developer that isn't responsible for building the whole image and just > wants to build and debug their userspace application, the SDK and resulting > sysroot should be all the pieces they need on their development machine. > > Regards, > Bryan > > > > > Then get them to install the Eclipse plugin by following the > instructions from > > http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#adt- > > eclipse > > > > > > Just want to check I'm on the right path and there's not another better > way. > > > > > > Many Thanks, > > > > Martin. > > > > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] SDK
Hi, I want to provide an SDK to the app developers that is a self contained installation. The ADT looked like just the thing except I don't want to have to setup an ADT Repo. I would like it to include: The cross development toolchain. The target sysroot to build against. I would like them to be able to dynamically link and statically link against everything in the Image. They may want to develop kernel modules so I would want the kernel header files etc in the target sysroot. The Eclipse IDE Yocto plug-in or another way of using Eclipse to build and debug for the target. I Would also like to use things like the LTTNG and Valgrind integration in Eclipse. QEMU would be a nice to have and with integration into Eclipse. I have my own distro and image files which aren't a million miles away from poky and core-image-minimal :) >From what I've read I think the best thing for me to do is bitbake my-image -cpopulate_sdk which gives my an installer for the toolchain, target sysroot and qemu (I think). Then get them to install the Eclipse plugin by following the instructions from http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#adt-eclipse Just want to check I'm on the right path and there's not another better way. Many Thanks, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] binutils failing in FIDO branch
And I also found this link https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available which looks promising. :) On Tue, Nov 10, 2015 at 11:40 AM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: > About all I know that we do have (in the manual at least) is contained in > this > section: > > > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#making-images-more-secure > > It's not a lot but it's something. (If anyone has any ideas on how to > extend > this area we'd appreciate the input.) > > Cheers, > Paul > > On Tuesday 10 November 2015 11:17:31 Martin Townsend wrote: > > Hi Paul, > > > > meta/conf/distro/include/security_flags.inc is much better than a blanket > > change of compiler flags. Thanks for the tip. Are there any other > > tips/web pages on Security or Linux hardening using Yocto? > > > > Cheers, > > Martin. > > > > > > On Mon, Nov 9, 2015 at 11:06 PM, Paul Eggleton < > > > > paul.eggle...@linux.intel.com> wrote: > > > On Monday 09 November 2015 22:32:59 Martin Townsend wrote: > > > > My issue is particular to my distro, I tried changing to poky and all > > > > was > > > > well. The reason for our own distro was to migrate from Arago which > we > > > > were using. So I copied Arago into a separate distro and then > started > > > > morphing it into something more akin to Poky over time. Alas I left > the > > > > following line in the distro conf, one which should have removed :( > > > > > > > > # Enable basic stack and buffer overflow protections > > > > TARGET_CPPFLAGS += "-fstack-protector -D_FORTIFY_SOURCE=1" > > > > > > > > After commenting this out binutils for the target builds fine. I'm > > > > guesssing that for libiberty CPPFLAGS propogates into configure or > > > > > > makefile > > > > > > > in the binutils recipe which then fails one of it's config checks and > > > > because of this fails to set HAVE_LIMITS and a few others no doubt. > > > > > > > > Many apologies for leading you on a wild goose chase, I don't know if > > > > > > there > > > > > > > is anything you can do so others don't fall foul of this. Is setting > > > > TARGET_CPPFLAGS or TARGET_CFLAGS for that matter useful in > configuration > > > > files?? If so, maybe making sure they are reverted for building > > > > > > binutils?? > > > > > > I'm assuming you could do something like: > > > > > > TARGET_CPPFLAGS += "${MY_EXTRAFLAGS}" > > > MY_EXTRAFLAGS = "-fstack-protector -D_FORTIFY_SOURCE=1" > > > MY_EXTRAFLAGS_pn-binutils = "" > > > > > > FYI we do have meta/conf/distro/include/security_flags.inc to apply > these > > > two > > > flags, but interestingly there's no mention of binutils in there. > > > > > > > Thanks for all the help and maybe it's time we moved over to Poky :) > > > > > > Well, there's nothing forcing you to use poky - it's a reference > > > distribution; > > > the assumption is usually that you'll want to change something at the > > > distribution level at which point you've effectively created your own > > > distro. > > > > > > Cheers, > > > Paul > > > > > > -- > > > > > > Paul Eggleton > > > Intel Open Source Technology Centre > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] binutils failing in FIDO branch
Hi Paul, meta/conf/distro/include/security_flags.inc is much better than a blanket change of compiler flags. Thanks for the tip. Are there any other tips/web pages on Security or Linux hardening using Yocto? Cheers, Martin. On Mon, Nov 9, 2015 at 11:06 PM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: > On Monday 09 November 2015 22:32:59 Martin Townsend wrote: > > My issue is particular to my distro, I tried changing to poky and all was > > well. The reason for our own distro was to migrate from Arago which we > > were using. So I copied Arago into a separate distro and then started > > morphing it into something more akin to Poky over time. Alas I left the > > following line in the distro conf, one which should have removed :( > > > > # Enable basic stack and buffer overflow protections > > TARGET_CPPFLAGS += "-fstack-protector -D_FORTIFY_SOURCE=1" > > > > After commenting this out binutils for the target builds fine. I'm > > guesssing that for libiberty CPPFLAGS propogates into configure or > makefile > > in the binutils recipe which then fails one of it's config checks and > > because of this fails to set HAVE_LIMITS and a few others no doubt. > > > > Many apologies for leading you on a wild goose chase, I don't know if > there > > is anything you can do so others don't fall foul of this. Is setting > > TARGET_CPPFLAGS or TARGET_CFLAGS for that matter useful in configuration > > files?? If so, maybe making sure they are reverted for building > binutils?? > > I'm assuming you could do something like: > > TARGET_CPPFLAGS += "${MY_EXTRAFLAGS}" > MY_EXTRAFLAGS = "-fstack-protector -D_FORTIFY_SOURCE=1" > MY_EXTRAFLAGS_pn-binutils = "" > > FYI we do have meta/conf/distro/include/security_flags.inc to apply these > two > flags, but interestingly there's no mention of binutils in there. > > > Thanks for all the help and maybe it's time we moved over to Poky :) > > Well, there's nothing forcing you to use poky - it's a reference > distribution; > the assumption is usually that you'll want to change something at the > distribution level at which point you've effectively created your own > distro. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] binutils failing in FIDO branch
Hi, My issue is particular to my distro, I tried changing to poky and all was well. The reason for our own distro was to migrate from Arago which we were using. So I copied Arago into a separate distro and then started morphing it into something more akin to Poky over time. Alas I left the following line in the distro conf, one which should have removed :( # Enable basic stack and buffer overflow protections TARGET_CPPFLAGS += "-fstack-protector -D_FORTIFY_SOURCE=1" After commenting this out binutils for the target builds fine. I'm guesssing that for libiberty CPPFLAGS propogates into configure or makefile in the binutils recipe which then fails one of it's config checks and because of this fails to set HAVE_LIMITS and a few others no doubt. Many apologies for leading you on a wild goose chase, I don't know if there is anything you can do so others don't fall foul of this. Is setting TARGET_CPPFLAGS or TARGET_CFLAGS for that matter useful in configuration files?? If so, maybe making sure they are reverted for building binutils?? Thanks for all the help and maybe it's time we moved over to Poky :) Cheers, Martin. On Mon, Nov 9, 2015 at 10:07 PM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: > What I think Martin hasn't mentioned here (but did on IRC) is this is > binutils > for the target machine, not host/cross. I would assume it's somehow > related to > the target being built for. Martin, can you provide any details on that > which > might help others to reproduce the issue? > > Cheers, > Paul > > On Monday 09 November 2015 12:15:40 Khem Raj wrote: > > No it should be well supported. So now I wonder why no one else sees it > > > > > On Nov 9, 2015, at 11:22 AM, Martin Townsend > > > wrote: > > > > > > Hi, > > > > > > I'm running Ubuntu 14.04 LTS. > > > > > > Could this be the problem? > > > > > > Cheers, > > > Martin. > > > > > > > > > On Mon, Nov 9, 2015 at 5:56 PM, Khem Raj > > <mailto:raj.k...@gmail.com>> wrote:> > > > On Mon, Nov 9, 2015 at 4:36 AM, Martin Townsend < > mtownsend1...@gmail.com > <mailto:mtownsend1...@gmail.com>> wrote: > > > > Hi, > > > > > > > > binutils is failing to compile. I'm using tip of fido branch. Error > > > > message is: > > > > > > > > > > > > > /home/martint/yocto/build/am43-devboard-aquila/bia-tmp-glibc/work/cortex > > > > > a9hf-vfp-neon-oe-linux-gnueabi/binutils/2.24-r0/binutils-2.24/libiberty/ > > > > fibheap.c: In function 'fibheap_replace_key_data': > > > > > > > > > /home/martint/yocto/build/am43-devboard-aquila/bia-tmp-glibc/work/cortex > > > > > a9hf-vfp-neon-oe-linux-gnueabi/binutils/2.24-r0/binutils-2.24/libiberty/ > > > > fibheap.c:38:24: error: 'LONG_MIN' undeclared (first use in this > > > > function) > > > > > > > > | #define FIBHEAPKEY_MIN LONG_MIN > > > > > > > > I've tracked it down to the fact that libiberty is the only component > > > > that > > > > doesn't define HAVE_LIMITS in config.h, so I assume this part of the > > > > configure is failing for some reason. > > > > > > > > Anyone else seen this, or have an idea on how to fix this? > > > > > > whats your host distro ? > > > > > > > Cheers, > > > > Martin. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > ___ > > > > yocto mailing list > > > > yocto@yoctoproject.org <mailto:yocto@yoctoproject.org> > > > > https://lists.yoctoproject.org/listinfo/yocto > > > > <https://lists.yoctoproject.org/listinfo/yocto> > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] binutils failing in FIDO branch
Hi, I'm running Ubuntu 14.04 LTS. Could this be the problem? Cheers, Martin. On Mon, Nov 9, 2015 at 5:56 PM, Khem Raj wrote: > On Mon, Nov 9, 2015 at 4:36 AM, Martin Townsend > wrote: > > Hi, > > > > binutils is failing to compile. I'm using tip of fido branch. Error > > message is: > > > > | > > > /home/martint/yocto/build/am43-devboard-aquila/bia-tmp-glibc/work/cortexa9hf-vfp-neon-oe-linux-gnueabi/binutils/2.24-r0/binutils-2.24/libiberty/fibheap.c: > > In function 'fibheap_replace_key_data': > > | > > > /home/martint/yocto/build/am43-devboard-aquila/bia-tmp-glibc/work/cortexa9hf-vfp-neon-oe-linux-gnueabi/binutils/2.24-r0/binutils-2.24/libiberty/fibheap.c:38:24: > > error: 'LONG_MIN' undeclared (first use in this function) > > | #define FIBHEAPKEY_MIN LONG_MIN > > > > I've tracked it down to the fact that libiberty is the only component > that > > doesn't define HAVE_LIMITS in config.h, so I assume this part of the > > configure is failing for some reason. > > > > Anyone else seen this, or have an idea on how to fix this? > > whats your host distro ? > > > > > Cheers, > > Martin. > > > > > > > > > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] binutils failing in FIDO branch
Hi, binutils is failing to compile. I'm using tip of fido branch. Error message is: | /home/martint/yocto/build/am43-devboard-aquila/bia-tmp-glibc/work/cortexa9hf-vfp-neon-oe-linux-gnueabi/binutils/2.24-r0/binutils-2.24/libiberty/fibheap.c: In function 'fibheap_replace_key_data': | /home/martint/yocto/build/am43-devboard-aquila/bia-tmp-glibc/work/cortexa9hf-vfp-neon-oe-linux-gnueabi/binutils/2.24-r0/binutils-2.24/libiberty/fibheap.c:38:24: error: 'LONG_MIN' undeclared (first use in this function) | #define FIBHEAPKEY_MIN LONG_MIN I've tracked it down to the fact that libiberty is the only component that doesn't define HAVE_LIMITS in config.h, so I assume this part of the configure is failing for some reason. Anyone else seen this, or have an idea on how to fix this? Cheers, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] populate_sdk and debian packages problem
Hi, I fixed the problem but I don't know if it's the right way to fix it. Basically it occurs because I redefine DPKG_ARCH DPKG_ARCH ?= "armv7ahf-vfp-neon" in local.conf We need to do this as we support several arm platforms that are all little endian but some have soft floating point, some are armv5 etc. This breaks do_package_write_deb in package_deb.bbclass which maps DPKG_ARCH to Debian's ideas about architectures. My fix was to use PACAKGE_ARCH and add "i686-nativesdk" to the list I've added "x86_64-nativesdk" to the 64 bit list but I don't know if this is correct or not, just building now. python () { if d.getVar('PACKAGES', True) != '': deps = ' dpkg-native:do_populate_sysroot virtual/fakeroot-native:do_populate_sysroot' d.appendVarFlag('do_package_write_deb', 'depends', deps) d.setVarFlag('do_package_write_deb', 'fakeroot', "1") # Map TARGET_ARCH to Debian's ideas about architectures darch = d.getVar('PACKAGE_ARCH', True) if darch in ["x86", "i486", "i586", "i686", "i686-nativesdk", "pentium"]: d.setVar('DPKG_ARCH', 'i386') elif darch in ["x86_64", "x86_64-nativesdk"]: d.setVar('DPKG_ARCH', 'amd64') elif darch == "arm": d.setVar('DPKG_ARCH', 'armel') Like I said I don't know if this is the correct way of doing it, this is my first time of delving into the depths of bitbake and Yocto :) If it is correct I don't mind submitting a patch if someone shows me how to do this. Cheers, Martin. On Tue, Nov 3, 2015 at 2:52 PM, Paul Eggleton wrote: > On Tuesday 03 November 2015 14:34:33 Martin Townsend wrote: > > I don't know if it worked before, we were using daisy with an external > > toolchain and populate_sdk wasn't working. I've wanted to go to Fido and > > use the built toolchain so I bit the bullet as all looks good except > > populate_sdk with dpkg. Anyway, I'll file a bug as it looks like there > is > > a problem. > > OK, thanks. > > > In the meantime if someone could point me in the direction of which class > > files to look at that would be great as I need to get this working asap > and > > I don't mind doing some ground work. > > Basically: > > meta/classes/package_deb.bbclass > meta/classes/rootfs_deb.bbclass > > Most of the logic is actually in Dpkg* classes in: > > meta/lib/oe/sdk.py > meta/lib/oe/package_manager.py > meta/lib/oe/rootfs.py > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] populate_sdk and debian packages problem
Hi Paul, I don't know if it worked before, we were using daisy with an external toolchain and populate_sdk wasn't working. I've wanted to go to Fido and use the built toolchain so I bit the bullet as all looks good except populate_sdk with dpkg. Anyway, I'll file a bug as it looks like there is a problem. In the meantime if someone could point me in the direction of which class files to look at that would be great as I need to get this working asap and I don't mind doing some ground work. Cheers, Martin. On Tue, Nov 3, 2015 at 2:20 PM, Paul Eggleton wrote: > Hi Martin, > > On Monday 02 November 2015 18:53:04 Martin Townsend wrote: > > I've just moved everything to fido and everything builds fine. One of > the > > reasons for moving to Fido was to use the built toolchain and create an > SDK > > using populate_sdk but it is failing with the following message: > > ERROR: Unable to install packages. Command > > > '/home/martin/ws_poweroasis/build/am43-devboard-aquila/bia-tmp-glibc/sysroot > > s/x86_64-linux/usr/bin/apt-get install --force-yes > --allow-unauthenticated > > nativesdk-packagegroup-sdk-host > > packagegroup-cross-canadian-am43-devboard-aquila' returned 100: > > Reading package lists... > > Building dependency tree... > > Reading state information... > > W: Unable to read > > > /home/martin/ws_poweroasis/build/am43-devboard-aquila/bia-tmp-glibc/work/am4 > > > 3_devboard_aquila-oe-linux-gnueabi/bia-image/1.0-r0/apt-sdk/preferences.d/ - > > DirectoryExists (2: No such file or directory) > > E: Unable to locate package nativesdk-packagegroup-sdk-host > > > > I checked the nativesdk-packagegroup-sdk-host build and it's empty. > > > > After a bit of searching I found that a similar problem exists in Daisy > and > > it was down to debian packages which I am using so I chaged to use the > > default IPK and the error message disappears. > > > > Is this a regression? or are Debian packages not supported for SDK? > > If it worked before then it's a regression. I'm afraid deb packaging is the > least well-tested of the three packaging options, from time to time it does > break unfortunately. Could you please file a bug at > bugzilla.yoctoproject.org ? > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] populate_sdk and debian packages problem
Hi, I've just moved everything to fido and everything builds fine. One of the reasons for moving to Fido was to use the built toolchain and create an SDK using populate_sdk but it is failing with the following message: ERROR: Unable to install packages. Command '/home/martin/ws_poweroasis/build/am43-devboard-aquila/bia-tmp-glibc/sysroots/x86_64-linux/usr/bin/apt-get install --force-yes --allow-unauthenticated nativesdk-packagegroup-sdk-host packagegroup-cross-canadian-am43-devboard-aquila' returned 100: Reading package lists... Building dependency tree... Reading state information... W: Unable to read /home/martin/ws_poweroasis/build/am43-devboard-aquila/bia-tmp-glibc/work/am43_devboard_aquila-oe-linux-gnueabi/bia-image/1.0-r0/apt-sdk/preferences.d/ - DirectoryExists (2: No such file or directory) E: Unable to locate package nativesdk-packagegroup-sdk-host I checked the nativesdk-packagegroup-sdk-host build and it's empty. After a bit of searching I found that a similar problem exists in Daisy and it was down to debian packages which I am using so I chaged to use the default IPK and the error message disappears. Is this a regression? or are Debian packages not supported for SDK? Many Thanks, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] populate_sdk and debian packages problem
Hi, I've just moved everything to fido and everything builds fine. One of the reasons for moving to Fido was to use the built toolchain and create an SDK using populate_sdk but it is failing with the following message: ERROR: Unable to install packages. Command '/home/martin/ws_poweroasis/build/am43-devboard-aquila/bia-tmp-glibc/sysroots/x86_64-linux/usr/bin/apt-get install --force-yes --allow-unauthenticated nativesdk-packagegroup-sdk-host packagegroup-cross-canadian-am43-devboard-aquila' returned 100: Reading package lists... Building dependency tree... Reading state information... W: Unable to read /home/martin/ws_poweroasis/build/am43-devboard-aquila/bia-tmp-glibc/work/am43_devboard_aquila-oe-linux-gnueabi/bia-image/1.0-r0/apt-sdk/preferences.d/ - DirectoryExists (2: No such file or directory) E: Unable to locate package nativesdk-packagegroup-sdk-host I checked the nativesdk-packagegroup-sdk-host build and it's empty. After a bit of searching I found that a similar problem exists in Daisy and it was down to debian packages which I am using so I chaged to use the default IPK and the error message disappears. Is this a regression? or are Debian packages not supported for SDK? Many Thanks, Martin. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto