[ 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 PROTECTED] /
/_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
