All,

  I wanted to update my situation for anyone who was following this
thread. I downloaded the source for the toolchain I was using from the
snapgear ftp server and re-built binutils and elf2flt making the mod
Erwin suggested(had to re-build bin-utils because libbfd.a was not in
the pre-compiled toolchain for whatever reason). I then replaced my
versions of arm-linux-elf2flt with the new one and re-compiled
everything, turning off XIP in my config.arch directory and I am
pleased to say that the system works much smoother now, none of the
issues I described below are occurring anymore(at least in my limited
testing thus far)!

After spending several hours going through the mail history of this
list last night, I was able to piece together that XIP for arm7tdmi
was busted for the stock 888 source tree, but one David Howells had
provided a set of patches for getting MTD+ROMFS+XIP to play well
together. I'm going to try out that patchset this evening and see if
it does indeed work.

Thanks again Erwin (And Greg and Jun and David and all other frequent
posters), I almost feel like you're all family after the hours I spent
reading many of your posts and discussions (many useful insights came
out of this that I intend on following up on).

-JB

On Thu, May 21, 2009 at 6:00 AM, Erwin Authried <[email protected]> wrote:
> Hi Greg,
>
> I have used this a lot for applications without XIP in the meantime, it
> works fine. I just wanted to note that running elf2flt without the "-a"
> option does NOT work.
>
> Sorry that I didn't make a neat patch, just not enough time.
>
> -Erwin
>
> Am Donnerstag, den 21.05.2009, 16:57 +1000 schrieb Greg Ungerer:
>> Hi Erwin,
>>
>> Erwin Authried wrote:
>> > Hi,
>> > I have solved the "reloc type R_ARM_PC24 unsupported in this context"
>> > error by modifying elf2flt.c:
>> >
>> > -Erwin
>> >
>> > ...
>> > #elif defined(TARGET_arm)
>> >                                 case R_ARM_ABS32:
>> >                                         relocation_needed = 1;
>> >                                         break;
>> >                                 case R_ARM_REL32:
>> >                                 case R_ARM_THM_PC11:
>> >                                 case R_ARM_THM_PC22:
>> > //  ==> add the following 4 lines:
>> >                                 case R_ARM_PC24:
>> >                                 case R_ARM_PLT32:
>> >                                 case R_ARM_GOTPC:
>> >                                 case R_ARM_GOT32:
>> >                                         relocation_needed = 0;
>> >                                         break;
>> >                                 default:
>> >                                         goto bad_resolved_reloc;
>>
>> Thats looks right to me. I think we can go ahead and push
>> that into the elf2flt CVS?
>>
>> Regards
>> Greg
>>
>>
>>
>> >
>> > Am Mittwoch, den 20.05.2009, 12:29 -0400 schrieb Jeff Bacon:
>> >> Hi, I've just started on a uClinux 2.6 port to a custom ARM7TDMI board
>> >> (we've had a uClinux 2.4 kernel running with no problems for a couple
>> >> of years now, but decided to take the plunge and upgrade). I just
>> >> joined the mailing list and am trying to resurrect the thread below
>> >> from Erwin...
>> >>
>> >>
>> >> First. here is some background on where we are right now
>> >>
>> >> We are currently using the same base kernel and toolchain mentioned
>> >> below(uClinux-dist-20080808, snapgear toolchain
>> >> arm-linux-tools-20070808.tar.gz) and we're having a ton of issues with
>> >> getting our XIP ROMFS root filesystem working out of flash (the kernel
>> >> boots, the filesystem mounts and I get a SASH prompt, but the system
>> >> is HIGHLY unstable and usually crashes after a couple of commands). In
>> >> fact, basic things are broken such as "cat". I've set the init=/bin/sh
>> >> kernel parameter to boot immediately into the shell, but if I try
>> >>
>> >> "cat /etc/motd", I get a ton of output like this(note, ROMFS debugging
>> >> is turned ON):
>> >>
>> >> ****************************************************************************************
>> >> <snip>
>> >> VFS: Mounted root (romfs filesystem) readonly.
>> >> Freeing init memory: 76K
>> >> BINFMT_FLAT: ROM mapping of file (we hope)
>> >> BINFMT_FLAT: Allocated data+bss+stack (21094 bytes): 2b8004
>> >> p=2bfffc
>> >> start_thread(regs=0x1eff08, entry=0x280044, start_stack=0x2bffb8)
>> >>
>> >> Sash command shell (version 1.1.1)
>> >> /> ls /etc
>> >> BINFMT_FLAT: ROM mapping of file (we hope)
>> >> BINFMT_FLAT: Allocated data+bss+stack (10894 bytes): 2f0004
>> >> p=2f3ffc
>> >> start_thread(regs=0x2c7fb0, entry=0x2e0044, start_stack=0x2f3f80)
>> >> inittab        modprobe.conf  motd           passwd         ramfs.img
>> >> rc             services       version
>> >> /> cat /etc/motd
>> >> BINFMT_FLAT: ROM mapping of file (we hope)
>> >> BINFMT_FLAT: Allocated data+bss+stack (11541 bytes): 2cc004
>> >> p=2cfffc
>> >> start_thread(regs=0x2b7fb0, entry=0x2c8044, start_stack=0x2cff78)
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> : : No such file or directory
>> >> />
>> >> ****************************************************************************************
>> >> Mounting /proc works, but I can't cat any of those files as well, but
>> >> either way, the system only SOMETIMES makes it this far before dying
>> >> completely (just stalls, no kernel panics or oops or anything).
>> >>
>> >> Anyway, while trying to debug this, the first thing I tried was taking
>> >> Flash out of the equation. So in my bootloader I restrict system RAM
>> >> to 4MB (we have an 8MB part) and copy the ROMFS image from flash into
>> >> the 2nd 4MB of RAM. I add the mem=4MB kernel parameter to restrict
>> >> uClinux to the 1st 4MB of RAM, then compiled the uclinux MTD driver
>> >> and gave it the location of the ROMFS in the 2nd half of RAM. The
>> >> kernel boots and the uclinux mtd driver finds and mounts it and I get
>> >> the prompt again, but the behavior is exactly the same, highly
>> >> unstable, things like "cat" don't work.
>> >>
>> >> So next I tried to compile userland WITHOUT XIP to see if that was the
>> >> problem and this is when I found the exact same issue as Erwin
>> >> described below. I've set the same options as you have in my
>> >> congif.arch file and I get the same  "ERROR: reloc type R_ARM_PC24
>> >> unsupported in this context" all over the place as you did.
>> >>
>> >> So, any idea what the issue is? Is it a toolchain problem? Is it a
>> >> kernel source problem? Again, I'm using the BASE
>> >> uClinux-dist-20080808, I haven't applied any of the patches as I
>> >> wanted to work from the known stable base tree.
>> >>
>> >> If anyone else has ever encountered the issues I'm describing and you
>> >> figured out that it's not XIP issues, can anyone let me in on the
>> >> secret?
>> >>
>> >> Finally, if I just want to separate kernel code issues from root
>> >> filesystem issues, what's the easiest, most stable method for creating
>> >> and mounting a root filesystem image (System RAM = 8MB, System Flash =
>> >> 8MB). Thanks for any and all help.
>> >>
>> >> Cheers,
>> >>
>> >> JB
>> >>
>> >> *************************************************************************************************
>> >>
>> >> List:       uclinux-dev
>> >> Subject:    [uClinux-dev] errors when linking without XIP
>> >> From:       Erwin Authried <eauth () softsys ! co ! at>
>> >> Date:       2009-03-23 11:26:51
>> >> Message-ID: 1237807611.711.254.camel () justakiss ! home ! at
>> >>
>> >> Hi,
>> >>
>> >> I have always compiled applications for ARM7TDMI with pic (-fpic
>> >> -msingle-pic-base) without problems. Now I tried to build without pic,
>> >> and got lots of
>> >>
>> >>   ERROR: reloc type R_ARM_PC24 unsupported in this context
>> >>
>> >> during linking. After searching the archives, I tried to run elf2flt
>> >> without the "-a" option. This time, the link succeeds, but I get a
>> >>
>> >>  BINFMT_FLAT: reloc outside program ...
>> >>
>> >> when I try to run the application on the target (I tried several
>> >> applicatons, all had the same problem). I have used
>> >> uClinux-dist-20080808 and the snapgear toolchain
>> >> arm-linux-tools-20070808.tar.gz.
>> >> I modified vendors/Atmel/AT91/config.arch to disable XIP, and built from
>> >> scratch:
>> >>
>> >> ############################################################################
>> >>
>> >> CPUFLAGS :=
>> >> # VENDOR_CFLAGS                # not required here
>> >> DISABLE_XIP := 1             # XIP works fine
>> >> DISABLE_MOVE_RODATA := 1       # until we get a toolchain release
>> >> DISABLE_SHARED_LIBS := 1
>> >> # LOPT := -O2                  # library is alway 02
>> >> # UOPT := -Os                  # user apps are always Os
>> >>
>> >> ############################################################################
>> >>
>> >> Any ideas what's wrong?
>> >>
>> >> -Erwin
>> >>
>>
>
> _______________________________________________
> 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
>
_______________________________________________
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

Reply via email to