Subject: Re: Release of Kernel source code for 2.0.33 and 2.1.78

From: David Woodhouse <[email-masked]>
Date: Mon, 19 Jan 1998 00:15:40 +0000

[email-masked] said:
>  I have just finished uploading the source code for kernel versions
> 2.0.33 and 2.1.78.

> 2.0.33 has been tested on the EBSA, RiscPC and A5000.  (Dave, can you
> try it on the ARC please?) 

On the A5000, cross-compiling using:

jma24 /mnt/tmp/root/usr/src/linux # arm-unknown-linuxaout-gcc -v
Reading specs from /usr/local/lib/gcc-lib/arm-unknown-linuxaout/2.7.2.2/specs
gcc version 2.7.2.2
jma24 /mnt/tmp/root/usr/src/linux # arm-unknown-linuxaout-as -v
GNU assembler version 2.7 (arm-unknown-linuxaout), using BFD version 2.7       

I needed this patch.

--- pgtable.h.orig      Sun Jan 18 23:29:11 1998
+++ pgtable.h   Sun Jan 18 23:33:22 1998
@@ -277,7 +277,7 @@
 extern __inline__ pmd_t mk_pmd (pte_t *ptep)
 {
	pmd_t pmd;
-	pmd_val(pmd) = virt_to_phys((void *)ptep) | _PAGE_TABLE;
+	pmd_val(pmd) = (unsigned long)virt_to_phys((void *)ptep) | _PAGE_TABLE;
	return pmd;
 }

However, I still get:

arm-unknown-linuxaout-gcc -D__KERNEL__ -I/mnt/tmp/root/usr/src/linux/include -m3 -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -pipe -D__ASSEMBLY__ -c -o entry-armo.o entry-armo.S
entry-armo.S: Assembler messages:
entry-armo.S:388: Error: Register or shift expression expected -- statement `teqp pc,$0x08000003'

entry-armo.S:406: Error: Register or shift expression expected -- statement `teqp pc,$0x00000003'

make[1]: *** [entry-armo.o] Error 1
make[1]: Leaving directory `/mnt/tmp/root/usr/src/linux/arch/arm/kernel'
make: *** [linuxsubdirs] Error 2        

These are in the ENABLEIRQS and DISABLEIRQS macros from assembler.h, and I've 
absolutely no clue how to go about fixing it.

Other than that: 
  Is it possible to compile the FP-emulation into the kernel?
  Does anyone have a mkswap or swapon binary for ARM3?

-- 
----                              ----                              ----
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: Mon, 19 Jan 1998 09:01:53 +0000

>  Is it possible to compile the FP-emulation into the kernel?

No, because as I understand it the ARM FPE is under a binary-only licence.  
This is a bit of an unhappy state of affairs, but until somebody writes us a 
better emulator we're rather stuck with it.

p.

---

From: Philip Blundell <[email-masked]>
Date: Mon, 19 Jan 1998 09:00:46 +0000

>m3 -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -pi
>pe -D__ASSEMBLY__ -c -o entry-armo.o entry-armo.S

Your binutils may be too old to grok `$'-style expressions.  I know Russell 
tried to make this a config option but it looks like some slipped through.

p.

---

From: Alan Cox <[email-masked]>
Date: Mon, 19 Jan 1998 09:22:26 +0000 (GMT)

> better emulator we're rather stuck with it.

That shouldnt be very hard to do. The 2.1.x FPU emulation used on the 
ultrasparc is designed to give a good basic FPU framework for any box.

Also writing an FPU emulator is generally not hard, but sometimes a little
tedious. You can often start with 

emulate_fmul(float a, float b)
{
	return a*b;
}

and compile all these routines with gcc -msoft-float ;)
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Matthew Wilcox <[email-masked]>
Date: Mon, 19 Jan 1998 10:13:27 +0000 (GMT)

> ultrasparc is designed to give a good basic FPU framework for any box.

Interesting..
As an aside, the current implementation of most of libm uses calls to the
FPE to do much of the work.  glibc2's maths routines work in fixed-point,
so this would mean that any replacement FPE would not have to be optimised
to the limit since it will be used less in the future.

---

From: Phil Norman <[email-masked]>
Date: Mon, 19 Jan 1998 11:55:26 +0000 (GMT)

> better emulator we're rather stuck with it.

Wouldn't it be possible to release it as a gcc binary form (ie you have a 
file like this:
{ 0xe7 0x77 0x77 0x77 .... }

(don't compile that one btw - it's an undefined instruction (useful for 
debugging)).  I've seen quite a few i386-linux programs distributed with 
bits of source code like that.  It makes for a fairly large source file, 
but it'd allow gcc to compile the thing into the linux kernel.

Phil

-- 
Phil Norman, mailing from Exeter Uni.
Programs available for download from my web page.
email:  [email-masked]
web:    http://newton.ex.ac.uk/general/ug/norman

---

From: James Craig <[email-masked]>
Date: Mon, 19 Jan 1998 12:45:43 +0000 (GMT)

> but it'd allow gcc to compile the thing into the linux kernel.
There's a few similar bits like that in the alpha kernel for much the same
job; It's not a big deal. The thing is though, why bother when it means
you've got another bit of code in the kernel that's just as good modular
(since it's probably not needed for *everything* - for example, embedded
ARM systems might not need FP at all).
I think it might be an idea for all the linux kernel stuff to be modular,
and include a semi-decent way of loading modules up from within a kernel
image (this goes for i386 too). initrd has the right idea, but it's not
ideal; We just want modules loaded up by the kernel at boot time - using a
whole FS and RAM disk etc. for that is overkill.
The other point is that if it worked that way (I guess I'm suggesting
something a bit like the RISC OS ROM here...) then we could rmmod modules
that were included with the kernel at boot-time and load up a replacement.
The best of both worlds - everything loaded at boot-time without needing
an FS, *and* modularity. :)
--
James Craig <[email-masked]>
	    <[email-masked]>
	    <[email-masked]>

---

From: Russ King <[email-masked]>
Date: Mon, 19 Jan 1998 13:01:51 +0000 (GMT)

> +++ pgtable.h   Sun Jan 18 23:33:22 1998

Change this to __virt_to_phys - it returns an unsigned long from an unsigned long.

> make: *** [linuxsubdirs] Error 2        

Which version of the binutils are you using?

>   Is it possible to compile the FP-emulation into the kernel?

Definitely not.  The FPEmulator is not part of the kernel since it is a copy of the Acorn FP Emulator
module in the RiscOS PRMs (modified under license).

>   Does anyone have a mkswap or swapon binary for ARM3?

The standard ones work.

---

From: Philip Blundell <[email-masked]>
Date: Mon, 19 Jan 1998 13:15:38 +0000

>but it'd allow gcc to compile the thing into the linux kernel.

No; I think you run into trouble with the GPL if you do that.

p.

---

From: Philip Blundell <[email-masked]>
Date: Mon, 19 Jan 1998 13:16:58 +0000

>(since it's probably not needed for *everything* - for example, embedded

The same code takes up less space in the kernel than as a module - quite 
noticeably so on ARM2/ARM3 systems.

p.

---

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

> but it'd allow gcc to compile the thing into the linux kernel.

The license intentionally protects Linux from such misuse
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]