Hi John, The kernel and file system image were built on linux, and I'm just trying to create user programs to transfer to the system over tftp. We want to allow our customers to use uClinux without being required to build a kernel or having a linux system. So we will provide them with an EDK project and a pre-built image to download to the FPGA. Their user programs can then be compiled on Windows and transferred to the FPGA via the network. All that, to say this: all the standard linux commands were built on linux and work fine. I've tried more than one Windows built binary and neither worked. The example attached is a simple Hello World program. I've attached the output files and verbose output logs. I don't see any relocations in the elf2flt output (elf2flt-log.txt) that would match the error (ld-err.txt). I built elf2flt.exe with MinGW. I don't really know, but I'm guessing from the name that elf files have multiple sections and the elf2flt program just concatenates all the sections into one contiguous block. Is that right? I didn't do anything with flthdr, do I need that? Thanks for helping me out. --Scott > -----Original Message----- > From: owner-microblaze-uclinux@itee.uq.edu.au > [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On Behalf Of > John Williams > Sent: Wednesday, October 27, 2004 7:47 PM > To: microblaze-uclinux@itee.uq.edu.au > Subject: Re: [microblaze-uclinux] Building microblaze toolchain > > > Hi Scott, > > Scott Thibault wrote: > > > I was able to build elf2flt on with MinGW finally. The binary is > > indeed recognized by uClinux but the loader reports that there is a > > relocation outside the program! Do you have any ideas? The > > ld-elf2flt output is below. I'm linking against the crt0.o > and libc.a > > of uClib, and the libgcc.a and libc_hard_shift.a from EDK. > The loader > > script is the default elf2flt.ld from the elf2flt on uclinux.org. > > Is it just one specific application that is causing this problem? Or > are you getting bad relocs on all apps (esp init, sh, etc)? > > Can you send the original .elf and .gdb files from which your > offending > executable is produced, and also a transcript of the kernel loader's > failure (ie details of bad relocation)? The mb-ld script deletes the > elf file after producing the flat - just comment out that > line temporarily. > > From the kernel loader message you can see which is the offending > relocation. If you manully run elf2flt in verbose mode ( -v > option) on > the .elf file, you can cross-check the bad relocation, and > use that as a > starting point. > > I'll look at it with a linux mb-elf2flt, see if I can work out what's > happening. The microblaze elf2flt support is pretty stable, > but every 6 > months or so a new corner case seems to emerge - maybe you've found > another one. > > Thanks, > > John > ___________________________ > microblaze-uclinux mailing list > microblaze-uclinux@itee.uq.edu.au Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
Attachment:
bad-reloc.zip
Description: Zip compressed data