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
solely using GNU make
features -- no preprocessing is required.
Last time I looked it had *at least* 0.1% of the autotools features
supported :-)
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht
to write a very small, portable,
specialised alternative to Make which is small enough to ship with
packages that use it?
Why on earth would one want to reinvent make?
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
.
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
--
To unsubscribe
--
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
--
To unsubscribe from
use gvim¹ :-)
rsc
¹ Or even Eclipse vmware, if your software department has a better
feeling while using buzzword technology.
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
/*. It very much depends on what you want to do.
Documentation/drivermodel/ might also be worth a look.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2
. 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
--
To unsubscribe from this list
applications.
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
On Wed, Aug 06, 2008 at 02:31:48PM -0700, Tim Bird wrote:
Add support for a built-in command line for x86 architectures.
The Kconfig help gives the major rationale for this addition.
If this feature is desired on all architectures, shouldn't it go out of
arch/?
rsc
--
Dipl.-Ing. Robert
the toolkits he knows about and is interested in, ELBS
was either the 2nd or 3rd tool that he mentioned.
Word is getting around dude.
What is ELBS? If it is somehow better than ptxdist, I'll have to apply a
few patches there 8-)
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
configurable
rules which are being executed in a dependency-defined order; so in the
end, it can built whatever it likes.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
On Fri, Oct 10, 2008 at 06:15:05PM +0200, Tom Cooksey wrote:
Is there any way to get the physical address of mlock()'d memory from
userspace?
What do you want to do? I don't really see a reason to do such strange
things any more these days.
rsc
--
Dipl.-Ing. Robert Schwebel | http
Tom,
[Please configure your mail client to break likes @ column 80]
On Mon, Oct 13, 2008 at 08:33:25AM +0200, Tom Cooksey wrote:
On Friday 10 October 2008 21:12:13 Robert Schwebel wrote:
On Fri, Oct 10, 2008 at 06:15:05PM +0200, Tom Cooksey wrote:
Is there any way to get the physical
*driver* is IMHO not
possible, so we'll have to rely on the proprietary drivers Freescale
deliver. Bad, but I don't see another chance by now.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht
On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote:
The topic of flattened device tree look interesting to me (perhaps
because I'm a hardened device driver person and things like that
always look interesting to me) ...
The recent oftree activities look indeed very promising; the
On Tue, Jun 02, 2009 at 10:10:58PM +0100, Russell King wrote:
I really don't think combining SoC support is going to be realistic,
device tree or not. When we had just four machine types (RiscPC,
EBSA110, EBSA285, Netwinder) I did look into this and came to the
conclusion that it would be far
On Fri, Jul 31, 2009 at 12:48:37PM -0700, Tim Bird wrote:
Those fractions-of-seconds boot times are beyond the reach of the
200 MHz-class ARM9 processors and similar, where it takes two or
three seconds just to load and uncompress the kernel from NOR or
NAND flash.
While I don't disagree
Zan,
On Fri, Aug 14, 2009 at 12:19:48PM -0600, Zan Lynx wrote:
That's factor 70 away from the 110 ms boot time Tim has talked about
some days ago (and he measured on an ARM cpu which had almost half
the speed of this one), and I'm wondering what we can do to improve
the boot time.
2.4s
Marco,
On Tue, Aug 18, 2009 at 12:06:48PM +0200, Marco Stornelli wrote:
Yeah, I agree, do you really need udevd, device file creation at every
start-up in /dev? Usually static devices nodes and mdev for hotplug are
enough or at least you could use a simple script to create only once
time the
On Tue, Aug 18, 2009 at 12:34:52PM +0200, Alex Riesen wrote:
On Tue, Aug 18, 2009 at 12:21, Robert Schwebelr.schwe...@pengutronix.de
wrote:
- In general we want to have our systems close to what the mainline
does; Automation Embedded is only a small market, and anything
which is *not*
On Tue, Aug 18, 2009 at 12:48:50PM +0200, Alex Riesen wrote:
But many of the problems you described and suggested solutions
point at userspace, right? (like pre-defined static /dev, mdev script,
or using of specially designed rootfs)
Yes, right. But even there, mdev is more in the embedded
Hi David,
On Wed, Dec 02, 2009 at 09:59:50PM +, David Woodhouse wrote:
On Wed, 2009-12-02 at 13:46 -0800, Tim Bird wrote:
It applies to anything in the embedded Linux ecosystem. This
would very much include open source boot loaders like U-Boot.
And coreboot.
The world needs more
On Thu, Dec 03, 2009 at 10:38:07PM +0900, Kyungmin Park wrote:
How about the TFTP over USB? It's required feature for no ethernet devices
In barebox (aka u-boot-v2) we have USB DFU support, in a very flexible
way. Would that fit your needs?
I wish some filesystem to share between u-boot and
On Fri, Dec 04, 2009 at 02:29:12PM +1100, Aras Vaichas wrote:
In barebox (aka u-boot-v2) we have USB DFU support, in a very flexible
way. Would that fit your needs?
That would probably be better than TFTP over ethernet. A USB DFU
upgrade would only require the microcontroller to be
Andy,
On Mon, Dec 21, 2009 at 10:38:31PM +, Andy Green wrote:
About tapping into the wisdom of the U-Boot community, most of their
changes were GTAxx-specific. For example I don't know any other Linux
device than GTA02 with a Glamo in it, there is a lot of code I ported
from Linux for
Hi Andy,
[is this the right set of lists to discuss these issues? It's not
directly CELF related, but I don't know a better place for general
project independend bootloader discussions]
On Tue, Dec 22, 2009 at 08:22:27AM +, Andy Green wrote:
DFU is a special update mechanism which I believe
On Wed, Dec 23, 2009 at 08:38:08AM +, Andy Green wrote:
I don't know or care when I get the binary packages from a repo where
they're already built. The whole point of a distro solution is someone
did all the work for you. You're only thinking about mass rebuild
yourself because it's the
On Wed, Dec 23, 2009 at 09:29:22AM +, Andy Green wrote:
If you don't step into for example toolchain problems or other crazy
things...
Again this is buildroot thinking. The distro provides both the native
and cross toolchains for you. You're going to want to use the same
distro as you
CONFIG_CMD_I2C.
Remove/adjust erroneous references to CONFIG_MODULE.
MTD: Correct typo in preprocessor directive.
Remove obsolete comment referring to CFG_CMD_JFFS2.
Remove PPC support for IDE.
Robert Schwebel (2):
README: rewrite some u-boot leftovers
README: add
On Thu, Apr 14, 2011 at 09:43:35AM +0200, Matthieu CASTET wrote:
Not to say such case are not interesting : loading a linux kernel with
only a serial driver, a ramdisk and a shell as init doesn't reflect
reality.
In real product what you want if fast user interaction (sound,
mounting big
Hi,
On Fri, Aug 02, 2013 at 04:53:50PM +0200, Marco Stornelli wrote:
In fact I need a way to do very guaranteed low latency. regarding the
high clock rate (about 1 GHz) modern ARM chips can provide, maybe
preempt-rt with the cpu affinity might be a decent way to go.
Modern hardware has
On Mon, Aug 05, 2013 at 09:25:18AM +0200, Michael Schnell wrote:
You can't. And you can't, even if you try to run bare-metal software
on a dedicated core. I can't imagine how for example the cache
influences between the cores could be determined.
This would render all efforts for hard
33 matches
Mail list logo
