Subject: Re: ARM and RPM

From: Philip Blundell <[email-masked]>
Date: Wed, 01 Jul 1998 10:18:33 +0100

>> A better solution may be to use ARMv3 and ARMv4, since there can be
>> no mistaking these.
>
>I agree.  Shall we etch this one in stone then?

Okay, sold.

p.

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

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 1 Jul 1998 12:34:10 +0100 (BST)

> >I agree.  Shall we etch this one in stone then?

This now means that we've covered the ARM6, ARM7 and StrongARM-based processors.
We still need to sort the older ARM2, ARM250 and ARM3 processors.

I suggest using ARMv1 for ARM2, and ARMv2 for ARM250 and ARM3.  The reasoning
behind this is that ARM250 and ARM3 have the SWP instruction, whereas ARM2
doesn't.

Therefore, when using GCC, it may produce SWP instructions for ARM3
processors, which will then mean that the binary will not run on an ARM2.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Philip Blundell <[email-masked]>
Date: Wed, 01 Jul 1998 14:24:08 +0100

>behind this is that ARM250 and ARM3 have the SWP instruction, whereas ARM2

I think I can go along with that.  ARM1 cpus could always be ARMv0. :-)

>processors, which will then mean that the binary will not run on an ARM2.

Actually, GCC doesn't do that.  LinuxThreads and the kernel are the only place 
you're likely to find SWP, at least at the moment.  But I guess it never hurts 
to be careful.

p.

---

From: John Vickers <[email-masked]>
Date: Wed, 01 Jul 1998 14:58:31 +0100 (BST)

On Wed 01 Jul, Russell King - ARM Linux Admin wrote:
[...]
> This now means that we've covered the ARM6, ARM7 and StrongARM-based processors.

What were you going to do for Strongarm/IOMD ?
That's ARMv4h in this scheme, right ?

> processors, which will then mean that the binary will not run on an ARM2.

I don't think that's a problem.
It's not really a kind of instruction a compiler (well not gcc/egcs
anyway) is likely to generate.  The current cvs egcs doesn't generate it.

BTW, I don't think it would be very hard to hack the arm md to handle
ARM1 ...

John.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 1 Jul 1998 16:13:04 +0100 (BST)

Philip Blundell writes:
> >Although this is true, it is still possible that a binary could contain SWP
> >instructions, which would then affect it's binary compatability.
> 
> I think the "don't do that then" rule covers this (and even the halfword issue) 
> really.  If you want portability, don't use those instructions. 

But Corel's VNC RPMs will be using the halfword instructions, and I get this
feeling of people mailing to say that they've installed the Corel RPMs and
nothing works now...

I wasn't thinking in terms the user, not the package maintainer anyway.
   _____

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 1 Jul 1998 15:54:25 +0100 (BST)

> That's ARMv4h in this scheme, right ?

Yep.  In this email message, I was considering using armv4h for half-word capable
machines (DECs EBSAs, Corels VNC etc) and armv4 for the RiscPC.  I am still proposing
this as a variation, but no one else has particularly commented on this yet.

---

From: Philip Blundell <[email-masked]>
Date: Wed, 01 Jul 1998 15:59:11 +0100

p.

---

From: Richard Bradbury <[email-masked]>
Date: Wed, 01 Jul 1998 16:33:18 +0100

On Wed, 01 Jul 1998 15:06:33, Russell King - ARM Linux Admin wrote:
>
> Ok, so what I'm intending to do (for next weeks patches) is to:
> 1) Make uname -m more useful, specifically:
...
> Could you let me know ASAP whether these are acceptable?

Will "uname -p" return the actual CPU model?, viz:

uname (GNU sh-utils) 1.16
  -m, --machine    print the machine (hardware) type
  -p, --processor  print the host processor type

-- 
R.

---

From: Philip Blundell <[email-masked]>
Date: Wed, 01 Jul 1998 15:48:12 +0100

>   Hardware  - the hardware that the kernel was compiled for/hardware
>		type passed to kernel on initialisation.
>		(shall be useful for keyboard maps - RiscPC against A5000
>		 against PC keyboard).
>   Optimistaion - Processor type used to optimise the kernel
>   IO Bus    - Currently Acorn or PCI (again obvious).  It could be a
>		list in the future (Acorn,PCI for instance).

I'm not convinced those belong in cpuinfo but if you want to put them in I 
won't try to stop you.

