On Wednesday 09 September 2009 16:33, Johannes Stezenbach wrote:
Sorry for slow reply.
On Fri, Sep 04, 2009 at 06:16:26PM +0200, Wolfram Sang wrote:
Now that microcom is in Debian sid (thanks!), where can I find ptx_ts?
It seems to be quite useful.
Back from the holidays, so here
On Wed, Aug 19, 2009 at 06:20:13PM +0200, Dirk Behme wrote:
Yes, correct. The copying itself is between 'copy' and 'done' so it
takes about 0.4s.
What's the size of the uncompressed kernel copied here?
The image is about 2.8MB, but I copied the whole partition of 3MB
because with raw
On Tue, Aug 18, 2009 at 05:31:42PM +0200, Dirk Behme wrote:
Sascha Hauer wrote:
On Fri, Aug 14, 2009 at 07:02:28PM +0200, Robert Schwebel wrote:
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
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: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* specific to these markets but mainline is good.
BTW, what is your
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
On Fri, Aug 14, 2009 at 07:02:28PM +0200, Robert Schwebel wrote:
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
Sascha Hauer wrote:
On Fri, Aug 14, 2009 at 07:02:28PM +0200, Robert Schwebel wrote:
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
Dirk Behme wrote:
Sascha Hauer wrote:
On Fri, Aug 14, 2009 at 07:02:28PM +0200, Robert Schwebel wrote:
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
Robert Schwebel wrote:
On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote:
[ �5.082616] �0.007992 RPC: Registered tcp transport module.
[ �5.605159] �0.522543 eth0: config: auto-negotiation on, 100FDX,
100HDX, 10FDX, 10HDX.
[ �6.602621] �0.997462 IP-Config: Complete:
[
On Fri, Aug 14, 2009 at 10:43:05PM +0200, Robert Schwebel wrote:
On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote:
r...@thebe:~$ microcom | ptx_ts U-Boot 2.0.0-rc9
Now that microcom is in Debian sid (thanks!), where can I find ptx_ts?
It seems to be quite useful.
[
Robert Schwebel wrote:
- 2.4 s up from u-boot to the end of Uncompressing Linux
- 300 ms until ubifs initialization starts
- 3.7 s for ubifs, until mounted root
So we basically have 7 s for the kernel. The rest is userspace, which hasn't
seen much optimization yet, other than trying to start
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
On Fri, Aug 14, 2009 at 7:02 PM, Robert
Schwebelr.schwe...@pengutronix.de wrote:
So we basically have 7 s for the kernel. The rest is userspace, which hasn't
seen much optimization yet, other than trying to start the GUI application as
early as possible, while doing all other init stuff in
2009/8/14 Robert Schwebel r.schwe...@pengutronix.de:
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
16 matches
Mail list logo