Skip to main content.

10. Kernel

10.1. Series

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.

10.1.1. Stable

10.1.1.1. Montavista

The latest stable kernel from the MontaVista? HardHat Linux 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: ftp://ftp.mvista.com/pub/CDKit/wip/ppc_8xx/RPMS

10.1.1.2. DENX Software Engineering

ftp://ftp.denx.de/pub/LinuxPPC/usr/src/

10.1.2. Development

http://www.kernel.org/ and http://penguinppc.org

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.

10.2. Memory Map

The bootloader 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.

See: http://lists.linuxppc.org/listarcs/linuxppc-embedded/200005/msg00157.html

also check out Documentation/IO-mapping.txt in the kernel source tree.

10.3. Porting

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 code, rather than the kernel itself. The other major kernel effort required is in devicedrivers for new hardware devices.

10.4. Patches

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 at http://www.zeta.org.au/~linsol/

10.5. Contributing

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.

10.6. Submitting Patches

In general, patches should be submitted in unidiff format to the linuxppc-embeddedmailinglist. 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.

10.7. Coding Style

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 http://www.gnu.org/prep/standards_toc.html

9. Boot Loader 1. Introduction 11. Device Drivers
Prev Home Next