>4) ELF_PLATFORM.  Currently, it is set to one of arm2, arm3, arm6, sa1x.
>   I think it would be better if it returned something more descriptive,
>   in a similar way to uname -m.  They will be kept separately for max
>   flexibility, and I propose to use (at the moment) the last 3 chars
>   of uname -m.

Keep it simple - just use the same string as uname -m returns.  We've already 
decided that uname -m will be able to encode virtually everything about a 
platform.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 1 Jul 1998 16:10:14 +0100 (BST)

> decided that uname -m will be able to encode virtually everything about a 

Will do.  I just thought that you'd have an argument for keeping it as short
as possible ;)
   _____

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Wed, 1 Jul 1998 15:06:33 +0100 (BST)

armv1l => ARM2
	armv2l => ARM3, ARM250
	armv3l => arm version 3 little endian (ARM6, ARM7)
	armv4l => arm version 4 little endian (StrongARM)

   where 'l' indicates little endian, and 'b' for big endian (if someone
   builds such a machine).

2) /proc/cpuinfo changes format, to give more useful information, eg:

	Processor	: DEC sa110 rev 1
	BogoMips	: 190.34
	Hardware	: Acorn-RiscPC
	Optimisation	: StrongARM
	IO Bus		: Acorn

   Processor - manufacturer, type, and revision of processor.
   Bogomips  - obvious

   Although this information is of limited use, it should be more useful
   than it's previous version.

3) ELF_HWCAP is now used by the kernel, depending on the CPU type, can have
   HWCAP_SWP and/or HWCAP_HALF set (SWP/LDRH).  Others can be added later
   if needed.

---

From: Matthew Wilcox <[email-masked]>
Date: Wed, 1 Jul 1998 17:06:27 +0100 (BST)

Philip Blundell
> I think the "don't do that then" rule covers this (and even the halfword
> issue) really.  If you want portability, don't use those instructions. 

Well, yes, *but* GCC will generate these instructions.  So I guess all
binaries should be built with -marmv3 (maximum)

