On Fri, 2012-03-02 at 02:57 +0000, Ben Hutchings wrote: > 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. 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.
Attachment:
signature.asc
Description: This is a digitally signed message part