Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Jamie Lokier wrote: > On uClinux with no MMU, you have to use FLT format (all architectures > support this I think) or FDPIC-ELF (just a few architectures support > this, the advantage is proper shared libraries and loadable modules). FRV does not support FLAT format, only FDPIC-ELF. David ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Dear Greg: > > It is not extracted, it is mounted and used "in-place" > using the MTD uclinux.c map driver. It is a RAM based > MTD setup. I can duplicate the result on skyeye as you do and I can see my console output finally. Thanks everyone's kind help in the past week :-) right I am trying to find out why it cost 5 mints between *1 and *2. I guess maybe my system timer duration is too long. appreciate your kind help, miloody GDB/ARMulator support by For further information check: http://www.uclinux.org/ Execution Finished, Exiting -*1 BINFMT_FLAT: ROM mapping of file (we hope) BINFMT_FLAT: Allocated data+bss+stack (21544 bytes): 83e08004 p=83e0fffc start_thread(regs=0x83c33fb0, entry=0x83e40044, start_stack=0x83e0ff98) Sash command shell (version 1.1.1) /> ---*2 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Hi Loody, loody wrote: 11. cp . Dear Greg: Everything seems fine before step 11. I am trying to find where or how to generate the conf. Here is what I use: cpu: arm7tdmi mach: at91 mem_bank: map=M, type=RW, addr=0x, size=0x4000 mem_bank: map=M, type=RW, addr=0x0100, size=0x0040 mem_bank: map=M, type=R, addr=0x0140, size=0x0040, file=boot.rom mem_bank: map=M, type=RW, addr=0x0200, size=0x0040 mem_bank: map=M, type=RW, addr=0x0240, size=0x8000 mem_bank: map=M, type=RW, addr=0x0400, size=0x0040 mem_bank: map=I, type=RW, addr=0xf000, size=0x1000 lcd: state=off BTW, I previously hand made root file system and pass it to the kernel which I configured as supporting initramfs. But after seeing what uclinux done for me, I feel my method is pretty ugly. I search the romfs on the net and most of them tell me what the format it is. And the inode.c in fs/romfs is used to handle extract. But I have no idea how kernel extracts the boot.rom and put it to the rootfs. appreciate your help, It is not extracted, it is mounted and used "in-place" using the MTD uclinux.c map driver. It is a RAM based MTD setup. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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 uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
> 11. cp . Dear Greg: Everything seems fine before step 11. I am trying to find where or how to generate the conf. BTW, I previously hand made root file system and pass it to the kernel which I configured as supporting initramfs. But after seeing what uclinux done for me, I feel my method is pretty ugly. I search the romfs on the net and most of them tell me what the format it is. And the inode.c in fs/romfs is used to handle extract. But I have no idea how kernel extracts the boot.rom and put it to the rootfs. appreciate your help, miloody ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote:
What target did you use as your base for this?
(What I really want to know is what is set in the
config.arch file).
Regards
Greg
Dear Greg:
I use GDB/armulator.
attach the config and config.arch for your reference.
Thanks for your help,
Here is what I did:
1. downloaded uClinux-dist-20080808.tar.gz
2. downloaded arm-linux-tools-20061213.tar.gz
3. mkdir user/hello
4. vi user/hello/hello.c and put in it:
int main()
{
printf("hello world\n");
}
5. vi user/hello/Makefile and put in it:
all: hello
romfs:
$(ROMFSINST) /bin/hello
clean:
-rm -f hello *.elf *.gdb *.o
6. vi user/Kconfig, adding in the "Miscellaneous Applications section:
config USER_HELLO_HELLO
bool "hello"
7. vi user/Makefile, adding in a line:
dir_$(CONFIG_USER_HELLO_HELLO) += hello
8. configured uClinux-dist to build "GDB/ARMulator" selecting to
use a linux-2.6.x kernel, and selected the new "hello" program
for inclusion as well
9. make
10. cd images
11. cp .
12. run "skyeye -e linux" and see:
Your elf file is little endian.
arch: arm
cpu info: armv3, arm7tdmi, 41007700, fff8ff00, 0
mach info: name at91, mach_init addr 0x4189a0
uart_mod:0, desc_in:, desc_out:, converter:
SKYEYE: use arm7100 mmu ops
Loaded ROM boot.rom
exec file "linux"'s format is elf32-little.
load section .text.head: addr = 0x01008000 size = 0x0190.
load section .init: addr = 0x010081a0 size = 0xee60.
load section .text: addr = 0x01017000 size = 0x000ce870.
not load section .rodata: addr = 0x010e6000 size = 0x .
not load section .pci_fixup: addr = 0x010e6000 size = 0x .
not load section .rio_route: addr = 0x010e6000 size = 0x .
not load section __ksymtab: addr = 0x010e6000 size = 0x .
not load section __ksymtab_gpl: addr = 0x010e6000 size = 0x .
not load section __ksymtab_unused: addr = 0x010e6000 size = 0x .
not load section __ksymtab_unused_gpl: addr = 0x010e6000 size =
0x .
not load section __ksymtab_gpl_future: addr = 0x010e6000 size =
0x .
not load section __kcrctab: addr = 0x010e6000 size = 0x .
not load section __kcrctab_gpl: addr = 0x010e6000 size = 0x .
not load section __kcrctab_unused: addr = 0x010e6000 size = 0x .
not load section __kcrctab_unused_gpl: addr = 0x010e6000 size =
0x .
not load section __kcrctab_gpl_future: addr = 0x010e6000 size =
0x .
load section __param: addr = 0x010e6000 size = 0x1000.
load section .data: addr = 0x010e8000 size = 0x9f98.
not load section .bss: addr = 0x010f1fa0 size = 0x8f20 .
not load section .comment: addr = 0x size = 0x13b0 .
call ARMul_InitSymTable,kernel filename is linux.
start addr is set to 0x01008000 by exec file.
Linux version 2.6.25-uc0 (g...@goober) (gcc version 3.4.4) #2 Fri Jan 30
21:38:07 EST 2009
CPU: Atmel-AT91M40xxx [1440] revision 0 (ARMvundefined/unknown),
cr=
Machine: Atmel AT91 EB01
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line:
PID hash table entries: 64 (order: 6, 256 bytes)
console [ttyS0] enabled
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 16MB = 16MB total
Memory: 15268KB available (832K code, 75K data, 60K init)
Mount-cache hash table entries: 512
io scheduler noop registered (default)
Atmel USART driver version 0.99
ttyS0 at 0xfffd (irq = 2) is a builtin Atmel APB USART
ttyS1 at 0xfffcc000 (irq = 3) is a builtin Atmel APB USART
brd: module loaded
uclinux[mtd]: RAM probe address=0x140 size=0x103000
Creating 1 MTD partitions on "ROM":
0x-0x00103000 : "ROMfs"
uclinux[mtd]: set ROMfs to be root filesystem
VFS: Mounted root (romfs filesystem) readonly.
Freeing init memory: 60K
Shell invoked to run file: /etc/rc
Command: hostname GDB-ARMulator
Command: /bin/expand /etc/ramfs.img /dev/ram0
Command: mount -t proc proc /proc
Command: mount -t ext2 /dev/ram0 /var
Command: mkdir /var/tmp
Command: mkdir /var/log
Command: mkdir /var/run
Command: mkdir /var/lock
Command: mkdir /var/empty
Command: cat /etc/motd
Welcome to
_ _
/ __| ||_|
_ _| | | | _ _ _ _ _
| | | | | | || | _ \| | | |\ \/ /
| |_| | |__| || | | | | |_| |/\
| ___\|_||_|_| |_|\|\_/\_/
| |
|_|
GDB/ARMulator support by
For further information check:
http://www.uclinux.org/
Execution Finished, Exiting
Sash command shell (version 1.1.1)
/>
13. from the command line I run "hello":
/> hello
hello world
/>
All seems to work...
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Wool
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
> What target did you use as your base for this? > (What I really want to know is what is set in the > config.arch file). > > Regards > Greg Dear Greg: I use GDB/armulator. attach the config and config.arch for your reference. Thanks for your help, miloody .config Description: Binary data config.arch Description: Binary data ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
> On Thu, Jan 29, 2009 at 06:12:15AM +, Jamie Lokier wrote: >> I wouldn't be surprised if the Codesourcery tools (especially >> pre-built libs) are targetting later ARM chips only, since people >> using later ARM chips are probably paying Codesourcery for the work. > > Our tools support all (post-V4) ARM processors; I believe that we > package libraries for all processors too nowadays. The defaults may > be fairly modern, though - so as Jamie said, be sure to tell the tools > what you want your code to run on! Hi: If I guess correctly, the compile option is determined by 2 parts. 1. my config 2. Makefile, which will use call function to ask compiler what he support or not. In my case, 1 is the same both on Codesourcery and arm-linux-2006. 2 is determined by compiler itself. I don't under compiler at all but is that possible the same option in different gcc will produce different object code? appreciate your kind help, miloody ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Hi Loody,
loody wrote:
2009/1/29 Greg Ungerer :
Hi Loody,
loody wrote:
Why is only supporting FLAT a problem for you?
(It is not entirely true to say uClinux only supports FLAT,
some uClinux architectures support fdelf-pic).
Sorry for using the word, ONLY. Tears will make the screen blur, you
know. :-(
I don't know how to make a flat with the arm-linux compiler linked
from uclinux.org. You can see it in the previous letter.
That is why I said to get the uClinux-dist.
It builds applications with that compiler against its
own uClibc. They work. I specifically test it for the
GDB/ARMulator target before uClinux-dist releases.
According all your suggestions, I stop trying to use different
cross-toolchains except
1. arm-linux-tools-20061213.tar.gz
2. arm-linux-tools-20070808.tar.gz
And I try to use both of them to compile applications at user.
2 can get the FLAT I need but 1 will fail while calling the linker and it
says
ld.real: address 0x22380 of busybox_unstripped.gdb section .text is
not within region flatmem
Please give details.
How exactly did you try to build these?
Standalone or in the uClinux-dist framework?
What where the compile lines?
More details please?
In the uClinux-dist framework, please see the attach file,
arm-linux-gcc_2006_link_error.log.
What target did you use as your base for this?
(What I really want to know is what is set in the
config.arch file).
Regards
Greg
So I wipe my tears out and recompile the kernel with 2 happily :)
but tears full fill my eyes again when my platform get
unknown-instruction-exception, while executing below instructions:
e1a0e00fmov lr, pc
e12fff13bx r3
:-(~~~
Details?
Is part of the kernel, or app?
Is part of kernel:
80008b74 :
80008b74: e1a0c00dmov ip, sp
80008b78: e92dd870stmdb sp!, {r4, r5, r6, fp, ip, lr, pc}
80008b7c: e24cb004sub fp, ip, #4 ; 0x4
80008b80: e24dd008sub sp, sp, #8 ; 0x8
80008b84: e59f0414ldr r0, [pc, #1044] ; 80008fa0 <.init+0xc00>
80008b88: eb003ddcbl 80018300
80008b8c: e59f3410ldr r3, [pc, #1040] ; 80008fa4 <.init+0xc04>
80008b90: e1a0e00fmov lr, pc
---> here it is
80008b94: e12fff13bx r3
80008b98: e59f0408ldr r0, [pc, #1032] ; 80008fa8 <.init+0xc08>
80008b9c: eb003dd7bl 80018300
80008ba0: e59f0404ldr r0, [pc, #1028] ; 80008fac <.init+0xc0c>
80008ba4: eb003dd5bl 80018300
80008ba8: e59f0400ldr r0, [pc, #1024] ; 80008fb0 <.init+0xc10>
80008bac: eb003dd3bl 80018300
80008bb0: e59f03fcldr r0, [pc, #1020] ; 80008fb4 <.init+0xc14>
80008bb4: eb003dd1bl 80018300
80008bb8: e10f3000mrs r3, CPSR
80008bbc: e3833080orr r3, r3, #128; 0x80
Thanks for your help,
miloody
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company 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
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Daniel Jacobowitz wrote:
> On Thu, Jan 29, 2009 at 06:12:15AM +, Jamie Lokier wrote:
> > I wouldn't be surprised if the Codesourcery tools (especially
> > pre-built libs) are targetting later ARM chips only, since people
> > using later ARM chips are probably paying Codesourcery for the work.
>
> Our tools support all (post-V4) ARM processors; I believe that we
> package libraries for all processors too nowadays. The defaults may
> be fairly modern, though - so as Jamie said, be sure to tell the tools
> what you want your code to run on!
ARM has a huge number of instruction set variants. This is a quick
guess, I'm no expert (but I've already been daunted when looking into
ARM FDPIC-ELF, simply at the number of different ways jumps and calls
are encoded)):
{ OABI, EABI soft-float, EABI hard-float }
times
{ ARMv4, ARMv4T, ARMv5, ARMv6, ARMv7 (?) }
times
{ not Thumb, Thumb, Thumb2 }
times
{ Thumb interwork or not }
times
{ non-PIC, PIC, PIC+single-pic-base }
Do you really have a policy of including pre-built multilib-ed libc
and libstdc++ as well as libgcc for all the combinations that make
sense?
My approach these days is to build all libraries including libgcc
specifically targetted at the CPU variant being used by whatever
projected I'm using. It saves headaches from things that crash
spontaneously otherwise. I haven't tried the Codesourcery ARM tools
yet, though I intended to soon.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
> make[2]: Entering directory `/home/cc/Desktop/temp/uClinux-dist/user/busybox' > LINKbusybox_unstripped^M > Trying libraries: crypt m^M > Failed: -Wl,--start-group -lcrypt -lm -Wl,--end-group > Output of: > ucfront-gcc arm-linux-gcc -Os -g -pipe -msoft-float -fno-common -fno-builtin > -Wall -DEMBED -D__PIC__ -fpic -msingle-pic-base -Dlinux -D__linux__ -Dunix ^ > -D__uClinux__ -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes Those are the flags for XIP. Can you turn off XIP? I've had problems on ARM-nommu with XIP and some toolchains, possibly the one you're using. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote: > 2009/1/29 Jamie Lokier : > > loody wrote: > >>e1a0e00fmov lr, pc > >>e12fff13bx r3 > > Actually my cpu get exception when executing this instruction not bx r3. > But lr is the destination for cpu to write, I have checked the arm > reference and it doesn't say any cautions when the destination is lr. You're right, that doesn't make sense to me either. > > "bx" is not available on all ARMs, and will fault when you don't have > > it. That's why it's necessary to build everything with the right GCC > > options. > > There are bx instructions generated when I use arm-linux-2006. > > BTW, can I take off the Thumb support in my compiler options? > Thumb is only used for decreasing the density of source code and so > far I just want my kernel say hello to me. At this point, you may want to subscribe to the linux-arm mailing list, and ask the question again there :-) http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
2009/1/29 Jamie Lokier :
> loody wrote:
>>e1a0e00fmov lr, pc
>>e12fff13bx r3
>
>> What is the specialty of the instruction, "mov lr,pc", which let
>> arm cpu fail?
>
> Both of those instructions can put the CPU into Thumb mode. If it
> doesn't support Thumb, you get an instruction fault.
>
> "mov lr,pc" is supported on all ARMs, but (guessing from what you're
> getting) maybe it can fault depending on the value in "lr"?
Hi:
I cannot understand the meaning of depending the value in "lr"?
Actually my cpu get exception when executing this instruction not bx r3.
But lr is the destination for cpu to write, I have checked the arm
reference and it doesn't say any cautions when the destination is lr.
>
> "bx" is not available on all ARMs, and will fault when you don't have
> it. That's why it's necessary to build everything with the right GCC
> options.
There are bx instructions generated when I use arm-linux-2006.
I list them below:
800096a0 <__kuser_helper_start>:
800096a0: e12fff1ebx lr
...
800096c0 <__kuser_cmpxchg>:
800096c0: e3e0mvn r0, #0 ; 0x0
800096c4: e290addsr0, r0, #0 ; 0x0
800096c8: e12fff1ebx lr
...
800096e0 <__kuser_get_tls>:
800096e0: ee1d0f70mrc 15, 0, r0, cr13, cr0, {3}
800096e4: e12fff1ebx lr
BTW, can I take off the Thumb support in my compiler options?
Thumb is only used for decreasing the density of source code and so
far I just want my kernel say hello to me.
appreciate your help,
miloody
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
2009/1/29 Greg Ungerer :
> Hi Loody,
>
> loody wrote:
>>>
>>> Why is only supporting FLAT a problem for you?
>>> (It is not entirely true to say uClinux only supports FLAT,
>>> some uClinux architectures support fdelf-pic).
>>
>> Sorry for using the word, ONLY. Tears will make the screen blur, you
>> know. :-(
>>
>>>
I don't know how to make a flat with the arm-linux compiler linked
from uclinux.org. You can see it in the previous letter.
>>>
>>> That is why I said to get the uClinux-dist.
>>> It builds applications with that compiler against its
>>> own uClibc. They work. I specifically test it for the
>>> GDB/ARMulator target before uClinux-dist releases.
>>>
>>
>> According all your suggestions, I stop trying to use different
>> cross-toolchains except
>> 1. arm-linux-tools-20061213.tar.gz
>> 2. arm-linux-tools-20070808.tar.gz
>>
>> And I try to use both of them to compile applications at user.
>> 2 can get the FLAT I need but 1 will fail while calling the linker and it
>> says
>> ld.real: address 0x22380 of busybox_unstripped.gdb section .text is
>> not within region flatmem
>
> Please give details.
> How exactly did you try to build these?
> Standalone or in the uClinux-dist framework?
> What where the compile lines?
> More details please?
In the uClinux-dist framework, please see the attach file,
arm-linux-gcc_2006_link_error.log.
>> So I wipe my tears out and recompile the kernel with 2 happily :)
>> but tears full fill my eyes again when my platform get
>> unknown-instruction-exception, while executing below instructions:
>>
>> e1a0e00fmov lr, pc
>> e12fff13bx r3
>>
>> :-(~~~
>
> Details?
> Is part of the kernel, or app?
Is part of kernel:
80008b74 :
80008b74: e1a0c00dmov ip, sp
80008b78: e92dd870stmdb sp!, {r4, r5, r6, fp, ip, lr, pc}
80008b7c: e24cb004sub fp, ip, #4 ; 0x4
80008b80: e24dd008sub sp, sp, #8 ; 0x8
80008b84: e59f0414ldr r0, [pc, #1044] ; 80008fa0 <.init+0xc00>
80008b88: eb003ddcbl 80018300
80008b8c: e59f3410ldr r3, [pc, #1040] ; 80008fa4 <.init+0xc04>
80008b90: e1a0e00fmov lr, pc
---> here it is
80008b94: e12fff13bx r3
80008b98: e59f0408ldr r0, [pc, #1032] ; 80008fa8 <.init+0xc08>
80008b9c: eb003dd7bl 80018300
80008ba0: e59f0404ldr r0, [pc, #1028] ; 80008fac <.init+0xc0c>
80008ba4: eb003dd5bl 80018300
80008ba8: e59f0400ldr r0, [pc, #1024] ; 80008fb0 <.init+0xc10>
80008bac: eb003dd3bl 80018300
80008bb0: e59f03fcldr r0, [pc, #1020] ; 80008fb4 <.init+0xc14>
80008bb4: eb003dd1bl 80018300
80008bb8: e10f3000mrs r3, CPSR
80008bbc: e3833080orr r3, r3, #128; 0x80
Thanks for your help,
miloody
arm-linux-gcc_2006_link_error.log
Description: Binary data
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Hi Loody, loody wrote: Why is only supporting FLAT a problem for you? (It is not entirely true to say uClinux only supports FLAT, some uClinux architectures support fdelf-pic). Sorry for using the word, ONLY. Tears will make the screen blur, you know. :-( I don't know how to make a flat with the arm-linux compiler linked from uclinux.org. You can see it in the previous letter. That is why I said to get the uClinux-dist. It builds applications with that compiler against its own uClibc. They work. I specifically test it for the GDB/ARMulator target before uClinux-dist releases. According all your suggestions, I stop trying to use different cross-toolchains except 1. arm-linux-tools-20061213.tar.gz 2. arm-linux-tools-20070808.tar.gz And I try to use both of them to compile applications at user. 2 can get the FLAT I need but 1 will fail while calling the linker and it says ld.real: address 0x22380 of busybox_unstripped.gdb section .text is not within region flatmem Please give details. How exactly did you try to build these? Standalone or in the uClinux-dist framework? What where the compile lines? More details please? So I wipe my tears out and recompile the kernel with 2 happily :) but tears full fill my eyes again when my platform get unknown-instruction-exception, while executing below instructions: e1a0e00fmov lr, pc e12fff13bx r3 :-(~~~ Details? Is part of the kernel, or app? Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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 uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote: >e1a0e00fmov lr, pc >e12fff13bx r3 > What is the specialty of the instruction, "mov lr,pc", which let > arm cpu fail? Both of those instructions can put the CPU into Thumb mode. If it doesn't support Thumb, you get an instruction fault. "mov lr,pc" is supported on all ARMs, but (guessing from what you're getting) maybe it can fault depending on the value in "lr"? "bx" is not available on all ARMs, and will fault when you don't have it. That's why it's necessary to build everything with the right GCC options. I wouldn't be surprised if the Codesourcery tools (especially pre-built libs) are targetting later ARM chips only, since people using later ARM chips are probably paying Codesourcery for the work. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote:
> When I use "-Wl,-elf2flt,-s32768" to compile my hellow.c.
It should say "-wL,-elf2flt=-s32768". Note the "=" (equal sign).
> b.
> When I use "-Wl,-elf2flt" to compile my hellow.c.
> it will say:
> arm-linux-uclibcgnueabi/bin/ld.real: error: no memory region specified
> for loadable section `.plt'
> collect2: ld returned 1 exit status
Something's wrong with the GCC options or with libc.
There should be no no ".plt" section when compiling for ARM-nommu.
Use "readelf -hledS hello.elf" (whatever ".elf" file is created by
GCC) to see what sections it has. For your ARM type, it should not
have ".plt" or ".got".
If it's wrong, you can use "-v" with GCC (and all the other options)
to see how it's linking. That might give a clue.
> c.
> so I try to use arm-linux-uclibcgnueabi-elf2flt to meet my requirement.
> And it say:
> TEXT -> vma=0x0 len=0x24
> DATA -> vma=0x0 len=0xc
> ERROR: text=0x24 overlaps data=0x0 ?
Are you running that on a linked ELF _executable_ (a.out) or an ELF
object file (*.o)? Looks like a *.o to me.
> it seems i need to modify some file to fix b and c. But I cannot find
> any config about elf2flt.
You should never run elf2flt yourself. Always let GCC do it.
> And it seems ALMOST work.
>
> ALMOST means I can see the kernel message says
> "tart_thread(regs=0x83c15ef8, entry=0x83d60044,
> start_stack=0x83d6ffb0)"
> but I cannot see the "hello" that I am looking for.
To some extent, the toolchain's uClibc must match the kernel you're
using, too.
> 1. I guess the reason why I cannot see the "hello" from console is due
> to some lib I have to put at root file system/lib. But I don't know is
> there any tool like readelf can tell me what lib flt needs? I only can
> do is use "file". But it only can tell me the format not the detail
> information. If someone knows any tool for flt, please let me know.
You can use "readelf" on the "a.out.elf" or "hello.elf" file that's
created by GCC. When compiling with "-Wl,elf2flt=-s32768", you get
_two_ output files. One's a flat executable which you run, and the
other ends with ".elf". You can run tools like "readelf" and "nm" and
"nm --dynamic" on the ELF file.
> BTW, is my hello.c too complicate that it fail to print message on console?
> #include
> int main()
> {
> printf("Hello World");
> return 0;
> }
It's fine.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
> Why is only supporting FLAT a problem for you? > (It is not entirely true to say uClinux only supports FLAT, > some uClinux architectures support fdelf-pic). Sorry for using the word, ONLY. Tears will make the screen blur, you know. :-( > > >> I don't know how to make a flat with the arm-linux compiler linked >> from uclinux.org. You can see it in the previous letter. > > That is why I said to get the uClinux-dist. > It builds applications with that compiler against its > own uClibc. They work. I specifically test it for the > GDB/ARMulator target before uClinux-dist releases. > According all your suggestions, I stop trying to use different cross-toolchains except 1. arm-linux-tools-20061213.tar.gz 2. arm-linux-tools-20070808.tar.gz And I try to use both of them to compile applications at user. 2 can get the FLAT I need but 1 will fail while calling the linker and it says ld.real: address 0x22380 of busybox_unstripped.gdb section .text is not within region flatmem So I wipe my tears out and recompile the kernel with 2 happily :) but tears full fill my eyes again when my platform get unknown-instruction-exception, while executing below instructions: e1a0e00fmov lr, pc e12fff13bx r3 :-(~~~ There are 2 ways come to my mind to solve this problem: a. find out why 1 cannot transform the flat successfully and I need someone who familiar with ld to help me. b. check why 2 will make my platform get unknown-instruction-exception. 2, buildroot and Codesourcery-toolchain all will let this happen. I guess the culprit is gcc 4.2x, since 1 use gcc 3.3. Jamie gives me some directions and I am still working on it. Is there any specific compile option in 4.2 and 3.3 will let this happen? What is the specialty of the instruction, "mov lr,pc", which let arm cpu fail? appreciate your help and consolation, miloody ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Quoth loody: > At beginning, I use the combination you suggest, but uclinux makes me > cry when I find that the only executable file format that can run on > uclinux is FLAT. This is because the other file formats rely on the VMM being able to make code/data appear at specific addresses. Without a VMM this isn't possible. > I don't know how to make a flat with the arm-linux compiler linked > from uclinux.org. You can see it in the previous letter. Have a look at the options used to compile any other application that comes with the uClinux-dist, and then use the same options yourself when compiling your own apps. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Hi Loody, loody wrote: You are really making things difficult for yourself to start out. My suggestion, get the uClinux-dist, use the arm-linux compiler linked from uclinux.org. I specifically use the GDB/ARMulator target. Build it "as is" and run it on the Skyeye emulator. Use that as a starting point. Regards Greg Hi: I feel it is too difficult either :-( It doesn't have to be :-) At beginning, I use the combination you suggest, but uclinux makes me cry when I find that the only executable file format that can run on uclinux is FLAT. No need to cry :-) Why is only supporting FLAT a problem for you? (It is not entirely true to say uClinux only supports FLAT, some uClinux architectures support fdelf-pic). I don't know how to make a flat with the arm-linux compiler linked from uclinux.org. You can see it in the previous letter. That is why I said to get the uClinux-dist. It builds applications with that compiler against its own uClibc. They work. I specifically test it for the GDB/ARMulator target before uClinux-dist releases. (GDB/ARMulator target emulates an ATMEL AT91x40 - an ARM7tdmi part). So, I ask for another cross-toolchain's help. I am sure others could pop up and give instructions on compilers and other tools they use. But I use the uClinux-dist with arm-linux tool (from uclinux.org link) to build working arm uclinux systems. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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 uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
> You are really making things difficult for yourself to start out. > > My suggestion, get the uClinux-dist, use the arm-linux compiler > linked from uclinux.org. I specifically use the GDB/ARMulator > target. Build it "as is" and run it on the Skyeye emulator. > Use that as a starting point. > > Regards > Greg > > Hi: I feel it is too difficult either :-( At beginning, I use the combination you suggest, but uclinux makes me cry when I find that the only executable file format that can run on uclinux is FLAT. I don't know how to make a flat with the arm-linux compiler linked from uclinux.org. You can see it in the previous letter. So, I ask for another cross-toolchain's help. Then, I cry ~~~ Thanks for your help, miloody ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Hi Loody,
loody wrote:
I try 2 another cross-toolchains today.
1. buildroot,
2. arm-uclinux, download from Codesourcery.
The transformation of elf to FLAT of them is quite different.
I get help from buildroot maintainer, so I can build buildroot with
elf2flt successfully.
a.
When I use "-Wl,-elf2flt,-s32768" to compile my hellow.c.
it will say:
arm-linux-uclibcgnueabi/bin/ld.real: unrecognized option '-s32768'
arm-linux-uclibcgnueabi/bin/ld.real: use the --help option for usage information
collect2: ld returned 1 exit status
(it seems the ld doesn't recognize the option,-s32768).
b.
When I use "-Wl,-elf2flt" to compile my hellow.c.
it will say:
arm-linux-uclibcgnueabi/bin/ld.real: error: no memory region specified
for loadable section `.plt'
collect2: ld returned 1 exit status
c.
so I try to use arm-linux-uclibcgnueabi-elf2flt to meet my requirement.
And it say:
TEXT -> vma=0x0 len=0x24
DATA -> vma=0x0 len=0xc
ERROR: text=0x24 overlaps data=0x0 ?
it seems i need to modify some file to fix b and c. But I cannot find
any config about elf2flt.
2 can successfully get flt as I need even I don't pass
"-Wl,-elf2flt,-s32768" to it.
( I assigned the -isystem as buildroot lib, since I cannot find
stdio.h in Codesourcery toolchain)
So I use arm-linux to compile uxlinux kernel image and use 2,
Codesourcery toolchain, to compile my hello.c, put hello_flt to the
root file system and let kernel execute it.
And it seems ALMOST work.
ALMOST means I can see the kernel message says
"tart_thread(regs=0x83c15ef8, entry=0x83d60044,
start_stack=0x83d6ffb0)"
but I cannot see the "hello" that I am looking for.
My questions are:
1. I guess the reason why I cannot see the "hello" from console is due
to some lib I have to put at root file system/lib. But I don't know is
there any tool like readelf can tell me what lib flt needs? I only can
do is use "file". But it only can tell me the format not the detail
information. If someone knows any tool for flt, please let me know.
BTW, is my hello.c too complicate that it fail to print message on console?
#include
int main()
{
printf("Hello World");
return 0;
}
2. Does anyone use buildroot and successfully get flt file? If so,
please tell me how to solve a,b,c above?
3. is there any other pre-compiled toolchains I can try? I google the
"arm-elf download", but I cannot get any good result.
appreciate your help,
You are really making things difficult for yourself to start out.
My suggestion, get the uClinux-dist, use the arm-linux compiler
linked from uclinux.org. I specifically use the GDB/ARMulator
target. Build it "as is" and run it on the Skyeye emulator.
Use that as a starting point.
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company 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
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
2009/1/28 Jamie Lokier : > loody wrote: >> "File is not an object file" >> so, it seems I have to make a object relocation file to let this tool, >> arm-linux-elf2flt, work. >> but how? > > Don't use the tool directly, use it with GCC as you found: > >> 2. I use "-Wl,-elf2flt=-s1024" with arm-linux-gcc and it says: >> >> /media/sda6/uclinux/usr/local/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld.real: >> address 0x53880 of a.out.gdb section .text is not within region >> flatmem >> /media/sda6/uclinux/usr/local/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld.real: >> error: no memory region specified for loadable section >> `__libc_freeres_fn' >> collect2: ld returned 1 exit status > > With a proper toolchain including uClibc _from that same toolchain_ it > just works. > > If you mix with uClibc from elsewhere, then it may fail. > > Note that some toolchains don't have uClinux no-MMU support. > Unfortunately there isn't a good site pointing to all the latest good > toolchains for each target. > > (By the way, you will need a bigger value than 1024 in the option > -Wl,-elf2flt,-s32768. That shouldn't affect compiling and linking, > but 1024 is too small and the program is likely to have problems when > you run it.) > >> it seems the elf2flt.ld need some modification, if I guess correctly. > > That's right. With all the toolchains I used, though, which come with > their own uClibc, elf2flt.ld is already correct. > > Oh, unless you're using C++. C++ doesn't work properly with older > toolchains. Try C. > >> 3. Do i use the wrong toolchain, since I use arm-linux instead of >> arm-elf. If so, where I can download arm-elf toolchain as arm-linux >> did on uclinux.org, except those obselete. > > They both work for creating C executables which run on uClinux. Yes, > the links on uclinux.org are obsolete. Search the archive of this > mailing list for more recent suggests. The Codesourcery ones get > mentioned a lot. > >> BTW, I have use build root to re-get the toolchain. But when I enable >> elf2flt config. the compile will show the error message below: >> >> /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19-build/bfd/libbfd.a(compress.o): >> In function `bfd_uncompress_section_contents': >> /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19/bfd/compress.c:96: >> undefined reference to `inflateInit_' >> /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19/bfd/compress.c:103: >> undefined reference to `inflate' >> make: *** [elf2flt] Error 1 > > I've never seen this. (But I'm intrigued by the possibility of > compressed section support in binutils, which I hadn't noticed before :-) > > Your solution is to get a toolchain that others have used, better a > more recent one, try a C program first (because C++ doesn't always > work on older toolchains), and don't mix with other libraries. So try > a "hello world" program first :-) Hi: I try 2 another cross-toolchains today. 1. buildroot, 2. arm-uclinux, download from Codesourcery. The transformation of elf to FLAT of them is quite different. I get help from buildroot maintainer, so I can build buildroot with elf2flt successfully. a. When I use "-Wl,-elf2flt,-s32768" to compile my hellow.c. it will say: arm-linux-uclibcgnueabi/bin/ld.real: unrecognized option '-s32768' arm-linux-uclibcgnueabi/bin/ld.real: use the --help option for usage information collect2: ld returned 1 exit status (it seems the ld doesn't recognize the option,-s32768). b. When I use "-Wl,-elf2flt" to compile my hellow.c. it will say: arm-linux-uclibcgnueabi/bin/ld.real: error: no memory region specified for loadable section `.plt' collect2: ld returned 1 exit status c. so I try to use arm-linux-uclibcgnueabi-elf2flt to meet my requirement. And it say: TEXT -> vma=0x0 len=0x24 DATA -> vma=0x0 len=0xc ERROR: text=0x24 overlaps data=0x0 ? it seems i need to modify some file to fix b and c. But I cannot find any config about elf2flt. 2 can successfully get flt as I need even I don't pass "-Wl,-elf2flt,-s32768" to it. ( I assigned the -isystem as buildroot lib, since I cannot find stdio.h in Codesourcery toolchain) So I use arm-linux to compile uxlinux kernel image and use 2, Codesourcery toolchain, to compile my hello.c, put hello_flt to the root file system and let kernel execute it. And it seems ALMOST work. ALMOST means I can see the kernel message says "tart_thread(regs=0x83c15ef8, entry=0x83d60044, start_stack=0x83d6ffb0)" but I cannot see the "hello" that I am looking for. My questions are: 1. I guess the reason why I cannot see the "hello" from console is due to some lib I have to put at root file system/lib. But I don't know is there any tool like readelf can tell me what lib flt needs? I only can do is use "file". But it only can tell me the format not the detail information. If someone knows any tool for flt, please let me know. BTW, is my hello.c too complicate that it fail
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote: > "File is not an object file" > so, it seems I have to make a object relocation file to let this tool, > arm-linux-elf2flt, work. > but how? Don't use the tool directly, use it with GCC as you found: > 2. I use "-Wl,-elf2flt=-s1024" with arm-linux-gcc and it says: > > /media/sda6/uclinux/usr/local/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld.real: > address 0x53880 of a.out.gdb section .text is not within region > flatmem > /media/sda6/uclinux/usr/local/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld.real: > error: no memory region specified for loadable section > `__libc_freeres_fn' > collect2: ld returned 1 exit status With a proper toolchain including uClibc _from that same toolchain_ it just works. If you mix with uClibc from elsewhere, then it may fail. Note that some toolchains don't have uClinux no-MMU support. Unfortunately there isn't a good site pointing to all the latest good toolchains for each target. (By the way, you will need a bigger value than 1024 in the option -Wl,-elf2flt,-s32768. That shouldn't affect compiling and linking, but 1024 is too small and the program is likely to have problems when you run it.) > it seems the elf2flt.ld need some modification, if I guess correctly. That's right. With all the toolchains I used, though, which come with their own uClibc, elf2flt.ld is already correct. Oh, unless you're using C++. C++ doesn't work properly with older toolchains. Try C. > 3. Do i use the wrong toolchain, since I use arm-linux instead of > arm-elf. If so, where I can download arm-elf toolchain as arm-linux > did on uclinux.org, except those obselete. They both work for creating C executables which run on uClinux. Yes, the links on uclinux.org are obsolete. Search the archive of this mailing list for more recent suggests. The Codesourcery ones get mentioned a lot. > BTW, I have use build root to re-get the toolchain. But when I enable > elf2flt config. the compile will show the error message below: > > /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19-build/bfd/libbfd.a(compress.o): > In function `bfd_uncompress_section_contents': > /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19/bfd/compress.c:96: > undefined reference to `inflateInit_' > /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19/bfd/compress.c:103: > undefined reference to `inflate' > make: *** [elf2flt] Error 1 I've never seen this. (But I'm intrigued by the possibility of compressed section support in binutils, which I hadn't noticed before :-) Your solution is to get a toolchain that others have used, better a more recent one, try a C program first (because C++ doesn't always work on older toolchains), and don't mix with other libraries. So try a "hello world" program first :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
2009/1/27 Jamie Lokier : > loody wrote: >> BTW, I also find that if I want uclinux kernel to support ELF binary >> file, I also have to enable the mmu option. >> But the format of cross-compiled binary file like busybox is only ELF, >> if there is option I can add to let busybox and other binary files >> compiled in different format. > > On uClinux with no MMU, you have to use FLT format (all architectures > support this I think) or FDPIC-ELF (just a few architectures support > this, the advantage is proper shared libraries and loadable modules). > > To make FLT files, usually you add "-Wl,-elf2flt=-s32768" or something > like that to the GCC command line. That option sets the stack size; > the size needed is different for each application. Too small and the > app will crash or worse, corrupt memory. Too large and it'll use a > lot of memory, and won't start at all after the system has developed > memory fragmentation. Enjoy :-) > > -- Jamie Hi: thanks for your kind help. After reading your replies, I googled the elf2flt and also try the options you suggest to me. But I find some problem while transferring the ELF to FLT. 1. I see there is a tool called, arm-linux-elf2flt. I try to use it to transfer my busybux as FLT format, but it complains "busybox: Input file contains no relocation info" so I googled the net,http://arc-linux.org/pipermail/arc-linux-dev/2006-December/000250.html, and guess maybe the elf2flt.ld is the relocation it needed. but it still complain: "File is not an object file" so, it seems I have to make a object relocation file to let this tool, arm-linux-elf2flt, work. but how? 2. I use "-Wl,-elf2flt=-s1024" with arm-linux-gcc and it says: /media/sda6/uclinux/usr/local/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld.real: address 0x53880 of a.out.gdb section .text is not within region flatmem /media/sda6/uclinux/usr/local/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld.real: error: no memory region specified for loadable section `__libc_freeres_fn' collect2: ld returned 1 exit status it seems the elf2flt.ld need some modification, if I guess correctly. 3. Do i use the wrong toolchain, since I use arm-linux instead of arm-elf. If so, where I can download arm-elf toolchain as arm-linux did on uclinux.org, except those obselete. BTW, I have use build root to re-get the toolchain. But when I enable elf2flt config. the compile will show the error message below: /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19-build/bfd/libbfd.a(compress.o): In function `bfd_uncompress_section_contents': /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19/bfd/compress.c:96: undefined reference to `inflateInit_' /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19/bfd/compress.c:103: undefined reference to `inflate' make: *** [elf2flt] Error 1 Have anyone pump to this problem before? appreciate your help, miloody ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote: > BTW, I also find that if I want uclinux kernel to support ELF binary > file, I also have to enable the mmu option. > But the format of cross-compiled binary file like busybox is only ELF, > if there is option I can add to let busybox and other binary files > compiled in different format. On uClinux with no MMU, you have to use FLT format (all architectures support this I think) or FDPIC-ELF (just a few architectures support this, the advantage is proper shared libraries and loadable modules). To make FLT files, usually you add "-Wl,-elf2flt=-s32768" or something like that to the GCC command line. That option sets the stack size; the size needed is different for each application. Too small and the app will crash or worse, corrupt memory. Too large and it'll use a lot of memory, and won't start at all after the system has developed memory fragmentation. Enjoy :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
But the format of cross-compiled binary file like busybox is only ELF, Why do you think so. I do use busybox in a non-MMU arch (NIOS). It is cross-compiled on a PC using the appropriate "uClinux-distr" tool chain. The format of the executable file "busybox" is flt. OTOH I do have another tool-chain for the (non-MMU) NIOS, that does not create Linux executable but stuff to run without an external OS on that hardware. Same seems to create an executable in elf format. if there is option I can add to let busybox and other binary files compiled in different format. the option is -elf2flt. Of course the tool chain needs to support this- If I guess correctly above, does that mean uclinux doesn't support ELF? It seems that this depends on the toolchain used. -Michael ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
2009/1/26 Greg Ungerer : > > Hi Miloody, > > loody wrote: >> >> I try to compile kernel with support binfmt_aout.c, CONFIG_BINFMT_AOUT. >> but it says "fs/binfmt_aout.c:438: error: `TASK_SIZE_26' undeclared >> (first use in this function)", and I check in asm/memory.h, it only >> support TASK_SIZE_26 when kernel with mmu support. >> Does that mean kernel without mmu supporting cannot run a.out binary file? > > Yes, that is right. > > Seeya > Gerg > Hi: thanks for your kind help. Would you please tell me why kernel without mmu cannot support a.out binary file? And does that mean the only way to execute the a.out binary file is by ld? BTW, I also find that if I want uclinux kernel to support ELF binary file, I also have to enable the mmu option. But the format of cross-compiled binary file like busybox is only ELF, if there is option I can add to let busybox and other binary files compiled in different format. If I guess correctly above, does that mean uclinux doesn't support ELF? appreciate your kind help, miloody ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Hi Miloody, loody wrote: I try to compile kernel with support binfmt_aout.c, CONFIG_BINFMT_AOUT. but it says "fs/binfmt_aout.c:438: error: `TASK_SIZE_26' undeclared (first use in this function)", and I check in asm/memory.h, it only support TASK_SIZE_26 when kernel with mmu support. Does that mean kernel without mmu supporting cannot run a.out binary file? Yes, that is right. Seeya Gerg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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 uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
