* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Alexander Neundorf @ 2008-06-13 6:30 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <8bd0f97a0806121829o6138cb30se025fa3c29cdd1a8@mail.gmail.com>
On Friday 13 June 2008 03:29:52 Mike Frysinger wrote:
> On Thu, Jun 12, 2008 at 9:25 PM, Rob Landley wrote:
> > He recently converted Battle for Wesnoth to use something called "scons"
> > as its build system,
Battle of Wesnoth is currently converted to both Scons and CMake, and in the
end they will decide about the winner.
(since Eric is good at arguing I guess it will be scons).
> > and apparently the resulting make stuff was 1/17th
> > the size of the original.
>
> probably because scons has ~1/17th the functionality of autotools.
> seriously, it's terrible.
I saw the presentation about scons by the main scons developer at FOSDEM this
year and it felt more like a library which you can use to create a
buildsystem, not like a ready-to-use buildsystem itself.
Alex
--
TU-Kaiserslautern
Lehrstuhl für Echtzeitsysteme
Postfach 3049
D-67653 Kaiserslautern
Germany
Tel: +49 (0)631 205 3644
Fax: +49 (0)631 205 4199
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Wang, Baojun @ 2008-06-13 5:14 UTC (permalink / raw)
To: Shaz, linux-embedded
In-Reply-To: <20080613043431.GP13599@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]
在 2008-06-13五的 06:34 +0200，Robert Schwebel写道：
> On Thu, Jun 12, 2008 at 10:52:44PM +0500, Shaz wrote:
> > I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
> > felt like asking that is there one good way to get a cross compiler
> > work. I tried buildroot, scratchbox and even openMoko with
> > openEmbedded but all of them had lots of issues and don't know which
> > will be the best alternative.
If you only need to use the cross toolchain, I think ELDK is a good choice. other alternatives would be gentoo cross toolchain (using crossdev ie crossdev -t powerpc64-unknownlinux-gnu) and emdebian/slind.
Gentoo cross toolchain is my favorite, it very simple to (e)merge (just
crossdev -t arch-vendor-platform-libc) and the toolchain is managed by
gentoo package manager (portage) so all packages in the toolchain is
upgradable. I've installed about 12 different (gentoo) cross toolchain
on one machine for cross compiling.
Personally I don't use emdebian/slind but still I think they're also a
good choice.
> There's also OSELAS.Toolchain:
> http://www.pengutronix.de/oselas/toolchain/index_en.html
>
> We try to be as close to mainline gcc/binutils as possible, and if there
> are issues, please report or send patches :-)
>
> > Anyways, I liked the idea of Qemu based cross compiler. Is it possible
> > for the inexperienced to get it working and emulate the exact model
> > and devices.
>
> No.
>
> rsc
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@dslab.lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel: +86-931-8912025 Fax: +86-931-8912022
[-- Attachment #2: 这是信件的数字签名部分 --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Cross Compiler and loads of issues
From: Robert Schwebel @ 2008-06-13 4:34 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded
In-Reply-To: <7b740b700806121052n2f98dfa4hc96ebfc1be5b6bbf@mail.gmail.com>
On Thu, Jun 12, 2008 at 10:52:44PM +0500, Shaz wrote:
> I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and
> felt like asking that is there one good way to get a cross compiler
> work. I tried buildroot, scratchbox and even openMoko with
> openEmbedded but all of them had lots of issues and don't know which
> will be the best alternative.
There's also OSELAS.Toolchain:
http://www.pengutronix.de/oselas/toolchain/index_en.html
We try to be as close to mainline gcc/binutils as possible, and if there
are issues, please report or send patches :-)
> Anyways, I liked the idea of Qemu based cross compiler. Is it possible
> for the inexperienced to get it working and emulate the exact model
> and devices.
No.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* override an interrupt handler?
From: Wang, Baojun @ 2008-06-13 4:03 UTC (permalink / raw)
To: linux-embedded
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
hi,
In my application I want to override the timer interrupt, and I'm
doing in this manner:
disable_irq(0); /* disable timer irq first */
free_irq(0, NULL); /* free the old irq */
setup_irq(0, new_irq0);
setup_irq() return with 0, however I got the following OOPs message:
Bad page state in process 'swapper'
page:81003e20 flags:0x00000400 mapping:00000000 mapcount:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[<8001819c>] dump_stack+0x8/0x34
[<8005ddc8>] bad_page+0x6c/0xa4
[<8005e600>] free_hot_cold_page+0x98/0x1e8
[<802074a8>] xm_init_clockevents+0x90/0xbc
[<80215998>] xm_init+0x208/0x240
[<80206680>] kernel_init+0xec/0x310
[<800149e0>] kernel_thread_helper+0x10/0x18
So, is it possible to override the timer interrupt handler? Any hints is
greatly appreciated.
Regards,
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@dslab.lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel: +86-931-8912025 Fax: +86-931-8912022
[-- Attachment #2: 这是信件的数字签名部分 --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Sam Ravnborg @ 2008-06-13 3:11 UTC (permalink / raw)
To: Rob Landley
Cc: Tim Bird, David Woodhouse, Greg Ungerer, Leon Woestenberg,
linux-embedded
In-Reply-To: <200806122025.54791.rob@landley.net>
>
> Um, actually Eric Raymond and I have had long talks about this, and if we're
> ever in the same state for more than 3 days we may finally get to do a
> serious research project about the successors to ./configure and make.
Tom has started a nice project which he named: quagmire.
See: http://code.google.com/p/quagmire/
From the website:
quagmire is intended to replace automake and libtool. Unlike these tools
it requires GNU make and is written solely using GNU make
features -- no preprocessing is required.
Sam
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: George G. Davis @ 2008-06-13 2:10 UTC (permalink / raw)
To: Marcus Tangermann; +Cc: linux-embedded
In-Reply-To: <1522484831@web.de>
On Thu, Jun 12, 2008 at 09:35:16PM +0200, Marcus Tangermann wrote:
> Hello,
>
> we currently try to boot a 2.6.21 kernel on a custom IXP422 based board. The boot loader (U-Boot) works fine so far, memory and flash test run successfully, the NPE is also able to ping a host. So we assume the board itself is more or less working at least.
> When we try to boot a 2.6.21 kernel after uncompressing the kernel the boot process dies somehow. We've figured out so far that the kernel dies somewhere between the gunzip and start_kernel.
> I would be glad for any hint to be able to solve the problem.
Try enabling DEBUG_LL to see if it's an machine ID error. If you see:
Error: unrecognized/unsupported processor variant.
or:
Error: unrecognized/unsupported machine ID...
Then you either don't have proper processor support enabled for your target
or your bootloader is passing in the wrong machine number.
If you still don't see anything, try hacking printk.c to call
printascii() (enabled for the DEBUG_LL case) to print directly to the
serial port w/o a driver, etc.,. You can find more details on these
low-level debugging hacks via a little googling...
HTH!
--
Regards,
George
>
> Thank you a lot in advance.
> Best regards
> Marcus
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Mike Frysinger @ 2008-06-13 1:29 UTC (permalink / raw)
To: Rob Landley
Cc: Tim Bird, David Woodhouse, Greg Ungerer, Sam Ravnborg,
Leon Woestenberg, linux-embedded
In-Reply-To: <200806122025.54791.rob@landley.net>
On Thu, Jun 12, 2008 at 9:25 PM, Rob Landley wrote:
> He recently converted Battle for Wesnoth to use something called "scons" as
> its build system, and apparently the resulting make stuff was 1/17th the size
> of the original.
probably because scons has ~1/17th the functionality of autotools.
seriously, it's terrible. funny you should mention it in a thread
about cross-compiling seeing as how it doesnt have a chance of
supporting it (has hard enough time supporting native builds).
-mike
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Robert P. J. Day @ 2008-06-13 1:28 UTC (permalink / raw)
To: Rob Landley
Cc: Tim Bird, David Woodhouse, Greg Ungerer, Sam Ravnborg,
Leon Woestenberg, linux-embedded
In-Reply-To: <200806122025.54791.rob@landley.net>
On Thu, 12 Jun 2008, Rob Landley wrote:
> He recently converted Battle for Wesnoth to use something called
> "scons" as its build system, and apparently the resulting make stuff
> was 1/17th the size of the original. You'd have to ask him for
> details, though...
scons is definitely wicked cool. every time i start a new project, i
am seriously tempted to give it a shot.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Rob Landley @ 2008-06-13 1:25 UTC (permalink / raw)
To: Tim Bird
Cc: David Woodhouse, Greg Ungerer, Sam Ravnborg, Leon Woestenberg,
linux-embedded
In-Reply-To: <48514D77.4060007@am.sony.com>
On Thursday 12 June 2008 11:23:19 Tim Bird wrote:
> David Woodhouse wrote:
> > I don't think that's true, unfortunately. Autoconf makes it _easy_ to do
> > the wrong thing, and people will often introduce new problems.
>
> If autoconf is the problem (and I think it is), then that's what
> should be fixed (see my original post). At a minimum, it would be
> nice if it had more built-in detection and warning of techniques
> that were dangerous for cross-compilation.
If autoconf is currently too complicated for people to use correctly,
complicating it more probably isn't the answer. (Down that path lies C++.)
> Paul Mundt wrote:
> > You can
> > either try to fix the packages in question, convince the package
> > developers to rip out the parts that cause trouble for your environment,
> > fix your own build environment to meet the needs of the packages, or
> > whine about it on a mailing list. Empirically we already know which one
> > of those options is going to win out. ;-)
>
> LOL. Well, at least Rob has put his money where his mouth is (so to
> speak) with Firmware Linux. The chance that I'll do anything but whine
> about autoconf is slim indeed... I'll shut up now!
Um, actually Eric Raymond and I have had long talks about this, and if we're
ever in the same state for more than 3 days we may finally get to do a
serious research project about the successors to ./configure and make.
He recently converted Battle for Wesnoth to use something called "scons" as
its build system, and apparently the resulting make stuff was 1/17th the size
of the original. You'd have to ask him for details, though...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Bill Gatliff @ 2008-06-13 1:22 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <200806121925.35883.rob@landley.net>
Rob Landley wrote:
> I just did a "make distclean" on a qemu tree I had lying around. On my 1.7
> ghz 64 bit laptop, it took 9.2 seconds to figure out it had nothing to do,
> just because it had to recurse into so many subdirectories to do it.
Which is precisely why recursive makes are considered bad.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
From: Rob Landley @ 2008-06-13 0:25 UTC (permalink / raw)
To: Robert P. J. Day
Cc: Mike Frysinger, David Woodhouse, Tim Bird, Greg Ungerer,
Sam Ravnborg, Leon Woestenberg, linux-embedded
In-Reply-To: <alpine.LFD.1.10.0806121208320.22877@localhost.localdomain>
On Thursday 12 June 2008 11:12:13 Robert P. J. Day wrote:
> On Thu, 12 Jun 2008, Mike Frysinger wrote:
> > On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
> > > If we just made people write portable code and proper Makefiles,
> > > it would be less of an issue :)
> >
> > people cant even write proper *native* makefiles. mtd-utils for
> > example ;).
>
> meooowww! :-) but at the risk of dragging this even further
> off-topic, i am *constantly* asked by people how to set up makefiles
> for their software project, and what would be nice is a small
> collection of examples of a makefile (or makefiles) done *right*. as
> in,
Make doesn't scale.
99% of the builds in the open source world are "make all", and most of the
smaller projects build natively on modern dual processor 2ghz laptops in
under 10 seconds anyway.
The larger projects with significant build times usually find that make
doesn't suit their needs, so that they write some other build system.
Sometimes they do it on top of make, such as the kernel's kbuild. Sometimes
they use another language like apache's ANT. Sometimes they roll their own
in C (anybody remember X11's imake?) KDE switched to cmake:
http://lwn.net/Articles/188693/
Current compilers have a "build at once" mode where they suck the whole
project in and run the optimizer on it at once, resulting in noticeably
smaller and faster output at the expense of needing buckets of memory to hold
all the source code and intermediate structures in memory at once. The main
roadblock to making use of this? Ripping out the existing makefiles and
replacing them with a very small shell script that does something similar
to "gcc *.c".
The first question you should be asking when doing a new build system from
scratch is probably "should I really be using make"?
> properly recursive,
Recursive make considered harmful:
http://aegis.sourceforge.net/auug97.pdf
How is needing to call make recursively _not_ just another way of sayng "the
dependency checking make does, which was the central idea behind its design,
is a lost cause and we need to jettison it to do builds"?
I just did a "make distclean" on a qemu tree I had lying around. On my 1.7
ghz 64 bit laptop, it took 9.2 seconds to figure out it had nothing to do,
just because it had to recurse into so many subdirectories to do it.
> supports cross-compiling without having to
> remove your left nad, etc, etc.
Can of worms. Answering that question would be a longer post than the rest of
this combined, but I've pointed out that I don't think going there is worth
it anymore for most packages.
> so ... would anyone like to recommend a software package or two
> somewhere whose makefile(s) is/are, ITHO, done well? that i/we could
> just point at and say, "do it like that!" anyone? anyone? bueller?
A software package with makefiles done well is like asking for a _good_
example of cobol programming.
The one and only advantage make has right now is that it's ubiquitous. So
was "ed", which dates from the same general timeframe. That's not an
endorsement.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Greg Ungerer @ 2008-06-13 0:16 UTC (permalink / raw)
To: Marcus Tangermann; +Cc: linux-embedded
In-Reply-To: <1522484831@web.de>
Hi Marcus,
Marcus Tangermann wrote:
> we currently try to boot a 2.6.21 kernel on a custom IXP422 based board. The boot loader (U-Boot) works fine so far, memory and flash test run successfully, the NPE is also able to ping a host. So we assume the board itself is more or less working at least.
> When we try to boot a 2.6.21 kernel after uncompressing the kernel the boot process dies somehow. We've figured out so far that the kernel dies somewhere between the gunzip and start_kernel.
> I would be glad for any hint to be able to solve the problem.
The most common problem like this I have seen are that the
ARM machine type set by the boot loader does not match those
compiled into the kernel. Also make sure that the RAM
size being passed to the kernel is correct too.
Enable the kernels CONFIG_DEBUG_LL and it may give you some
early debug output (like an id not supported message). That
assumes a serial console...
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Glenn Henshaw @ 2008-06-13 0:13 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <8bd0f97a0806121304m7d00fb6dq27fa7aa37cbeb828@mail.gmail.com>
On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote:
> On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
>> we currently try to boot a 2.6.21 kernel
>> on a custom IXP422 based board.
>
What bootloader are you using? It may be that the memory controller
is initialized improperly.
For other resources, try the NSLU2 groups/pages. It runs the same
processor and kernel (actually many 2.6 variants).
... Glenn
--
Glenn Henshaw Logical Outcome Ltd.
e: thraxisp@logicaloutcome.ca w: www.logicaloutcome.ca
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: David Woodhouse @ 2008-06-12 22:15 UTC (permalink / raw)
To: Glenn Henshaw; +Cc: linux-embedded
In-Reply-To: <17882748-2E1B-4DB4-82FD-C5D5C4E62CC8@logicaloutcome.ca>
On Thu, 2008-06-12 at 17:28 -0400, Glenn Henshaw wrote:
> > On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
> >> we currently try to boot a 2.6.21 kernel
> >
> > time to upgrade
>
> Wrong answer!!!
>
> Many embedded devices can't upgrade kernels easily because of
> customer requirements and certifications. For example, I have worked
> on Linux based applications in the financial industry. A kernel
> upgrade here is viewed as equivalent to switching from Windows XP to
> Vista, and requires significant effort in certification testing from
> the customer's perspective. This doesn't make economic sense for
> either party.
If this certification was granted despite Marcus' admission that the
kernel doesn't even boot -- it dies between gunzip and start_kernel --
then I suspect it wasn't the kind of certification which takes 4 years
to achieve.
_Most_ people who are having trouble with old kernels have extremely
_bad_ reasons for not updating.
--
dwmw2
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Jim Freeman @ 2008-06-12 22:02 UTC (permalink / raw)
To: Mike Frysinger
Cc: James Chapman, David VomLehn, weigelt, Linux Embedded Maillist
In-Reply-To: <8bd0f97a0806121446i68af3b96sbe51cc510f7d4fb6@mail.gmail.com>
On Thu, Jun 12, 2008 at 05:46:42PM -0400, Mike Frysinger wrote:
> On Thu, Jun 12, 2008 at 5:42 PM, James Chapman wrote:
> > David VomLehn wrote:
> >> Amen, brother. I'm fortunate in that I work for an organization that is
> >> quite good about enforcing code reviews, specifically, the QA organization
> >> is empowered to reject changes that do not have code review notes. I also
> >> have a fairly broad scope, so I'm in on code reviews for a number of open
> >> source components. At each such review, one of my criteria is whether the
> >> change is suitable for pushing back to the appropriate community. This is
> >> not necessarily a short-term way to make friends, but the long-term effects
> >> will be good both for the company and for the open source community in
> >> general.
> >>
> >> Now, if we can only get the time to actually push all the backlogged fixes
> >> out...
> >
> > Er, is that GPL or LGPL code that you're modifying? If so, you *have* to
> > push those code changes out (make them available to others), whether you
> > think people will be interested or not!
>
> umm, not really. only if (1) he gives a binary to someone and (2)
> they ask him for the source. if he doesnt distribute or no one asks,
> he doesnt have to do squat.
> -mike
And I'm just betting that when he said "push ... fixes ... out"
he meant "work to get them incorporated back upstream", not just
make them available to requesters.
Most vendors these days have finally gotten the clue that sources/changes
have to be made available to downstream requesters, but far fewer
are sufficiently self-enlightened to figure out that changes need to
be accepted upstream for them to keep flowing back. And to make that
happen, vendors have to take on substantially higher overhead to win
acceptance of patches/changes upstream, an undertaking often sadly
fraught with hassle, uncertainty, and even peril. So they mostly
don't bother. To their (and their customers, and our) long-term
detriment.
And Cisco has probably learned by now (and by sad experience) to do
the Right (tm) thing.
...jfree
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Mike Frysinger @ 2008-06-12 21:56 UTC (permalink / raw)
To: Tim Bird; +Cc: James Chapman, David VomLehn, weigelt, Linux Embedded Maillist
In-Reply-To: <48519AD1.7020503@am.sony.com>
On Thu, Jun 12, 2008 at 5:53 PM, Tim Bird wrote:
> Mike Frysinger wrote:
>>> Er, is that GPL or LGPL code that you're modifying? If so, you *have* to
>>> push those code changes out (make them available to others), whether you
>>> think people will be interested or not!
>>
>> umm, not really. only if (1) he gives a binary to someone and (2)
>> they ask him for the source. if he doesnt distribute or no one asks,
>> he doesnt have to do squat.
>
> This is closer to correct, but missing some important details.
>
> Start the GPL compliance tutorial/flameware in 3, 2, 1...
yeah, i really dont think licensing things belong here. sorry for following up.
how about this policy: if you want to make a statement, go pay a
lawyer. but that statement still shouldnt be made here ;).
-mike
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Tim Bird @ 2008-06-12 21:53 UTC (permalink / raw)
To: Mike Frysinger
Cc: James Chapman, David VomLehn, weigelt, Linux Embedded Maillist
In-Reply-To: <8bd0f97a0806121446i68af3b96sbe51cc510f7d4fb6@mail.gmail.com>
Mike Frysinger wrote:
>> Er, is that GPL or LGPL code that you're modifying? If so, you *have* to
>> push those code changes out (make them available to others), whether you
>> think people will be interested or not!
>
> umm, not really. only if (1) he gives a binary to someone and (2)
> they ask him for the source. if he doesnt distribute or no one asks,
> he doesnt have to do squat.
This is closer to correct, but missing some important details.
Start the GPL compliance tutorial/flameware in 3, 2, 1...
Luckily this in only on the linux-embedded list. If it were on LKML
the fun would really begin. :-)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Mike Frysinger @ 2008-06-12 21:46 UTC (permalink / raw)
To: James Chapman; +Cc: David VomLehn, weigelt, Linux Embedded Maillist
In-Reply-To: <48519837.1090902@katalix.com>
On Thu, Jun 12, 2008 at 5:42 PM, James Chapman wrote:
> David VomLehn wrote:
>> Amen, brother. I'm fortunate in that I work for an organization that is
>> quite good about enforcing code reviews, specifically, the QA organization
>> is empowered to reject changes that do not have code review notes. I also
>> have a fairly broad scope, so I'm in on code reviews for a number of open
>> source components. At each such review, one of my criteria is whether the
>> change is suitable for pushing back to the appropriate community. This is
>> not necessarily a short-term way to make friends, but the long-term effects
>> will be good both for the company and for the open source community in
>> general.
>>
>> Now, if we can only get the time to actually push all the backlogged fixes
>> out...
>
> Er, is that GPL or LGPL code that you're modifying? If so, you *have* to
> push those code changes out (make them available to others), whether you
> think people will be interested or not!
umm, not really. only if (1) he gives a binary to someone and (2)
they ask him for the source. if he doesnt distribute or no one asks,
he doesnt have to do squat.
-mike
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Alexey Zaytsev @ 2008-06-12 21:43 UTC (permalink / raw)
To: Glenn Henshaw; +Cc: linux-embedded
In-Reply-To: <17882748-2E1B-4DB4-82FD-C5D5C4E62CC8@logicaloutcome.ca>
On Fri, Jun 13, 2008 at 1:28 AM, Glenn Henshaw
<thraxisp@logicaloutcome.ca> wrote:
>
> On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote:
>
>> On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
>>>
>>> we currently try to boot a 2.6.21 kernel
>>
>> time to upgrade
>
> Wrong answer!!!
While the answer may be not valid any time you see
somebody complaining about an relatively old kernel not
working, it looks perfectly valid here.
They are experimenting with a new board, (well, not all that
new, probably), and a year-old kernel does not work. The
obvous thing it to try the latest kernel and see it it's working.
Should at least give a clue about what's wrong.
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Craig Hollabaugh @ 2008-06-12 21:43 UTC (permalink / raw)
To: Glenn Henshaw; +Cc: linux-embedded
In-Reply-To: <17882748-2E1B-4DB4-82FD-C5D5C4E62CC8@logicaloutcome.ca>
Glenn,
I totally agree with your certification statement statement as a legit
reason to not upgrade. I once worked for a aircraft lighting supplier,
their FAA certification testing process took about 4 years. Going
through the cert process makes one more resistant to change.
Craig
On Thu, 2008-06-12 at 17:28 -0400, Glenn Henshaw wrote:
> On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote:
>
> > On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
> >> we currently try to boot a 2.6.21 kernel
> >
> > time to upgrade
>
> Wrong answer!!!
>
> Many embedded devices can't upgrade kernels easily because of
> customer requirements and certifications. For example, I have worked
> on Linux based applications in the financial industry. A kernel
> upgrade here is viewed as equivalent to switching from Windows XP to
> Vista, and requires significant effort in certification testing from
> the customer's perspective. This doesn't make economic sense for
> either party.
>
> Often developers not working in the embedded space don't understand
> this reality.
>
> Helpful responses on what does/does not work would be more
> appreciated.
>
> ... Glenn
>
> >
> >
> >> on a custom IXP422 based board.
> >
> > you'll have better luck asking on the arm kernel mailing lists. they
> > process this stuff every day.
> > -mike
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> > embedded" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Dr. Craig Hollabaugh, craig@hollabaugh.com, 970 240 0509
Author of Embedded Linux: Hardware, Software and Interfacing
www.embeddedlinuxinterfacing.com
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: James Chapman @ 2008-06-12 21:42 UTC (permalink / raw)
To: David VomLehn; +Cc: weigelt, Linux Embedded Maillist
In-Reply-To: <485190E8.80705@cisco.com>
David VomLehn wrote:
> Enrico Weigelt wrote:
>> * Rob Landley <rob@landley.net> schrieb:
>>
>>> Cross compiling breaks stuff, yes.
>>>
>>> Most packages don't cross compile at all. Debian has somewhere north
>>> of 30,000 packages. Every project that does large scale cross
>>> compiling (buildroot, gentoo embedded, timesys making fedora cross
>>> compile, etc) tends to have about 200 packages that cross compile
>>> more or less easily, another 400 or so that can be made to cross
>>> compile with _lot_ of effort and a large enough rock, and then the
>>> project stalls at about that size.
>>>
>>
>> The problem is: most embedded projects don't make really general-purpose
>> fixes (instead strange things like hacking up autogenerated files), so
>> they can't feed back to upstream.
>>
>> IMHO, a huge waste of working time.
>>
>>
> Amen, brother. I'm fortunate in that I work for an organization that is
> quite good about enforcing code reviews, specifically, the QA
> organization is empowered to reject changes that do not have code review
> notes. I also have a fairly broad scope, so I'm in on code reviews for a
> number of open source components. At each such review, one of my
> criteria is whether the change is suitable for pushing back to the
> appropriate community. This is not necessarily a short-term way to make
> friends, but the long-term effects will be good both for the company and
> for the open source community in general.
>
> Now, if we can only get the time to actually push all the backlogged
> fixes out...
Er, is that GPL or LGPL code that you're modifying? If so, you *have* to
push those code changes out (make them available to others), whether you
think people will be interested or not!
> --
> David VomLehn, dvomlehn@cisco.com
> The opinions expressed herein are likely mine, but might not be my
> employer's...
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Mike Frysinger @ 2008-06-12 21:35 UTC (permalink / raw)
To: Glenn Henshaw; +Cc: linux-embedded
In-Reply-To: <17882748-2E1B-4DB4-82FD-C5D5C4E62CC8@logicaloutcome.ca>
On Thu, Jun 12, 2008 at 5:28 PM, Glenn Henshaw wrote:
> On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote:
>> On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
>>> we currently try to boot a 2.6.21 kernel
>>
>> time to upgrade
>
> Wrong answer!!!
not really
> Many embedded devices can't upgrade kernels easily because of customer
> <snip>
and there are plenty of *wrong* reasons that people are using old kernels.
> Often developers not working in the embedded space don't understand this
> reality.
if i'm not classified as an embedded developer, then i dont know what one is :P
> Helpful responses on what does/does not work would be more appreciated.
i gave a realistic one and i sent him to the right place -- the arm
kernel mailing lists
-mike
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Glenn Henshaw @ 2008-06-12 21:28 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <8bd0f97a0806121304m7d00fb6dq27fa7aa37cbeb828@mail.gmail.com>
On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote:
> On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote:
>> we currently try to boot a 2.6.21 kernel
>
> time to upgrade
Wrong answer!!!
Many embedded devices can't upgrade kernels easily because of
customer requirements and certifications. For example, I have worked
on Linux based applications in the financial industry. A kernel
upgrade here is viewed as equivalent to switching from Windows XP to
Vista, and requires significant effort in certification testing from
the customer's perspective. This doesn't make economic sense for
either party.
Often developers not working in the embedded space don't understand
this reality.
Helpful responses on what does/does not work would be more
appreciated.
... Glenn
>
>
>> on a custom IXP422 based board.
>
> you'll have better luck asking on the arm kernel mailing lists. they
> process this stuff every day.
> -mike
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Glenn Henshaw Logical Outcome Ltd.
e: thraxisp@logicaloutcome.ca w: www.logicaloutcome.ca
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: David VomLehn @ 2008-06-12 21:11 UTC (permalink / raw)
To: weigelt; +Cc: Linux Embedded Maillist
In-Reply-To: <20080612182529.GB7423@nibiru.local>
Enrico Weigelt wrote:
> * Rob Landley <rob@landley.net> schrieb:
>
>> Cross compiling breaks stuff, yes.
>>
>> Most packages don't cross compile at all. Debian has somewhere north of
>> 30,000 packages. Every project that does large scale cross compiling
>> (buildroot, gentoo embedded, timesys making fedora cross compile, etc) tends
>> to have about 200 packages that cross compile more or less easily, another
>> 400 or so that can be made to cross compile with _lot_ of effort and a large
>> enough rock, and then the project stalls at about that size.
>>
>
> The problem is: most embedded projects don't make really general-purpose
> fixes (instead strange things like hacking up autogenerated files), so
> they can't feed back to upstream.
>
> IMHO, a huge waste of working time.
>
>
Amen, brother. I'm fortunate in that I work for an organization that is
quite good about enforcing code reviews, specifically, the QA
organization is empowered to reject changes that do not have code review
notes. I also have a fairly broad scope, so I'm in on code reviews for a
number of open source components. At each such review, one of my
criteria is whether the change is suitable for pushing back to the
appropriate community. This is not necessarily a short-term way to make
friends, but the long-term effects will be good both for the company and
for the open source community in general.
Now, if we can only get the time to actually push all the backlogged
fixes out...
--
David VomLehn, dvomlehn@cisco.com
The opinions expressed herein are likely mine, but might not be my
employer's...
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Enrico Weigelt @ 2008-06-12 20:55 UTC (permalink / raw)
To: Linux Embedded Maillist
In-Reply-To: <20080612185525.7770F24035@gemini.denx.de>
* Wolfgang Denk <wd@denx.de> schrieb:
> In message <20080612181806.GA7423@nibiru.local> you wrote:
> >
> > Perl never was crosscompile-capable.
> > I've rewrote much of the buildscripts, but not finished yet.
>
> Note that Perl is included with our ELDK, and we do cross-compile it.
> It's not exactly trivial, but not really difficult either.
URL ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
^ 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