Subject: Curtis-Mathes UniView 7500FE-based box

From: Chris Rutter <[email-masked]>
Date: Wed, 10 Nov 1999 19:33:22 +0000 (GMT)

The Curtis-Mathes UniView is a box best forgotten: it contains an ARM
7500FE, and enough standard hardware that RISC OS seems to run without
much modification on it.

What would be required to get Linux up and running on this box?  I see
a 7500 arch in the 2.3 tree, but that seems to have numbered IRQs and
references to ISA and so forth, so it looks like it has a more PCish
bus and wouldn't be suitable for this very Acorn-ish machine.

On that subject, what exactly constitutes an architecture (as in
`arch-rpc', `arc-cl7500', and so on)?  I see these various architecutres
which then contain, often, #ifdefs to do individual things based on
processor type, so it's not exactly clear *when* a new architecture
directory should be created (consider these two cases in point:
Riscstation and UniView).

Ta.

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

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

---

From: Dave Gilbert <[email-masked]>
Date: Wed, 10 Nov 1999 21:18:47 +0000 (GMT)

> 7500FE, and enough standard hardware that RISC OS seems to run without

Define much modification :-)

> Riscstation and UniView).

Well each architecture may consist of one or more machines which are
mostly alike; small differences can be taken care of within the
architectures. Ideally a kernel built for a particular architecture should
boot on any machine included in that architecture.

So if you Curtis thingamy box is basically the same as an existing
architecture with a couple of tweaks (preferably that you can figure out
at run time) then stay with that architecture.

Dave

-- 
 --------------------------------------------------------------------   
/ Dr. David Alan Gilbert      | Running Linux on           |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 ____________________________|___ http://www.treblig.clara.net   __/

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 11 Nov 1999 00:23:35 +0000 (GMT)

> bus and wouldn't be suitable for this very Acorn-ish machine.

There is no 7500 stuff in the 2.3 tree.

> Riscstation and UniView).

In general, if an architecture requires a load of #ifdefs in its
architecture specific directories, and there are a lot of them, then
it does not warrant living together.  With a "correct" design, there
should be zero #ifdefs in the architecture code since we have a
very efficient optimised way of causing GCC to "comment out" code
using the following:

	if (machine_is_xxx()) {
	}

At compile time, if support for machine xxx is not requested, it will
be evaluated as zero, and GCC will optimise out the unreachable code.
If, however, it is the only machine type selected, it will be evaluated
as non-zero, and GCC will optimise the condition away and include the
code.  If multiple machines are selected, GCC will leave the code in
along with the condition.

There are other factors that will affect your choice.  In general, I
do not like seeing the virt_to_phys() macros be anything other than
constant mathematical expressions (which will be a single instruction)
since page table walking uses these heavily.  Lookup tables and functions
occupy many instructions, and will impact heavily the speed at which
page tables can be traversed (they have to convert physical->virtual
for every second-level table).

Hope this helps.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |