Re: Instructions cache flush on ARM (was: N800 Video playback)
On Mon, 2007-04-23 at 21:09:26 +0300, ext Siarhei Siamashka wrote: On Monday 23 April 2007 16:49, Guillem Jover wrote: You are right. gcc has function void __clear_cache (char *BEG, char *END) which should be more portable. It should, but it still has the problem of emitting an OABI syscall due to our old gcc. You could use syscall(2) and __ARM_NR_cacheflush instead. Yes, but __clear_cache(char *BEG, char *END) works fine with the current combination of gcc and kernel in maemo. So I guess it's the best option if portability is desired. That it works fine now does not mean it's the correct solution. Also I disagree on the premise that it's more portable, both solutions are quite non-portable, either you'll have to check if that function is present in autoconf or similar, or you'll have to check for the presence of the syscall NR on arm. If you decide to drop support for old ABI from kernel without upgrading gcc, that would be a bug in maemo platform :-) No, because as this is coming from gcc it gets embedded in the actual object, so it would need a recompilation, I wouldn't say that's a bug in maemo, you have hardcoded OABI calls in your object files. Also that makes it more difficult for people to flash their own new kernel. regards, guillem ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Instructions cache flush on ARM (was: N800 Video playback)
2007/4/23, Siarhei Siamashka [EMAIL PROTECTED]: Thanks, it works. But I'm worried about [1]. Looks like EABI has a new syscall interface and this code from qemu uses old ABI. And from reading description at the wiki page, compatibility with old ABI can be disabled (and it makes sense disabling it as this compatibility reduces performance a bit). You are right. gcc has function void __clear_cache (char *BEG, char *END) which should be more portable. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Instructions cache flush on ARM (was: N800 Video playback)
On Mon, 2007-04-23 at 16:11:17 +0800, ext 黄涛 wrote: 2007/4/23, Siarhei Siamashka [EMAIL PROTECTED]: Thanks, it works. But I'm worried about [1]. Looks like EABI has a new syscall interface and this code from qemu uses old ABI. And from reading description at the wiki page, compatibility with old ABI can be disabled (and it makes sense disabling it as this compatibility reduces performance a bit). You are right. gcc has function void __clear_cache (char *BEG, char *END) which should be more portable. It should, but it still has the problem of emitting an OABI syscall due to our old gcc. You could use syscall(2) and __ARM_NR_cacheflush instead. regards, guillem ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Instructions cache flush on ARM (was: N800 Video playback)
On Monday 23 April 2007 16:49, Guillem Jover wrote: You are right. gcc has function void __clear_cache (char *BEG, char *END) which should be more portable. It should, but it still has the problem of emitting an OABI syscall due to our old gcc. You could use syscall(2) and __ARM_NR_cacheflush instead. Yes, but __clear_cache(char *BEG, char *END) works fine with the current combination of gcc and kernel in maemo. So I guess it's the best option if portability is desired. If you decide to drop support for old ABI from kernel without upgrading gcc, that would be a bug in maemo platform :-) By the way, do you have any plans for upgrading toolchain? Either I'm extremely unlucky, or current toolchain is really very buggy. It does not support -pg option properly (for profiling with gprof), also I encountered at least one internal compiler error and a couple of invalid code generation bugs already. One more question is about the kernel, ARM11 seems to support unaligned memory access in hardware, but this feature is not enabled on N800. Is it done for consistency with Nokia 770? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Instructions cache flush on ARM (was: N800 Video playback)
On Friday 20 April 2007 19:04, you wrote: I have seen your code in xserver which does the same job for downscaling, but in nonoptimized C and with much higher impact on quality. Using JIT scaler there can improve both image quality and performance a lot. The only my concern is about instruction cache coherency. As ARM requires explicit instructions cache flush for self modyfying or dynamically generated code, I wonder if using just mmap is safe (does it flush cache for allocated region of memory?). Maybe maemo kernel hackers/developers can help with this information? arm linux support flush icache by syscall cacheflush, qemu have this function: static inline void flush_icache_range(unsigned long start, unsigned long stop) { register unsigned long _beg __asm (a1) = start; register unsigned long _end __asm (a2) = stop; register unsigned long _flg __asm (a3) = 0; __asm __volatile__ (swi 0x9f0002 : : r (_beg), r (_end), r (_flg)); } you can reference kernel source arch/arm/kernel/traps.c and include/asm-arm/unistd.h Thanks, it works. But I'm worried about [1]. Looks like EABI has a new syscall interface and this code from qemu uses old ABI. And from reading description at the wiki page, compatibility with old ABI can be disabled (and it makes sense disabling it as this compatibility reduces performance a bit). I wonder if there is a better portable solution (running on any ARM linux or even better on any POSIX compatible system). It would be reasonable to assume that allocating memory with mmap implies that we are going to execute code from that area and instructions cache should be flushed for it: mmap(0, some_buffer_size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); But I wonder if mmap requesting executable block of memory really does instructions cache flush in reality? I just want to submit this ARM optimized scaler to upstream ffmpeg and want to make it as portable as possible. 1. http://wiki.debian.org/ArmEabiPort#head-96054c6cb4209b4a589e645dd50ac0fe133b8ced ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers