-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 14 Sep 2012 09:45:35 -0600 Stephen Warren swarren@wwwdotorg.org wrote:
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:
- 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.
honestly im not 100% sure where it comes from but you just need to do "bootz ${kernel_addr_r} ${initrd_addr_r} ${fdt_addr_r}" for example you need to load the kernel and initrds to first but the u-boot they ship takes care of loading/building however it does it putting the dtb into that location, you just need to use it.
- 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.
appended is really ugly but neccesary when you dont have a u-boot supporting 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?
the bigger issue is not that that boards cant be updated, its that the vendors have not shipped updates supporting dtb
In other words, I hope everyone is already doing what I think you're saying Calxeda is doing, except for legacy bootloaders.
calxeda are doing a few things right, they make using dtb easy, they make working with u-boot pretty easy from a generic distro point of view.
Dennis