-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 14 Sep 2012 09:45:35 -0600 Stephen Warren <[email protected]> wrote:
> On 09/13/2012 11:18 PM, Peter Robinson wrote: > > > > On 13 Sep 2012 20:40, "Stephen Warren" <[email protected] > > <mailto:[email protected]>> 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. 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. > > 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. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBTVawACgkQkSxm47BaWfdwCQCdFfOIcTtlTyFxxyQK8Yz5OOLx 5DsAn3kkmczCQbP5HUKEVDcqJXhjrdBX =y6M3 -----END PGP SIGNATURE----- _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
