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
