Hi gaspa, On Tue, Feb 8, 2011 at 2:47 AM, Andrea Gasparini <gaspa@xxxxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
