Re: [yocto] Naive Questsions about 3rd Party Kernel Module

[Lennart Sorensen]

On Mon, Sep 12, 2016 at 01:41:24PM -0300, Daniel. wrote:
> If you don't make your driver GPL you can't access GPL symbols. This
> *may* be the reason behind the "Unknown symbols"
> Regards,

Well at least for __stack_chk_fail the kernel has:

#ifdef CONFIG_CC_STACKPROTECTOR

/*
 * Called when gcc's -fstack-protector feature is used, and
 * gcc detects corruption of the on-stack canary value
 */
__visible void __stack_chk_fail(void)
{
panic("stack-protector: Kernel stack is corrupted in: %p\n",
__builtin_return_address(0));
}
EXPORT_SYMBOL(__stack_chk_fail);

#endif

So as long as the kernel is configured with CC_STACKPROTECTOR, it should
exist, and it is not GPL only.

So at least as long as the kernel module is built by the same kernel
build files as the kernel was with the same config and the same compiler,
it should work.  If someone tries to manually build the kernel module
instead of using the kernel build scripts to do it, then they are asking
for trouble.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Striping cross-compiled paths

[Lennart Sorensen]

On Mon, Sep 12, 2016 at 08:16:02PM +0100, Burton, Ross wrote:
> If those paths come from __FILE__ and so on, then currently no.  It would
> be great if GCC could do this, but currently it can not.

__FILE__ contains whatever was passed to gcc, so if you ask it to do:

gcc file.c

then __FILE__ will be just file.c, while if you do:

gcc /full/path/to/my/file.c

then __FILE__ will be /full/path/to/my/file.c

So it really depends on how the makefile does things, and what bitbake
passes to the build.  It is not gcc's fault at all.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Naive Questsions about 3rd Party Kernel Module

[Lennart Sorensen]

On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote:
> Following up as I've done more investigation and debugging this afternoon:
> 
> I've been able to resolve my problem with the missing symbolic link to
> .so by explicitly including a runtime dependency
> (RDEPENDS_${PN}) to the -dev module, so my link is now present on the
> filesystem image at boot.  I've also found reasonably strong evidence
> that that library contains the function __stack_chk_fail; but the
> evidence could equally indicate that that library calls it as I found
> the string using the strings function.
> 
> Either way, it looks like I have a critical kernel module, and a less
> critical kernel module, that are relying on a shared library that
> either are missing on my image or are not available properly in kernel
> space.  Any suggestions on how I can resolve this would be greatly
> appreciated.

Kernel modules only use kernel code.  They never use user space libraries.
It simply doesn't work that way.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

[Lennart Sorensen]

