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 requirments, 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 and/or board support only present in the development series.
The latest stable kernel from the MontaVista Hard Hat Linux kit is probably your best bet.
Also, check for later updates in: ftp://ftp.mvista.com/pub/CDK/updates/,
or for the very latest work-in-progress, see: ftp://ftp.mvista.com/pub/CDK/wip/ppc_8xx/RPMS
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/
http://www.fsmlabs.com/linuxppcbk.html.
The latest up-to-the-minute development kernel for PowerPC devices can be accessed via a number of methods.
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.
The boot loader 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.
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 ROM startup code, rather than the kernel itself. The other major kernel effort required is in device drivers for new hardware devices.
Once you've got something working, there's an abundance of kernel patches available on the 'net which can help customise 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.
For a number of embedded-system related patches including kernel size optimisations, see: http://members.xoom.com/greyhams/linux/patches/
Peter Allworth has some kernel patches at: http://www.zeta.org.au/~linsol/
The people who actively contribute to open source development are also the ones that 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 organisation, and can save countless hours of unnecessary debugging.
In general, patches should be submitted in unidiff format to the mailing list. 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 http://www.gnu.org/prep/standards_toc.html.
And remember, you don't have to like the guidelines, you just have to follow them.