Hi Jin,
Sergey 'Jin' Bostandzhyan wrote:
I've been using Linux on ARM9 for quite a while, but now a customer
wants uClinux. I scouted the net for information, however there are still some
missing bits and pieces and I hope that someone can point me in the right
direction.
I read the test results from Hyok S. Choi, who compared uClinux vs. Linux
on ARM9 and I have a question regarding cache flushing on arm926. In the paper
[hyok1] (see references at the end of the mail) it is mentioned that the cache
needs to be flushed on context switches. But the ARM manual[arm1] specifies
the following:
"The caches are virtual index, virtual tag, addressed using the Modified
Virtual Address (MVA). This enables the avoidance of cache cleaning and/or
invalidating on context switch."
Whereas information about the MVA can be found in [arm2][arm3]:
"The VA is translated using the FCSE PID value to the MVA. The Instruction
Cache (ICache) and Memory Management Unit (MMU) detect the MVA
(see Process ID Register c13)."
So is it possible that the recent ARM cores now include a notion of process id,
which seriously improves cache performance on context switches. And as a
consequence the results in [hyok1] might not be reproducible?
You might get a better answer on this specific topic on the ARM linux
kernel mailing list.
There has been patches over the years to use the FCSE PID bits in
VM linux to avoid flushing on every context switch (FASS for example)
but as far as I can tell none have ever been accepted to mainline.
There has always been some downside implications for using them
(reduced VM address space for example).
So currently I beleive that Hyok's results are still valid.
Ofcourse there is downsides to using uClinux as well. The memory
allocation/fragmentation problems are more severe. On many ARM
based cores you must having paging enabled to be able to use any
data cache. Not to mention issues with XIP and shared libs, etc.
Another question - about shared flat libraries. Is it correct that there is
no shared flat support for ARM yet? From what I saw the -mid-shared-library
gcc option is not available for ARM, is there any workaround? I found a
one year old post about this on the mailing list, it seems that someone was
planning to do some work on this, but I did not find any conclusive results.
The RidgeRun guys released their xflat support for shared libs on ARM:
http://www.xflat.org
That is the only implemenation for ARM that I know of.
And a question regarding the toolchain: can I build for uclinux using
a "normal" arm-uclibc-gnueabi toolchain and postprocess the output with elf2flt,
or is a "special" toolchain required?
I looked at the arm-2007q3-51-arm-uclinuxeabi csl toolchain, they added
uclinux-eabi while the vanilla gcc only provides uclinux-elf. Does that mean
that I can not build for uclinux eabi using vanilla gcc? Actually, this leads
back to the previous question, if a "special" toolchain is needed or if I
can work with vanilla gcc toolchain compiled for arm eabi and what is this
uclinux-elf configuration?
I use a standard arm-linux toolchain for ARM uclinux development.
This is the one I use:
http://ftp.snapgear.org/pub/snapgear/tools/arm-linux/arm-linux-tools-20061213.tar.gz
build instructions:
http://ftp.snapgear.org/pub/snapgear/tools/arm-linux/build-arm-linux-3.4.4
It is just a standard arm-linux toolchain (support big and little-endian
targets) augmented with elf2flt).
I don't use XIP or shared libs for arm non-mmu development though.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
