[yocto] nativesdk-expect configure error

[Martin Townsend]

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

[Martin Townsend]

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-4.5-5.12.0.226-r0.13.armv7ahf_neon

Re: [yocto] meta-mono: QA Error building mono-5.12.0.226

[Martin Townsend]

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

Re: [yocto] System recovery

[Martin Townsend]

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
<enrico.bonom...@gmail.com> 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 <mtownsend1...@gmail.com>:
>>
>> On Wed, May 9, 2018 at 11:21 AM, Enrico Bonomi
>> <enrico.bonom...@gmail.com> 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 <mtownsend1...@gmail.com>:
>> >>
>> >> 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
>> >> <enrico.bonom...@gmail.com>
>> >> 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

Re: [yocto] System recovery

[Martin Townsend]

On Wed, May 9, 2018 at 11:21 AM, Enrico Bonomi
<enrico.bonom...@gmail.com> 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 <mtownsend1...@gmail.com>:
>>
>> 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 <enrico.bonom...@gmail.com>
>> 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

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

[Martin Townsend]

Hi Bruce,

On Thu, May 3, 2018 at 3:27 AM, Bruce Ashfield <bruce.ashfi...@gmail.com> wrote:
>
>
> On Wed, May 2, 2018 at 5:05 PM, Martin Townsend <mtownsend1...@gmail.com>
> 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

[Martin Townsend]

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

[Martin Townsend]

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

[Martin Townsend]

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 

Re: [yocto] image inheritance problem

[Martin Townsend]

On Fri, Jan 26, 2018 at 7:17 PM, Martin Townsend
<mtownsend1...@gmail.com> wrote:
> Hi Khem,
>
> On Fri, Jan 26, 2018 at 6:57 PM, Khem Raj <raj.k...@gmail.com> 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

[Martin Townsend]

Hi Khem,

On Fri, Jan 26, 2018 at 6:57 PM, Khem Raj <raj.k...@gmail.com> 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

Re: [yocto] Problem building kernel FIT image with initramfs

[Martin Townsend]

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
<mtownsend1...@gmail.com> 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

[Martin Townsend]

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

[Martin Townsend]

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

[Martin Townsend]

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

[Martin Townsend]

On Fri, Oct 7, 2016 at 8:46 AM, Martin Townsend <mtownsend1...@gmail.com> wrote:
> On Fri, Oct 7, 2016 at 5:32 AM, Khem Raj <raj.k...@gmail.com> wrote:
>>
>>> On Oct 6, 2016, at 12:09 PM, Martin Townsend <mtownsend1...@gmail.com> 
>>> wrote:
>>>
>>> On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend <mtownsend1...@gmail.com> 
>>> 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/
>>

Re: [yocto] SDK Problems for SuperH 4

[Martin Townsend]

On Fri, Oct 7, 2016 at 5:32 AM, Khem Raj <raj.k...@gmail.com> wrote:
>
>> On Oct 6, 2016, at 12:09 PM, Martin Townsend <mtownsend1...@gmail.com> wrote:
>>
>> On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend <mtownsend1...@gmail.com> 
>> 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/sy

Re: [yocto] SDK Problems for SuperH 4

[Martin Townsend]

On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend <mtownsend1...@gmail.com> 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-po

[yocto] SDK Problems for SuperH 4

[Martin Townsend]

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

[Martin Townsend]

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 = < 23 0>;
> dc-gpios = <  5 0>;
> cs-gpios = <  1 0>;
> wr-gpios = <  0 0>;
> db-gpios = <  7 0>,
><  8 0>,
><  9 0>,
>< 10 0>,
>< 11 0>,
>< 15 0>,
>< 16 0>,
>< 17 0>;
> /* LED pin drives backlight directly. Use transistor (50mA) */
> /* led-gpios = < 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

[Martin Townsend]

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

Re: [yocto] ERROR: busybox-udhcpd not found in the base feeds

[Martin Townsend]

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 <mtownsend1...@gmail.com>
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

[Martin Townsend]

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

[Martin Townsend]

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

[Martin Townsend]

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 <raj.k...@gmail.com> wrote:

> On Wed, Nov 18, 2015 at 1:23 AM, Martin Townsend
> <mtownsend1...@gmail.com> 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 warnings

[Martin Townsend]

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

[yocto] aclocal

[Martin Townsend]

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

Re: [yocto] SDK

[Martin Townsend]

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 <beven...@melinkcorp.com>
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

[Martin Townsend]

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

[Martin Townsend]

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

[Martin Townsend]

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

[yocto] binutils failing in FIDO branch

[Martin Townsend]

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] binutils failing in FIDO branch

[Martin Townsend]

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 <raj.k...@gmail.com> wrote:

> On Mon, Nov 9, 2015 at 4:36 AM, Martin Townsend <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/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

Re: [yocto] binutils failing in FIDO branch

[Martin Townsend]

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 <mtownsend1...@gmail.com>
> > > 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 <raj.k...@gmail.com
> > > <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

[yocto] populate_sdk and debian packages problem

[Martin Townsend]

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