Re: [RFC] include DTB in linux-image files on armel
On Mon, 2012-04-23 at 11:53 +0200, Arnaud Patard wrote:
> Ian Campbell <firstname.lastname@example.org> writes:
> > On Fri, 2012-04-20 at 14:25 +0100, Ian Campbell wrote:
> >> On Fri, 2012-04-20 at 13:35 +0200, Bastian Blank wrote:
> >> > On Fri, Apr 20, 2012 at 11:11:27AM +0100, Ian Campbell wrote:
> >> > > -install-image_armel_$(FEATURESET)_$(FLAVOUR)_plain_image \
> >> > > +ifneq ($(filter armel,$(ARCH)),)
> >> > > +install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_image:
> >> >
> >> > What is this supposed to do?
> >> I'm not sure. I copied the pattern from the similar powerpc case.
> >> s390/s390x does the same.
> >> Oh, I see, those cases both cover multiple arches and use $(ARCH), hence
> >> need gating appropriately. As it stands my patch only support armel so
> >> could use armel explicitly. Except I think we need to add armhf support
> >> for this too and that would require this pattern.
> > Here is an updated patch, supports armhf as well. There's not actually
> afaik, some imx and omap boards have DT support in the 3.2 kernel but I
> have less things supported. For instance, I guess that if you try to
> boot a DT enabled kernel on imx53qsb/loco, you won't get sata support.
So I suppose that, at least for wheezy, we'll stick with ATAGs for those
platforms by default.
The guy doing the dreamplug patches has taken quite a nice approach
which allows him to cut over each bit of hardware from static per-board
to DT based detection one at a time without losing support for devices
during the transition.
> > any users in armhf AFAIK, actually until dreamplug support goes in there
> > is none in armel either...
> dreamplug and iomega iconnect if I manage to get iconnect support merged :)
> > It now uses /usr/lib/linux-image-VERSION/foo.dtb which is consistent
> > with the attached flash-kernel-install-dtb.patch which is under
> > discussion in #667681.
> > Ian.
> > diff --git a/linux-2.6/debian/rules.real b/linux-2.6/debian/rules.real
> > index a7f56c3..2fbcdc8 100644
> > --- a/linux-2.6/debian/rules.real
> > +++ b/linux-2.6/debian/rules.real
> > @@ -356,8 +356,16 @@ endif
> > PACKAGE_DIR='$(PACKAGE_DIR)' PACKAGE_NAME='$(PACKAGE_NAME)' REAL_VERSION='$(REAL_VERSION)'
> > +$(MAKE_SELF) install-base
> > -install-image_armel_$(FEATURESET)_$(FLAVOUR)_plain_image \
> > -install-image_armhf_$(FEATURESET)_$(FLAVOUR)_plain_image \
> > +ifneq ($(filter armel armhf,$(ARCH)),)
> > +install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_image: DTB_INSTALL_DIR = /usr/lib/linux-image-$(REAL_VERSION)
> > +install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_image:
> > + install -m644 '$(DIR)/arch/$(KERNEL_ARCH)/boot/zImage' $(INSTALL_DIR)/vmlinuz-$(REAL_VERSION)
> > + +$(MAKE_CLEAN) -C $(DIR) dtbs
> > + shopt -s nullglob ; for i in $(DIR)/arch/arm/boot/*.dtb ; do \
> > + install -D -m644 $$i '$(PACKAGE_DIR)'/'$(DTB_INSTALL_DIR)'/$$(basename $$i) ; \
> > + done
> > +endif
> fwiw, I've looked at the powerpc kernel package and looks like that
> they're shipping the DTS file and not the DTB. I've no opinion on this
> except that if we choose to ship DTB, we need to be sure that dtc is
> installed when building (I didn't check if it was already in build-deps).
Yes, I noticed that last time but forgot again before this new posting.
I put the dtb in /usr/lib/linux-image-VER/ without the /dts suffix which
PPC uses. We could ship both I suppose?
I'm slightly concerned that Linux appears to ship and use its own fork
of DTC rather than the system installed version, but I'm not sure why it
does this but it suggests that compiling on the target would at a
minimum require us to package that variant of DTC.
Current Noise: Deicide - Empowered By Blasphemy
Why be a man when you can be a success?
-- Bertolt Brecht