Re: ARM: backporting dreamplug patches for Wheezy
On Mon, 2012-04-09 at 15:02 +0100, Ben Hutchings wrote: Or shall we wait until we are bumping for some other reason? [...] Can do. In which case: apply them, test the result and then comment them out in series/base with a leading comment that they're to be enabled at the next ABI bump. I was just about to do this but the patch also touches debian/config/armel/config.kirkwood and I'm not sure what to do there since commenting that change out isn't really an option. Shall I commit just the patches and commented out series entries? Ian. -- Ian Campbell You're ugly and your mother dresses you funny. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1335705815.16558.10.ca...@cthulhu.hellion.org.uk
Re: ARM: backporting dreamplug patches for Wheezy
On Sun, 2012-04-08 at 21:17 +0100, Ben Hutchings wrote: On Sun, 2012-04-08 at 11:25 +0100, Martin Michlmayr wrote: * Ian Campbell i...@hellion.org.uk [2012-04-08 11:10]: These Dreamplug patches add DT support for kirkwood in a way which is designed not to interfere with existing non-DT platforms and more generally upstream has done things in a way that FDT and ATAG platforms can safely be supported using the same kernel image. I'm no longer on the kernel team but fwiw I'm all in favour of these patches going into the Debian kernel for wheezy (if we can figure out a solution for the ABI change). We shouldn't worry too much about ABI changes until shortly before release. I suppose we don't want to be bumping it willy-nilly though? Would adding some ignores be appropriate in the short term? Or shall we wait until we are bumping for some other reason? The not already ignored new and changed symbols are: Added symbols: irq_create_of_mappingmodule: vmlinux, version: 0x4e7df11b, export: EXPORT_SYMBOL_GPL irq_dispose_mapping module: vmlinux, version: 0x2c7db649, export: EXPORT_SYMBOL_GPL irq_domain_add_simplemodule: vmlinux, version: 0xdd9fba6c, export: EXPORT_SYMBOL_GPL irq_domain_generate_simple module: vmlinux, version: 0x96a06d17, export: EXPORT_SYMBOL_GPL irq_domain_simple_opsmodule: vmlinux, version: 0x54853294, export: EXPORT_SYMBOL_GPL irq_of_parse_and_map module: vmlinux, version: 0x1ee9814e, export: EXPORT_SYMBOL_GPL mmc_spi_get_pdatamodule: drivers/mmc/host/of_mmc_spi, version: 0xfe4dab60, export: EXPORT_SYMBOL mmc_spi_put_pdatamodule: drivers/mmc/host/of_mmc_spi, version: 0x64163f18, export: EXPORT_SYMBOL of_address_to_resource module: vmlinux, version: 0x8dad55e8, export: EXPORT_SYMBOL_GPL of_alias_get_id module: vmlinux, version: 0xb0a6e317, export: EXPORT_SYMBOL_GPL of_dev_get module: vmlinux, version: 0xefdc6847, export: EXPORT_SYMBOL of_dev_put module: vmlinux, version: 0x15955066, export: EXPORT_SYMBOL of_device_alloc module: vmlinux, version: 0xc72f5cab, export: EXPORT_SYMBOL of_device_is_available module: vmlinux, version: 0xa568af0e, export: EXPORT_SYMBOL of_device_is_compatible module: vmlinux, version: 0xb3eaf07b, export: EXPORT_SYMBOL of_device_register module: vmlinux, version: 0x286373c8, export: EXPORT_SYMBOL of_device_unregister module: vmlinux, version: 0x3de3433e, export: EXPORT_SYMBOL of_fdt_unflatten_treemodule: vmlinux, version: 0x14d5945d, export: EXPORT_SYMBOL_GPL of_find_all_nodesmodule: vmlinux, version: 0x2c93eb74, export: EXPORT_SYMBOL of_find_compatible_node module: vmlinux, version: 0x39834109, export: EXPORT_SYMBOL of_find_device_by_node module: vmlinux, version: 0x9d6e5383, export: EXPORT_SYMBOL of_find_i2c_device_by_node module: vmlinux, version: 0x5cea3d88, export: EXPORT_SYMBOL of_find_matching_nodemodule: vmlinux, version: 0xa240cc7f, export: EXPORT_SYMBOL of_find_node_by_name module: vmlinux, version: 0x5bcf5e7e, export: EXPORT_SYMBOL of_find_node_by_path module: vmlinux, version: 0xf71b39bb, export: EXPORT_SYMBOL of_find_node_by_phandle module: vmlinux, version: 0x97515893, export: EXPORT_SYMBOL of_find_node_by_type module: vmlinux, version: 0xd8a05f87, export: EXPORT_SYMBOL of_find_node_with_property module: vmlinux, version: 0x4644db5c, export: EXPORT_SYMBOL of_find_property module: vmlinux, version: 0xa1b43ab9, export: EXPORT_SYMBOL of_get_address module: vmlinux, version: 0xbfdff814, export: EXPORT_SYMBOL of_get_mac_address module: vmlinux, version: 0xff917654, export: EXPORT_SYMBOL of_get_named_gpio_flags module: vmlinux, version: 0x8c7a3757, export: EXPORT_SYMBOL of_get_next_childmodule: vmlinux, version: 0x69085435, export: EXPORT_SYMBOL of_get_parentmodule: vmlinux, version: 0xbfb1435b, export: EXPORT_SYMBOL of_get_pci_address module: vmlinux, version: 0x30d70fa9, export: EXPORT_SYMBOL of_get_phy_mode module: vmlinux, version: 0xa6c38b19, export: EXPORT_SYMBOL_GPL
Re: ARM: backporting dreamplug patches for Wheezy
On Mon, 2012-04-09 at 12:45 +0100, Ian Campbell wrote: On Sun, 2012-04-08 at 21:17 +0100, Ben Hutchings wrote: On Sun, 2012-04-08 at 11:25 +0100, Martin Michlmayr wrote: * Ian Campbell i...@hellion.org.uk [2012-04-08 11:10]: These Dreamplug patches add DT support for kirkwood in a way which is designed not to interfere with existing non-DT platforms and more generally upstream has done things in a way that FDT and ATAG platforms can safely be supported using the same kernel image. I'm no longer on the kernel team but fwiw I'm all in favour of these patches going into the Debian kernel for wheezy (if we can figure out a solution for the ABI change). We shouldn't worry too much about ABI changes until shortly before release. I suppose we don't want to be bumping it willy-nilly though? We aren't. Would adding some ignores be appropriate in the short term? I don't think so; some of the changed functions could plausibly be used by OOT modules. Or shall we wait until we are bumping for some other reason? [...] Can do. In which case: apply them, test the result and then comment them out in series/base with a leading comment that they're to be enabled at the next ABI bump. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Re: ARM: backporting dreamplug patches for Wheezy
* Ian Campbell i...@hellion.org.uk [2012-04-08 11:10]: These Dreamplug patches add DT support for kirkwood in a way which is designed not to interfere with existing non-DT platforms and more generally upstream has done things in a way that FDT and ATAG platforms can safely be supported using the same kernel image. I'm no longer on the kernel team but fwiw I'm all in favour of these patches going into the Debian kernel for wheezy (if we can figure out a solution for the ABI change). -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120408102526.ga28...@jirafa.cyrius.com
Re: ARM: backporting dreamplug patches for Wheezy
On Sun, 2012-04-08 at 11:25 +0100, Martin Michlmayr wrote: * Ian Campbell i...@hellion.org.uk [2012-04-08 11:10]: These Dreamplug patches add DT support for kirkwood in a way which is designed not to interfere with existing non-DT platforms and more generally upstream has done things in a way that FDT and ATAG platforms can safely be supported using the same kernel image. I'm no longer on the kernel team but fwiw I'm all in favour of these patches going into the Debian kernel for wheezy (if we can figure out a solution for the ABI change). We shouldn't worry too much about ABI changes until shortly before release. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Re: ARM: backporting dreamplug patches for Wheezy
On Fri, 2012-03-02 at 15:09 +0100, Arnaud Patard wrote: Ben Hutchings b...@decadent.org.uk writes: On Thu, 2012-03-01 at 07:39 +, Ian Campbell wrote: An initial set of patches for the Dreamplug (basically a descendant of shivaplug, guruplug etc, see [0]) have been accepted into the ARM SoC maintainer's tree. Would it be acceptable to backport these to the Wheezy kernel? I'm happy to do the backporting and test them etc. I recently started running a Dreamplug as my home firewall so I'm motivated to have this h/w supported in Debian. So long as one of the existing flavours (kirkwood?) can support this as well, I see no problem with it. I'll leave it to the ARM maintainers to assess the state of the code. It's not a matter of kirkwood only. iirc, one needs more patches than the 2 mentionned here and some a modifying code inside plat-orion. FYI I have just rebuilt 3.2.9-1 with exactly those two patches (plus a one liner backport patch) and the system boots fine using a u-boot with FDT support enabled. I didn't try the CONFIG_ARM_APPENDED_DTB mode and the help text indicates that updating the bootloader is preferable. It looks like the exact patches which are going upstream have evolved a bit since then (and there are now others which cover more functionality) so I will retry with those. This means it can have some side effects on orion and mv78xxx platforms too (and I think that the patches merged have been tested only on dreamplug and not on orion/mv78xxx). I don't think the patches touch anything near orion or mv78xxx, the diffstat of the patches I tested is: arch/arm/boot/dts/kirkwood-dreamplug.dts | 25 arch/arm/boot/dts/kirkwood.dtsi |6 + arch/arm/mach-kirkwood/Kconfig | 14 +++ arch/arm/mach-kirkwood/Makefile |1 + arch/arm/mach-kirkwood/Makefile.boot |2 + arch/arm/mach-kirkwood/board-dt.c| 179 ++ 6 files changed, 227 insertions(+), 0 deletions(-) Also, I don't know if the kirkwood kernels made with device tree stuff enabled in kernel have no bad side effect on other kirkwood devices Given the diffstat above I think this is very unlikely to be the case, at least for this round of patches. Wouldn't these concerns about damaging other boards be alleviated by using the patches which have been accepted into mainline already? (once they have been) I'll have a look but it does not mean it'll be merged. If one needs to backport the whole arm-soc tree to get it, I fear wear we'll be in troubles. I'm fairly certain that things are not as bad as you fear. The series has been structured so that we could just take the first patch if we wanted. This first patch uses DTB only to identify the board, but then goes on to initialise it statically, again just like the old mach-types system. Subsequent patches just transition the device one by one from the static scheme to the DTB based scheme. Anyway, thanks for looking into this, I look forward to your conclusions. Ian. signature.asc Description: This is a digitally signed message part
Re: ARM: backporting dreamplug patches for Wheezy
Ben Hutchings b...@decadent.org.uk writes: On Thu, 2012-03-01 at 07:39 +, Ian Campbell wrote: An initial set of patches for the Dreamplug (basically a descendant of shivaplug, guruplug etc, see [0]) have been accepted into the ARM SoC maintainer's tree. Would it be acceptable to backport these to the Wheezy kernel? I'm happy to do the backporting and test them etc. I recently started running a Dreamplug as my home firewall so I'm motivated to have this h/w supported in Debian. So long as one of the existing flavours (kirkwood?) can support this as well, I see no problem with it. I'll leave it to the ARM maintainers to assess the state of the code. It's not a matter of kirkwood only. iirc, one needs more patches than the 2 mentionned here and some a modifying code inside plat-orion. This means it can have some side effects on orion and mv78xxx platforms too (and I think that the patches merged have been tested only on dreamplug and not on orion/mv78xxx). Also, I don't know if the kirkwood kernels made with device tree stuff enabled in kernel have no bad side effect on other kirkwood devices I'll have a look but it does not mean it'll be merged. If one needs to backport the whole arm-soc tree to get it, I fear wear we'll be in troubles. The specific patches are: http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077981c28286 http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34 I imagine there will be more patches as more stuff is moved over to FDT. Is this our first platform which requires an FDT? Do we have a plan in mind for how to deal with those? The FDT file needs to live in /boot so the bootloader can find it. They aren't big -- it seems that an 8K DTB would be quite a large one. powerpc installs device tree stuff into /usr/lib/package/dts. I believe the appropriate files are compiled and then appended or linked to the kernel at installation time by mkvmlinuz. (I hope someone who actually knows powerpc can correct me on this...) I guess that on armel/armhf, I believe it should be handled on flash-kernel side, in order to handle it correctly. For instance, we'll have devices with uboot supporting device tree and other with uboot not supporting it (and, updating uboot is not always possible). Although in principal they describe the hardware in reality the FDTs are being co-evolved along with the kernel code -- I'm not sure what the upstream policy is wrt backwards compatibility. I would hope that, modulo bugs, the most recent FDT would work for all kernels but I don't know that this is going to be the case. Doesn't sound like a safe assumption. device tree code is still work in progress and given that there are still a lot of places/drivers missing support for it, things may change. One should be very carefull when making assumptions about it. I think the choices are: * version the DTB files, like we do for vmlinuz and initrd, and have all the relevant ones in each linux-image package; * put all supported DTBs in a single package (linux-base? or something new? per arch?); * a new (tiny) package per supported board; * punt the problem to the bootloader package and/or the user; I don't think CONFIG_ARM_APPENDED_DTB can be used unless we concatenate at install time since you can only support a single board at a time that way. Is it safe to assume that boot loaders will be able to pass in DTBs? Thinking forward, what if existing platforms get DT support and we want to consolidate flavours without requiring an updated boot loader? We will have to handle the case of bootloaders not supporting device tree. Moreover, some systems are not using uboot at all (for instance, custom vendor bootloader or redboot) or can't update the uboot. Also, some new devices may use UEFI in future and I've no idea how it'll be handled. I think ideally we should be able to build a kernel image which can accept a DTB either appended or passed separately by the boot loader. Is that supported? This will have to be checked/tested. At least, the Kconfig entry for ARM_APPENDED_DTB is quite scary about enabling it and booting without a DTB appended. Arnaud -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqcvccwm@lebrac.rtp-net.org
Re: ARM: backporting dreamplug patches for Wheezy
On Fri, 2012-03-02 at 15:09 +0100, Arnaud Patard wrote: Ben Hutchings b...@decadent.org.uk writes: On Thu, 2012-03-01 at 07:39 +, Ian Campbell wrote: An initial set of patches for the Dreamplug (basically a descendant of shivaplug, guruplug etc, see [0]) have been accepted into the ARM SoC maintainer's tree. Would it be acceptable to backport these to the Wheezy kernel? I'm happy to do the backporting and test them etc. I recently started running a Dreamplug as my home firewall so I'm motivated to have this h/w supported in Debian. So long as one of the existing flavours (kirkwood?) can support this as well, I see no problem with it. I'll leave it to the ARM maintainers to assess the state of the code. It's not a matter of kirkwood only. iirc, one needs more patches than the 2 mentionned here and some a modifying code inside plat-orion. Are you sure? The two patches I'm talking about touch: $ git diff --stat HEAD~2 arch/arm/boot/dts/kirkwood-dreamplug.dts | 25 arch/arm/boot/dts/kirkwood.dtsi |6 + arch/arm/mach-kirkwood/Kconfig | 14 +++ arch/arm/mach-kirkwood/Makefile |1 + arch/arm/mach-kirkwood/Makefile.boot |2 + arch/arm/mach-kirkwood/board-dt.c| 180 ++ 6 files changed, 228 insertions(+), 0 deletions(-) I've applied these to v3.3-rc4 and they worked fine. I also tested a previous non-DT version of dreamplug support on v3.2. These patches are very similar apart from the user of DT other the mach-type to identify the dreamplug. I haven't yet tested backported versions of the two DT patches. The DT support in the above is very basic and doesn't extend to many peripherals at all (only the UART). In fact if we only take the first patch then it only covers board ID and none of the peripherals. This means it can have some side effects on orion and mv78xxx platforms too (and I think that the patches merged have been tested only on dreamplug and not on orion/mv78xxx). Also, I don't know if the kirkwood kernels made with device tree stuff enabled in kernel have no bad side effect on other kirkwood devices I'll have a look but it does not mean it'll be merged. If one needs to backport the whole arm-soc tree to get it, I fear wear we'll be in troubles. I hope it won't come to that. Ian. -- Ian Campbell Current Noise: Crippled Black Phoenix - Laying Traps Save yourself from the 'Gates' of hell, use Linux. -- like that one. -- The_Kind @ LinuxNet -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1330699054.18632.82.ca...@zakaz.uk.xensource.com
Re: ARM: backporting dreamplug patches for Wheezy
On Thu, 2012-03-01 at 07:39 +, Ian Campbell wrote: An initial set of patches for the Dreamplug (basically a descendant of shivaplug, guruplug etc, see [0]) have been accepted into the ARM SoC maintainer's tree. Would it be acceptable to backport these to the Wheezy kernel? I'm happy to do the backporting and test them etc. I recently started running a Dreamplug as my home firewall so I'm motivated to have this h/w supported in Debian. So long as one of the existing flavours (kirkwood?) can support this as well, I see no problem with it. I'll leave it to the ARM maintainers to assess the state of the code. The specific patches are: http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077981c28286 http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34 I imagine there will be more patches as more stuff is moved over to FDT. Is this our first platform which requires an FDT? Do we have a plan in mind for how to deal with those? The FDT file needs to live in /boot so the bootloader can find it. They aren't big -- it seems that an 8K DTB would be quite a large one. powerpc installs device tree stuff into /usr/lib/package/dts. I believe the appropriate files are compiled and then appended or linked to the kernel at installation time by mkvmlinuz. (I hope someone who actually knows powerpc can correct me on this...) Although in principal they describe the hardware in reality the FDTs are being co-evolved along with the kernel code -- I'm not sure what the upstream policy is wrt backwards compatibility. I would hope that, modulo bugs, the most recent FDT would work for all kernels but I don't know that this is going to be the case. Doesn't sound like a safe assumption. I think the choices are: * version the DTB files, like we do for vmlinuz and initrd, and have all the relevant ones in each linux-image package; * put all supported DTBs in a single package (linux-base? or something new? per arch?); * a new (tiny) package per supported board; * punt the problem to the bootloader package and/or the user; I don't think CONFIG_ARM_APPENDED_DTB can be used unless we concatenate at install time since you can only support a single board at a time that way. Is it safe to assume that boot loaders will be able to pass in DTBs? Thinking forward, what if existing platforms get DT support and we want to consolidate flavours without requiring an updated boot loader? I think ideally we should be able to build a kernel image which can accept a DTB either appended or passed separately by the boot loader. Is that supported? Ben. Ian. [0] http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx -- Ben Hutchings One of the nice things about standards is that there are so many of them. signature.asc Description: This is a digitally signed message part
Re: ARM: backporting dreamplug patches for Wheezy
On Fri, 2012-03-02 at 02:57 +, Ben Hutchings wrote: On Thu, 2012-03-01 at 07:39 +, Ian Campbell wrote: An initial set of patches for the Dreamplug (basically a descendant of shivaplug, guruplug etc, see [0]) have been accepted into the ARM SoC maintainer's tree. Would it be acceptable to backport these to the Wheezy kernel? I'm happy to do the backporting and test them etc. I recently started running a Dreamplug as my home firewall so I'm motivated to have this h/w supported in Debian. So long as one of the existing flavours (kirkwood?) can support this as well, I see no problem with it. I'll leave it to the ARM maintainers to assess the state of the code. Yes it's kirkwood. The specific patches are: http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077981c28286 http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34 I imagine there will be more patches as more stuff is moved over to FDT. Is this our first platform which requires an FDT? Do we have a plan in mind for how to deal with those? The FDT file needs to live in /boot so the bootloader can find it. They aren't big -- it seems that an 8K DTB would be quite a large one. powerpc installs device tree stuff into /usr/lib/package/dts. I believe the appropriate files are compiled and then appended or linked to the kernel at installation time by mkvmlinuz. (I hope someone who actually knows powerpc can correct me on this...) This sounds like they use the powerpc equivalent of CONFIG_ARM_APPENDED_DTB. I don't see mkvmlinuz on ARM. Is flash-kernel the ARM equivalent? Although in principal they describe the hardware in reality the FDTs are being co-evolved along with the kernel code -- I'm not sure what the upstream policy is wrt backwards compatibility. I would hope that, modulo bugs, the most recent FDT would work for all kernels but I don't know that this is going to be the case. Doesn't sound like a safe assumption. No, I suppose not :-( I think the choices are: * version the DTB files, like we do for vmlinuz and initrd, and have all the relevant ones in each linux-image package; * put all supported DTBs in a single package (linux-base? or something new? per arch?); * a new (tiny) package per supported board; * punt the problem to the bootloader package and/or the user; I don't think CONFIG_ARM_APPENDED_DTB can be used unless we concatenate at install time since you can only support a single board at a time that way. Is it safe to assume that boot loaders will be able to pass in DTBs? I had to turn on the config option in u-boot. I've sent a patch to u-boot upstream for this board type. Existing u-boot's for other kirkwood platforms probably don't have this enabled. Thinking forward, what if existing platforms get DT support and we want to consolidate flavours without requiring an updated boot loader? Enabling DTB support does not conflict with the existing mach-types/ATAG for boards which use that so you can have DTB and non-DTB boards enabled in the build and the former will use a DTB while the latter will use the ATAGs mechanism like they do today. I think ideally we should be able to build a kernel image which can accept a DTB either appended or passed separately by the boot loader. Is that supported? If you enable CONFIG_ARM_APPENDED_DTB then the kernel will get the DTB from either the bootloader or find it appended (appended appears to take priority, if I'm reading the asm right). Ian. -- Ian Campbell Time flies like an arrow. Fruit flies like a banana. signature.asc Description: This is a digitally signed message part
ARM: backporting dreamplug patches for Wheezy
An initial set of patches for the Dreamplug (basically a descendant of shivaplug, guruplug etc, see [0]) have been accepted into the ARM SoC maintainer's tree. Would it be acceptable to backport these to the Wheezy kernel? I'm happy to do the backporting and test them etc. I recently started running a Dreamplug as my home firewall so I'm motivated to have this h/w supported in Debian. The specific patches are: http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077981c28286 http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34 I imagine there will be more patches as more stuff is moved over to FDT. Is this our first platform which requires an FDT? Do we have a plan in mind for how to deal with those? The FDT file needs to live in /boot so the bootloader can find it. They aren't big -- it seems that an 8K DTB would be quite a large one. Although in principal they describe the hardware in reality the FDTs are being co-evolved along with the kernel code -- I'm not sure what the upstream policy is wrt backwards compatibility. I would hope that, modulo bugs, the most recent FDT would work for all kernels but I don't know that this is going to be the case. I think the choices are: * version the DTB files, like we do for vmlinuz and initrd, and have all the relevant ones in each linux-image package; * put all supported DTBs in a single package (linux-base? or something new? per arch?); * a new (tiny) package per supported board; * punt the problem to the bootloader package and/or the user; I don't think CONFIG_ARM_APPENDED_DTB can be used unless we concatenate at install time since you can only support a single board at a time that way. Ian. [0] http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx -- Ian Campbell BOFH excuse #129: The ring needs another token signature.asc Description: This is a digitally signed message part
