linux-kernel - Re: New fast(?)-boot results on ARM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 15 Aug 2009 07:59:32 +0200
From:	Dirk Behme <dirk.behme@...glemail.com>
To:	Robert Schwebel <r.schwebel@...gutronix.de>
CC:	Denys Vlasenko <vda.linux@...glemail.com>,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Tim Bird <tim.bird@...sony.com>, kernel@...gutronix.de
Subject: Re: New fast(?)-boot results on ARM

Robert Schwebel wrote:
> On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote:
>>> rsc@...be:~$ microcom | ptx_ts "U-Boot 2.0.0-rc9"
>>> [  2.395740] <  2.395740>
>>> [  2.395860] <  0.000120>
>>> [  0.000011] <  0.000011> U-Boot 2.0.0-rc9 (Aug  5 2009 - 10:05:58)
>>> [  0.000059] <  0.000048>
>>> [  0.003823] <  0.003764> Board: Phytec phyCORE-i.MX27
>>> [  0.010753] <  0.006930> cfi_probe: cfi_flash base: 0xc0000000 size: 0x02000000
>>> [  0.018711] <  0.007958> NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST Micro NAND 64MiB 1,8V 8-bit)
>>> [  0.026592] <  0.007881> imxfb@...fb0: i.MX Framebuffer driver
>>> [  0.178655] <  0.152063> dev_protect: currently broken
>>> [  0.178736] <  0.000081> Using environment in NOR Flash
>>> [  0.182577] <  0.003841> initialising PLLs
>>> [  0.367142] <  0.184565> Malloc space: 0xa3f00000 -> 0xa7f00000 (size 64 MB)
>>> [  0.370568] <  0.003426> Stack space : 0xa3ef8000 -> 0xa3f00000 (size 32 kB)
>>> [  0.445993] <  0.075425> running /env/bin/init...
>>> [  0.870592] <  0.424599>
>>> [  0.874559] <  0.003967> Hit any key to stop autoboot:  0
>> boot loader is not fast. considering its simple task, it can be made
>> faster.
> 
> Yup, will check. Almost 1 s seems really long.

Some things to check regarding this and kernel uncompression (copy):

- How often is (compressed/uncompressed) kernel data copied? Once the 
compressed one from storage (NOR/NAND?) to RAM by boot loader? Then by 
kernel's uncompression from RAM to it's final location in RAM?

- For boot loader and uncompression, is D-Cache enabled?

- Is data (image) copy done by optimized functions? Using (a) DMA or 
at least (b) some optimized memcpy using ARM's ldmia/stmia?

Best regards

Dirk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/