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
Attachment:
signature.asc
Description: This is a digitally signed message part