-- 
Set Alias$Case Set Alias$[ |||| |MSet Alias$Otherwise Set Alias$[ \ Matthew
"" |MSet Alias$When If %0=%%0 Then Set Alias$[ "" ||MIf %0=%%0    \ Wilcox
Then Set Alias$Otherwise Set Alias$[ |||||||||||||||| ||MIf       \
%0=%%0 Then Set Alias$When Set Alias$[ ||||||||||||||||
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Wed, 01 Jul 1998 17:14:30 +0100

>binaries should be built with -marmv3 (maximum)

For binaries that you want to distribute, yes.  Remember that the architecture 
check will only help to stop you from installing the wrong thing - it won't 
make binaries run on the wrong processor.

In the same way, Intel binaries for distribution are built without using any 
Pentium-specific instructions.

People like Corel who are targeting one particular platform might decide to 
distribute binaries with -march=armv4 of course but that's different.

p.

---

From: John Vickers <[email-masked]>
Date: Wed, 01 Jul 1998 16:41:20 +0100 (BST)

> feeling of people mailing to say that they've installed the Corel RPMs and

But your scheme handles the halfword thing already ! (Which seems a lot
more of an issue than swp, which only affects ancient machines,
and is even then a bit obscure for user code).

John.

---

From: Phil Norman <[email-masked]>
Date: Wed, 1 Jul 1998 17:58:28 +0100 (BST)

> and is even then a bit obscure for user code).

Actually, SWP is really a Bad Thing (TM) for future technologies.  SWP,
for some reason, bypasses the cache.  This generates BIG problems if you
have multiple processors.  SWP bypassing the cache is especially bad since
it means there isn't an atomic instruction for swapping if you want
multiprocessing to work properly (unless you do kludgy things).  So maybe
SWP should be avoided altogether?

-- 
Rule of programming #1: Everything that can go wrong will go wrong,
        except when you're running the debugger.

Phil Norman, mailing from Oregan Networks.
email:	[email-masked]
URL:	http://newton.ex.ac.uk/general/ug/norman

---

From: Philip Blundell <[email-masked]>
Date: Wed, 01 Jul 1998 19:01:21 +0100

>Will "uname -p" return the actual CPU model?, viz:

Let's worry about one thing at a time.  I agree that having that behaviour is 
desirable but it's a lot less urgent.

p.

---

From: "Neil A. Carson" <[email-masked]>
Date: Wed, 01 Jul 1998 19:33:50 +0100

> SWP should be avoided altogether?

Whaaaat? Can you tell me how it would work if it *didn't* bypass the
cache?

	Regards,

	Neil

-- 
Neil A. Carson

---

From: Phil Norman <[email-masked]>
Date: Wed, 1 Jul 1998 23:18:41 +0100 (BST)

> Whaaaat? Can you tell me how it would work if it *didn't* bypass the

I'm not a great expert on hardware so I don't know.  However, the fact
remains that this is a problem.

-- 
Rule of programming #5: If a C program gives more than 50 compiler
        errors, you've missed out a semicolon.

---

From: Philip Blundell <[email-masked]>
Date: Wed, 01 Jul 1998 23:39:55 +0100

>remains that this is a problem.

Why do you think it's a problem?

p.

---

From: Phil Norman <[email-masked]>
Date: Thu, 2 Jul 1998 09:08:17 +0100 (BST)

> Why do you think it's a problem?

As I mentioned in my first reply on this thread, because SWP is an
exceptionally useful instruction for changing the state of processes etc
atomically.  However, in multiprocessor situations (ie possibly the coming
Pheoble^H^He) because it bypasses the cache, any trans-processor talking
which is implemented in order that the different processor caches are kept
up to date with each other, won't work.

I'm not amazingly sure about the details of this, but I think that's about
right.

---

From: Matthew Wilcox <[email-masked]>
Date: Thu, 2 Jul 1998 10:47:35 +0100 (BST)

Neil A. Carson
> Whaaaat? Can you tell me how it would work if it *didn't* bypass the

Okay, this is partly my fault: I seem to have explained the problem to Phil
imperfectly.

SWP was defined to be an indivisible load-and-store instruction to allow
for mutexes to be implemented efficiently.  In order to work with SMP
systems, it _must_ bypass the cache, irrespective of the setting of the
cacheable bits and this is how it works on the ARM3, ARM610 and ARM710.
The Really Bad Thing is that on StrongARM, SWP does _not_ bypass the
cache, which makes life harder for SMP systems.  Of course, this isn't
the only `interesting' feature of the StrongARM's cache, but this
has been discussed ad nauseam previously on this list and those who
are interested may grep the archives.  One work-around is to put all
semaphores in an uncached page.  Another is to disable the data cache
entirely and put a shared discrete cache on your SMP processor card,
as Acorn are rumoured to be doing for Phoeb[l]e.

If I've misheard a rumour, I'd like to apologise now and hope that
someone will correct me authoritatively.

---

From: Alan Cox <[email-masked]>
Date: Thu, 2 Jul 1998 11:47:30 +0100 (BST)

> semaphores in an uncached page.  Another is to disable the data cache

Thats actually pretty horrible as soon as you want semaphores in structures
For global sempahores its easy. You can use the __initdata type trick
and have an __uncached 

> as Acorn are rumoured to be doing for Phoeb[l]e.

Shared caches do not work very well from the Intel experience. The biggest
single win for PPro over Pentium SMP was the local L2 caches as well as
local L1.

Having a page for semaphores isnt that uncommon a technique. There are
SMP MIPS boards around that actually have an I/O device which is a set
of semaphores as the older MIPS couldnt do the job itself directly.

---

From: Paul Koning <[email-masked]>
Date: Thu, 2 Jul 1998 09:40:01 -0400

>>>>> "Matthew" == Matthew Wilcox <[email-masked]> writes:

 Matthew> SWP was defined to be an indivisible load-and-store
 Matthew> instruction to allow for mutexes to be implemented
 Matthew> efficiently.  In order to work with SMP systems, it _must_
 Matthew> bypass the cache, irrespective of the setting of the
 Matthew> cacheable bits and this is how it works on the ARM3, ARM610
 Matthew> and ARM710.  The Really Bad Thing is that on StrongARM, SWP
 Matthew> does _not_ bypass the cache, which makes life harder for SMP
 Matthew> systems.

I don't see why that's bad.  It's perfectly reasonable for CPU
designers not to put another special case in the logic.  After all, if 
you have a variable that's accessed with SWP (bypassing the cache) AND 
with any other instruction, it won't work right if the variable is in
cached space.

Conversely, if you put the variable in uncached space, SWP needs no
special handling.  Fewer gates taken, which is a Good Thing,
especially if those gates are removed from a critical timing path
(which may be the case) thereby speeding up everything in the whole
processor. 

Isn't it the rule of RISC to move to software those things that don't
absolutely have to be done in hardware?

	paul

---

From: Timothy Baldwin <[email-masked]>
Date: Thu, 02 Jul 1998 22:08:43 +0100

In message <[email-masked]>

>    where 'l' indicates little endian, and 'b' for big endian (if someone

I would suggest omitting both the 'l' and the 'b' mixed endianess systems,
if support ever get coded into the kernel. (At least some hardware is
capable, by changing the processor endianess on the fly.)

>       Processor       : DEC sa110 rev 1

Would it be helpful and possible to be more specific about the
type of Acorn IO Bus?
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Alan Cox <[email-masked]>
Date: Thu, 2 Jul 1998 22:22:54 +0100 (BST)

> capable, by changing the processor endianess on the fly.)

Well if both get in I guess we use armv3*

---

From: Philip Blundell <[email-masked]>
Date: Thu, 02 Jul 1998 22:30:09 +0100

>Would it be helpful and possible to be more specific about the

Possible yes, but only on the basis of the machine type you configured your 
kernel for - helpful no.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 2 Jul 1998 22:47:21 +0100 (BST)

> Well if both get in I guess we use armv3*

*8-)

Seriously tho, it's not a good idea to switch endianess on the fly.  Nasty
thinks happen.  It's about as insane as switching the MMU off on the fly
and expecting Linux to carry on working.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Alan Cox <[email-masked]>
Date: Thu, 2 Jul 1998 23:18:08 +0100 (BST)

> and expecting Linux to carry on working.

The final , never relesed version of RiscOS (the MIPS unix not the acorn
one) supported running both endian user mode binaries at once
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: "Neil A. Carson" <[email-masked]>
Date: Fri, 03 Jul 1998 00:02:48 +0100

> as Acorn are rumoured to be doing for Phoeb[l]e.

Good description of SWP, much better than mine! Semaphores have to go in
an uncached area with SA, I think. Bit silly really---but not
impossible.

Pretty unlikely I would think. As the bus clock can't run at more than
66MHz on current chips, and the current speed of main memory can exceed
this on bursts (100MHz), there's no point in putting a cache on the
outside---main memory may just as well be used instead :) If SA could
run its external bus at say 200MHz, then I guess one could implement an
external cache effectively. However, this is unlikely to happen. This
effectively means that efficient SMP with StrongARMs is impossible.

> someone will correct me authoritatively.

Not authoritative, just technical :)

	Regards,

	Neil

-- 
Neil A. Carson

---

From: "Neil A. Carson" <[email-masked]>
Date: Thu, 02 Jul 1998 23:59:47 +0100

> I'm not amazingly sure about the details of this, but I think that's about

Not quite. Normally systems like this need to be able to use atomic
read-modify-write or superset TAS (test and set) instructions over a bus
to something such as a semaphore, in order to easily gain and release
locks (at the lowest level). In order to do this, the bus transaction
_has_ to be atomic, which it can't be on an ARM unless it bypasses
cache.

-- 
Neil A. Carson

---

From: Alan Cox <[email-masked]>
Date: Fri, 3 Jul 1998 13:53:36 +0100 (BST)

> outside---main memory may just as well be used instead :) If SA could

Latency. Its 7 bus clocks to start an SDRAM burst then 1 per read

---

From: "Neil A. Carson" <[email-masked]>
Date: Sat, 04 Jul 1998 17:07:09 +0100

> Latency. Its 7 bus clocks to start an SDRAM burst then 1 per read

Given accesses to most areas are cached, which burst four words in a
row, and unlike Intel architecture the SA can't terminate a bus cycle
early so the SRAM gain is potentially less than on the Intel
architecture. However, I do take your point---however when Acorn tried
some SRAM for their kernel, they found it didn't make any niticable
difference.

What we want is to fill a machine with the new 100MHz EDO :)

	Neil

-- 
Neil A. Carson

---

From: Philip Blundell <[email-masked]>
Date: Sat, 04 Jul 1998 22:00:59 +0100

>row, 

In enhanced mode, though, it can arrange to get the word you're trying to load 
in the first access.  If you can do this in a single cycle rather than having 
to wait for the SDRAM initial access time, it can be an improvement - 
even if your memory unit is still tied up for a fairly long time afterwards.

p.

---

From: "Neil A. Carson" <[email-masked]>
Date: Sat, 04 Jul 1998 23:17:27 +0100

Point taken :)

	neil

-- 
Neil A. Carson