Hi Nicolas,
make omap2plus_defconfig
then
edit .config and remove CONFIG_ARCH_OMAP2=y line
then
make oldconfig and turn on CONFIG_THUMB2_KERNEL
then make uImage
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
GZIP arch/arm/boot/compressed/piggy.gzip
CC arch/arm/boot/compressed/misc.o
CC arch/arm/boot/compressed/decompress.o
arch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:232: Error: r15 not allowed here -- `cmp r10,pc'
make[2]: *** [arch/arm/boot/compressed/head.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2
make: *** [uImage] Error 2
-- john
Hello everyone,
In the spirit of reaching out to the Linaro community, I'd like to
engage in some conversation with those working on the HardFP ABI switch
and toolchain effort, since we will shortly be doing the same in the
Fedora ARM community. The intention is to support hardfp in time for the
Fedora 15 ARM release, which *will* lag behind the x86 F-15 release.
Anyway. I could do with some pointers to the current state of things,
and who I should talk to and engage with at the LDS in another week. I
will be there representing the Fedora ARM community. And I look forward
to meeting those of you who don't already know me from other lives ;)
Jon.
Nicolas, Andy,
I see that Andy's stuff went into linux-linaro-2.6.38 earlier. What
new CONFIG_'s do I need to turn on in the packaged kernel to ensure we
get all the fabulous new stuff enabled?
Thanks,
John
Hi,
notes and actions from our Wednesday graphics working group call are
available on the wiki:
+ https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-04-27
Details about when and where of this meeting can be found here:
+ https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2…
Summary
=======
* LDS demo poster finalized.
* kwin
* Packages done and available for ARM platforms.
* Tested on imx51 (\o/), to be tested on pandaboard.
* chromium-wm: build/packaging has begun.
* Furious preparation for memory management mini-summit.
* nux: cairo-gles work being leveraged for dispatch method and texture wrap solution.
* GLEW-gles published on git.linaro.org and out for review.
Thanks,
--
- Alexandros
Jan Seiffert has been looking into vectorising the adler32 routine in
zlib. On the A9 there's a 3.0 x improvement to be had on blocks that
fit in the L1 cache and a 2.1 x improvement for larger blocks.
See:
http://mail.madler.net/pipermail/zlib-devel_madler.net/2011-May/002556.html
for the work in progress.
-- Michael
---------- Forwarded message ----------
From: Michael Hope <michael.hope(a)linaro.org>
Date: Mon, May 2, 2011 at 10:35 AM
Subject: Re: [Zlib-devel] [3/8][RFC V3 Patch] Add special ARM Adler32 version
To: zlib-devel(a)madler.net
On Mon, May 2, 2011 at 9:48 AM, Jan Seiffert
<kaffeemonster(a)googlemail.com> wrote:
> 2011/4/24 Jan Seiffert <kaffeemonster(a)googlemail.com>:
>> This adds an NEON version, a iWMMXt version for Intel (now Marvel)
>> StrongARM and a version for ARMv6 DSP instructions of Adler32.
>>
>
> Thanks again to Edwin Török the NEON and ARMv6 DSP version are now
> tested and fixed.
>
> The good news is NEON:
> an i.MX515@800MHz (arm7l) with NEON
> -------- orig ------
> a: 0x0CB4B676, 10000 * 160000 bytes t: 4010 ms
> a: 0x25BEB273, 10000 * 159999 bytes t: 2990 ms
> a: 0x733CB174, 10000 * 159998 bytes t: 4060 ms
> a: 0x1144AF76, 10000 * 159996 bytes t: 4050 ms
> a: 0x3F4ECB8A, 10000 * 159992 bytes t: 4060 ms
> a: 0x1902A382, 10000 * 159984 bytes t: 4060 ms
> -------- vec ------
> a: 0x0CB4B676, 10000 * 160000 bytes t: 1450 ms
> a: 0x25BEB273, 10000 * 159999 bytes t: 1450 ms
> a: 0x733CB174, 10000 * 159998 bytes t: 1460 ms
> a: 0x1144AF76, 10000 * 159996 bytes t: 1450 ms
> a: 0x3F4ECB8A, 10000 * 159992 bytes t: 1460 ms
> a: 0x1902A382, 10000 * 159984 bytes t: 1450 ms
> speedup: 2.765517
Hi Jan. I see similar numbers. I wasn't sure what you were using to
benchmark this so I wrote my own little stub that did the
seed=0x0CB4B676 version over data from rand(). I ran each test five
times and picked the lowest user time as the best. All were built
with gcc-linaro-4.5-2011.04 with -mfpu=neon -mtune=cortex-a9. The
results were:
Cortex-A9 @ 1 GHz:
Plain C: 4.094 s
ARMv6: 4.578 s
NEON: 1.985 s
Cortex-A8 @ 720 MHz:
Plain C: 4.164 s
NEON: 1.819 s
NEON: 1.570 s (with -mtune=cortex-a8)
It's interesting how the slower A8 does better than the A9. It's
probably due to the A8 having wider access to the L2 cache as running
the same test but on 16 k of data so that it fits in the L1 cache
gives:
Cortex-A8: 5.234 s
Cortex-A9: 3.969 s
The ratio here is 0.760 which is very similar to the ratio between the
clock frequencies.
-- Michael