[opensuse-arm] [RFC] Moving beagle and panda to Device Tree
Hi, it seems that panda and beagle legacy support (I mean non Device Tree support) will be dropped more or less quickly. To prepare openSUSE for the switch, I made dtb-omap3-beagle and dtb-omap4-panda packages in my home repo. Where should I submit them? openSUSE:Factory:ARM, or a devel project? Moreover, I made those packages 'noarch' type since DTB is not arch specific but it would also make sense to make them 'armv7' arch type since it is only used on armv7 boards. Instead of making a package for each board, another way would be to build all DTB supported by our kernel version (using 'make dtbs' while building linux kernel, for each flavour), but DTB may be removed from kernel sources since they should not be kernel specific. What is your opinion? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 20.09.2013 um 09:56 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Hi,
it seems that panda and beagle legacy support (I mean non Device Tree support) will be dropped more or less quickly. To prepare openSUSE for the switch, I made dtb-omap3-beagle and dtb-omap4-panda packages in my home repo. Where should I submit them? openSUSE:Factory:ARM, or a devel project? Moreover, I made those packages 'noarch' type since DTB is not arch specific but it would also make sense to make them 'armv7' arch type since it is only used on armv7 boards.
Instead of making a package for each board, another way would be to build all DTB supported by our kernel version (using 'make dtbs' while building linux kernel, for each flavour), but DTB may be removed from kernel sources since they should not be kernel specific.
What is your opinion?
It is a pretty tough call. IIUC the kernel guys want to move the dts's out of the kernel tree sometime soon, so having them separate makes sense. Whether this should be one rpm that rpm "provide"s each dtb contained in it or it's separate rpms I don't know. I am leaning towards seperate rpms, but I guess whoever implements it wins. As for architecture, we definitely want to limit the installable scope. I don't want to see panda dtbs installable in my aarch64 system. Can we do that with a noarch rpm? Alex
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 20/09/2013 17:09, Alexander Graf a écrit :
Am 20.09.2013 um 09:56 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Hi,
it seems that panda and beagle legacy support (I mean non Device Tree support) will be dropped more or less quickly. To prepare openSUSE for the switch, I made dtb-omap3-beagle and dtb-omap4-panda packages in my home repo. Where should I submit them? openSUSE:Factory:ARM, or a devel project? Moreover, I made those packages 'noarch' type since DTB is not arch specific but it would also make sense to make them 'armv7' arch type since it is only used on armv7 boards.
Instead of making a package for each board, another way would be to build all DTB supported by our kernel version (using 'make dtbs' while building linux kernel, for each flavour), but DTB may be removed from kernel sources since they should not be kernel specific.
What is your opinion? It is a pretty tough call. IIUC the kernel guys want to move the dts's out of the kernel tree sometime soon, so having them separate makes sense. Whether this should be one rpm that rpm "provide"s each dtb contained in it or it's separate rpms I don't know. I am leaning towards seperate rpms, but I guess whoever implements it wins.
Ok. Having separate RPM for each board should be better to not pollute /boot partition with lots of DTBs.
As for architecture, we definitely want to limit the installable scope. I don't want to see panda dtbs installable in my aarch64 system. Can we do that with a noarch rpm?
No, 'noarch' is compatible with all architectures. So, to limit installable scope, we should use ExclusiveArch armv7*. Technically speaking, it should be a noarch package, but it should not hurt if we make them armv7 packages. ;) Guillaume
Alex
Guillaume
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (2)
-
Alexander Graf -
Guillaume Gardet