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

Re: ARM: backporting dreamplug patches for Wheezy

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

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 Campbell

Time flies like an arrow.  Fruit flies like a banana.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: