This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I think I am missing something.
If arm-elf (linked against newlib) takes less space
than arm-linux (linked against glibc) what's the point in
using
arm-linux ?.
The arm-linux target is a ARM-system which uses Linux as its opsys.
The arm-elf (as default) target is a ARM-system which uses the Angel-monitor firmware on the target board.
In the 1st case the apps communicate through the Linux kernel (syscalls) with the hardware, in the 2nd case with the monitor services ('traps' etc.)
But generally the glue routines (low-level I/O, memory handling etc.) could also be for something 'local', but in the arm-elf case they are integrated into the standard C library which is basically wrong. In the Linux case integrating them to the C library is then right because the interface between Linux/ARM and the application has been standardized. As the 'elf' could hint, the target one is aiming to, maybe isn't very 'real'...
The 'glue' parts in newlib could really be for Linuces too. There is a port for SVR3/i386 (in 'newlib/libc/sys/sysvi386') but not anything similar for any Linux. The Linux/x86 port in newlib is something really weird. Anyway it should be possible to extend those '*-elf' ports in newlib for their equivalent '*-linux' targets by simply providing those glue libraries for these. But surprisingly no public tries has been seen... I did this for SVR4/x86/ELF, the existing SVR3/x86/COFF port was a very good starting point because these are quite similar what becomes to the startups etc. Meanwhile trying to find out the structure in the Linux-syscalls was much harder, the Linux-startup in glibc expects something from glibc, there aren't so much docs for Linux as there are for the SVR4 ABI and such... So porting newlib for the mostly undocumented Linux (at least when I tried these things) can be very hard unless one is one of the glibc-developers.
I suppose that those using arm-elf
will have to pay a toll for an executable that does
the same but occupies much
less space. Otherwise, everyone would use arm-elf.
Yes, it is true that using newlib for arm-elf with glue routines for arm-linux could enable one to produce simple apps for Linux/ARM. But this really means 'simple', getting a C library for Linux which is based on newlib, ie. reinventing everything which is now included into glibc, will be a huge task. For instance there aren't much network support in newlib, not much termcap/terminfo, curses etc. usual Unix 'text-based' apps support either... Getting the "Hello World" running doesn't help much.
Which are the pros and cons of using arm-elf ?.
The board I will use will be running linux.
Then your C library choices can be glibc or the uclibc if the ucLinux is also acceptable... Other surely know more about the alternatives for glibc with Linux/ARM, if there really are any. Maybe ucLinux is one more alternative for Linux with its own kernel, C library and such...
I may choose either an atmel at91rm9200-dk board (processor: arm920t) or a sharp lh7a400 (processor: arm922t) Both boards can handle up to 64MB of SDRAM.
What would you recommend me to use arm-linux or arm-elf ?.
You already froze your choice to be Linux instead of a no-opsys board. Or not ucLinux or something else...
Maybe you should ask whether NetBSD/ARM could be better than Linux/ARM, they both are for embedded-Unix-like systems... Just check what NetBSD nowadays supports in ARM boards and if there are any comparisons between Linux and NetBSD for their footprints, ie. which one requires less space in some purposes... Ok, 'http://www.netbsd.org' will lead you to the NetBSD pages and basically NetBSD can called as 'real Unix' because the Berkeley guys (like Bill Joy, the writer of many Unix tools like 'vi') have influenced Unix so much, meanwhile Linux is only one Unix-clone more, just like Mark Williams 'Coherent', Whitesmiths 'Idris' etc. were long before it... So asking whether Unix could be better than Linux in your case is also reasonable. In the late 80's and early 90's people used to do similar things with 'embedded' and 'real-time' Unices as what is done with Linux nowadays... I remember some German company using NetBSD instead of Linux in their network-controlled laser printer recently. Hmmm, what opsys was used in that yankee TiVo "hard-disk video recorder", wasn't it something else than Linux?
Anyway I would like to see some comparisons between Linux/ARM and NetBSD/ARM in the embedded cases...
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |