Subject: Port to new ARM platform

From: Carl Price <[email-masked]>
Date: Thu, 15 Apr 1999 13:15:35 -0700 (PDT)

Hi all,

   I have been hanging out mostly on the C7110 list and saw a link
to this list.  What I want is an idea of where to start on doing a 
port to a new ARM platform.  I have the Linux Device Drivers book and
have downloaded The Linux Kernel, but I don't see a lot of documentation
on what needs to be done to go to a new platform, just how to work on 
an existing platform.

   So on to what I want to do.  I have just gotten a HP Jornada 820 from
work, and I would like to see about putting Linux on it instead of WinCE.
(For those not familiar, this is a StrongArm 1100 w/SA1101 companion chip).

   I hope to be able to keep all I do documented as I go, so hopefully in
the future others will be able to look at the documentation to get an idea
of what they need to do to port to a new platform.

   Any pointers would be welcomed.

--Carl

*****************************************************************************
*** Carl W. Price          [email-masked]                  ****   /    ****
***                                                          ***   /__ __ ***
*** All opinions are my own and in no way represent the      ***  /  //_/ ***
*** views and opinions of hp or any of it's employees.       ****    /   ****
*******************************************************************ICBD******
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Thu, 15 Apr 1999 21:54:27 +0100

>(For those not familiar, this is a StrongArm 1100 w/SA1101 companion chip).

Try the sa1100-linux list as a starting point.  I imagine most of the 1100 
hackers probably read this mailing list too but you never know.

Since the 1100 architecture is relatively "closed" in that a lot of stuff is 
on chip, you should find that the Brutus port contains most of what you need 
to get going.  It's a very long time since I worked with the 1101 and I don't 
remember enough about it to say what you'd have to do in order to get it to 
perform.

As to what you actually have to *do*, the best thing is just to read the code, 
look for the system-specific bits (most are concentrated in include/asm-arm/
arch-*) and figure out how to fill in the appropriate bits for your platform.  
If you have devices that are currently unsupported you will need to write new 
drivers for them too.

p.

---

From: Werner Almesberger <[email-masked]>
Date: Fri, 16 Apr 1999 00:04:09 +0200 (MET DST)

[ Copied to linux-7110, mainly for the merging bit at the end. ]

Carl Price wrote:
> What I want is an idea of where to start on doing a port to a new ARM
> platform.

This is roughly what was done for the Linux-7k port (BTW, there should
be the original timeline on Calcaria - it doesn't reflect exactly what
was done, but it's still a surprisingly good approximation):

1) Gather as much documentation about the hardware as possible. Then read
   it and get an idea of what Murphy may have in store for you. (E.g. on
   the Psion, the scattered memory model was a deeply nasty surprise for
   me.) Some of the fundamental problems you discover at this point may
   influence some larger-scale design, so it's good to do this early.
2) Solve the booting problem: how to bring the machine from a state where
   you can interfere with its operation to a state where a piece of your
   code runs with full privileges (i.e. the CPU's supervisor mode, or
   whatever it is called). This may require tools to develop under the
   "native" OS (EPOC, WinCE, ...).
3) Design a memory model for the early kernel. This includes well-known
   IO areas, parameters passed during boot, perhaps free memory lists,
   page tables, interrupt/exception vector tables, etc. Start thinking
   about initrd too. (You'll eventually want to suport it anyway, and it
   may be a long time until you can access CFs, PCMCIA, disks, etc.)
4) Make head-*.c work, then the beginning of init/main.c. As soon as you
   can write some character(s) to the serial port from main.c (no matter
   how you do it - just fiddling with port bits is okay at this point),
   your project is in good shape.
5) Get the timer and interrupts to work.
6) Get your initial console, either on a serial port or on the LCD.
7) Add drivers for all the rest, in whichever order you like.
8) Solve power management :-)

The 7k port may be a useful thing to look at, because it hasn't been
merged with the ARM branch yet (*), so all the differences are trivial
to find, and also because it targets a similar hardware environment.
E.g. the PCMCIA point enabler may be useful for you. (Even in the
current state of the 7k port, getting the "standard" Linux PCMCIA tools
to work would be a major effort.) In order to get an idea for what is
needed, you may want to have a look at the earliest patch that does
what you need, then look at a recent one for the actual implementation.

(* If the Brutus port suggested by Philip is in a similar state of
   separation, it is of course a better choice also for the overview.
   For any actual hardware-related issues, you'll need it anyway.)

Talking about merging: 7k now has a few components that will need to be
merged with the mainstream at a comparably high level. The "smart"
sticky keys (they make Shift and friends behave like on the HP100/200LX)
are architecture-independent and so is the PCMCIA point enabler (the
latter needs a bit of streamlining, but most of the code is generic).
This means that they'll have to wait for 2.3 to start.

After that, I plan to wait until those changes trickle back into the ARM
mainstream, and then more can be merged into the ARM branch.

Other, possibly more contentious bits to be merged "high" are:
 - handling of system-specific keys (0xfxx; things like backlight on/off,
   contrast +/-, power on/off, etc.)
 - power management (needs more field experience)
 - maybe uwire

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, DI-ICA,EPFL,CH   [email-masked] /
/_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Nicolas Pitre <[email-masked]>
Date: Thu, 15 Apr 1999 21:19:13 -0400 (EDT)

> (For those not familiar, this is a StrongArm 1100 w/SA1101 companion chip).

Linux already run on the SA1100 and I maintain some patches for it that
you can find at ftp.cam.org/users/nico.  Most basic drivers are in there
and the whole thing should be mature enough to be merged into the main ARM
Linux tree soon.  Until then I suggest you look at my ftp site for patches
and some (a bit outdated now) notes for them.

Many SA1100/Linux developers are mostly communicating on the
[email-masked] mailing list.  I suggest you subscribe to it.
On www.arm.linux.org.uk you'll find a link to the Itsy project which host
the mailing list mentionned above.  There is also few others projects out
there running Linux on the SA1100 but we probably miss a web page to
reference all of them...

>    Any pointers would be welcomed.

All of these are useful:

http://www.inkvine.fluff.org/~chris/arm-tools.html
ftp://ftp.cam.org/users/nico/
http://ssdl-redstone.stanford.edu/~zskiraly/salinux
http://www.tazenda.demon.co.uk/phil/armlinux/
http://www.arm.linux.org.uk/
... and the SA1100-Linux mailing list.

I suggest that you target diff-2.2.3-rmk2-np5.gz since the frame buffer
driver seems to be broken with diff-2.2.5-rmk4-np6.gz at the moment.

PS: I'm on vacation from now until the 27th.  So I'm off the net til then.

Nicolas Pitre, B. ing.
[email-masked]