On Apr 26, 2006, at 2:19 PM, Wolfgang Denk wrote:
In message <A8793E99-83C1-4FD9-8735- D2E8F98B3003@kernel.crashing.org> you wrote:
I think thats part of the idea with arch/powerpc defining a standard mechanism for how a boot loader should pass information to the kernel (via a flat device tree).
Yet another standard.
How would you propose that we handle booting arch/powerpc kernels from u-boot going forward? (for new board ports and existing board ports).
Ideally, I'd like to see a common kernel interface for all archi- tectures, PowerPC and ARM and MIPS and ... But last time I dared to suggest this I've been told what a nincompoop I am.
I will accept what is decided by the P.T.B., but I request not to break backwards compatibility with existing systems.
I've been thinking about the various issues related to booting an arch/powerpc kernel via u-boot. I was hoping to get some ideas/ comments on what people thought about the various issues/questions related to producing a system that can boot an arch/powerpc kernel for an embedded system. I'm using u-boot as the boot loader since its a popular choice (I imagine the issues are similar for others):
[NOTE: dts, flat dev tree, etc are used interchangeably]
1. boot with an "old" u-boot (via bd_t): * Have a boot wrapper that takes bd_t and dts and merges them @ runtime * Boot wrapper has to be custom based on bd_t definition for the system * dts owned by kernel??
2. boot with a "new" u-boot (has a .dts in it): * capable of booting arch/powerpc kernel directly w/o modification * in a production system don't want to update u-boot * dts owned by u-boot??
Some questions/issues: * ownership of .dts is problematic. I hate having a file duplicated by both u-boot and kernel. However it also seems bad to make the build of either depend on the user grabbing a dts from some third party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS port. Boards ship with an "old" u-boot, thus we need a kernel wrapper with .dts. However, newer u-boot's can (hopefully will) have a dts in them
* updating of dts: In case 1, this is trivial since its part of the kernel blob. Case 2. is more difficult. What do people think of treating the dts like the environment. You have a version compiled in, but can alternately have a blob in another location that will be used if exists. This would allow one to update the dts portion w/o effecting the actual boot loader.
* one solution to the copies of .dts is that we make the wrapper portion of the kernel the owner of the official latest and greatest .dts. Every so often a maintainer can sync their .dts with u-boot to keep them relatively in sync. However, the main mechanism would be to load the latest .dts blob into the secondary location. We can provide scripts/tools to do this via u-boot and linux.
comments, other issues people have thought of?
- kumar