[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclinux-dev
Subject:    Re: [uClinux-dev] Busybox and arm7tdmi
From:       Erwin Authried <eauth () softsys ! co ! at>
Date:       2009-05-31 7:21:49
Message-ID: 1243754509.3739.17.camel () timing-laptop
[Download RAW message or body]

Am Samstag, den 30.05.2009, 23:12 -0400 schrieb Jeff Bacon:
> Erwin,
> 
>    You were absolutely correct. After going over EVERYTHING with a
> fine-tooth comb I found the issue.
> 
> The gcc 3.4.4 toolchain from the snapgear website used the -fPIC
> option when libgcc.a was compiled for the toolchain. When I ran the
> "nm" utility on that file to look at all the symbols I found several
> that had _GLOBAL_OFFSET_TABLE_ listed.
> 
> When I compared those entries with the map file for the busybox
> binary, I found that a single file in the libbb directory (xatonum.c)
> generated code that referenced one of these libgcc built-ins that
> utilized the GOT (_udivdi3 for those interested). All other libgcc.a
> references were ok.
> 
> So I looked a little further at this file and it turns out that there
> is something in my settings SOMEWHERE for ULONG_MAX and ULLONG_MAX
> that caused the wrong set of function definitions to be included in
> the compilation. Long story short, if I force the secondary set of
> function definitions in that file, the code generates properly and
> busybox links correctly with the proper load-to-ram flag being set
> from elf2flt. I tested it out on my platform and it worked!
> 
> On to your second point Erwin, you are correct again, I will NOT want
> to run BB from RAM in the end. After reading through the mailing list
> at all the horror stories with arm7tdmi + XIP, I decided that I first
> wanted to get a system up and running and configured properly without
> messing with any XIP stuff, then once I was satisfied with that, I
> would apply the XIP patches and attempt to replicate my known good
> system using XIP instead. This way if any issue crop up I know that
> it's due to XIP issues and not misconfigurations.

I'm not sure what you are referring to, but I have made the opposite
experience. I have always used PIC without any trouble. There was just
one special application where I had to use non-pic code recently, and
this made trouble with elf2flt, as you know. 

If you are talking about true XIP (=text segment executed directly in
flash), this may be slightly more complicated. But this isn't a
requirement to use pic code, and often you can't use that anyway because
the flash is too slow or the filesystem is compressed to save space. But
even without that, the text segment is shared in ram if multiple
instances of the same application are running.

-Erwin

> 
> Plus this became a personal crusade for me once I realized it didn't
> want to "just work" :) I tend to get like that and will hack away at aa
> problem until I figure it out, even if I won't end up using it in the
> end! Thanks again.
> 
> -JB
> 
> On Sat, May 30, 2009 at 5:07 AM, Erwin Authried <eauth@softsys.co.at> wrote:
> > most probably, at least one of your object files/libraries has been
> > compiled with the -fpic option. You have to fix that, overriding the
> > flag with flthdr doesn't work. Do you have a special reason why you want
> > to build busybox without xip? You know that the large text segment of
> > busybox is allocated seperately for each instance of busybox that you
> > are running?
> >
> > -Erwin
> >
> > Am Freitag, den 29.05.2009, 19:03 -0400 schrieb Jeff Bacon:
> >> Is anyone currently running busybox on and ARM7TDMI using NON_XIP? I
> >> have been banging my head against a wall all day because I cannot seem
> >> to get it to run correctly. I'm using the Snapgear 3.4.4 arm-linux
> >> toolchain and it compiles everything correctly for the non XIP case,
> >> all userland binaries are showing up with the "ram load" flag when
> >> running them through arm-linux-flthdr EXCEPT for busybox. For some
> >> reason, this keeps showing up with the "Has-PIC-GOT" flag and I think
> >> that this is what's causing me troubles, but I have no idea why
> >> elf2flt is throwing in this flag. All of my libraries were compiled
> >> without XIP as well, and like I said before, all my other non-busybox
> >> binaries are showing the correct flags.
> >>
> >> My BB binary contains only one applet, ls, and only for testing. If I
> >> try to run it as is, I get a kernel bug:
> >>
> >> Unhandled fault: vector exception (0x000) at 0x00000000
> >>
> >> Ok fine, so I try to force a ram load by running "arm-linux-flthdr -r
> >> busybox" and it adds the ram load flag in there, but I still get the
> >> kernel bug.
> >>
> >> Next, I try running arm-linux-elf2flt directly on the
> >> busybox_unstripped.gdb elf image and it gives me a FLAT file with the
> >> correct ram load flag only,  but of course running THAT one gives me
> >> other errors (I also put in the kernel trace flag)
> >>
> >> /var> ./busyboxb --help
> >> BINFMT_FLAT: Loading file: ./busybox
> >> Mapping is 4e0000, Entry point is 690, data_start is fd20
> >> Load ./busybox: TEXT=4e0040-4efd20 DATA=4efd24-4f23a4 BSS=4f23a4-4f5994
> >> BINFMT_FLAT: reloc outside program 0x1f978 (0 - 0x15954/0xfce0),
> >> killing busybox!
> >>
> >> I'm lost now and sure could use some help/pointers. Is this a hopeless
> >> scenario? Do I HAVE to have XIP in order to use busybox?
> >>
> >> -JB
> >> _______________________________________________
> >> 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
> >
> > _______________________________________________
> > 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
> >
> _______________________________________________
> 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

_______________________________________________
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

[prev in list] [next in list] [prev in thread] [next in thread]

Configure | About | News | Add a list | Sponsored by KoreLogic