On Wed, Oct 05, 2016 at 04:10:01PM +, Dinh Nguyen (dinhn) wrote:
> >>> I wonder why do we want to override default PACKAGES here. If we can 
> >>> leave that alone things would work out on its own.
> 
> I did remove the PACKAGES setting in my .bb — so all default packages were 
> built. But still having some other issue as stated in other emails.
> 
> Thanks Khem.
>   —Dinh
> 
> 
> 
> On 10/5/16, 8:34 AM, "Khem Raj"  wrote:
> 
> >I wonder why do we want to override default PACKAGES here. If we can leave
> >that alone things would work out on its own.
> >
> >On Tue, Oct 4, 2016 at 11:55 PM, Paul Eggleton
> > wrote:
> >> On Wed, 05 Oct 2016 05:12:27 Dinh Nguyen wrote:
> >>> Thanks much Paul.
> >>>
> >>>  PACKAGES = "${PN}" should work
> >>>
> >>> It solved the early error “ c-mlib listed in PACKAGES multiple times, this
> >>> leads to packaging errors” — Thanks again.
> >>>
> >>>
> >>> But running into other issue. Below is my do_install
> >>>
> >>> do_install () {
> >>>   oe_runmake all

Is that doing a compile in the install target?

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

[Lennart Sorensen]

On Wed, Oct 05, 2016 at 04:06:25PM +, Dinh Nguyen (dinhn) wrote:
> Many thanks Paul. Your help is greatly appreciated.
> 
> 1. >>> Like the other responder I would suggest you not set PACKAGES
> 
> Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built 
> as shown below:
> 
> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find 
> tmp/deploy | grep c-mlibtmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk
> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk
> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
> tmp/deploy/licenses/c-mlib
> 
> 2. >>> FILES_${PN}-dev = "${includedir}”
> 
> I added that to .bb as you suggested so .so file doesn't end up in the 
> ${PN}-dev
> Package — No longer see the error mentioned in previous mail. Thx
> 
> 3. >>> This is what I suspected would happen - these files would normally be 
> part of
> the ${PN}-dbg package, but since you've removed that from PACKAGES, they are 
> ending up unpackaged and that is not allowed.
> 
> Did you mean the "install -m 0644 xxx yyy” to remove those files from the 
> PACKAGES? How do I copy .so and binaries from my target to the libdir or 
> bindir?
> 
> After changing the .bb to remove the PACKAGES setting and FILES_${PN}-dev = 
> "${includedir}”
> For the very first time, packages were built find, image were created under 
> image directory and c-mlib source is still in the yp workspace as shown below:
> 
> A.Packages were built
> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find 
> tmp/deploy | grep c-mlib
> tmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk
> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk
> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
> tmp/deploy/licenses/c-mlib
> 
> B. Source files and the c-mlib git directory still have all the sources (e.g 
> just grep the mlib_api.c) 
> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find . 
> -name "mlib_api.c"
> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git/src/mlib_api.c
> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/packages-split/c-mlib-dbg/usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c
> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/package/usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c
> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ 
> 
> C. Image was built as well including binaries and libmlib.so
> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$
>  ls -ltr
> total 1424
> -rw-r--r-- 1 dinhn dinhn 171701 Oct  5 01:17 datamodel_cache
> -rw-r--r-- 1 dinhn dinhn 187434 Oct  5 01:17 invoke
> -rw-r--r-- 1 dinhn dinhn 184961 Oct  5 01:17 invoke_b
> -rw-r--r-- 1 dinhn dinhn 171701 Oct  5 01:17 protocol_infra
> -rw-r--r-- 1 dinhn dinhn 191362 Oct  5 01:17 publisher
> -rw-r--r-- 1 dinhn dinhn 187084 Oct  5 01:17 rpc-register
> -rw-r--r-- 1 dinhn dinhn 179648 Oct  5 01:17 service
> -rw-r--r-- 1 dinhn dinhn 174518 Oct  5 01:17 subscriber
> 
> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$
>  cd ../lib
> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/lib$
>  ls -ltr
> total 856
> -rw-r--r-- 3 dinhn dinhn 872657 Oct  5 01:17 libmlib.so
> 
> So it is all good for the first time, but thereafter that, if I do clean 
> “bitbake -c clean c-mlib” and “bitbake c-mlib” again.
> All packages were build successful, but all data under c-mlib got was gone. 
> Nothing there including .c/h files, image directory etc...
> 
> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git$
>  ls -ltr
> total 0
> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git$
>  
> 
> Please give me an idea why how to solve this? Sorry for a long email ;-))

Are the files present in the image/packages?  Maybe it is just the
bitbake cache skipping doing work it already did last time.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 07:47:58PM +, Dinh Nguyen (dinhn) wrote:
> 
> Hi Paul, thanks much for prompt response. 
> 
> The c-mlib.bb below has the packages var as
> PACKAGES =+ "${PN}” I also tried PACKAGES = "${PN}” 

Don't do that.

In bitbake.conf you have:

PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale 
${PACKAGE_BEFORE_PN} ${PN}"

So all those package names are implied and always exist.  Don't try to
add them yourself.

Only do anything with PACKAGES if you want to add any other package
names or totally override the list of packages (in which case you have
to use PACKAGES = of course)

For example base-files does override the list completely, as does glibc
and a few other ones, but most only add to it.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build ntp with openssl support

[Lennart Sorensen]

