Samsung Galaxy S2 ラインナップの最新のリークが私たちを左右に襲ってきて以来、人々は主にバグのあるリリース前の ICS ビルドと非常に安定した GB の間で ROM を行き来しています。 結局のところ、これが私たちが習慣として XDA 上で行っていることです。リークを見つけ、フラッシュし、使用し、調整します。 飛ばなければ、ただロールバックするだけです。 もちろん、そもそもデバイス上にあるべきではないものをフラッシュすることには常に固有のリスクが伴いますが、今日の時代ではデバイスを完全にブロックするリスクはかなり小さいです。 特に、デバイスを死んだ状態から復活させるために利用できるツールがあるため、 UnBrickable Mod XDA エリート認定開発者による アダムアウトラー.
そうは言っても、リークの世界ではすべてがうまくいくわけではないようです。 XDA Elite 認定開発者に感謝 エントロピー512、リークを受信しているほとんどのデバイスは、フラッシュ後に起動しないという非常に高いリスクにさらされていることがわかりました。 漏洩した ICS カーネルには重大なバグがあり、 /data eMMC チップ内のパーティションは、ワイプやフラッシュなどの特定の操作中に破損するようです。 これは当初、CWM などのカスタム リカバリで実行される操作にのみ影響すると考えられていました。 しかし、からのフラッシュから硬いレンガが生成されたという報告があります。 在庫の回収 同じように。 影響を受けるデバイスは次のとおりです。
- 全て エピック 4G タッチ (SPH-D710) ICS 漏れ
- 全て ギャラクシーノート（GT-N7000） ICS リーク
- の AT&T ギャラクシー S II (SGH-I777) UCLD3 リーク - およびおそらくその他すべて
- 韓国の SHW-M250S/K/L 公式リリースとそのソースから構築されたカーネル
Entropy と他の開発者は、サイト全体に散在するいくつかの警告を投稿し、何が起こっているかを詳しく説明しています。 私たちの提案は、もちろん、デバイスをハードブリックするつもりでない限り、カーネルのバグが完全に修正されるまで、ユーザーはリークから ICS をフラッシュしないようにすることです。 これは eMMC のファームウェア エラーであるため、Unbrickable Mod や JTAG を介しても回復できないことに注意してください。 これは、もう少し詳しく知りたい人のために、Entropy 自身から直接提供されたものです。
危険: 多くの Samsung ICS リーク カーネルにより、デバイスが損傷する可能性があります。
さまざまな Samsung デバイスの動作に注意を払っている人は、ICS リークされたカーネルが使用されると、一部のデバイスで大量のハードブリックが発生していることに気づいたかもしれません。 これらのハードブリックは、単純なブートローダー破損ハードブリックとは異なり、JTAG サービスのベンダーがこれらのデバイスを復活させることができていないという点で特に厄介です。 これは、これらのカーネルが実際に、eMMC ストレージ デバイスに永久的な損傷を与えていると思われる事態を引き起こしているという事実によるものです。
影響を受けることが確認されているカーネルは次のとおりです。
[*]すべての Epic 4G Touch (SPH-D710) ICS がリーク[*]すべての Galaxy Note (GT-N7000) ICS がリーク[*]AT&T Galaxy S II (SGH-I777) UCLD3 リーク - そしておそらく他のすべて[*]韓国の SHW-M250S/K/L 公式リリースと、そこから構築されたカーネル ソース
安全であるべきカーネルは次のとおりです。
[*]GT-I9100 ICS リーク[*]GT-I9100 公式リリース[*]GT-I9100 Update4 ソース ベースから構築されたカーネル
影響を受けるカーネルの実行時に損害を引き起こす可能性のある操作:
CWM (およびおそらく他のカスタム リカバリ) でのワイプ (確認済み)
CWM での Nandroid バックアップの復元 (最初にワイプ)
CWM で別のファームウェアをフラッシュする (ほとんどのフラッシュは最初に消去されます)
ストック 3e リカバリのワイプ (疑わしい、パーティションもワイプ)
影響を受けるカーネルの実行時に大きなファイルが削除される (疑わしいが確認されていない)
影響を受けるカーネルがある場合:
Odin/Heimdall を使用して、正常であることがわかっているカーネルを直ちにフラッシュします。 Mobile Odin、CWM、またはその他のデバイス上の方法をフラッシュに使用しないでください。 既知の正常なカーネルは次のとおりです。
[*]ほぼすべてのジンジャーブレッド カーネル[*]GT-I9100 Update4 ソース コードから構築された ICS カーネル
この問題の根本原因はまだ特定されていませんが、XDA の多数の認定開発者は、Samsung が機能を有効にしたことが原因ではないかと疑っています。 影響を受けるカーネル、MMC_CAP_ERASE - これはフラッシュ書き込みパフォーマンスを大幅に向上させるパフォーマンス機能ですが、フラッシュの欠陥を引き起こす可能性があります。 チップセット。 GT-I9100 ICS カーネルではこの機能が有効になっていないため、安全であるように見えます。 ただし、この機能を持たないすべてのカーネルが安全であると宣言するのに十分な情報はありません。これは、カーネルの根本原因を確認できる唯一のエンティティです。 この問題を、大きなリスクを冒さずに解決したと宣言する（複数のデバイスを破壊し、修復する方法がない）のはサムスンです 彼ら自身。
一般に、追って通知があるまで、GT-I9100 以外の Exynos ベースのデバイスで Samsung ICS リークを実行している場合は、別のものをフラッシュすることを強くお勧めします。
そして、これは今朝、XDA メンバーのご好意で私たちのフォーラムにも現れました。 ガーウィン. どうやら Google に問い合わせたところ、彼らもこの問題を認識しており、エンジニアの 1 名が修正に向けて取り組んでくれることを期待しているようです。
かなり時間が経ってしまいましたが、ありがたいことに Android の Sumrall 氏が私たちの質問に答えてくれました。 コミュニティは、これは待った価値があったとわかると思います。問題: fwrev が正しく設定されていません。私たちが疑っていたように、バグ修正は私たちのビルドには含まれていません。 (パッチはこれを無条件に適用します。)質問: リビジョンが修正と一致しませんでした(スーパーブリックの問題について説明しているので、赤色で強調してください。)引用：
最初の投稿者 ケン・サムラル
このパッチには、mmc.c に fwrev を cid レジスタの権利ビットに設定する行が含まれています。 このパッチが適用される前は、ファイル /sys/class/block/mmcblk0/device/fwrev は、emmc デバイス rev 4 以降の CID から初期化されていなかったため、ゼロが表示されていました。（2回目のお問い合わせ時）パッチが適用されるまで、fwrev は 0 です。
質問: なぜ /data パーティションなのでしょうか?引用：
最初の投稿者 ケン・サムラル
おそらくバグがあると思われますが、 ただし、rev 0x19 はプロトタイプ デバイスに含まれていたファームウェアの前のバージョンでしたが、別のバグがあることがわかりました。 mmc 消去コマンドを発行すると、チップ内のデータ構造が台無しになり、電源が投入されるまでデバイスがロックアップする可能性があります。 循環した。 この問題は、ICS の開発中に多くの開発者が fastboot によるユーザーデータの消去を行っていたときに発見されました。 そこで Samsung は問題を修正し、ファームウェア リビジョン 0x25 に移行しました。はい、0x19 が 10 進数の 25 であるのは非常に厄介で、そのことが emmc ファームウェアの問題を診断しようとするときに多くの混乱を引き起こしました。 私は最終的に、emmc バージョンを_常に_ 16 進数で参照し、曖昧さをなくすために数値の前に 0x を付けることを学びました。しかし、 0x19 にはおそらく 32 K バイトのゼロをフラッシュに挿入する可能性があるバグがありますが、、ファームウェア リビジョン 0x19 のデバイスではこのパッチを使用できません。 このパッチは、リビジョン 0x25 ファームウェアの 2 バイトのコードに対して非常に特殊なハッキングを行います。 おそらく 0x19 では動作せず、せいぜいチップが誤動作し、次の時点でデータが失われる可能性があります。 最悪。 このパッチを emmc ファームウェアに適用する際の選択基準が非常に厳しいのには理由があります。数日後、私は結果を報告し、ワイプするまでファイル システムは破損しなかったと述べました。 これはそのフォローアップに対する返答です。前回の投稿で述べたように、ファームウェア Rev 0x19 には、消去コマンドが与えられた後に emmc チップがロックアップする可能性があるバグがあります。 毎回ではありませんが、十分な頻度で行われます。 通常、デバイスはこの後に再起動できますが、起動プロセス中にロックアップします。 ごくまれに、fastboot がロードされる前でもロックアップすることがあります。 あなたのテスターは不運でした。 fastboot を開始することさえできないため、デバイスがブリックされている可能性があります。 :-( もし彼が fastboot を実行できたら、 そうすれば、共有できると仮定すると、私が持っているファームウェア更新コードを使用してデバイスを回復できる可能性があります。 聞いてみます。
質問: JTAG が機能しないのはなぜですか?引用：
最初の投稿者 ケン・サムラル (Android SE)
/data はチップで最も多くの書き込みアクティビティが発生する場所であるためです。 /system には書き込まれることはなく (システムの更新中を除く)、/cache はめったに使用されません (主に OTA の受信に使用されます)。
質問: 破損したファイル システムは (eMMC 上で) 修復できますか?引用：
最初の投稿者 ケン・サムラル
上で述べたように、リビジョン 0x19 ファームウェアには、emmc 消去コマンドの後に、 emmc チップの内部データ構造が不良状態にあり、特定のセクターがロックされたときにチップがロックアップする原因となる アクセスされました。 唯一の修正はチップを消去し、ファームウェアを更新することでした。 そのためのコードはありますが、共有できるかどうかわかりません。 聞いてみます。
したがって、この修正は現時点では適用されませんが、スーパーブリックの問題に関する優れた洞察と、修正が適用されるという情報が得られました。 は すでに開発されています (リリースされることを願っています!)。 このバグは私たちに当てはまる可能性が高く、0x19 ファームウェアの修正が提供されていると仮定すると、私たちのデバイスにも適用されることになります。もっと軽い話として、彼の近況を含めたいと思いました。引用：
最初の投稿者 ケン・サムラル
e2fsck はファイルシステムを修復できますが、多くの場合、32 K バイトがブロック グループの先頭に挿入され、多くの i ノードが消去されるため、e2fsck を実行すると多くのファイルが失われることがよくありました。
引用：
最初の投稿者 ケン・サムラル
Android カーネル開発者の刺激的な生活を垣間見ることができます。 :-) 結局のところ、仕事のほとんどはバグのあるハードウェアとの戦いであることがわかりました。 少なくとも、時々そのように見えることがあります。
この問題が解決されるまでは、デバイスに ICS をフラッシュしないでください。
ポータルで何かを公開したいですか? ニュースライターに連絡してください。
[ありがとう エントロピー512 皆さんの努力のおかげで!!!]