* [Buildroot] buildroot for AM3358 AM3359 with wireless-tools shared library
From: Arnout Vandecappelle @ 2012-11-12 6:14 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352286268.3710.9.camel@debian.fritz.box>
Hi Juergen,
I'm sorry, but I haven't been able to pinpoint the core issue - except that it
looks like gcc is using the host configuration to build crt0, which seems odd.
This code has changed a lot in gcc 4.7, so maybe you can try that?
Regards,
Arnout
On 11/07/12 12:04, J?rgen Benjamin Ronshausen wrote:
> sorry it took me so long.
>
> regards J?rgen
>
> output/toolchain/gcc-4.6.3-intermediate/gcc/config.status
>
> http://pastebin.com/fLGkJmKi
>
> config.log
>
> http://pastebin.com/WEZd2w7n
>
> auto-host.h
>
> http://pastebin.com/sJZXZvAN
>
> On Thu, 2012-11-01 at 00:06 +0100, Arnout Vandecappelle wrote:
>> On 10/31/12 12:30, J?rgen Benjamin Ronshausen wrote:
>>> logfile1's size is 3MB, to big for pastebin, so i uploaded both to
>>> github
>>>
>>> https://github.com/steven11/the-hunt-for-wireless-tools
>>
>> gcc-intermediate's config thinks that largefile is enabled... Can you post
>> output/toolchain/gcc-4.6.3-intermediate/gcc/config.status, config.log and
>> auto-host.h?
>>
>> BTW what kind of build machine do you use?
>>
>> 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] buildroot-2012.08: Handling drm module
From: Zvi Vered @ 2012-11-12 3:58 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A029E0.4020802@mind.be>
Hello,
Build is OK.
The resulting image boots OK.
But the screen flickers with this image.
The image was not built with buildroot.
I built vanilla 3.4.7 downloaded from kernel.org
With knoppix 7.0.4, when I boot with: "knoppix 2" there is no flickering.
When I boot with "knoppix 2 nodrm" the screen flickers.
Is "nodrm" a boot parameter (like vga=normal) ?
Thanks,
Zvika
-----Original Message-----
From: Arnout Vandecappelle
Sent: Monday, November 12, 2012 12:42 AM
To: Zvi Vered
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] buildroot-2012.08: Handling drm module
On 11/11/12 22:05, Zvi Vered wrote:
> Hello,
>
> I just tried buildroot-2012.08
>
> According to .config buildroot does not handle 'drm'. at all.
> Am I right ?
>
> When I booted my PC104 module with 'knoppix 2 nodrm' the text screen
> flickers.
> With 'knoppix 2' the screen is OK.
>
> Now I want to boot the PC104 with "my" distribution based on vanilla
> 3.4.7, busybox.
> Can you help ?
Can you explain what your problem is? Is it that the build fails, or that
the
resulting image doesn't boot, or that the screen still flickers with the
buildroot image?
In any case, it is probably a kernel problem. If you use exactly the same
kernel
version and kernel configuration as in knoppix, you should get the same
behaviour.
(You can usually get the configuration of a running kernel from
/proc/config.gz).
Note that knoppix may have additional kernel patches as well.
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] Various problem using buildroot-2012.05
From: Stefan Fröberg @ 2012-11-12 0:04 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A02B0C.4000107@mind.be>
12.11.2012 0:47, Arnout Vandecappelle kirjoitti:
> On 11/10/12 15:51, Stefan Fr?berg wrote:
>>
>> If you try to use buildroot-made target gcc to compile perl, that is,
>> you use buildroot to cross-compile gcc to run
>> natively inside
>> uClibc (?) environment, then you might encounter problems.
>>
>> As Thomas has said in few times here for people telling about
>> problems of native gcc-toolchain, buildroot is about
>> cross-compiling stuff
>> and buildroot produced native gcc-toolchain is really not supported
>> and might be still broken
>> (I don't know what the current status of it is now).
>
> The current status is: we're going to remove it. Thomas has just
> posted some
> patches to do that.
>
Awww...
Well, it's good that he mentioned it at this point, before I started
doing any real work with that native toolchain.
> The idea is: if you need a toolchain on the target, there is no
> reason not to
> use a normal distro: debian, ubuntu, gentoo, ....
>
>
> As for perl, however, I think we really would like to be able to
> cross-compile
> perl modules. But that unfortunately still needs some work. I messed
> about
> with it for a bit, but I can't say I really understand how the perl
> build system
> works.
>
Yeah.
Another "little" difficult case is Python.
Even tought Python uses autotools, it (and Perl) will always be the
worst cross-compile
friendly citizens in my book.
Way back, before buildroot, I tried many times to cross-compile it in
Mingw32 environment and it was an
absolute nightmare. With Perl I had even less luck.
Every time I find an interesting open source project that I would like
to try and cross-compile,
I will make an silent prayer to God's of programmers that the build
system that is revealed from
tarball will be a GNU autoconf script (or even cmake one for God's sake)
and not
some hodge-bodge, custom made, configuration nightmare.
Regards
Stefan
>
> Regards,
> Arnout
>
^ permalink raw reply
* [Buildroot] [PATCH 1/2] Deprecate the support for the toolchain on target
From: Arnout Vandecappelle @ 2012-11-11 23:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121111235938.358914c5@skate>
On 11/11/12 23:59, Thomas Petazzoni wrote:
>
> On Sun, 11 Nov 2012 23:53:33 +0100, Arnout Vandecappelle wrote:
>
>> Who, documentation has nothing to do with the toolchain on target!
>> I can easily imagine use cases where you want to be able to do 'man
>> tcpdump' on the target.
>
> Well this is what we agreed during the meeting, and is even noted in
> your Action Points at
> http://elinux.org/Buildroot:DeveloperDaysELCE2012#Action_points :-)
Right. Typing turns of your brain, to some extent :-)
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 02/23] manual: make clean target consistent with others in buildroot
From: Samuel Martin @ 2012-11-11 23:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A02D3E.8060701@mind.be>
2012/11/11 Arnout Vandecappelle <arnout@mind.be>:
> On 11/11/12 14:14, Samuel Martin wrote:
>>
>> Signed-off-by: Samuel Martin<s.martin49@gmail.com>
>>
>> diff --git a/docs/manual/manual.mk b/docs/manual/manual.mk
>> index 1eaf73a..83d2fcb 100644
>> --- a/docs/manual/manual.mk
>> +++ b/docs/manual/manual.mk
>> @@ -38,10 +38,10 @@ $(call
>> GENDOC_INNER,$(1),chunked,split-html,chunked,Split HTML)
>> $(call GENDOC_INNER,$(1),pdf,pdf,pdf,PDF,--dblatex-opts "-P
>> latex.output.revhistory=0")
>> $(call GENDOC_INNER,$(1),text,txt,text,Text)
>> $(call GENDOC_INNER,$(1),epub,epub,epub,EPUB)
>> -clean: clean-$(1)
>> -clean-$(1):
>> +clean clean-$(1): $(1)-clean
>
>
> I think you can safely remove clean-$(1) - or should we consider this API?
Actually, I kept it to, at least, not break the release.
IIRC, Peter generates the manual and includes it in the release tarball.
That's why I choose the safe path ;-) but I can remove it as soon as
Peter has confirmed it does not break anything.
Regards,
--
Sam
^ permalink raw reply
* [Buildroot] [PATCH 05/11] nfs-utils: reformat patch set as git patches
From: Arnout Vandecappelle @ 2012-11-11 23:24 UTC (permalink / raw)
To: buildroot
In-Reply-To: <d86142f877a476239ab6c3cf49f09cebb6f285f6.1352583641.git.thomas.petazzoni@free-electrons.com>
On 11/10/12 22:42, Thomas Petazzoni wrote:
> As we will need to add more patches to nfs-utils, we need a correct
> ordering when applying patches. Therefore, reformat the patches to use
> a git format and git naming.
>
> The nfs-utils-dont-mix-flags.patch is no longer needed as it was
> patching Makefile.in files that were being regenerated due to the
> package having _AUTORECONF = YES. The Makefile.in are properly
> regenerated thanks to the nfs-utils-0002-Patch-taken-from-Gentoo.patch
> patch.
>
> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
[snip]
> diff --git a/package/nfs-utils/nfs-utils-cross-build.patch b/package/nfs-utils/nfs-utils-0002-Patch-taken-from-Gentoo.patch
> similarity index 69%
> rename from package/nfs-utils/nfs-utils-cross-build.patch
> rename to package/nfs-utils/nfs-utils-0002-Patch-taken-from-Gentoo.patch
> index 43928bf..e310c49 100644
> --- a/package/nfs-utils/nfs-utils-cross-build.patch
> +++ b/package/nfs-utils/nfs-utils-0002-Patch-taken-from-Gentoo.patch
> @@ -1,7 +1,17 @@
> -Patch taken from Gentoo.
> +From 971389625c9602085d399d8ae7fc42b75efcfb7c Mon Sep 17 00:00:00 2001
> +From: Gustavo Zacarias<gustavo@zacarias.com.ar>
> +Date: Sat, 10 Nov 2012 18:56:12 +0100
> +Subject: [PATCH] Patch taken from Gentoo
Could you take the opportunity to improve the patch description a bit?
[snip]
> diff --git a/package/nfs-utils/nfs-utils-susv3-legacy.patch b/package/nfs-utils/nfs-utils-0003-Switch-legacy-index-in-favour-of-strchr.patch
> similarity index 50%
> rename from package/nfs-utils/nfs-utils-susv3-legacy.patch
> rename to package/nfs-utils/nfs-utils-0003-Switch-legacy-index-in-favour-of-strchr.patch
> index 66dd181..82a6c43 100644
> --- a/package/nfs-utils/nfs-utils-susv3-legacy.patch
> +++ b/package/nfs-utils/nfs-utils-0003-Switch-legacy-index-in-favour-of-strchr.patch
> @@ -1,11 +1,20 @@
> -Switch legacy index() in favour of strchr()
> -Updated for 1.2.6 from the previous patch by Frederik Pasch.
> +From 636e78e4c9bc8be174805bde2f3ae7f940dc3d0e Mon Sep 17 00:00:00 2001
> +From: Gustavo Zacarias<gustavo@zacarias.com.ar>
> +Date: Sat, 10 Nov 2012 18:58:15 +0100
> +Subject: [PATCH] Switch legacy index() in favour of strchr() Updated for
> + 1.2.6 from the previous patch by Frederik Pasch.
There should be an extra newline here.
[snip]
> +--
> +1.7.9.5
> +
Minor nit: this git version number is also something that is in the way for
refreshing patches. I posted a script a while ago to generate patches from
git, and it strips those lines from the patches.
[snip]
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 00/23] Pull request for branch for-2012/doc
From: Arnout Vandecappelle @ 2012-11-11 23:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHXCMMLJvvLUXss-Cvt77sUA8RrUHjSLQSAD5sLmMKjdXxvS9Q@mail.gmail.com>
On 11/11/12 14:23, Samuel Martin wrote:
> Ooops, forgot to mention that there still is some "TODO" here and
> there in this series,
> because I think I haven't all inputs to write them...
> So, feel free to fill the gaps!
Once this has been committed, I'll read the whole manual and (try to) fix
open issues and spelling mistakes (if any :-) and fill in the gaps.
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 21/23] manual: add pkg-list.txt (generated list of available packages)
From: Arnout Vandecappelle @ 2012-11-11 23:11 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352639701-27829-22-git-send-email-s.martin49@gmail.com>
On 11/11/12 14:14, Samuel Martin wrote:
> +Available packages
> +------------------
> +// docs/manaual/pkg-list.txt is generated using the following command:
> +// $ git grep -E '\((autotools|cmake|generic)-package\)' package/ | \
> +// cut -d':' -f1 | grep '\.mk$' | \
> +// sed -e 's;.*\?/\(.*\?\).mk;* \1;' | \
> +// sort> docs/manual/pkg-list.txt
> +
> +include::pkg-list.txt[]
Would it be possible to generate this list dynamically? Saves us the trouble
of keeping it consistent manually. It could be difficult to convince a2x to
look into the output directory for its include:: files, though.
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 1/2] Deprecate the support for the toolchain on target
From: Thomas Petazzoni @ 2012-11-11 22:59 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A02C6D.1040105@mind.be>
On Sun, 11 Nov 2012 23:53:33 +0100, Arnout Vandecappelle wrote:
> Who, documentation has nothing to do with the toolchain on target!
> I can easily imagine use cases where you want to be able to do 'man
> tcpdump' on the target.
Well this is what we agreed during the meeting, and is even noted in
your Action Points at
http://elinux.org/Buildroot:DeveloperDaysELCE2012#Action_points :-)
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 02/23] manual: make clean target consistent with others in buildroot
From: Arnout Vandecappelle @ 2012-11-11 22:57 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352639701-27829-3-git-send-email-s.martin49@gmail.com>
On 11/11/12 14:14, Samuel Martin wrote:
> Signed-off-by: Samuel Martin<s.martin49@gmail.com>
>
> diff --git a/docs/manual/manual.mk b/docs/manual/manual.mk
> index 1eaf73a..83d2fcb 100644
> --- a/docs/manual/manual.mk
> +++ b/docs/manual/manual.mk
> @@ -38,10 +38,10 @@ $(call GENDOC_INNER,$(1),chunked,split-html,chunked,Split HTML)
> $(call GENDOC_INNER,$(1),pdf,pdf,pdf,PDF,--dblatex-opts "-P latex.output.revhistory=0")
> $(call GENDOC_INNER,$(1),text,txt,text,Text)
> $(call GENDOC_INNER,$(1),epub,epub,epub,EPUB)
> -clean: clean-$(1)
> -clean-$(1):
> +clean clean-$(1): $(1)-clean
I think you can safely remove clean-$(1) - or should we consider this API?
Regards,
Arnout
> +$(1)-clean:
> $(Q)$(RM) -rf $(O)/docs/$(1)
> -.PHONY: $(1) clean-$(1)
> +.PHONY: $(1) $(1)-clean
> endef
>
> MANUAL_SOURCES = $(wildcard docs/manual/*.txt) $(wildcard docs/images/*)
--
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 2/2] Mark a number of development related packages as deprecated
From: Arnout Vandecappelle @ 2012-11-11 22:54 UTC (permalink / raw)
To: buildroot
In-Reply-To: <c42b5a3ae08ae07779a6ee389a8367318efe96bf.1352586949.git.thomas.petazzoni@free-electrons.com>
On 11/10/12 23:36, Thomas Petazzoni wrote:
> automake, autoconf, libtool and make on the target are basically
> useless if we don't support building a toolchain on the target. Of
> course, the host variant of automake, autoconf and libtool will remain
> available.
>
> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Still for 2012.11 please :-)
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 1/2] Deprecate the support for the toolchain on target
From: Arnout Vandecappelle @ 2012-11-11 22:53 UTC (permalink / raw)
To: buildroot
In-Reply-To: <4afe9c298939f3701caa09c2cc5c4bc04f6d4408.1352586949.git.thomas.petazzoni@free-electrons.com>
On 11/10/12 23:36, Thomas Petazzoni wrote:
> config BR2_HAVE_DOCUMENTATION
> bool "documentation on the target"
> + # We no longer want to support a toolchain on the target
> + depends on BR2_DEPRECATED
> help
> Install the documentation, including manual pages and info
> pages, on the target.
Who, documentation has nothing to do with the toolchain on target! I can
easily imagine use cases where you want to be able to do 'man tcpdump' on
the target.
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 1/2 v3] neard: new package
From: Simon Dawson @ 2012-11-11 22:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A025C1.4040809@mind.be>
On 11 Nov 2012 22:25, "Arnout Vandecappelle" <arnout@mind.be> wrote:
> Since you changed the version number, you shouldn't keep my Tested-by
> (Ack is debatable).
>
> However, I retested it so you can add it again :-)
Thanks Arnout; sorry about the faux pas.
Simon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121111/252ddf4a/attachment.html>
^ permalink raw reply
* [Buildroot] Various problem using buildroot-2012.05
From: Arnout Vandecappelle @ 2012-11-11 22:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509E69FD.2000804@petroprogram.com>
On 11/10/12 15:51, Stefan Fr?berg wrote:
>
> If you try to use buildroot-made target gcc to compile perl, that is, you use buildroot to cross-compile gcc to run
> natively inside
> uClibc (?) environment, then you might encounter problems.
>
> As Thomas has said in few times here for people telling about problems of native gcc-toolchain, buildroot is about
> cross-compiling stuff
> and buildroot produced native gcc-toolchain is really not supported and might be still broken
> (I don't know what the current status of it is now).
The current status is: we're going to remove it. Thomas has just posted some
patches to do that.
The idea is: if you need a toolchain on the target, there is no reason not to
use a normal distro: debian, ubuntu, gentoo, ....
As for perl, however, I think we really would like to be able to cross-compile
perl modules. But that unfortunately still needs some work. I messed about
with it for a bit, but I can't say I really understand how the perl build system
works.
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 2/2 v3] neardal: new package
From: Simon Dawson @ 2012-11-11 22:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A02527.4020801@mind.be>
On 11 Nov 2012 22:22, "Arnout Vandecappelle" <arnout@mind.be> wrote:
> Boy, looks like I wasn't paying attention... You need to copy the
> dependencies from dbus-glib:
> depends on BR2_PACKAGE_DBUS # dbus-glib
> depends on BR2_USE_WCHAR # glib2
>
> And of course a comment to explain its absence.
Okay; thanks Arnout.
Simon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121111/0354e4d3/attachment-0001.html>
^ permalink raw reply
* [Buildroot] buildroot-2012.08: Handling drm module
From: Arnout Vandecappelle @ 2012-11-11 22:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CABRndgxqqO3HC08rVngxm2eaSVjQ9Ks04U7Mss5-xu=B4WGMdg@mail.gmail.com>
On 11/11/12 22:05, Zvi Vered wrote:
> Hello,
>
> I just tried buildroot-2012.08
>
> According to .config buildroot does not handle 'drm'. at all.
> Am I right ?
>
> When I booted my PC104 module with 'knoppix 2 nodrm' the text screen flickers.
> With 'knoppix 2' the screen is OK.
>
> Now I want to boot the PC104 with "my" distribution based on vanilla
> 3.4.7, busybox.
> Can you help ?
Can you explain what your problem is? Is it that the build fails, or that the
resulting image doesn't boot, or that the screen still flickers with the
buildroot image?
In any case, it is probably a kernel problem. If you use exactly the same kernel
version and kernel configuration as in knoppix, you should get the same behaviour.
(You can usually get the configuration of a running kernel from /proc/config.gz).
Note that knoppix may have additional kernel patches as well.
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 1/2 v3] neard: new package
From: Arnout Vandecappelle @ 2012-11-11 22:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352628468-14490-2-git-send-email-spdawson@gmail.com>
On 11/11/12 11:07, spdawson at gmail.com wrote:
> From: Simon Dawson<spdawson@gmail.com>
>
> Signed-off-by: Simon Dawson<spdawson@gmail.com>
> Acked-by: Arnout Vandecappelle (Essensium/Mind)<arnout@mind.be>
> Tested-by: Arnout Vandecappelle (Essensium/Mind)<arnout@mind.be>
> (built-test on a minimal powerpc config)
Since you changed the version number, you shouldn't keep my Tested-by
(Ack is debatable).
However, I retested it so you can add it again :-)
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 2/2 v3] neardal: new package
From: Arnout Vandecappelle @ 2012-11-11 22:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352628468-14490-3-git-send-email-spdawson@gmail.com>
On 11/11/12 11:07, spdawson at gmail.com wrote:
> From: Simon Dawson<spdawson@gmail.com>
>
> Signed-off-by: Simon Dawson<spdawson@gmail.com>
> Acked-by: Arnout Vandecappelle (Essensium/Mind)<arnout@mind.be>
> Tested-by: Arnout Vandecappelle (Essensium/Mind)<arnout@mind.be>
> (built-test on a minimal powerpc config)
> ---
> v3: Remove spurious dependency on neard, add Arnout Vandecappelle's acks
> v2: (No v2, bumped entire patch series to v3)
>
> package/Config.in | 1 +
> package/neardal/Config.in | 7 +++++++
> package/neardal/neardal.mk | 16 ++++++++++++++++
> 3 files changed, 24 insertions(+)
> create mode 100644 package/neardal/Config.in
> create mode 100644 package/neardal/neardal.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index 6115fb4..0e6970c 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -419,6 +419,7 @@ source "package/libusb/Config.in"
> source "package/libusb-compat/Config.in"
> source "package/libv4l/Config.in"
> source "package/mtdev/Config.in"
> +source "package/neardal/Config.in"
> source "package/pcsc-lite/Config.in"
> endmenu
>
> diff --git a/package/neardal/Config.in b/package/neardal/Config.in
> new file mode 100644
> index 0000000..719bf95
> --- /dev/null
> +++ b/package/neardal/Config.in
> @@ -0,0 +1,7 @@
> +config BR2_PACKAGE_NEARDAL
> + bool "neardal"
> + select BR2_PACKAGE_DBUS_GLIB
Boy, looks like I wasn't paying attention... You need to copy the
dependencies from dbus-glib:
depends on BR2_PACKAGE_DBUS # dbus-glib
depends on BR2_USE_WCHAR # glib2
And of course a comment to explain its absence.
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] group file: define groups expected by udev
From: Arnout Vandecappelle @ 2012-11-11 22:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352603315-1731-1-git-send-email-danomimanchego123@gmail.com>
On 11/11/12 04:08, Danomi Manchego wrote:
> udev-182 requires several groups to be resolvable at udev startup,
> including disk, cdrom, floppy, tape, audio, video, lp, tty, dialout,
> and kmem. Only some of these are in the default skeleton's group
> file, So let's add the missing groups, and plugdev too.
>
> This avoids getting these logs in /var/logs/messages:
>
> Jan 1 00:00:08 buildroot daemon.err udevd[37]: specified group 'dialout' unknown
> Jan 1 00:00:08 buildroot daemon.err udevd[37]: specified group 'kmem' unknown
> Jan 1 00:00:08 buildroot daemon.err udevd[37]: specified group 'video' unknown
> Jan 1 00:00:08 buildroot daemon.err udevd[37]: specified group 'lp' unknown
> Jan 1 00:00:08 buildroot daemon.err udevd[37]: specified group 'floppy' unknown
> Jan 1 00:00:08 buildroot daemon.err udevd[37]: specified group 'cdrom' unknown
> Jan 1 00:00:08 buildroot daemon.err udevd[37]: specified group 'tape' unknown
>
> Signed-off-by: Danomi Manchego<danomimanchego123@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Not tested or anything, but I agree with the principle and the patch looks
good.
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 1/2] Deprecate the support for the toolchain on target
From: Thomas Petazzoni @ 2012-11-11 22:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CA+wH294SsYiTG9AP9_q==F2-3MKf_Oe75yCM21rSDSgyNTeGcA@mail.gmail.com>
Alex,
On Sat, 10 Nov 2012 23:26:19 +0000, Alex Bradbury wrote:
> If someone took lead on reintroducing this functionality would it be
> accepted? There are at least a couple of cases where installing
> development files are useful:
> * When using buildroot to build a rootfs that is used as a sysroot for
> an external build system
To build a sysroot containing a cross-compiler + header files and
libraries you don't need the support for the toolchain on target.
> * When using e.g. luajit packages which can make use of header files
> to generate bindings (not exploited all that much right now due to
> lack of preprocessor support in luajit)
What do you need the toolchain on target for this? Header files are
available in the toolchain sysroot, i.e in
output/host/usr/<arch-tuple>/sysroot/.
So unless I'm wrong, none of those use-cases require a toolchain on the
target. Or maybe you could provide more details about those use cases
to convince us that having a toolchain on the target is important?
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] libtool version update 2.4.2
From: Thomas Petazzoni @ 2012-11-11 22:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A02018.1000804@mind.be>
On Sun, 11 Nov 2012 23:00:56 +0100, Arnout Vandecappelle wrote:
> On 11/10/12 10:53, Thomas Petazzoni wrote:
> > Alexander,
> >
> > On Fri, 9 Nov 2012 16:38:52 +0400, Alexander Khryukin wrote:
> >
> >> -LIBTOOL_VERSION = 2.2.10
> >> +LIBTOOL_VERSION = 2.4.2
> >
> > How much testing did you give to this version bump? A libtool
> > version bump is a very sensitive operation, as host-libtool is used
> > to autoreconfigure many packages in Buildroot. Therefore, this
> > patch needs a good amount of testing before being committed
> > (ideally testing that all packages having<foo>_AUTORECONF = YES
> > still build).
>
> Can't we rely on the autobuilders to do that?
Sure, we'll certainly rely on the autobuilders for a complete testing.
But I wanted to know if it had been tested again 2 packages or 20-40
packages, which makes quite a bit of difference :)
> That said, I wouldn't do this for 2012.11 anymore...
For sure, it should not be part of 2012.11, we already have enough
issues to fix.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] libtool version update 2.4.2
From: Arnout Vandecappelle @ 2012-11-11 22:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121110105308.740a3bfa@skate>
On 11/10/12 10:53, Thomas Petazzoni wrote:
> Alexander,
>
> On Fri, 9 Nov 2012 16:38:52 +0400, Alexander Khryukin wrote:
>
>> -LIBTOOL_VERSION = 2.2.10
>> +LIBTOOL_VERSION = 2.4.2
>
> How much testing did you give to this version bump? A libtool version
> bump is a very sensitive operation, as host-libtool is used to
> autoreconfigure many packages in Buildroot. Therefore, this patch needs
> a good amount of testing before being committed (ideally testing that
> all packages having<foo>_AUTORECONF = YES still build).
Can't we rely on the autobuilders to do that?
That said, I wouldn't do this for 2012.11 anymore...
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] buildroot-2012.08: Handling drm module
From: Zvi Vered @ 2012-11-11 21:05 UTC (permalink / raw)
To: buildroot
Hello,
I just tried buildroot-2012.08
According to .config buildroot does not handle 'drm'. at all.
Am I right ?
When I booted my PC104 module with 'knoppix 2 nodrm' the text screen flickers.
With 'knoppix 2' the screen is OK.
Now I want to boot the PC104 with "my" distribution based on vanilla
3.4.7, busybox.
Can you help ?
Thanks,
Zvika
^ permalink raw reply
* [Buildroot] QT packackage grantlee not building
From: Zoltan Gyarmati @ 2012-11-11 21:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509D7A48.4030002@mind.be>
Hi,
going to check it as soon a spossible, a defconfig would be
useful indeed.
Thx for the report!
BR,
Zoltan Gyarmati
On 11/09/2012 10:48 PM, Arnout Vandecappelle wrote:
> On 11/09/12 22:44, Sagaert Johan wrote:
>> Currently the build of the QT grantlee package is broken:
>> it seems like libpthread is not linked in.
>
> Could you post a defconfig so we can try to reproduce?
>
> Regards,
> Arnout
^ permalink raw reply
* [Buildroot] [PATCH] lcdproc: bump version to 0.5.6
From: Simon Dawson @ 2012-11-11 21:02 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121111210859.5c6f7510@skate>
Hi Thomas.
On 11 November 2012 20:08, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> There are apparently build issues with lcdproc 0.5.6. Not sure if they
> are new or if they were present in older versions. See
> http://autobuild.buildroot.org/results/9967bc20a6094e836c4c18ff2cd30edef143bb8e/build-end.log.
> Basically, lcdproc uses -I<foo>/host/usr/include -L<foo>/host/usr/lib
> to build things for the target.
Okay; I'll have a look. (I must have missed this problem because I'm
applying quite a large local patch to lcdproc, which necessitates an
autoreconf.)
Simon.
^ permalink raw reply
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