I can't guarantee than I can help, but I (and probably others here) have built linux kernels for the SH platform under cygwin, so you could post your specific problems. You may have to do some research to see what versions of gcc/binutils/glibc people are using to build the particular mishmash of kernel/glibc/? you're using; check out Dan Kegel's crosstools package for some guidance on what needs to be done to rebuild a working toolchain.

Best of luck
mt

I cannot speak for the cygwin tools since I don't use Windows...except maybe for games. :-)

I know that the kernel is really finnicky about the compiler. What is happening when you build with cygwin? Do you get errors, or does the kernel fail to execute?

This something that I am running up against, building a toolchain that the lolo loader will accept as a "good" elf formatted files. So far, I've tried "arm-softfloat", then "arm-9tdmi" and niether of these toolchains produce an "acceptable" elf format.

When I compile a statically linked program on the host, tell lolo to "load elf" and then "cat filename > /dev/ttyS0", lolo complains of an error in the elf file format. Wierd.

The build host is Mandrake 10.1 Official using gcc-3.4.1 and I am building the crosstools from crosstool-0.28-rc37.tar.gz.

Hi Tom,

What version of lolo do you have, and could you copy/paste the exact error message?

Thanks

This is the output from lolo:
================ begin lolo =====================
CPLD_CE_REG_REVISION: 0x37 (rev: b)
CPLD_CE_REG_MODE : 0xfe
default screen (54): 4 10bpp
Error, found no suitable display drivers
Error, couldn't get a display handle.
must 'video-open' before drawing!

*****************************************************************
LogicLoader

(c) Copyright 2002-2004, Logic Product Development, Inc.
All Rights Reserved.
Version 1.4.3.1-LLH7a400_10 0001
*****************************************************************

Type 'help all' for a list of commands.

losh> load elf
loading from stdin:
F
fseek(delta:-148) failed during load, possibly strange elf?
0xc0045be4 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00 .ELF...a........
0xc0045bf4 02 00 28 00 01 00 00 00 d0 80 00 00 34 00 00 00 ..(.........4...
0xc0045c04 2c 25 06 00 02 00 00 00 34 00 20 00 03 00 28 00 ,%......4. ...(.
0xc0045c14 1a 00 17 00 ....
0xc0045b44 01 00 00 00 00 00 00 00 00 80 00 00 00 80 00 00 ................
0xc0045b54 c4 f9 05 00 c4 f9 05 00 05 00 00 00 00 80 00 00 ................

elf file type : 0x0002
machine type: 0028 version: 1
prog start addr : 0x000080d0
num prog headers: 3
num sect headers: 26
offset : 0x00000000 disk length: 0xc00c0000 mem len: 0x00000000
phyaddr: 0x00000094 vaddr : 0x00000003 dl addr: 0xc00c0000
elf load failed.
ignoring rest of file...done
losh>

=============== snip ==================

The file that I used as a test upload was the tmp test file compiled at the end of the crosstools build. I use the build.sh and defs from the ftp://ftp.buici.com/pub/arm/crosstool/ site to build on a Linux host.

Running "file" on this elf image reports:
[tom@BeastBox tmp]$ file arm-linux-hello-static
arm-linux-hello-static: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.3, statically linked, not stripped

Just for giggles, I took an ELF file from another ARM project to see if that created the same problem. It does. The file was a stock "/bin/dd" taken from a Debian ARM woody distro.

Maybe what I am doing to do the upload is at fault? I have used blob quite a bit in the past to upload files into embedded arm systems and with blob, I simply start the upload (from within blob) and then "cat file > /dev/ttyS0". Would this present a problem?

I wouldn't think so as lolo announces "loading from stdin:" and /dev/ttyS0 is uncooked. Unless lolo cooks its' data passing through stdin from its' UART???

Uhhuh, I see what you are doing now. You aren't using a pure ELF file format but are hard locating the load at a fixed target address via the linker description file. Your "ELF" image is really an absolute-linked binary within an ELF descriptor wrapper.

I was under the impression that the lolo loader would be doing any fixup relocation when an ELF was being loaded. We had taken this technique a bit further under uClinux where we were stripping off the ELF header with objcopy to produce a purely binary image.

Close, but not exactly, you should/might be able to load the same ELF
files when you are loading from tftp or compact flash. The problem is
that the elf program header is included in the chunk of the file
which we're supposed to load, as described by the program header,
and since we're loading from a serial stream, we can't seek
backwards in the source file to load everything we "should" be
loading. I *believe* there's a flag for the linker that causes it
not to include the program header in the image... '-N' maybe?

note: user tom@openhardware is now TomW
Not exactly, you wouldn't want to eliminate the header from the image in your case. I see that by keeping the header, that you can pull the load address and filesize from it. By the use of your linker description file, you also keep the relocation table down to one table and that table is empty. You have an interesting solution of loading hard-linked code in a debug environ!

If you really wanted to "remove" the header, the only way that can be done, successfully, is to absolute org sections within the app by means of the linker description file. Then use objcopy to extract those Sections. For example, if you wanted to squish the air (header) out of "sample_LLH7a400_10_RAM", simply do: arm-linux-objcopy -O binary sample_LLH7a400_10_RAM sample

Then it could be loaded by: load raw 0xc00c0000 680

The difference in size is, of course, remarkable:

-rwxr-xr-x 1 tom tom 680 Nov 23 06:12 sample*
-rwxr-xr-x 1 tom tom 33908 Nov 23 06:03 sample_LLH7a400_10_RAM*

I mention objcopy here as some of your users may be new to the GNU tools and haven't yet discovered how powerfull a utility it is. It can also be used to convert the binary images into SREC or HEX or ...

If anyone is interested in creating ROMable code using gcc + ld + objcopy, look at: http://www.openhardware.net/misc/AbsoluteLinkingWithGcc.pdf

I don't have any experience using Windows to host development. In the past, it hasn't been acceptable because the cygwin tools, while a great idea, are not as stable as thost built on UNIX/Linux. Moreover, Windows tends to be much slower than the same hardware running Linux...IMHE.

That said, it will serve you best to be circumspect about the tool chain you use to build the kernel and the boot loader. Both blob and the kernel are very sensitive to compiler versions. I never got to the bottom of the compability issues, so I can only say this: I am using gcc-3.4.1 and glibc-2.3.3 built from crosstool with good results. The 3.3 compiler worked, too. Earlier compilers, including some of the 2.95 version, were not able to build the kernel.

Yeah, 2.95 versions were really, really, REALLY buggy! heh. I've had success with gcc-3.3.3 and glibc-2.3.2 so far. I did a quick try at gcc-3.4.1, ran into an unresolvable problem building the 2.6.8 kernel (it was the fpu bug) and couldn't resolve it (yes, I patched the Makefile). Others tell me they can get past that bug. I might give it a try some other time, but gcc-3.3.3 seems to be ok.

Eventually, I'll be moving to uClibc from glibc because of the LGPL license.