私のデバイスのカーネルの起動時間を改善しようとするのに助けが必要です。使っていますオマップ138カーネルバージョンへ2.6.37起動プロセスは50秒ほどかかりますが、かなり長い時間だと思います。以下は、ブートプロセスのいくつかのステップのイメージです。ご覧のとおり、メッセージは19秒遅れています。EMAC：MII PHYの設定私の考えでは、これが私の起動時間の主な問題のようです。
いくつかのテストを経た後、解凍の過程でこれらの遅延が発生することがわかりました。initramfs.cpio.lzma。私はいくつかのメッセージを印刷してそれを見つけました。initramfs.cこれはファイルであり、この遅延は次のように発生します。しかし、内部ループルートファイルシステムに解凍する機能。 initramfs.cpio.lzmaは5.3MBで、カーネルイメージ全体（uImage）は7.3MBです。
私の質問は：私が何か間違っているのでしょうか？それともそれを改善する唯一の方法はカーネルのサイズを減らすことです。おそらく、あなたのいくつかは以前にこの問題に対処したことがあるかもしれません。とても感謝しています。
ベストアンサー1
たぶんCPUのボトルネックではなく、フラッシュメディアのアクセス時間が遅いのではないでしょうか？ TIフォーラムで0.6MB /秒のフラッシュスループット制限を議論する次のスレッドを見つけました。 OMAP-L138 EVM SPIフラッシュ読み取りパフォーマンスと起動時間
テストのために（Janusが提案したように）カーネルイメージおよび/またはinitramfsを圧縮できることを確認してください（gzip -0可能であれば）。または（他のワークステーションで）より簡単にコピーを入手してください。initramfs.cpio.lzmaファイル、解凍するファイルシステムcpioの初期化次に再圧縮を使用しますlzma -0。新しく圧縮されたファイルをフラッシュメディアに上書きします。ファイルが少し大きくなると予想しました。起動速度が速いと、CPU がボトルネックを引き起こす可能性があります。起動が遅い場合、IOはボトルネックを引き起こす可能性があります。
繰り返しテストを使用することも可能ですlzma -9が、圧縮と解凍には多くのメモリが必要になる場合があります。
以下は lzma(v5.07) のマニュアルページから抜粋したものです。
On the same hardware, the decompression speed is approximately a constant number of bytes of compressed data per second. In other words, the better the compression, the faster the decom- pression will usually be. This also means that the amount of uncompressed output produced per second can vary a lot. The following table summarises the features of the presets: Preset DictSize CompCPU CompMem DecMem -0 256 KiB 0 3 MiB 1 MiB -1 1 MiB 1 9 MiB 2 MiB -2 2 MiB 2 17 MiB 3 MiB -3 4 MiB 3 32 MiB 5 MiB -4 4 MiB 4 48 MiB 5 MiB -5 8 MiB 5 94 MiB 9 MiB -6 8 MiB 6 94 MiB 9 MiB -7 16 MiB 6 186 MiB 17 MiB -8 32 MiB 6 370 MiB 33 MiB -9 64 MiB 6 674 MiB 65 MiB