Hi,
After Sascha Hauer's talk [1] about u-boot-v2 [2] at ELC-E [3] there was
an increasing demand for a separate mailing list for this new boot-
loader. So this is just a short note that, in the meantime, such a list
has been created on infradead [4].
Robert
PS: Many thanks to the organizing cre
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
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 k
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 fu
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 belie
Hi Andi,
On Tue, Dec 22, 2009 at 10:23:37PM +, Andy Green wrote:
> Fedora provides a whole solution there, with the restriction it's
> designed for native build, not cross.
That's probably also a matter of taste. I still find it a feature to be
able to cross compile the systems - we can still
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 th
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
FIG_SHELL_SIMPLE".
scripts: Delete non-barebox content from scripts/.
commands: Remove reference to non-existent CONFIG_CMD_I2C.
Remove/adjust erroneous references to CONFIG_MODULE.
MTD: Correct typo in preprocessor directive.
Remove obsolete comment referring t
Hello Andrew,
On Fri, Oct 22, 2010 at 12:20:50AM +0100, Andrew Murray wrote:
> I'm performing some research [for a CELF presentation] into reducing
> boot time on embedded systems and would like to see if the embedded
> community agree with the following statement as to why Linux
> [arguably] take
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 bi
After 5 years of development, there is a new memedit release out :-)
http://www.pengutronix.de/software/memedit/index_en.html
Memedit is a small tool that can be used to map & access physical memory
on embedded devices.
The new feature is that we have memory fill support now.
rsc
--
Pengutronix
On Fri, Aug 02, 2013 at 10:33:37AM +0200, Michael Schnell wrote:
> Is there a kind of "official" way to set aside one of the available
> cores in an SMP system from the Linux OS to do deeply embedded
> extremely-low-latency stuff in a kind of single task "main loop" type
> environment ? I.e. creati
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 ha
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 ha
On Mon, Aug 05, 2013 at 09:45:23AM +0200, Michael Schnell wrote:
> On 08/02/2013 06:16 PM, Jon Sevy wrote:
> >You might try the Open Source Automation Development Labs website for
> >real-time Linux latency measurements and methodology:
> >http://www.osadl.org/
> Thanks for the pointer !
>
> On t
:-)
> 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
should have
spent your time for improving libtool ...
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-5
es GNU make and is written 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 Indust
seen that. I maintain > 500 packets in PTXdist and guess
which ones make 90% of the problems. Hint: they are not related to
autotools ...
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht
s that libtool and
> the .la files were the problem.
Right, libtool's paths are critical: libtools isn't sysroot aware, and
it seems to be not easily fixable.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Han
ools or other software installed to
> build them; this is no different.
autotools need only a shell and make
> Perhaps it might even be possible 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
ple who try to do something better than autotools have only a
fraction of the features.
Open Source is darwinism: if there is something better, let's use it.
But compare apples with apples.
> If you're going to rewrite Autotools using GNU Make, why not ask if
> another
it any more.
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
ject (has
been some time ago), the support for Maverick Crunch was horrible and
cirrus' effort to support Linux mainline was almost 0.
If you want to have something which has good community support, check
what the mainline Linux kernel supports and base your stuff on that.
rsc
--
s community driven
> here, not so much opinions on what is best (which will probably be the
> unwanted side effect of this mail anyway...)
PTXdist is in use and community driven, so it migth be worth a look :-)
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Lin
dly feeling that we solve his problems best ... which, by
the way, doesn't work too bad.
> But, they may provide a GUI, if you are into graphical presentations.
Well, if someone absolutely needs a GUI, he can use gvim¹ :-)
rsc
¹ Or even Eclipse & vmware, if your software
g as a regular user, tell me!
The question is: why do you need a tar file?
Hmm, I'm wondering if this discussion isn't off-topic here, as it is a
kernel mailing list. But I know no other list anyway, so if nobody
complains ...
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix
M, which it clearly
> doesn't like without a lot of hacking, plus, how would I
> upgrade it?
Archiving is pretty easy: all you need is:
- the ptxdist tarballs you have installed from
- all the source tarballs which have been downloaded on the first run of
the "get" stages
- y
ady to be booted, and it
still works with automatic overnight builds.
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
--
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
is attached to where and so on.
Check arch/arm/mach-at91/*. 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
l-blown configuration.
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,
which is often not the case in embedded 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-512
; My first reaction is that as soon as you enable CONFIG_EMBEDDED you
> can easily enter codepaths noone else has used for a while and that
> got unnoticed broken.
That may be no problem; if we ever come to a safety kernel, it will have
to be audited and carefully tested anyway.
rsc
--
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.-
or
whatever came with your board support package.
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
When he listed 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
4411715.html
Ok, you do native building, that's not what we do for ptxdist's standard
root filesystems.
But note that ptxdist itself is only a system to manage configurable
rules which are being executed in a dependency-defined order; so in the
end, it can built whatever it likes.
rsc
--
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
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 the
documentation about the cores without NDAs, an open *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 Soluti
On Mon, Oct 13, 2008 at 07:50:08AM -0500, Bill Gatliff wrote:
> Robert Schwebel wrote:
> > In reality, there are no real alternatives for accelerates chips.
>
> Would the Silicon Motion SM50x chips qualify as an alternative?
>
> They can do the blitting, at least. No OpenGL,
t; generation(s) of devices...
The BoM argument is probably true for high volume consumer or automotive
use cases. For industrial usage, long term maintainability and thus
availability of documentation and code is usually a more important
argument.
Just my 0.02 ct. I'm just a poor open source guy :)
orm has
mandatorily taken an intentional decision :)
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
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; t
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
On Tue, Jun 02, 2009 at 08:35:35PM -0700, Greg KH wrote:
> On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote:
> > Could flickerfree-bootsplash be a topic? Or is that completely
> > pushed into the userspace these fastboot days?
>
> We have that working today, no
Hi David,
On Fri, Jul 31, 2009 at 11:03:10AM -0700, David VomLehn wrote:
> On Fri, Jul 31, 2009 at 05:53:52PM +0200, Robert Schwebel wrote:
> > On Tue, Jun 02, 2009 at 08:35:35PM -0700, Greg KH wrote:
> > > On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote:
> &g
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
Hi,
On Thu, Aug 13, 2009 at 05:33:26PM +0200, Robert Schwebel wrote:
> On Thu, Aug 13, 2009 at 08:28:26AM -0700, Arjan van de Ven wrote:
> > > That's bad :-) So there is no room for improvement any more in our
> > > ARM boot sequences ...
> >
> > on x86 we&
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.
On Fri, Aug 14, 2009 at 07:46:51PM +0100, Jamie Lokier wrote:
> Zan Lynx wrote:
> > Or maybe its cheap and slow flash. In that case I think your only
> > hope is to make all the code as small as possible and/or find a
> > different flash filesystem that does not have to read so much of the
> > devi
On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote:
> > r...@thebe:~$ microcom | ptx_ts "U-Boot 2.0.0-rc9"
> > [ 2.395740] < 2.395740>
> > [ 2.395860] < 0.000120>
> > [ 0.11] < 0.11> U-Boot 2.0.0-rc9 (Aug 5 2009 - 10:05:58)
> > [ 0.59] < 0.48>
> > [ 0.003823] <
On Fri, Aug 14, 2009 at 11:01:58PM +0200, Linus Walleij 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
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 t
On Tue, Aug 18, 2009 at 12:34:52PM +0200, Alex Riesen wrote:
> On Tue, Aug 18, 2009 at 12:21, Robert Schwebel
> wrote:
> > - In general we want to have our systems close to what the mainline
> > does; Automation & Embedded is only a small market, and anything
> >
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
59 matches
Mail list logo
