[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ARM: backporting dreamplug patches for Wheezy

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:

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


[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

Reply to: