Ad-hoc arm board

[Dave Hylands]

Hi gaspa,

On Tue, Feb 8, 2011 at 2:47 AM, Andrea Gasparini <gaspa at yattaweb.it> wrote:
> Hi,
> Working on a custom arm based board, I'm currently juggling with mach-types
> and machine IDs for our ARM boards, but perhaps it came the time to set
> them in the right way...

You can request mach-type entries over here:
http://www.arm.linux.org.uk/developer/machines/

Generally, I would look at other machines in the arch/arm hiearchy.
The omap one is fairly complex. I think I used the mach-integrator as
my first example.

There are some guides to porting ARM boards.

The first one is quite old, and lots of the smaller details have
changed. This is what I used to get started.
<http://www.glomationinc.com/PortingLinuxKernel.pdf>

Some more recent ones:
<http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html#>
<http://free-electrons.com/doc/kernel-porting.pdf>

> And  moreover, do anyone has a pointer on documentation/articles/somewhat
> on how to write a good board-*.c and how (and perhaps when) to handle
> platform devices instead of a classical device driver? I'm  currently going
> by trying, and perhaps it's not the better method to achieve my purposes.

Generally speaking, when dealing with an SoC, most (if not all) of the
peripherals on the chip should be platform drivers.
There is some info in the Documentation directory:
<http://lxr.linux.no/#linux+v2.6.37/Documentation/driver-model/platform.txt>

One of the things you can do with platform devices/drivers is to split
the data from the code. So all of the things like peripheral base
address, irq, etc can all go in the platform data. Then the same
platform driver (especially when compiled as a module) can be used on
multiple boards.

Platform drivers also have some power management hooks for dealing
with suspend/resume.

Dave Hylands