-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 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.
I was wondering what the distros were planning to do, or has it even been considered? Fedora 18 will likely ship 3.6.x but will be updated to 3.7.1 likely and also 3.8.x if not 3.9.x We get the joy of things breaking every kernel release because no one else seems to be testing or using the upstream kernel.
I would like to see us as distros and linaro go to the vendors and get them to ship dtb files and updated u-boot with dtb support. Ideally with some consistent macro use to make distro support of u-boot saner. appended dtb is pretty ugly and I do not want to support it. I feel like we have an opportunity here to correct some of the wrongs of the past as u-boot updates will be forced on the world to deal with the forced move to DeviceTree. do we have vendors on this list? if not can we get the list of contacts and reach out to them to get things straightened up?
Dennis
On 09/13/2012 11:32 AM, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 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.
Thanks. :)
Just so you know, the long term plan is to split dts files out of the kernel. It is there now for historical reasons (ppc was already there) and because things are changing rapidly for the ARM dts files. Generally speaking, the dtb's and kernels don't need to be in sync and it should be considered a kernel bug if a new kernel does not work with an older dtb. Likewise, new dtb's should not break old kernels.
Ubuntu is building at least the highbank dtb now, but it is primarily for running qemu.
I was wondering what the distros were planning to do, or has it even been considered? Fedora 18 will likely ship 3.6.x but will be updated to 3.7.1 likely and also 3.8.x if not 3.9.x We get the joy of things breaking every kernel release because no one else seems to be testing or using the upstream kernel.
I would like to see us as distros and linaro go to the vendors and get them to ship dtb files and updated u-boot with dtb support. Ideally with some consistent macro use to make distro support of u-boot saner. appended dtb is pretty ugly and I do not want to support it. I feel like we have an opportunity here to correct some of the wrongs of the past as u-boot updates will be forced on the world to deal with the forced move to DeviceTree. do we have vendors on this list? if not can we get the list of contacts and reach out to them to get things straightened up?
At least some vendors are.
There was some discussion about u-boot standardization recently on this list, but it was more on the environment side and boot device selection. There is already a default config in u-boot, but that still leaves off lots of things. Perhaps creating a "standard" config that platforms include would be the first step. This could turn on EFI partitions, ext2 fs, hush shell, FDT, etc. Dealing with old bootloaders is still another issue.
Rob
Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlBSCpsACgkQkSxm47BaWfcHeACeOkvZUdoGQOKBI9u2K/g5Fjct BTEAn2ArwfQbGTVcmFK3y/FzJDsftGQq =wMfb -----END PGP SIGNATURE----- _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
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.
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?
Thanks.
On 13 Sep 2012 20:40, "Stephen Warren" 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?
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.
Peter
Thanks.
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
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.
-----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
-
Dennis Gilmore -
Peter Robinson -
Rob Herring -
Stephen Warren