On Fri, Sep 23, 2016 at 02:19:20PM +0200, Oliver Graute wrote:
> On 22/09/16, Khem Raj wrote:
> > On Thu, Sep 22, 2016 at 12:16 AM, Oliver Graute  
> > wrote:
> > > On 19/09/16, Oliver Graute wrote:
> > >> On 16/09/16, Andre McCurdy wrote:
> > >> > On Fri, Sep 16, 2016 at 1:24 AM, Oliver Graute 
> > >> >  wrote:
> > >> > > Hello,
> > >> > >
> > >> > > how can I build ntp with openssl support?
> > >> > >
> > >> > > I already created a ntp_%.bbappend file to extend the recipe 
> > >> > > ntp_4.2.8p4.bb.
> > >> > >
> > >> > > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> > >> >
> > >> > You don't really need this line unless you are adding a file to
> > >> > SRC_URI or replacing a file already in SRC_URI with your own version.
> > >> >
> > >> > > PACKAGECONFIG += "openssl"
> > >> >
> > >> > This will enable openssl, but it will also disable all the default
> > >> > PACKAGECONFIG options (cap, debug and refclocks) which is probably not
> > >> > what you want. Try this instead:
> > >> >
> > >> >   PACKAGECONFIG_append = " openssl"
> > >> >
> > >> > Note the space between " and openssl. It's required.
> > >>
> > >> ok now I see the right configure script options during the configuration
> > >> of the ntp build.
> > >>
> > >> --with-openssl-libdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
> > >> --with-openssl-incdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
> > >> --with-crypto
> > >>
> > >> But ntp is still build without openssl support. The configure scripts
> > >> can't find the relevant openssl stuff.
> > >>
> > >> configure:34762: checking for openssl library directory
> > >> configure:34802: result: no
> > >> configure:34807: WARNING: libcrypto and libssl not found in any of 
> > >> /home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
> > >> configure:34811: checking for openssl include directory
> > >> configure:34833: result: 
> > >> /home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
> > >> configure:34877: checking if we will use crypto
> > >> configure:34879: result: no
> > >> configure:35109: checking if we want to use OpenSSL's crypto random (if 
> > >> available)
> > >> configure:35119: result: yes
> > >>
> > >> some clue whats wrong here?
> > >
> > > in my sysroots/imx6ulevk/usr/lib I have
> > >
> > > ls -la libssl*
> > >
> > > libssl3.so
> > > libssl.a
> > > libssl.so -> libssl.so.1.0.0
> > > libssl.so.1.0.0
> > >
> > > ls -la libcrypt*
> > >
> > > libcrypt.a
> > > libcrypt_pic.a
> > > libcrypt_pic.map
> > > libcrypt.so -> ../../lib/libcrypt.so.1
> > >
> > >
> > > but no libcrypto.so. I guess thats the reason why my ntp configure
> > > script is complaining.
> > >
> > > Some ideas how to get libcrypto.so in my /usr/lib folder in the yocto
> > > sysroot?
> > >
> > 
> > It seems your openssl is not being compiled correctly. Can you go into
> > builddir or openssl
> > and see if libcrypto.so.1.0.0 is built ? if not then you have to do
> > some digging why its not
> > configuring to build libcrypto
> 
> libcrypto is build by openssl
> 
> openssl/1.0.2d-r0/openssl-1.0.2d$ ls -la  libcrypt*
> libcrypto.a
> libcrypto.pc
> libcrypto.so -> libcrypto.so.1.0.0
> libcrypto.so.1.0.0
> 
> but in my sysroot libcrypto is located in lib NOT in usr/lib
> 
> the ntp recipe in 
> meta-openembedded/meta-networking/recipes-support/ntp/ntp_4.2.8p4.bb
> defines:
> 
>  --with-openssl-libdir=${STAGING_LIBDIR}
> 
> I assume I need ${STAGING_BASELIBDIR} here instead. But currently I fail
> with overwriting this in my bbappend file.
> 
> If I use EXTRA_OECONF to overwrite it in my bbappend I see two 
> --with-openssl-libdir
> statements while configuring. The first with /lib the second one with 
> /usr/lib. 
> 
> EXTRA_OECONF  += "\
>   --with-openssl \
>   --with-openssl-libdir=${STAGING_BASELIBDIR} \
>   --with-openssl-incdir=${STAGING_INCDIR} \
>   --with-crypto \
> "

I have a .bbappend file containing:

# This is wrong in the upstream .bb file and doesn't work so override it
PACKAGECONFIG[openssl] = "--with-crypto, \
  --without-crypto, \
  openssl"
PACKAGECONFIG_append = " openssl"

By NOT specifying the directories, it uses pkg-config, which of course
returns both directories correctly.  The ntp configure script can't
imagine that the openssl libraries are in two different directories at
the same time and hence fails to find them even though it searches both
of them, but only trying one at a time.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Freescale DPAA drivers

[Lennart Sorensen]

On Fri, Sep 23, 2016 at 02:13:43PM +, Anicic Damir (PSI) wrote:
> I am using Yocto 2.1, PowerPC64, default kernel 4.1.22
> Building for T2080rdb.
> 
> Everything builds, but kernel is missing DPAA Freescale drivers
> (dpaa_eth at least)
> 
> 
> It seems that DPAA Freescale drivers not in any Linux kernel (or am I wrong).
> 
> Why is that so, is Freescale not planing to include them in kernel ?

I have seen them try.  There was a v5 patch for dpaa_eth in December 2015,
but I don't know what happened after that.

There is drivers/staging/fsl-mc/ in the most recent kernel, but I am
not sure that's everything needed yet.

In fact today there was:

http://lkml.iu.edu/hypermail/linux/kernel/1609.2/04508.html
http://lkml.iu.edu/hypermail/linux/kernel/1609.2/00356.html

So they are trying again it seems.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Tuning for a machine based on Cortex-A9

