Subject: Re: ARM-Linux for the A5000

From: David Woodhouse <[email-masked]>
Date: Tue, 13 Jan 1998 15:22:26 +0000

[email-masked] said:
>  The way forward is probably NFS root.  You can cross-compile an A5000
> kernel.

> p. 

If we're not too stupid to make ourselves a cross-compiler, that is :(
After a few hours of attempting to compile first gcc-2.7.2.2 with the patches 
on the FTP site, and then egcs-1.0.1, we're thoroughly p***ed off with the 
whole thing.

It there anyone out there who could mail me one, please?

If you can, please mail it directly to [email-masked]

-- 
----                              ----                              ----
David Woodhouse, Robinson College, CB3 9AN, England.   (+44) 0976 658355
    [email-masked]        http://dwmw2.robinson.cam.ac.uk
	    finger [email-masked] for PGP key.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 13 Jan 1998 16:05:56 +0000

>If you can, please mail it directly to [email-masked]

The patches on the ftp site are quite old - I suggest you go for egcs until 
gcc 2.8 is officially released.  What problem are you having?  Don't forget 
that you need binutils installed first, and you also need the Linux kernel 
headers to be in place to build libgcc.a.

p.

---

From: Alan Cox <[email-masked]>
Date: Tue, 13 Jan 1998 19:39:20 +0000 (GMT)

> on the FTP site, and then egcs-1.0.1, we're thoroughly p***ed off with the 

Nod. I had horrible problems and my compiler looked like it was writing
wrong code afterwards. bintuils seems to cross wonderfully. I'd happily
provide ftp space for a cross arm compiler set that works. Bonus points
if it can write the bogoid acorn binary format too ;)

Alan

---

From: Alan Cox <[email-masked]>
Date: Wed, 14 Jan 1998 00:23:14 +0000 (GMT)

Acorns linker may cope with AOFF from a.out but nto everyone working on arm
linux will have access to acorn kit as the ARM moves on, and AOFF is needed
for stuff like the ebsa285 loader. So aout2aoff or similar is needed

Alan

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 13 Jan 1998 23:22:41 +0000 (GMT)

> if it can write the bogoid acorn binary format too ;)

Umm.. I'll look at the cross-code that gcc 2.8 is producing and see if
I can spot the difference.  It's not necessary to write AOF code - Acorn's
linker copes with a.out input files.

OTOH, since gcc 2.8 isn't compiling my kernel right yet, there's prolly
other problems that ought to be resolved before we let it run free.

---

From: Philip Blundell <[email-masked]>
Date: Wed, 14 Jan 1998 09:24:37 +0000

>for stuff like the ebsa285 loader. So aout2aoff or similar is needed

Do you just need to be able to generate executable AOF from an a.out binary?  
If so it shouldn't be hard - it's something I've thought about before (because 
I wanted to be able to cross-compile Acorn applications).

Linkable AOF is probably a bit harder.

p.

---

From: Alan Cox <[email-masked]>
Date: Wed, 14 Jan 1998 09:45:26 +0000 (GMT)

> Do you just need to be able to generate executable AOF from an a.out binary?  

Or ELF , or arbitary binary image. I wrote the AOF headers for the EBSA285
test app in hex instead

> I wanted to be able to cross-compile Acorn applications).

aout2aoff for folks with stuff like the EBSA boards that expect that format
might be a good move. It seems fairly easy to arrange

---

From: David Alan Gilbert <[email-masked]>
Date: Wed, 14 Jan 1998 10:06:58 +0000

Hi,
  I have cross compilation going fairly reliably from an Alpha 
producing ARM kernels; the way I look at is if I can do it from an
Alpha it should be dead easy to do it from a 32 bit machine.

  I'll post my current list of instructions in a few days time. I'm
using EGCS-971225 with a small patch (which is really an Alpha only
problem).

  For me (from Alpha) Binutils-....18 produces a kernel which doesn't
boot but ....15 works - I haven't figured out why yet.

  So far I have it working for producing old Arc (and should do A5K
kernels) and I have produced a RiscPC kernel - but I know there
are those having problems producing RPC kernels.

  Instructions in a couple of days (when I am doing email from home).

Dave
-- 
----------------------------------------------------------------------
- Dr. David Alan Gilbert - WARNING! This is a beta release .signature-
- Work:    dg @ cogency.co.uk        -    0161-428-9444              -
- Home:    gro.gilbert @ treblig.org -                               -
----------------------------------------------------------------------
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Wed, 14 Jan 1998 11:36:00 +0000

>Or ELF , or arbitary binary image. I wrote the AOF headers for the EBSA285

Right.  Well, objcopy will convert ELF/a.out/whatever to raw binary for you, 
so all we really need is the trivial bit of code to wrap it in an AOF header.  
I'll knock something up a bit later.

p.

---

From: Russell King <[email-masked]>
Date: Wed, 14 Jan 1998 00:15:54 +0000 (GMT)

> linker copes with a.out input files.

If you're using GCC 2.8, then PLEASE make sure that you are using the correct
libgcc.a - if you're using -mapcs-32, then you *must* use the APCS-32 version
of libgcc.a, otherwise the ApCS-26 version.  This has already caused someone
problems, so if other people report it, I'll add it to the FAQ.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        [email-masked]       --- ---
  | | | |     http://www.arm.uk.linux.org/~rmk/home.html     /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Philip Blundell <[email-masked]>
Date: Wed, 14 Jan 1998 23:08:48 +0000

>problems, so if other people report it, I'll add it to the FAQ.

It's quite hard to use the wrong version - nobody should have the path to 
libgcc.a coded in anywhere.

p.