Hi,
As painfully found out by mono team, if big/little cores have
different cache line sizes, __clear_cache doesn't work as expected.
This affects any home-grown cache flushing mechanism as well.
http://www.mono-project.com/news/2016/09/12/arm64-icache/
protip, if you suspect your application is
Hi,
On 16 July 2014 17:19, Claudio Fontana wrote:
> do you have a prepackaged static libfdt.a for aarch64?
> I think it's part of some of the released images you provide, but
> maybe you have it also available as a single package?
It comes in libfdt-dev package on Ubuntu/Debian systems.
Riku
Hi,
This is essentially what sbrsh was created for a decade ago:
http://www.scratchbox.org/documentation/user/scratchbox-1.0/html/sbrsh.html
http://packages.qa.debian.org/s/sbrsh.html
You run register sbrsh with binfmt-misc (or just prefix sbrsh command) and
run sbrshd on the target device. You
On 9 April 2014 22:22, Maxim Kuvyrkov wrote:
> On Apr 9, 2014, at 1:51 AM, Riku Voipio wrote:
>
> > Hi,
> >
> > The preprocessed file:
> >
> > http://people.linaro.org/~rikuvoipio/qmltextgenerator.ii.gz
> >
> > With compile command line:
>
Hi,
The preprocessed file:
http://people.linaro.org/~rikuvoipio/qmltextgenerator.ii.gz
With compile command line:
g++ -save-temps -c -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fvisibility=hidden
-fvisibility-inlines-hidden -Wall -W -
On 24 February 2014 17:10, Peter Maydell wrote:
> On 24 February 2014 14:54, Rob Savoye wrote:
> > On 02/24/2014 07:15 AM, Wookey wrote:
> >> Where does a 'boards' file go/come from?
> > It's a DejaGnu config file, used for remote testing.
> >> Yes, or setting QEMU_UNAME on the command line, b
Hi,
According the debian bug report [1], it is not possible to use std::future
on armv5 targetting toolchains. This is because libstdc++ will only enable
std::future if ATOMIC_INT_LOCK_FREE > 1. There is no LDREX for armv5 and
older, so this definition is set to ATOMIC_INT_LOCK_FREE when compilin
Hi,
Your meta-linaro or meta-openembedded git tree is out of date. You need to
run git pull to get latest version in these directories. If you do not want
ltp in your images, feel free to remove if from the list of packages
included in the image :) This is again nothing to do with linaro-toolchain
Hi,
On 28 April 2013 07:17, Aparna Mandke wrote:
> Hi,
> I am trying to compile Qt 4.8 for ARMv8. I need following packages.
>
> libqt4-dev libqt4-opengl-dev libphonon-dev libicu-dev libsqlite3-dev
> libxext-dev libxrender-dev gperf libfontconfig1-dev libphonon-dev
> libpng12-dev libjpeg62-dev
Hi,
The testcase at https://launchpadlibrarian.net/128616769/compare-test.c
With aarch64:
aarch64-oe-linux-gcc -o a-test ./compare-test.c
./a-test:
fail ret: -1: Bad address
With X86_64:
gcc -o test ./compare-test.c
./test
correct. ret: -1: Bad address
setting -D_FILE_OFFSET_BITS=64 doesn't m
On 1 January 2013 16:55, Arnd Bergmann wrote:
> On Monday 31 December 2012, Riku Voipio wrote:
>> http://sourceforge.net/mailarchive/forum.php?thread_name=CAAqcGH%3D-xM_a%3DR0o4cWoLqh7wKRLbiuHa_qPtrOBT2watYq_HA%40mail.gmail.com&forum_name=fuse-devel
>>
>> No respon
On 27 December 2012 23:15, Arnd Bergmann wrote:
> On x86, this never showed up, because its bits/sigcontext.h
> does not include asm/sigcontext.h, which it does on arm64,
> causing the conflicting __s64 definition to be pulled in
> through linux/types.h.
Ok, that explains.
> I think it would be
Hi,
The following code fails to build with OE Aarch64 toolchain with
current kernel headers. While ugly, the code is a reduced testcase
from fuse build failure (
https://bugs.launchpad.net/linaro-oe/+bug/1087757 ) and the same fuse
code compiles on all other architectures. Before I send a workarou
le
>>
>> This is fixed in the pending merge request:
>>
>> https://code.launchpad.net/~riku-voipio/linaro-image-tools/linaro-image-tools/+merge/106591
>
> I see that's approved. I'll update the bzr revno on the
On 24 May 2012 16:04, Peter Maydell wrote:
> $ linaro-media-create --image-file=host.img --image-size=1.9G
> --output-directory=host --dev fastmodel --hwpack
> hwpack_linaro*kvm-host* --hwpack-force-yes --binary
> linaro-precise-dev*
> [snip lots of output]
> ...I guess it doesn't like the non-i
ay is already in the sources.list.d
in the images. just aot-get update
4) BUG: faults as there's no AXF file
This is fixed in the pending merge request:
https://code.launchpad.net/~riku-voipio/linaro-image-tools/linaro-image-tools/+merge/106591
5) Run linaro-media-create --image-file=guest.img -
On 12 April 2012 09:05, Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
>> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>
> The directory should be /libhf/ or /libhfp/ for that for consistency
> with all the other architectures. Note e.g.
On 5 April 2012 04:18, Mike Frysinger wrote:
> On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote:
>> The choice of using multiarch path for armhf linker path was agreed
>> mostly because 1) people agreed that having the possibility of armhf
>> and armel binaries on the s
On 3 April 2012 02:56, Mike Frysinger wrote:
> On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote:
>> yes, this was brought up at Linaro Connect as well; having the ldso name in
>> a multiarch location doesn't mean that anything else needs to be in this
>> location.
> while true, it seems like /l
Hi Dennis,
On 31 March 2012 19:52, Dennis Gilmore wrote:
> Linaro Connect and other events are probably the worst place for such
> decisions and discussions to be made. though maybe there is not a good
> place. the wider community needs to be engaged for greatest acceptance.
> otherwise then if f
Hi,
binutils-gold is crashing while compiling chromium[1]. This was
originally found on Debian[2], but affects ubuntu[3] as well. Also,
regular, non-gold ld will segfault with null pointer reference on the same
linking commands. testcase:
# wget
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=1
21 matches
Mail list logo
