In message 6E3621C5-A379-4ABC-99C0-9A02B48D525D@kernel.crashing.org Kumar Gala wrote:
- 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??
Since we cannot go back in time and fix the "old" U-Boot this seems to be the only option.
- boot with a "new" u-boot (has a .dts in it):
- capable of booting arch/powerpc kernel directly w/o modification
OK.
- in a production system don't want to update u-boot
Let's say we have to support such situations, too.
- dts owned by u-boot??
I'm not sure about this. I tend to believe the dts belongs to the kernel.
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
Can we provide the dts as a separate blob that gets built with the kernel image? From U-Boot's point of view, this could be a multi-file image which combines the dts and the kernel into a single file so that users don't have to care much about this.
- 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
I don't like this idea.
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.
If we consider this, then we might as well combine the dts with the kernel image. Alternatively, the dts might be stored in a separate location in memory. It would be easy to extend the "bootm" command to take an additional argument (dts address).
- 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.
Why not load it separately or as part of the Linux kernel image?
Best regards,
Wolfgang Denk