[Lennart Sorensen]

On Wed, Aug 24, 2016 at 07:51:40AM +, Ottavio Campana wrote:
> Hello,
> 
> I am trying to port a third-party BSP based on buildroot to yocto, but I am 
> not able to tune the compiler to extactly match the original one.
> 
> Particularly, if I run readelf on a binary compiled with the gcc that is used 
> by buildroot I get this output
> 
> ottavio@ottavio:~$ readelf -A hello_world
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-A9"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Application
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2
>   Tag_FP_arch: VFPv3
>   Tag_Advanced_SIMD_arch: NEONv1
>   Tag_ABI_PCS_wchar_t: 4
>   Tag_ABI_FP_rounding: Needed
>   Tag_ABI_FP_denormal: Needed
>   Tag_ABI_FP_exceptions: Needed
>   Tag_ABI_FP_number_model: IEEE 754
>   Tag_ABI_align_needed: 8-byte
>   Tag_ABI_align_preserved: 8-byte, except leaf SP
>   Tag_ABI_enum_size: int
>   Tag_CPU_unaligned_access: v6
>   Tag_MPextension_use: Allowed
>   Tag_Virtualization_use: TrustZone
> ottavio@ottavio:~$
> 
> I tried to replicate this by configuring a new machine, and my machine 
> configuration looks like this
> 
> require ../../../meta/conf/machine/include/tune-cortexa9.inc
> 
> AVAILTUNES += "cortexa9t-vfpv3-neon"
> ARMPKGARCH_tune-cortexa9t-vfpv3-neon  = "cortexa9"
> TUNE_FEATURES_tune-cortexa9t-vfpv3-neon   = 
> "${TUNE_FEATURES_tune-armv7at-vfpv3} neon cortexa9"
> PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv7at-vfpv3} cortexa9-vfp cortexa9-vfpv3 
> cortexa9t2-vfp cortexa9t2-vfpv3 cortexa9-neon"
> 
> DEFAULTTUNE = "cortexa9t-vfpv3-neon"
> 
> If I run readelf on any compiled binary obtained with yocto, I get this 
> result:
> 
> ottavio@ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$
>  readelf -A .libs/bzip2
> Attribute Section: aeabi
> File Attributes
>   Tag_CPU_name: "Cortex-A9"
>   Tag_CPU_arch: v7
>   Tag_CPU_arch_profile: Application
>   Tag_ARM_ISA_use: Yes
>   Tag_THUMB_ISA_use: Thumb-2
>   Tag_FP_arch: VFPv3
>   Tag_ABI_PCS_wchar_t: 4
>   Tag_ABI_FP_rounding: Needed
>   Tag_ABI_FP_denormal: Needed
>   Tag_ABI_FP_exceptions: Needed
>   Tag_ABI_FP_number_model: IEEE 754
>   Tag_ABI_align_needed: 8-byte
>   Tag_ABI_align_preserved: 8-byte, except leaf SP
>   Tag_ABI_enum_size: int
>   Tag_CPU_unaligned_access: v6
>   Tag_MPextension_use: Allowed
>   Tag_Virtualization_use: TrustZone
> ottavio@ottavio:~/poky/build-xxx/tmp/work/cortexa9-vfpv3-poky-linux-gnueabi/bzip2/1.0.6-r5/build$
> 
> I am quite close to get a similar binary, the missing part is the 
> Tag_Advanced_SIMD_arch: NEONv1 .  I get exactly the same result if I use 
> DEFAULTTUNE = "cortexa9t-vfpv3", thus it seems that the neon and 
> cortexa9-neon options I tried to add are ignored.
> 
> At this point I have two questions
> 
> Question #1
> 
> How should I change ARMPKGARCH_tune-cortexa9t-vfpv3-neon , 
> TUNE_FEATURES_tune-cortexa9t-vfpv3-neon and 
> PACKAGE_EXTRA_ARCHS_tune-cortexa9t-vfpv3-neon to have exactly the same kind 
> of elf?
> 
> Question # 2
> 
> Why the only options for neon in meta/conf/machine/include/tune-cortexa9.inc 
> are offered for HF tunes?

Well it looks to me like the HF neon options imply vfp, while the vfp3
tunes imply not neon.  Since they share registers the performance may
in fact be better if they are not mixed.

Of course there exists A9's without neon, so one might want to build
for that.

The git commit that added the vfpv3 tunes says they are for 32 register
VFP on A9s.  Neon already implies 32 registers for the vfp.

As far as I can tell, you can set DEFAULTTUNE to cortexa9t-neon to get
softfp with neon support, or you can set it to cortexa9thf-neon to get
hardfp with neon support.

