On Thu, 2012-03-01 at 07:39 +0000, 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.
Attachment:
signature.asc
Description: This is a digitally signed message part