On 09/13/2012 11:18 PM, Peter Robinson wrote:
On 13 Sep 2012 20:40, "Stephen Warren" <swarren@wwwdotorg.org mailto:swarren@wwwdotorg.org> wrote:
On 09/13/2012 10:32 AM, Dennis Gilmore wrote:
Hey all,
So as distros we are soon going to be forced to support DTB files. Fedora likely sooner than the rest as we closely follow the mainline kernel throughout the life of a fedora release. Ideally the device manufacturers will provide dtb files. but then devices like the pandaboard, beagleboardXM etc with no storage to speak of we have to ship u-boot so likely will need to ship dtb files also. so far the best
At this stage in ARM development, the source of .dtb files is generally the kernel build. Shipping U-Boot+DTB and kernel rather than U-Boot and kernel+dtb is probably not going to work out very well.
Could you elaborate why?
It's fairly early days for device tree on ARM. Hence, the bindings are not set in stone. In general, people try hard not to make incompatible changes, but it's still possible for that to happen if needed.
As Rob mentioned, eventually the .dts files should be moved out of the kernel source tree. I believe that's the point when the bindings are considered stable (or perhaps that action will be triggered by them being stable).
Also note, this is nothing to do with APPENDED_DTB vs not; more on that below.
vendor i know of for dtb support is calxeda. and thats where we should encourage vendors to emulate, but until we get to there we need to take baby steps.
For the rest of us, can you please describe what Calxeda is doing, so we know what to emulate?
Their uboot supplies the dtb so you don't need to append it to the kernel, I'm sure they the best to go into all the tech details.
What do you mean supplies? There are two different issues here:
1) The source of the dtb; was it built from the .dts in the kernel source tree, built from .dts from some other place, or run-time generated by the bootloader/firmware.
2) How was the dtb passed to the kernel; it can either be passed by the bootloader as a separate blob, or can be appended to the kernel image using CONFIG_APPENDED_DTB.
The two are largely orthogonal (well, run-time generation of the dtb image probably isn't compatible with CONFIG_APPENDED_DTB unless you do some extra work in the bootloader and duplicate the kernel build process...)
For (1) above, right now, I believe it's typical to use the .dtb built by the kernel boot process for all SoCs/boards.
For (2) above, having the bootloader pass the dtb to the kernel separately is certainly the preferred mechanism; CONFIG_APPENDED_DTB is really a fallback for boards where the bootloader can't be upgraded. Are there boards like this that recent distros are running on?
In other words, I hope everyone is already doing what I think you're saying Calxeda is doing, except for legacy bootloaders.