Certainly cortexa9t-vfpv3 should NOT do neon as far as I can tell.

Getting the output you had above with neon support in it, I believe
means doing DEFAULTTUNE=cortexa9thf-neon

There is no such option as cortexa9t-vfpv3-neon that I can find in the
files anywhere, so that wouldn't work.  No point trying to invent one
since neon implies vfpv3 already.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build a toolchain compiler with ARM hard-float support

[Lennart Sorensen]

On Thu, Sep 29, 2016 at 08:17:47AM -0500, Mark Hatle wrote:
> The machine configuration file should be setting the 'DEFAULTTUNE' variable to
> an appropriate ISA and ABI (hard float) for your configuration.  If it is not,
> you may have to create your own variant and change the DEFAULTTUNE setting --
> assuming the board supports the necessary hard float components.  (And yes,
> there are some armv7a variants that people removed the VFP instructions from 
> --
> even though it's theoretically against spec.)

ARM says the Cortex-A5 and A9 are both optional VFP, so I don't think
it is against the spec in any way.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Big endian ARM machine with NEON wanted

[Lennart Sorensen]

On Fri, Oct 14, 2016 at 07:41:13AM +0200, Mike Looijmans wrote:
> On 13-10-16 19:20, Andreas Müller wrote:
> >
> >Does anybody know a big endian and common machine supporting NEON? I
> >would need one for testing my port of portaudio.
> 
> 
> Most ARM systems can run in both big-endian and little-endian modes.
> Somewhere early during boot this choice is being made.
> 
> Having said that, since big-endian machines are getting rare, there's very
> little support for big-endian ARM systems. Most (if not all) boards can run
> big-endian, but software support is usually lacking, in particular in the
> bootloader parts where this matters.
> 
> If it's just for testing some software, maybe you can use a QEMU machine?

Well from what I was able to find, it seems ARMv7 systems can only run
BE8 mode, while ARMv5 and older had BE32 mode, and ARMv6 had both options.

Qemu seems to support BE8 mode when emulating ARMv7 (at least if you
have a recent enough version).

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] any rumblings about a newer YP powerpc reference board than mpc8315e-rdb?

[Lennart Sorensen]

On Fri, Mar 03, 2017 at 01:55:24PM -, Andy Pont wrote:
> Ross Burton wrote...
> 
> >> it seems of limited value for YP to have a powerpc reference board,
> >> mpc8315e-rdb, that is essentially impossible to procure. is there any
> >> effort being made to look around for a newer powerpc reference board
> >> that people could actually buy?
> >
> >Do you have any suggestions?
> 
> If we are being strictly pedantic then is isn't PowerPC (at least in the 
> world that is Freescale / NXP / Whoever they are this week).
> 
> I would look at one of the P10xx series QorIQ boards.  Digi-Key list the 
> P1021RDB-PC-ND and P1024RDB-PA-ND as being active parts which are either 
> single or dual e500 cores.

Well it is a decent powerpcspe reference, but I sure wouldn't consider
it a powerpc reference.  It isn't quite compatible with standard powerpc.

Where I used to work we told freescale that nothing with the e500 was
ever going to be of interest, since if wasn't compatible with our existing
83xx based stuff, nor anything in the future like the e5500/e6500 or
even e500mc.

Sure for some uses it is fine, but I consider it wrong to call it
powerpc without clearly mentioning it is the SPE variant, not the
traditional type one would be used to.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Remove a recipe's do_install_append() function in an append file

[Lennart Sorensen]

On Tue, Mar 28, 2017 at 10:27:15AM -0700, Khem Raj wrote:
> On Thu, Mar 23, 2017 at 3:28 PM, Cody Piersall  wrote:
> > Hello,
> >
> > I am building zsh from meta-oe layer, and it has a do_install_append()
> > function defined like this:
> >
> > do_install_append () {
> > rm -fr ${D}/usr/share
> > }
> >
> > which gets rid of lots lots of useful functionality, like
> > context-aware autocompletion.  Can a bbappend file get rid of that
> > function, or do I need to edit the actual recipe? I've attempted
> > defining an empty do_install_append() { : } but it didn't work.
> >
> 
> if its in a bbappend, there is not much you can do about undoing it except
> to not apply the bbappend or modify it directly.
> 
> So you can send a patch to meta-oe to convince that its a good idea to keep
> /usr/share for zsh, or you can carry a local patch to meta-oe where you undo 
> it

Perhaps instead of deleting it, it should be put in another package that
people can choose to install if they want it.  Deleting it certainly
does seem rather unfortunate if someone actulally wanted it.

-- 
Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto