* [Buildroot] [PATCH] imx-lib: new package
From: Benoît Thébaudeau @ 2012-12-17 19:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF55F7.9090906@mind.be>
Dear Arnout Vandecappelle,
On Monday, December 17, 2012 6:27:19 PM, Arnout Vandecappelle wrote:
> On 17/12/12 16:57, Beno?t Th?baudeau wrote:
> > Dear Arnout Vandecappelle,
> >
> > On Monday, December 17, 2012 4:50:37 PM, Arnout Vandecappelle
> > wrote:
> >> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> >>> +IMX_LIB_INCLUDE = \
> >>> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> >>> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> >>> + -I$(LINUX_DIR)/include
> >>
> >> Actually, I wonder if this is the right thing to do... This is
> >> a
> >> userspace library that requires a platform-specific linux/xxx.h.
> >> For
> >> an
> >> external toolchain, these headers don't exist in
> >> $(STAGING_DIR)/usr/include/linux
> >>
> >> Directly using $(LINUX_DIR)/include means that the headers are
> >> not
> >> patched for userspace. For those platform-specific headers that's
> >> probably not a problem, but it's not good for e.g. linux/types.h.
> >>
> >> An easy workaround is to use -idirafter instead of -I.
> >> However,
> >> perhaps it's an even better idea to do 'make headers_install' as
> >> part
> >> of
> >> the normal linux build process, so that packages depending on
> >> those
> >> headers can use the patched version. But then again, is it a good
> >> idea to
> >> replace the toolchain's kernel headers with a new set of kernel
> >> headers?
> >>
> >> Any advice is welcome!
> >
> > FYI, I've successfully built the 11.09.01 version under BuildRoot
> > without the
> > "-I$(LINUX_DIR)/include", and the issue that you mention is only
> > for this
> > folder. I had to make a patch to make the headers install work, but
> > that should
> > not be related. Can you try with your package?
>
> ipu/mxc_ipu_hl_lib.h needs linux/mxcfb.h which only exists in the
> imx
> kernels.
I see. I did not have this issue because I have built a custom toolchain based
on Freescale's kernel, so including these headers. This would not be very
practical to impose the use of a custom toolchain here.
Best regards,
Beno?t
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 17:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355752131-31966-1-git-send-email-arnout@mind.be>
On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> +if BR2_PACKAGE_IMX_LIB
> +choice
> + prompt "i.MX platform"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
> + bool "imx25-3stack"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
> + bool "imx27ads"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
> + bool "imx37-3stack"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
> + bool "imx50"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
> + bool "imx51"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
> + bool "imx53"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
> + bool "imx6q"
> +
> +endchoice
Here's a second issue that I'd like to get some feedback on:
gst-fsl-plugins also uses a PLATFORM definition, but the list of
platforms is slightly different:
MX28/MX233/MX25/MX27/MX31/MX35/MX37/MX51/MX53/MX50/MX5X/MX6
Ideally the 'platform' should be defined only once, but where? Or
should I add all the platforms to gst-fsl-plugins with a select of the
appropriate imx-lib platform?
What to do with the platforms that are different? In some cases, I can
make a guess of course (e.g. MX27 -> IMX27ADS)
I can only test the mx6q because that's the only one for which I have a
board... Build-testing doesn't make a difference because all platforms
use the same API.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 17:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <871ueo8y7k.fsf@dell.be.48ers.dk>
On 17/12/12 17:01, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle<arnout@mind.be> writes:
>
> Arnout> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> >> +IMX_LIB_INCLUDE = \
> >> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> >> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> >> + -I$(LINUX_DIR)/include
>
> Arnout> Actually, I wonder if this is the right thing to do... This is a
> Arnout> userspace library that requires a platform-specific linux/xxx.h. For
> Arnout> an external toolchain, these headers don't exist in
> Arnout> $(STAGING_DIR)/usr/include/linux
>
> Arnout> Directly using $(LINUX_DIR)/include means that the headers are not
> Arnout> patched for userspace. For those platform-specific headers that's
> Arnout> probably not a problem, but it's not good for e.g. linux/types.h.
>
> Arnout> An easy workaround is to use -idirafter instead of -I. However,
> Arnout> perhaps it's an even better idea to do 'make headers_install' as part
> Arnout> of the normal linux build process, so that packages depending on those
> Arnout> headers can use the patched version. But then again, is it a good idea
> Arnout> to replace the toolchain's kernel headers with a new set of kernel
> Arnout> headers?
>
> Another possibility is to bundle the needed kernel headers with the
> package, similar to how E.G. mtd-utils does it.
Unfortunately, Freescale probably has a much lower standard about ABI
compatibility than kernel.org. Also it's relatively likely that a
buildroot user will use a different Freescale kernel than the one assumed
by buildroot. So you may end up with userspace assuming different struct
layouts than the kernel...
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 17:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <2112128925.1003709.1355759859440.JavaMail.root@advansee.com>
On 17/12/12 16:57, Beno?t Th?baudeau wrote:
> Dear Arnout Vandecappelle,
>
> On Monday, December 17, 2012 4:50:37 PM, Arnout Vandecappelle wrote:
>> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
>>> +IMX_LIB_INCLUDE = \
>>> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
>>> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
>>> + -I$(LINUX_DIR)/include
>>
>> Actually, I wonder if this is the right thing to do... This is a
>> userspace library that requires a platform-specific linux/xxx.h. For
>> an
>> external toolchain, these headers don't exist in
>> $(STAGING_DIR)/usr/include/linux
>>
>> Directly using $(LINUX_DIR)/include means that the headers are not
>> patched for userspace. For those platform-specific headers that's
>> probably not a problem, but it's not good for e.g. linux/types.h.
>>
>> An easy workaround is to use -idirafter instead of -I. However,
>> perhaps it's an even better idea to do 'make headers_install' as part
>> of
>> the normal linux build process, so that packages depending on those
>> headers can use the patched version. But then again, is it a good
>> idea to
>> replace the toolchain's kernel headers with a new set of kernel
>> headers?
>>
>> Any advice is welcome!
>
> FYI, I've successfully built the 11.09.01 version under BuildRoot without the
> "-I$(LINUX_DIR)/include", and the issue that you mention is only for this
> folder. I had to make a patch to make the headers install work, but that should
> not be related. Can you try with your package?
ipu/mxc_ipu_hl_lib.h needs linux/mxcfb.h which only exists in the imx
kernels.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] [RFC] new target: live filesystem
From: Richard Genoud @ 2012-12-17 16:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHXCMMKXJ8Crr770fXoYz=+SbNcU0VCNXkMcvXsKJKRmd0xsWg@mail.gmail.com>
2012/12/17 Samuel Martin <s.martin49@gmail.com>:
> Hi Richard,
> There are plenty of good reasons to not use output/target as root for
> a chroot or a NFS root, as explained here:
> http://buildroot.org/downloads/manual/manual.html#faq-why-not-use-target-as-chroot
>
> And here, you'll find the right way to do this (so far):
> http://buildroot.org/downloads/manual/manual.html#_nfs_boot
>
Yes, I know...
It's just more convenient (fast) for me like that:
When I recompile a small software (with make mysoft-reconfigure), I'd
like it to be fast, and de-tar-ing the whole RFS takes some time.
But, it's true that it's not the right way to do it.
(I also always forgot to sudo when I want to copy something to the
nfsroot, so, like that, the tree is mine and there's no cp problem)
Thanks for the links though !
Regards,
Richard.
^ permalink raw reply
* [Buildroot] [PATCH] [RFC] new target: live filesystem
From: Samuel Martin @ 2012-12-17 16:08 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CACQ1gAj-H5P3SaX=fhzxpW=aPwp+kJuZw2CQ9AYgmnSKZKpp7g@mail.gmail.com>
Hi Richard,
2012/12/17 Richard Genoud <richard.genoud@gmail.com>:
> 2012/12/17 Jeremy Rosen <jeremy.rosen@openwide.fr>:
>> Hello everybody
>>
>> there is a little bit more work to do on this patch (mainly updating a few more places in the documentation) but i'd like to have a go/no-go before I do that...
>
> I was looking for that kind of feature, I hope it will be accepted.
> For now, I use the output/target tree and those parameters in the
> /etc/exports file:
> *(rw,all_squash,no_subtree_check,anonuid=my_uid,anongid=my_gid)
>
> But that means that all the FS is owned by my user.
There are plenty of good reasons to not use output/target as root for
a chroot or a NFS root, as explained here:
http://buildroot.org/downloads/manual/manual.html#faq-why-not-use-target-as-chroot
And here, you'll find the right way to do this (so far):
http://buildroot.org/downloads/manual/manual.html#_nfs_boot
Regards,
--
Sam
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Peter Korsgaard @ 2012-12-17 16:01 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF3F4D.1030100@mind.be>
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
Arnout> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
>> +IMX_LIB_INCLUDE = \
>> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
>> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
>> + -I$(LINUX_DIR)/include
Arnout> Actually, I wonder if this is the right thing to do... This is a
Arnout> userspace library that requires a platform-specific linux/xxx.h. For
Arnout> an external toolchain, these headers don't exist in
Arnout> $(STAGING_DIR)/usr/include/linux
Arnout> Directly using $(LINUX_DIR)/include means that the headers are not
Arnout> patched for userspace. For those platform-specific headers that's
Arnout> probably not a problem, but it's not good for e.g. linux/types.h.
Arnout> An easy workaround is to use -idirafter instead of -I. However,
Arnout> perhaps it's an even better idea to do 'make headers_install' as part
Arnout> of the normal linux build process, so that packages depending on those
Arnout> headers can use the patched version. But then again, is it a good idea
Arnout> to replace the toolchain's kernel headers with a new set of kernel
Arnout> headers?
Another possibility is to bundle the needed kernel headers with the
package, similar to how E.G. mtd-utils does it.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Benoît Thébaudeau @ 2012-12-17 15:57 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CF3F4D.1030100@mind.be>
Dear Arnout Vandecappelle,
On Monday, December 17, 2012 4:50:37 PM, Arnout Vandecappelle wrote:
> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> > +IMX_LIB_INCLUDE = \
> > + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> > + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> > + -I$(LINUX_DIR)/include
>
> Actually, I wonder if this is the right thing to do... This is a
> userspace library that requires a platform-specific linux/xxx.h. For
> an
> external toolchain, these headers don't exist in
> $(STAGING_DIR)/usr/include/linux
>
> Directly using $(LINUX_DIR)/include means that the headers are not
> patched for userspace. For those platform-specific headers that's
> probably not a problem, but it's not good for e.g. linux/types.h.
>
> An easy workaround is to use -idirafter instead of -I. However,
> perhaps it's an even better idea to do 'make headers_install' as part
> of
> the normal linux build process, so that packages depending on those
> headers can use the patched version. But then again, is it a good
> idea to
> replace the toolchain's kernel headers with a new set of kernel
> headers?
>
> Any advice is welcome!
FYI, I've successfully built the 11.09.01 version under BuildRoot without the
"-I$(LINUX_DIR)/include", and the issue that you mention is only for this
folder. I had to make a patch to make the headers install work, but that should
not be related. Can you try with your package?
Best regards,
Beno?t
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Benoît Thébaudeau @ 2012-12-17 15:50 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355752131-31966-1-git-send-email-arnout@mind.be>
Dear Arnout Vandecappelle,
On Monday, December 17, 2012 2:48:50 PM, Arnout Vandecappelle wrote:
> From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
>
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
> I'm not sure if I'll get the packages that use this library in an
> upstreamable state - but at least this one is.
>
> ---
> package/Config.in | 1 +
> package/imx-lib/Config.in | 53
> ++++++++++++++++++++++++++++++++++++++++++++
> package/imx-lib/imx-lib.mk | 41 ++++++++++++++++++++++++++++++++++
> 3 files changed, 95 insertions(+)
> create mode 100644 package/imx-lib/Config.in
> create mode 100644 package/imx-lib/imx-lib.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index d6af55d..5151346 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -420,6 +420,7 @@ endmenu
>
> menu "Hardware handling"
> source "package/ccid/Config.in"
> +source "package/imx-lib/Config.in"
> source "package/lcdapi/Config.in"
> source "package/libaio/Config.in"
> source "package/libraw1394/Config.in"
> diff --git a/package/imx-lib/Config.in b/package/imx-lib/Config.in
> new file mode 100644
> index 0000000..0ed452a
> --- /dev/null
> +++ b/package/imx-lib/Config.in
> @@ -0,0 +1,53 @@
> +comment "imx-lib needs an imx-specific kernel to be built"
> + depends on !BR2_LINUX_KERNEL
> +
> +config BR2_PACKAGE_IMX_LIB
> + bool "imx-lib"
> + depends on BR2_LINUX_KERNEL
> + depends on BR2_arm
> + help
> + Library of userspace helpers specific for the Freescale i.MX
> + platform. It wraps the kernel interfaces for some i.MX platform
> + specific drivers. It requires a kernel that includes the i.MX
> + specific headers to be built.
> +
> + This library is provided by Freescale as-is and doesn't have
> + an upstream.
> +
> +if BR2_PACKAGE_IMX_LIB
> +choice
> + prompt "i.MX platform"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
> + bool "imx25-3stack"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
> + bool "imx27ads"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
> + bool "imx37-3stack"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
> + bool "imx50"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
> + bool "imx51"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
> + bool "imx53"
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
> + bool "imx6q"
> +
> +endchoice
> +
> +config BR2_PACKAGE_IMX_LIB_PLATFORM
> + string
> + default "IMX25_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
> + default "IMX27ADS" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
> + default "IMX37_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
> + default "IMX50" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
> + default "IMX51" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
> + default "IMX53" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
> + default "IMX6Q" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
> +endif
> diff --git a/package/imx-lib/imx-lib.mk b/package/imx-lib/imx-lib.mk
> new file mode 100644
> index 0000000..29f5ae1
> --- /dev/null
> +++ b/package/imx-lib/imx-lib.mk
> @@ -0,0 +1,41 @@
> +#############################################################
> +#
> +# imx-lib
> +#
> +#############################################################
> +
> +IMX_LIB_VERSION = 12.09.01
> +# No official download site from freescale, just this mirror
> +IMX_LIB_SITE =
> http://download.ossystems.com.br/bsp/freescale/source
> +IMX_LIB_LICENSE = LGPLv2.1+
> +# No license file included
> +
> +IMX_LIB_INSTALL_STAGING = YES
> +
> +# imx-lib needs access to imx-specific kernel headers
> +IMX_LIB_DEPENDENCIES += linux
> +IMX_LIB_INCLUDE = \
> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> + -I$(LINUX_DIR)/include
> +
> +IMX_LIB_MAKE_ENV = \
> + $(TARGET_MAKE_ENV) \
> + $(TARGET_CONFIGURE_OPTS) \
> + CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \
> + PLATFORM=$(BR2_PACKAGE_IMX_LIB_PLATFORM) \
> + INCLUDE="$(IMX_LIB_INCLUDE)"
> +
> +define IMX_LIB_BUILD_CMDS
> + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D)
> +endef
> +
> +define IMX_LIB_INSTALL_STAGING_CMDS
> + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(STAGING_DIR)
> install
> +endef
> +
> +define IMX_LIB_INSTALL_TARGET_CMDS
> + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(TARGET_DIR)
> install
> +endef
> +
> +$(eval $(generic-package))
This looks good. There is however a missing runtime dependency on firmware-imx.
Best regards,
Beno?t
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 15:50 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355752131-31966-1-git-send-email-arnout@mind.be>
On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote:
> +IMX_LIB_INCLUDE = \
> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
> + -I$(LINUX_DIR)/include
Actually, I wonder if this is the right thing to do... This is a
userspace library that requires a platform-specific linux/xxx.h. For an
external toolchain, these headers don't exist in
$(STAGING_DIR)/usr/include/linux
Directly using $(LINUX_DIR)/include means that the headers are not
patched for userspace. For those platform-specific headers that's
probably not a problem, but it's not good for e.g. linux/types.h.
An easy workaround is to use -idirafter instead of -I. However,
perhaps it's an even better idea to do 'make headers_install' as part of
the normal linux build process, so that packages depending on those
headers can use the patched version. But then again, is it a good idea to
replace the toolchain's kernel headers with a new set of kernel headers?
Any advice is welcome!
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] add support for Freescale .sb format to uboot
From: Attila Kinali @ 2012-12-17 13:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87pq2o8ad0.fsf@dell.be.48ers.dk>
On Wed, 05 Dec 2012 13:20:11 -0800
Peter Korsgaard <jacmet@uclibc.org> wrote:
> >>>>> "Attila" == Attila Kinali <attila@kinali.ch> writes:
>
> >> Not really. I don't have any imx hw here. Are you able to test it?
>
> Attila> I have an i.mx23 EVK at work. So i guess i could test it.
>
> Great, thanks.
Sorry, i didnt have time to test it yet.
And unfortunately it doesn't look like i will have time for it
until the end of the week. How it is between christmas and new year,
i cannot tell. But i try to fit it in somehow.
Thanks for your patience and sorry for the delay
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
^ permalink raw reply
* [Buildroot] [PATCH] imx-lib: new package
From: Arnout Vandecappelle @ 2012-12-17 13:48 UTC (permalink / raw)
To: buildroot
From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
I'm not sure if I'll get the packages that use this library in an
upstreamable state - but at least this one is.
---
package/Config.in | 1 +
package/imx-lib/Config.in | 53 ++++++++++++++++++++++++++++++++++++++++++++
package/imx-lib/imx-lib.mk | 41 ++++++++++++++++++++++++++++++++++
3 files changed, 95 insertions(+)
create mode 100644 package/imx-lib/Config.in
create mode 100644 package/imx-lib/imx-lib.mk
diff --git a/package/Config.in b/package/Config.in
index d6af55d..5151346 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -420,6 +420,7 @@ endmenu
menu "Hardware handling"
source "package/ccid/Config.in"
+source "package/imx-lib/Config.in"
source "package/lcdapi/Config.in"
source "package/libaio/Config.in"
source "package/libraw1394/Config.in"
diff --git a/package/imx-lib/Config.in b/package/imx-lib/Config.in
new file mode 100644
index 0000000..0ed452a
--- /dev/null
+++ b/package/imx-lib/Config.in
@@ -0,0 +1,53 @@
+comment "imx-lib needs an imx-specific kernel to be built"
+ depends on !BR2_LINUX_KERNEL
+
+config BR2_PACKAGE_IMX_LIB
+ bool "imx-lib"
+ depends on BR2_LINUX_KERNEL
+ depends on BR2_arm
+ help
+ Library of userspace helpers specific for the Freescale i.MX
+ platform. It wraps the kernel interfaces for some i.MX platform
+ specific drivers. It requires a kernel that includes the i.MX
+ specific headers to be built.
+
+ This library is provided by Freescale as-is and doesn't have
+ an upstream.
+
+if BR2_PACKAGE_IMX_LIB
+choice
+ prompt "i.MX platform"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
+ bool "imx25-3stack"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
+ bool "imx27ads"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
+ bool "imx37-3stack"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
+ bool "imx50"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
+ bool "imx51"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
+ bool "imx53"
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
+ bool "imx6q"
+
+endchoice
+
+config BR2_PACKAGE_IMX_LIB_PLATFORM
+ string
+ default "IMX25_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
+ default "IMX27ADS" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
+ default "IMX37_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
+ default "IMX50" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
+ default "IMX51" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
+ default "IMX53" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
+ default "IMX6Q" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
+endif
diff --git a/package/imx-lib/imx-lib.mk b/package/imx-lib/imx-lib.mk
new file mode 100644
index 0000000..29f5ae1
--- /dev/null
+++ b/package/imx-lib/imx-lib.mk
@@ -0,0 +1,41 @@
+#############################################################
+#
+# imx-lib
+#
+#############################################################
+
+IMX_LIB_VERSION = 12.09.01
+# No official download site from freescale, just this mirror
+IMX_LIB_SITE = http://download.ossystems.com.br/bsp/freescale/source
+IMX_LIB_LICENSE = LGPLv2.1+
+# No license file included
+
+IMX_LIB_INSTALL_STAGING = YES
+
+# imx-lib needs access to imx-specific kernel headers
+IMX_LIB_DEPENDENCIES += linux
+IMX_LIB_INCLUDE = \
+ -I$(LINUX_DIR)/drivers/mxc/security/rng/include \
+ -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \
+ -I$(LINUX_DIR)/include
+
+IMX_LIB_MAKE_ENV = \
+ $(TARGET_MAKE_ENV) \
+ $(TARGET_CONFIGURE_OPTS) \
+ CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \
+ PLATFORM=$(BR2_PACKAGE_IMX_LIB_PLATFORM) \
+ INCLUDE="$(IMX_LIB_INCLUDE)"
+
+define IMX_LIB_BUILD_CMDS
+ $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D)
+endef
+
+define IMX_LIB_INSTALL_STAGING_CMDS
+ $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(STAGING_DIR) install
+endef
+
+define IMX_LIB_INSTALL_TARGET_CMDS
+ $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(TARGET_DIR) install
+endef
+
+$(eval $(generic-package))
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] Results of an all-package build
From: Arnout Vandecappelle @ 2012-12-17 13:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50CEDCB3.2070705@mind.be>
On 17/12/12 09:49, Arnout Vandecappelle wrote:
> On 16/12/12 01:07, Peter Korsgaard wrote:
>>>>>>> >>>>>> "Arnout" == Arnout Vandecappelle<arnout@mind.be> writes:
>> >
>> > Hi,
>> >
>> > Arnout> As part of the test of the disable-doc patch I just sent, I
>> > Arnout> built something approaching an allyespackageconfig for x86_64
>> > Arnout> with a Sourcery-2012.09 toolchain. Interesting to look at the
>> > Arnout> results.
>> >
>> > Arnout> - The following fail to build:
>> >
>> > Arnout> * classpath
>> > Arnout> * diffutils
>> > Arnout> * gpsd
>> > Arnout> * ipsec-tools
>> > Arnout> * linux-pam
>> > Arnout> * ltp-testsuite
>> > Arnout> * matchbox-desktop
>> > Arnout> * metacity
>> > Arnout> * webkit
Webkit is fixed now.
>> > Arnout> * neard
>> > Arnout> * netatalk
Not fixed by lib64 patch...
>> > Arnout> * network-manager
>> > Arnout> * pcmanfm
>> > Arnout> * pv
>> > Arnout> * sconeserver-http-sconesite-image
Not fixed by using pkg-config...
>> > Arnout> * xdriver_xf86-video-geode
>> > Arnout> * xdriver_xf86-input-synaptics
>> > Arnout> * valgrind (because glibc 2.16 is not supported, needs valgrind bump)
>> > Arnout> * xstroke
>> > Arnout> * grub
>> > Arnout> * uboot (wrong ARCH parameter)
> I'll try to re-run current HEAD (which has fixed quite a few packages
> already) with make -k and put it on a pastebin.
The results of a make -k of just these packages (except for grub and
uboot) is on http://tny.cz/8f1cf19f .
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] inadyn: Needs MMU
From: Maxime Ripard @ 2012-12-17 13:12 UTC (permalink / raw)
To: buildroot
Fixes
http://autobuild.buildroot.org/results/11d681a7f2c1d55a3d70573e9145aa231f6d4298/build-end.log
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
package/inadyn/Config.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/inadyn/Config.in b/package/inadyn/Config.in
index 623da41..a2dfa74 100644
--- a/package/inadyn/Config.in
+++ b/package/inadyn/Config.in
@@ -1,5 +1,6 @@
config BR2_PACKAGE_INADYN
bool "inadyn"
+ depends on BR2_USE_MMU # Uses fork()
help
INADYN is a free DynDNS client. It gives the possibility
to have your own fixed hostname registered on the internet,
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [PATCH] [RFC] new target: live filesystem
From: Richard Genoud @ 2012-12-17 12:41 UTC (permalink / raw)
To: buildroot
In-Reply-To: <805796c3-1a48-4485-8d1b-5c1c5d2cbfb4@zimbra2.corp.accelance.fr>
2012/12/17 Jeremy Rosen <jeremy.rosen@openwide.fr>:
> Hello everybody
>
> there is a little bit more work to do on this patch (mainly updating a few more places in the documentation) but i'd like to have a go/no-go before I do that...
I was looking for that kind of feature, I hope it will be accepted.
For now, I use the output/target tree and those parameters in the
/etc/exports file:
*(rw,all_squash,no_subtree_check,anonuid=my_uid,anongid=my_gid)
But that means that all the FS is owned by my user.
Regards,
Richard.
^ permalink raw reply
* [Buildroot] [PATCH] package/liburcu: Requires threads support
From: Maxime Ripard @ 2012-12-17 11:32 UTC (permalink / raw)
To: buildroot
Fixes
http://autobuild.buildroot.org/results/eeb6a81588a12e5b572a4e5d27e001b3ae5eac49/build-end.log
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
package/liburcu/Config.in | 5 +++++
package/lttng-libust/Config.in | 6 ++++--
package/lttng-tools/Config.in | 7 ++++++-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/package/liburcu/Config.in b/package/liburcu/Config.in
index 69878b1..f21541f 100644
--- a/package/liburcu/Config.in
+++ b/package/liburcu/Config.in
@@ -1,6 +1,7 @@
config BR2_PACKAGE_LIBURCU
bool "liburcu"
depends on BR2_arm || BR2_armeb || BR2_i386 || BR2_powerpc || BR2_x86_64
+ depends on BR2_TOOLCHAIN_HAS_THREADS
help
Userspace implementation of the Read-Copy-Update (RCU)
synchronization mechanism. This library is mainly used by
@@ -8,3 +9,7 @@ config BR2_PACKAGE_LIBURCU
purposes as well.
http://lttng.org/urcu
+
+comment "liburcu needs threads support in toolchain"
+ depends on !BR2_TOOLCHAIN_HAS_THREADS
+
diff --git a/package/lttng-libust/Config.in b/package/lttng-libust/Config.in
index ab12963..45e0ede 100644
--- a/package/lttng-libust/Config.in
+++ b/package/lttng-libust/Config.in
@@ -6,8 +6,9 @@ config BR2_PACKAGE_LTTNG_LIBUST
# util-linux needs wchar and largefile
depends on BR2_USE_WCHAR
depends on BR2_LARGEFILE
- # liburcu only works on some architectures
+ # liburcu only works on some architectures and requires threads support
depends on BR2_arm || BR2_armeb || BR2_i386 || BR2_powerpc || BR2_x86_64
+ depends on BR2_TOOLCHAIN_HAS_THREADS
help
Userspace tracing library for the Lttng tracing
infrastructure. It allows userspace programs to create
@@ -16,5 +17,6 @@ config BR2_PACKAGE_LTTNG_LIBUST
http://lttng.org
-comment "lttng-libust needs WCHAR and LARGEFILE support"
+comment "lttng-libust needs WCHAR, LARGEFILE and threads support"
depends on !(BR2_USE_WCHAR || BR2_LARGEFILE)
+ depends on !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/lttng-tools/Config.in b/package/lttng-tools/Config.in
index b854757..3d95eeb 100644
--- a/package/lttng-tools/Config.in
+++ b/package/lttng-tools/Config.in
@@ -3,8 +3,9 @@ config BR2_PACKAGE_LTTNG_TOOLS
depends on BR2_PACKAGE_LTTNG_MODULES
select BR2_PACKAGE_LIBURCU
select BR2_PACKAGE_POPT
- # liburcu only works on some architectures
+ # liburcu only works on some architectures and requires thread support
depends on BR2_arm || BR2_armeb || BR2_i386 || BR2_powerpc || BR2_x86_64
+ depends on BR2_TOOLCHAIN_HAS_THREADS
help
Userspace utilities for the LTTng 2.0 tracing
infrastructure.
@@ -22,3 +23,7 @@ config BR2_PACKAGE_LTTNG_TOOLS
lttng-libust.
http://lttng.org
+
+comment "lttng-tools needs threads support"
+ depends on !BR2_TOOLCHAIN_HAS_THREADS
+
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [PATCH] jpeg: fix make source
From: Peter Korsgaard @ 2012-12-17 11:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355743111-18183-1-git-send-email-arnout@mind.be>
>>>>> "Arnout" == Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> writes:
Arnout> 'make source' fails because the host-jpeg-source target doesn't exist
Arnout> anymore. Fix this by adding this target explicitly.
Committed, thanks.
Arnout> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Arnout> ---
Arnout> Note that this is only necessary because of the rather twisted
Arnout> way that the top-level target and dependency lists are
Arnout> generated. Now that all packages have been converted to
Arnout> gentargets it would probably be possible to create all
Arnout> necessary dependencies in the package-generic macro, which
Arnout> would remove the need for this patch.
Agreed.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCHv2] linux: Support multiple device tree build
From: Maxime Ripard @ 2012-12-17 11:23 UTC (permalink / raw)
To: buildroot
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
linux/Config.in | 5 +++--
linux/linux.mk | 6 ++++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/linux/Config.in b/linux/Config.in
index f408ad5..3ff6b4a 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -261,11 +261,12 @@ config BR2_LINUX_KERNEL_USE_CUSTOM_DTS
endchoice
config BR2_LINUX_KERNEL_INTREE_DTS_NAME
- string "Device Tree Source file name"
+ string "Device Tree Source file names"
depends on BR2_LINUX_KERNEL_USE_INTREE_DTS
help
Name of the device tree source file, without
- the trailing .dts
+ the trailing .dts. You can provide a list of
+ dts files to build, separated by spaces.
config BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
string "Device Tree Source file path"
diff --git a/linux/linux.mk b/linux/linux.mk
index c4bdf90..c7d0099 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -187,10 +187,12 @@ endef
ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y)
ifeq ($(BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT),)
define LINUX_BUILD_DTB
- $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(KERNEL_DTS_NAME).dtb
+ $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) \
+ $(foreach dtbfile, $(call qstrip, $(KERNEL_DTS_NAME)), $(dtbfile).dtb)
endef
define LINUX_INSTALL_DTB
- cp $(KERNEL_ARCH_PATH)/boot/$(KERNEL_DTS_NAME).dtb $(BINARIES_DIR)/
+ $(foreach dtbfile, $(call qstrip, $(KERNEL_DTS_NAME)),
+ cp $(KERNEL_ARCH_PATH)/boot/$(dtbfile).dtb $(BINARIES_DIR)/)
endef
endif
endif
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [git commit] jpeg: fix make source
From: Peter Korsgaard @ 2012-12-17 11:22 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=7cba1dead6ce53ccd8ea1c634fc9589f1b2e956e
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
'make source' fails because the host-jpeg-source target doesn't exist
anymore. Fix this by adding this target explicitly.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/jpeg/jpeg.mk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/package/jpeg/jpeg.mk b/package/jpeg/jpeg.mk
index 9f40e6f..3caacaa 100644
--- a/package/jpeg/jpeg.mk
+++ b/package/jpeg/jpeg.mk
@@ -7,3 +7,4 @@
jpeg: $(if $(BR2_PACKAGE_JPEG_TURBO),jpeg-turbo,libjpeg)
host-jpeg: host-libjpeg
+host-jpeg-source: host-libjpeg-source
^ permalink raw reply related
* [Buildroot] [PATCH] jpeg: fix make source
From: Arnout Vandecappelle @ 2012-12-17 11:18 UTC (permalink / raw)
To: buildroot
'make source' fails because the host-jpeg-source target doesn't exist
anymore. Fix this by adding this target explicitly.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
Note that this is only necessary because of the rather twisted way that
the top-level target and dependency lists are generated. Now that all
packages have been converted to gentargets it would probably be possible
to create all necessary dependencies in the package-generic macro, which
would remove the need for this patch.
package/jpeg/jpeg.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/jpeg/jpeg.mk b/package/jpeg/jpeg.mk
index 9f40e6f..3caacaa 100644
--- a/package/jpeg/jpeg.mk
+++ b/package/jpeg/jpeg.mk
@@ -7,3 +7,4 @@
jpeg: $(if $(BR2_PACKAGE_JPEG_TURBO),jpeg-turbo,libjpeg)
host-jpeg: host-libjpeg
+host-jpeg-source: host-libjpeg-source
--
tg: (8286d71..) t/jpeg (depends on: master)
^ permalink raw reply related
* [Buildroot] [PATCH] linux: Support multiple device tree build
From: Baruch Siach @ 2012-12-17 11:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1355742312-25258-1-git-send-email-maxime.ripard@free-electrons.com>
Hi Maxime,
On Mon, Dec 17, 2012 at 12:05:12PM +0100, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> linux/linux.mk | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/linux/linux.mk b/linux/linux.mk
> index c4bdf90..c7d0099 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -187,10 +187,12 @@ endef
> ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y)
> ifeq ($(BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT),)
> define LINUX_BUILD_DTB
> - $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(KERNEL_DTS_NAME).dtb
> + $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) \
> + $(foreach dtbfile, $(call qstrip, $(KERNEL_DTS_NAME)), $(dtbfile).dtb)
> endef
> define LINUX_INSTALL_DTB
> - cp $(KERNEL_ARCH_PATH)/boot/$(KERNEL_DTS_NAME).dtb $(BINARIES_DIR)/
> + $(foreach dtbfile, $(call qstrip, $(KERNEL_DTS_NAME)),
> + cp $(KERNEL_ARCH_PATH)/boot/$(dtbfile).dtb $(BINARIES_DIR)/)
> endef
> endif
> endif
Please update the comment and help text in the
BR2_LINUX_KERNEL_INTREE_DTS_NAME config option as well.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [Buildroot] [PATCH] linux: Support multiple device tree build
From: Maxime Ripard @ 2012-12-17 11:05 UTC (permalink / raw)
To: buildroot
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
linux/linux.mk | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/linux/linux.mk b/linux/linux.mk
index c4bdf90..c7d0099 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -187,10 +187,12 @@ endef
ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y)
ifeq ($(BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT),)
define LINUX_BUILD_DTB
- $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(KERNEL_DTS_NAME).dtb
+ $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) \
+ $(foreach dtbfile, $(call qstrip, $(KERNEL_DTS_NAME)), $(dtbfile).dtb)
endef
define LINUX_INSTALL_DTB
- cp $(KERNEL_ARCH_PATH)/boot/$(KERNEL_DTS_NAME).dtb $(BINARIES_DIR)/
+ $(foreach dtbfile, $(call qstrip, $(KERNEL_DTS_NAME)),
+ cp $(KERNEL_ARCH_PATH)/boot/$(dtbfile).dtb $(BINARIES_DIR)/)
endef
endif
endif
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [PATCH] [RFC] new target: live filesystem
From: Jeremy Rosen @ 2012-12-17 8:58 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354800968-16745-1-git-send-email-jeremy.rosen@openwide.fr>
Hello everybody
there is a little bit more work to do on this patch (mainly updating a few more places in the documentation) but i'd like to have a go/no-go before I do that...
Peter, could I have a final call on this ?
Regards
J?r?my Rosen
fight key loggers : write some perl using vim
----- Mail original -----
> De: "J?r?my Rosen" <jeremy.rosen@openwide.fr>
> ?: buildroot at busybox.net
> Cc: "J?r?my Rosen" <jeremy.rosen@openwide.fr>
> Envoy?: Jeudi 6 D?cembre 2012 14:36:07
> Objet: [PATCH] [RFC] new target: live filesystem
>
> add a new target to deploy a live filesystem to be used with NFS or
> as a chroot
>
> Signed-off-by: J?r?my Rosen <jeremy.rosen@openwide.fr>
> ---
> v2 : implement Arnoult's suggestion, update manual entry
> v3 : improve documentation for the chroot case, more suggestions by
> Arnoult
> ---
> docs/manual/beyond-buildroot.txt | 20 ++++++++------------
> fs/Config.in | 1 +
> fs/live/Config.in | 14 ++++++++++++++
> fs/live/live.mk | 19 +++++++++++++++++++
> support/dependencies/dependencies.sh | 8 ++++++++
> 5 files changed, 50 insertions(+), 12 deletions(-)
> create mode 100644 fs/live/Config.in
> create mode 100644 fs/live/live.mk
>
> diff --git a/docs/manual/beyond-buildroot.txt
> b/docs/manual/beyond-buildroot.txt
> index a87b584..17ccc1a 100644
> --- a/docs/manual/beyond-buildroot.txt
> +++ b/docs/manual/beyond-buildroot.txt
> @@ -9,19 +9,15 @@ Boot the generated images
> NFS boot
> ~~~~~~~~
>
> -To achieve NFS-boot, enable _tar root filesystem_ in the _Filesystem
> -images_ menu.
> +To achieve NFS-boot, enable _live root filesystem_ in the
> _Filesystem
> +images_ menu and select a _live image location_ to choose where the
> live
> +filesystem will be deployed. you can use _$(BINARIES_DIR)_ to easily
> +build in +/path/to/output_dir/images+
>
> -After a complete build, just run the following commands to setup the
> -NFS-root directory:
> +You will be asked for a password during the build. This is needed to
> create
> +device entries in the target filesystem
>
> --------------------
> -sudo tar -xavf /path/to/output_dir/rootfs.tar -C
> /path/to/nfs_root_dir
> --------------------
> -
> -Remember to add this path to +/etc/exports+.
> -
> -Then, you can execute a NFS-boot from your target.
> +You will need to add the _live image location_ to +/etc/exports+.
>
> Chroot
> ------
> @@ -29,7 +25,7 @@ Chroot
> If you want to chroot in a generated image, then there are few thing
> you should be aware of:
>
> -* you should setup the new root from the _tar root filesystem_
> image;
> +* you should use the _live root filesystem_ image;
>
> * either the selected target architecture is compatible with your
> host
> machine, or you should use some +qemu-*+ binary and correctly set
> it
> diff --git a/fs/Config.in b/fs/Config.in
> index da4c5ff..664d2f6 100644
> --- a/fs/Config.in
> +++ b/fs/Config.in
> @@ -11,5 +11,6 @@ source "fs/romfs/Config.in"
> source "fs/squashfs/Config.in"
> source "fs/tar/Config.in"
> source "fs/ubifs/Config.in"
> +source "fs/live/Config.in"
>
> endmenu
> diff --git a/fs/live/Config.in b/fs/live/Config.in
> new file mode 100644
> index 0000000..a79f1dc
> --- /dev/null
> +++ b/fs/live/Config.in
> @@ -0,0 +1,14 @@
> +config BR2_TARGET_ROOTFS_LIVE
> + bool "live root filesystem"
> + help
> + Create a live image of the root filesystem that is directly
> + usable as over NFS or chroot.
> +
> +config BR2_TARGET_ROOTFS_LIVE_DEST
> + string "live image location"
> + depends on BR2_TARGET_ROOTFS_LIVE
> + default "$(BINARIES_DIR)/live"
> + help
> + The directory where the image should be stored.
> + This directory will be emptied and recreated
> +
> diff --git a/fs/live/live.mk b/fs/live/live.mk
> new file mode 100644
> index 0000000..52f7444
> --- /dev/null
> +++ b/fs/live/live.mk
> @@ -0,0 +1,19 @@
> +#############################################################
> +#
> +# Build the live root filesystem directory
> +#
> +#############################################################
> +
> +
> +define ROOTFS_LIVE_CMD
> + sudo rsync -a --no-o --no-g --delete-during $(TARGET_DIR)/ \
> + $(BR2_TARGET_ROOTFS_LIVE_DEST)/
> +endef
> +
> +define ROOTFS_LIVE_INIT
> + if [ -z $(shell which sudo) ] ; then echo "sudo seems to not be
> installed on the host system" ; false ; fi
> +endef
> +
> +ROOTFS_LIVE_PRE_GEN_HOOKS += ROOTFS_LIVE_INIT
> +
> +$(eval $(call ROOTFS_TARGET,live))
> diff --git a/support/dependencies/dependencies.sh
> b/support/dependencies/dependencies.sh
> index 7a02512..ebaabbb 100755
> --- a/support/dependencies/dependencies.sh
> +++ b/support/dependencies/dependencies.sh
> @@ -158,6 +158,7 @@ if grep ^BR2_TOOLCHAIN_BUILDROOT=y $CONFIG_FILE >
> /dev/null && \
> exit 1 ;
> fi
> fi
> +
> if grep -q ^BR2_PACKAGE_CLASSPATH=y $CONFIG_FILE ; then
> for prog in javac jar; do
> if ! which $prog > /dev/null ; then
> @@ -166,3 +167,10 @@ if grep -q ^BR2_PACKAGE_CLASSPATH=y $CONFIG_FILE
> ; then
> fi
> done
> fi
> +
> +if grep ^BR2_TARGET_ROOTFS_LIVE=y $CONFIG_FILE > /dev/null ; then
> + if ! which sudo > /dev/null ; then
> + /bin/echo -e "\nYou need sudo installed on your build machine
> to build a live filesystem\n"
> + exit 1 ;
> + fi
> +fi
> --
> 1.7.10.4
>
>
^ permalink raw reply
* [Buildroot] Results of an all-package build
From: Arnout Vandecappelle @ 2012-12-17 8:49 UTC (permalink / raw)
To: buildroot
In-Reply-To: <871ueqhna8.fsf@dell.be.48ers.dk>
On 16/12/12 01:07, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle<arnout@mind.be> writes:
>
> Hi,
>
> Arnout> As part of the test of the disable-doc patch I just sent, I
> Arnout> built something approaching an allyespackageconfig for x86_64
> Arnout> with a Sourcery-2012.09 toolchain. Interesting to look at the
> Arnout> results.
>
> Arnout> - The following fail to build:
>
> Arnout> * classpath
> Arnout> * diffutils
> Arnout> * gpsd
> Arnout> * ipsec-tools
> Arnout> * linux-pam
> Arnout> * ltp-testsuite
> Arnout> * matchbox-desktop
> Arnout> * metacity
> Arnout> * webkit
> Arnout> * neard
> Arnout> * netatalk
> Arnout> * network-manager
> Arnout> * pcmanfm
> Arnout> * pv
> Arnout> * sconeserver-http-sconesite-image
> Arnout> * xdriver_xf86-video-geode
> Arnout> * xdriver_xf86-input-synaptics
> Arnout> * valgrind (because glibc 2.16 is not supported, needs valgrind bump)
> Arnout> * xstroke
> Arnout> * grub
> Arnout> * uboot (wrong ARCH parameter)
>
> Arnout> midori and jamvm are not built because they depend on the above.
>
> Interesting, and better than I feared ;) Do you have the build errors
> archived somewhere? I would like to see atleast the classpath issue.
No I haven't, but they're easy enough to reproduce.
For classpath:
checking for QtCore QtGui >= 4.1.0... yes
checking QT_CFLAGS... -I/home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/include/QtGui -DQT_SHARED -I/home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/include -I/home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/include/QtCore
checking QT_LIBS... -lQtGui -L/home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib -lQtCore
checking for /home/arnout/src/buildroot/output-ext-toolchain-x86_64/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/include/QtGui/QWidget... configure: error: cannot check for file existence when cross compiling
I'll try to re-run current HEAD (which has fixed quite a few packages
already) with make -k and put it on a pastebin.
> Arnout> There are a few more that fail to build in my environment if the
> Arnout> libxml2/mesa3d and linux-fusion patches are not applied. Also xenomai
> Arnout> must be extracted manually before the build, otherwise linux fails to
> Arnout> build.
>
> Arnout> - About 920 packages (host+target) are built, from 843 source
> Arnout> tarballs.
>
> Arnout> - legal-info succeeds without problems, except that sylpheed's
> Arnout> license file is not correctly defined.
>
> Ok, could you provide a bit more info or send patches, please?
You already fixed it :-)
[snip]
> Arnout> - Time for a clean build (without ccache and JLEVEL=3) on my laptop
> Arnout> is 6 hours. A yocto build takes roughly the same time on my laptop,
> Arnout> but has less than half as many packages.
>
> Heh. Nice, it seems doable to do this on a relatively regular schedule.
Yep. Although the Linaro toolchain is probably a more appropriate choice.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [git commit] pciutils: work around race condition in make install with high BR2_JLEVEL
From: Peter Korsgaard @ 2012-12-17 8:27 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=8286d7113f481c2acbc9dc5ff62a364087700d51
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Fixes http://autobuild.buildroot.net/results/908d7368c8dc8e320fd33f3193039f5925adc352
make install and install-lib can race against eachother causing 'install'
to fail. Work around it using MAKE1.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/pciutils/pciutils.mk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/pciutils/pciutils.mk b/package/pciutils/pciutils.mk
index ba866a0..6219711 100644
--- a/package/pciutils/pciutils.mk
+++ b/package/pciutils/pciutils.mk
@@ -48,12 +48,12 @@ endef
# Ditch install-lib if SHARED is an option in the future
define PCIUTILS_INSTALL_TARGET_CMDS
- $(MAKE) BUILDDIR=$(@D) -C $(@D) PREFIX=$(TARGET_DIR)/usr \
+ $(MAKE1) BUILDDIR=$(@D) -C $(@D) PREFIX=$(TARGET_DIR)/usr \
SHARED=$(PCIUTILS_SHARED) install install-lib
endef
define PCIUTILS_INSTALL_STAGING_CMDS
- $(MAKE) BUILDDIR=$(@D) -C $(@D) PREFIX=$(STAGING_DIR)/usr \
+ $(MAKE1) BUILDDIR=$(@D) -C $(@D) PREFIX=$(STAGING_DIR)/usr \
SHARED=$(PCIUTILS_SHARED) install install-lib
endef
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox