You will need to decide whether to use a tried-and-tested, stable
series kernel, or a development kernel. The choice will depend on
your project requirements and how much work you want to do to port
and maintain the kernel on your hardware. For any non-trivial project,
you can expect several major kernel releases during the project's life.
Consider the availability of the features you need, how leading edge
you want to be, and the likely status of each kernel series by the time
you're ready to ship.
You are probably best off using the stable version, unless you want to actively
participate in future development of Linux itself, or require features or board
support only present in the development series.
The latest stable kernel from the MontaVista?
kit is probably your best bet.
Also, check for later updates in ftp://ftp.mvista.com/pub/CDKit/updates/
For the very latest work-in-progress, see:
Work is ongoing to merge the embedded PowerPC
changes into the current
development tree, but the latest PPC changes take some time to propagate here.
is responsible for configuring the memory map
before jumping to the Linux kernel. Embedded PowerPC
processors provide extreme
flexibility for address mapping of internal and external devices. You should
use this flexibitily to configure the memory map of your board to match the
needs of the Linux kernel, rather than modify the Linux kernel MMU
handling to match some arbitrary addressing scheme.
also check out Documentation/IO-mapping.txt
in the kernel source tree.
Provided that the CPU
you are using is already supported in
the kernel, most of the work involved in porting Linux to a new platform
actually involves changes to the ROMstartup
than the kernel itself. The other major kernel effort required is in
for new hardware devices.
Once you've got something working, there's an abundance of kernel patches
available on the Internet which can help customize the kernel to your
application. Patches are generally issued against a particular kernel
version, but can often be applied against other versions either automatically
or with manual assistance. The latest patches are usually available from
the linuxppc-embedded mailing list. Peter Allworth has some kernel patches
The people who actively contribute to open source development are also
the ones who benefit the most from it, so it makes sense to actively
contribute wherever you can.
Virtually all the existing embedded Linux code is covered by the GPL
which requires you to redistribute any changes you make. Contributing
your work offers an invaluable opportunity for peer review far beyond
what is normally possible within a single organization and can save
countless hours of unnecessary debugging.
In general, patches should be submitted in unidiff format to the
Even if you submit them directly to the maintainer,
remember to cc: a copy to the mailing list, to keep everyone else informed
of what's going on. If it's large, put it up for ftp and post a pointer instead.
When working on an existing code base, you should always use whatever
coding style is used in the existing code. Consistency here is better
than your subjective notion of correctness.
When working on the kernel, follow the guidelines in Documentation/CodingStyle
When working on other GNU software, follow the guidelines at