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 hol
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 it is:
>
> http://pengutronix.de/software/ptx_ts/index_en.html
>
> 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 it is:
http://pengutronix.de/software/ptx_ts/index_en.html
Hope it can be useful...
Regards,
Wolfram
--
Pengutronix e.K. | Wol
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
>> becaus
Sascha Hauer wrote:
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
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 wrot
Dirk Behme wrote
> Btw.: I tried to summarize some hints given in this thread in
>
> http://elinux.org/Boot_Time#Boot_time_check_list
>
> Please feel free to add and correct stuff!
That's a great summary of the points raised in the discussion.
It's good to organize the information and save it in
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 ro
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 bo
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 b
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 Tue, Aug 18, 2009 at 12:44, Robert Schwebel wrote:
> 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 smal
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
> > which is *not* specific to these
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
> which is *not* specific to these markets but mainline is good.
BTW, what is your mainline (or it looks
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
Johannes Stezenbach wrote:
> 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"
>
[ 7.137924] < 0.059316> starting udev
[ 7.147925] < 0.010001> mou
Tim Bird wrote:
> See the definitions of CONF_PRE_OPEN and CON_POST_OPEN
> in net/ipv4/ipconfig.c
>
> They are set to ridiculously long values. In my experience,
> you can cut them down considerably with no dangerous side
> effects (but I haven't asked the network guys about the
> possible downsi
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: C
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.
> > > [
On 08/15/2009 12:35 AM, Zan Lynx wrote:
Linus Walleij wrote:
2009/8/14 Robert Schwebel :
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
On 08/14/2009 11:04 PM, Denys Vlasenko wrote:
[ 2.742628]<0.016050> 0x0036-0x0400 : "root"
[ 3.058610]<0.315982> UBI: attaching mtd7 to ubi0
[ 3.062878]<0.004268> UBI: physical eraseblock size: 16384 bytes (16
KiB)
[ 3.070601]<0.007723> UBI: logical eras
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"
[ 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]
Linus Walleij wrote:
2009/8/14 Robert Schwebel :
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
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
2009/8/14 Robert Schwebel :
> 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
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 7:02 PM, Robert
Schwebel 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 parallel. Adding
> "quiet"
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
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.
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 device to
> mount. Perhaps use a read-only compressed filesystem for the sy
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 star
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're doing pretty well ;-)
>
> On i.MX27 (4
32 matches
Mail list logo
