Embedded 版 (精华区)

发信人: he (无情的雨), 信区: Embedded_system
标  题: linux for ppc chapter 10 
发信站: 哈工大紫丁香 (2001年06月04日11:04:57 星期一), 站内信件

----------------------------------------------------------------------------
----
10. Kernel
10.1 Series
You will need to decide whether to use a tried-and-tested stable series kern
el, or a development kernel. The choice will depend on your project requirme
nts, and how much work you want to do to port and maintain the kernel on you
r hardware. For any non-trivial project, you can expect several major kernel
 releases during the project's life. Consider the availability of the featur
es 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 activ
ely participate in future development of Linux itself, or require features a
nd/or board support only present in the development series.
Stable
Montavista
The latest stable kernel from the MontaVista Hard Hat Linux kit is probably
your best bet.
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/w
ip/ppc_8xx/RPMS
Denx Software Engineering
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/
Development
FSMLabs
http://www.fsmlabs.com/linuxppcbk.html.
The latest up-to-the-minute development kernel for PowerPC devices can be ac
cessed via a number of methods.
Official Sources
http://www.kernel.org/
Work is ongoing to merge the embedded PowerPC changes into the current devel
opment tree, but the latest PPC changes take some time to propagate here.
10.2 Memory Map
The boot loader is responsible for configuring the memory map before jumping
 to the Linux kernel. Embedded PowerPC processors provide extreme flexibilit
y 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.ht
ml 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 c
hanges to the ROM startup code, rather than the kernel itself. The other maj
or kernel effort required is in device drivers for new hardware devices.
10.4 Patches
Once you've got something working, there's an abundance of kernel patches av
ailable on the 'net which can help customise the kernel to your application.
 Patches are generally issued against a particular kernel version, but can o
ften be applied against other versions either automatically or with manual a
ssistance.
For a number of embedded-system related patches including kernel size optimi
sations, see: http://members.xoom.com/greyhams/linux/patches/
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 o
nes 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 of
fers an invaluable opportunity for peer review far beyond what is normally p
fers an invaluable opportunity for peer review far beyond what is normally p
ossible within a single organisation, and can save countless hours of unnece
ssary debugging.
10.6 Submitting Patches
In general, patches should be submitted in unidiff format to the mailing lis
t. Even if you submit them directly to the maintainer, remember to cc: a cop
y 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 su
bjective notion of correctness.
When working on the kernel, follow the guidelines in Documentation/CodingSty
le.
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.
----------------------------------------------------------------------------
---- 
--

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.235.250]