Subject: how to get an elf system from the 2.0.35 redhat installation?

From: Peter Teichmann <[email-masked]>
Date: Tue, 20 Apr 1999 15:48:53 +0000

Hi there,

as 12MB per user program are not much and I want to use KDE too, I would like
to have an kernel that also supports elf binaries and a c compiler which can
compile elf binaries.

After reading http://www.tazenda.demon.co.uk/phil/arm-tools.html I thought
that I first had to compile binutils and egcs, then install them, after that
compile the new kernel, boot the new kernel ...

I am running the 2.0.35 kernel and the compiler+libraries from the
redhat rpms at ftp.arm.linux.org.uk.

The computer is a riscpc with sa, 64+2MB Ram, 64 MB swap, enough free hd
space.

Unfortunately I got the following error message while compiling egcs-1.1.1
with phils patch:

make[1]: Entering directory `/usr/src/egcs-1.1.1/libiberty'
make[1]: Leaving directory `/usr/src/egcs-1.1.1/libiberty'
make[1]: Entering directory `/usr/src/egcs-1.1.1/texinfo'
make all-recursive
make[2]: Entering directory `/usr/src/egcs-1.1.1/texinfo'
Making all in intl
make[3]: Entering directory `/usr/src/egcs-1.1.1/texinfo/intl'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/src/egcs-1.1.1/texinfo/intl'
Making all in lib
make[3]: Entering directory `/usr/src/egcs-1.1.1/texinfo/lib'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/src/egcs-1.1.1/texinfo/lib'
Making all in makeinfo
make[3]: Entering directory `/usr/src/egcs-1.1.1/texinfo/makeinfo'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/src/egcs-1.1.1/texinfo/makeinfo'
make[2]: Leaving directory `/usr/src/egcs-1.1.1/texinfo'
make[1]: Leaving directory `/usr/src/egcs-1.1.1/texinfo'
make[1]: Entering directory `/usr/src/egcs-1.1.1/etc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/src/egcs-1.1.1/etc'
make[1]: Entering directory `/usr/src/egcs-1.1.1/gcc'
gcc  -DIN_GCC    -g -O2  -DHAVE_CONFIG_H     -I. -I. -I./config \
-DPREFIX=\"/usr\" \
  -c `echo ./prefix.c | sed 's,^\./,,'`
In file included from config/arm/linux-elf.h:81,
                 from tm.h:2,
                 from config/arm/xm-arm.h:54,
                 from config/arm/xm-linux.h:22,
                 from config.h:2,
                 from prefix.c:66:
config/arm/elf.h:406: syntax error before `extern'
make[1]: *** [prefix.o] Error 1
make: *** [all-gcc] Error 2
make[1]: Leaving directory `/usr/src/egcs-1.1.1/gcc'

Looking at line 406 in elf.h I could not find something strange. Does
anyone know what is the problem here?

And another question: Is my way how to get an elf system ok?

-- 
Peter Teichmann

----------------------------------------------------------------------------
Email: [email-masked]  WWW: rcswww.urz.tu-dresden.de/~teich-p

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

---

From: Philip Blundell <[email-masked]>
Date: Tue, 20 Apr 1999 16:55:16 +0100

>anyone know what is the problem here?

I think this may be a symptom of a broken or outdated version of some tool or 
other.  Look in files like config.h and auto-host.h and check that nothing 
strange has been left there - in particular look for strings starting with @ 
that should have been substituted by configure.

Also try egcs 1.1.2 rather than 1.1.1.

>And another question: Is my way how to get an elf system ok?

Yes.  You could also try downloading precompiled binaries, say from Debian, 
rather than bootstrapping your entire system from scratch (which is tedious 
and not entirely trivial).  You will still need to build your own kernel since 
they don't currently have explicit support for the RiscPC.

p.

---

From: Peter Teichmann <[email-masked]>
Date: Tue, 20 Apr 1999 17:18:57 +0000

In message <[email-masked]>

> they don't currently have explicit support for the RiscPC.

But aren't the precompiled binaries all for armv4 architecture, and the
RiscPC IOMD does not support 16 bit wide memory accesses?

-- 
Peter Teichmann

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 20 Apr 1999 19:42:04 +0100 (BST)

> RiscPC IOMD does not support 16 bit wide memory accesses?

Peter, you are 100% correct here.  As far as I know, there are no pre-compiled
binaries available for the RiscPC yet.  There are a couple of people looking
into creating a set.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 20 Apr 1999 20:26:45 +0100

>But aren't the precompiled binaries all for armv4 architecture,

No.

p.

---

From: Peter Teichmann <[email-masked]>
Date: Tue, 20 Apr 1999 19:37:31 +0000

> Also try egcs 1.1.2 rather than 1.1.1.

I now tried also 1.1.2. The same error. I have cut down elf.h until there
was only one line in it:

extern void text_section ();

I think there is definitely no error, everyone can see it. But it was still
reported: error in line 1 before extern.

-- 
Peter Teichmann

---

From: Philip Blundell <[email-masked]>
Date: Tue, 20 Apr 1999 20:41:20 +0100

>reported: error in line 1 before extern.

The error will be in whatever comes before elf.h in the compilation.  Did you 
examine the include files I suggested you should look at?

p.

---

From: Nicholas Clark <[email-masked]>
Date: Tue, 20 Apr 1999 21:02:53 +0100 (BST)

> anyone know what is the problem here?

No idea why this happens.

cd gcc
grep TOP *.h

edit the file grep finds (I think it's auto-host.h)
remove the line

TOP

from that file

Nick

---

From: Peter Teichmann <[email-masked]>
Date: Tue, 20 Apr 1999 22:32:28 +0000

In message <[email-masked]>

> examine the include files I suggested you should look at?

Well, not exact enough. But after a hint from Paul Konig (gcc --save-temps)
I found that there was a line containing only "TOP" in auto-host.h.
After I removed it it went a bit further.

Then I got another error:

checking whether the C compiler (/usr/src/egcs-1.1.2/gcc/xgcc -B/usr/src/egcs-1.1.2/gcc/ -g -O2) works...  no
configure: error: installation or configuration problem: C compiler cannot create executables
make: *** [configure-traget-libiberty] Error 1

I thought that I perhaps should install the new binutils for the new C
compiler, but installing them did not help. Only the old aout C compiler
now does not work anymore (because of the elf binutils).

-- 
Peter Teichmann

---

From: Philip Blundell <[email-masked]>
Date: Wed, 21 Apr 1999 09:38:00 +0100

>now does not work anymore (because of the elf binutils).

I'm pretty sure this is described in Chris Rutter's toolchain guide.  The 
actual error message is probably mentioned on my web page too.

p.

---

From: Dave Baukus <[email-masked]>
Date: Wed, 21 Apr 1999 16:29:16 -0500

Has anybody attempted to get the AMD AM79C792 "lance" ethernet going on ARM
linux ?
We were able to get it compiled and working on a *86 PC running the
2.2.3 kernel by adding the device ID to the "chipset" table in lance.c.
However, on ARM linux w/ the 2.2.2 kernel it does not work.

The driver configures itself fine, but when ip config attempts to use
it for bootp, the bootp packets go out, the bootp server replys and the
lance driver does not get the reply.

I'm still running w/ all  cacheing/buffering off.

--
Dave Baukus
	Inet Technologies Inc.
	[email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 22 Apr 1999 22:05:31 +0100 (BST)

> lance driver does not get the reply.

It may be worth trying to display the first 16 bytes of the received packet
to see what is being passed into the kernel.  This should consist of two
sets of 6 bytes of ether addresses, 2 bytes of ether type, followed by 0x45
(being the first byte of the IP header).
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Timothy Baldwin <[email-masked]>
Date: Fri, 23 Apr 1999 15:05:16 +0100

In message <[email-masked]>
          Russell King - ARM Linux Admin <[email-masked]> wrote:

> > > Yes.  You could also try downloading precompiled binaries, say from
> > > Debian, rather than bootstrapping your entire system from scratch
> > > (which is tedious and not entirely trivial).  You will still need
> > > to build your own kernel since  they don't currently have
> > > explicit support for the RiscPC.
> > 
> Peter, you are 100% correct here.  As far as I know, there are no
> pre-compiled binaries available for the RiscPC yet.  There are a couple
> of people looking into creating a set.

Russell, you are 50% wrong here. After removing a few files Debian will
work on Risc PCs, I have it running on mine. However the usual disclaimer
about it being an incomplete unstable distribution applies.

Also, I intend to upload a biuld of Russell next stable kernel to
my web site.

-- 
http://www.reinhouse.freeserve.co.uk/
  Please don't CC replies to me!!!
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Dave Baukus <[email-masked]>
Date: Fri, 23 Apr 1999 10:08:52 -0500

> (being the first byte of the IP header).

	It appears that we are receiving all FF's.
	
	The driver allocates "discriptor rings" and the card writes to the
	rings when it receives packets. Is it possible that the region of
	memory that was allocated by the driver is not correctly mapped
	to the bus ? 
	
	The driver is constantly masking hardcoded values into the bus address
	that I do not understand. Can anyone comment on the meaning of
	the 0x80000000 in the following code fragment:

        rx_buff = kmalloc(PKT_BUF_SZ, GFP_DMA | gfp);
        if (rx_buff == NULL)
                lp->rx_ring[i].base = 0;
        else
              lp->rx_ring[i].base = (u32)virt_to_bus(rx_buff) | 0x80000000;

---

From: Chris Rutter <[email-masked]>
Date: Sat, 24 Apr 1999 11:04:17 +0100 (BST)

> about it being an incomplete unstable distribution applies.

Removing a few files?  Which files?

-- 
Chris <[email-masked]>                         ( http://www.fluff.org/chris )