Re: ARM: backporting dreamplug patches for Wheezy
Ben Hutchings <ben@decadent.org.uk> writes:
> 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.
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
Reply to: