Xperiaは扱いやすい
一般的にXperiaは公式にリカバリ手段が提供されており、flashtoolなども扱いやすいので、開発には使いやすいと思われています。というのも、他の国産メーカーなどは、Miyabi LSMやTOMOYO Linuxなどで/systemがガッチリ固められていたり、NANDロックによって簡単に復旧不可の文鎮になってしまいますし、ROMの初期イメージが容易に手に入るのも大きな利点です。しかし、いかにXperiaが扱いやすいとは言っても、絶対に気をつけるべき点が２カ所有ります。
必ず気をつける点
まず、TAパーティション。TrimAreaの略で、ここにブートローダーのロック状態や、バンド情報、DRMキーなど端末ごとに固有のデータが保存されています。ここが壊れるとハードブリックします。flashtoolはチェックサムを合わせれば任意のTAイメージを焼くことも出来ますが、失敗すると裏蓋をはがしてテストポイントを使って、s1toolから正常なTAイメージを書き戻すことになります。
もう一点は、ハードウェアの物理的な破損です。単にコネクタの接触不良や水没ということではなく、違う機種のカーネルを焼いた場合に、ハードウェア内のレジスタが不正な復旧処理によっておかしくなる場合などです。
GXの画面反転問題
Xperia GX (TX)にも後者の問題が存在します。同じblueプラットフォームのVやTのカーネルでは、ディスプレイパネルの型番を認識できない場合に、パネル内のレジスタの型番を書き換えるコンフィグが有効になっています。誤って(または故意に)VやTのカーネルをTXに焼くと、このリカバリプロセスが走って、画面が180度反転したままになる悲惨なことになります。
カスタムカーネルで起動できれば、このレジスタをもう一度書き換えることも出来ますが、国内モデルでは絶望的ですね。
同じプラットフォームで下手に互換性があるためにフラッシュしてしまうと、こういう事態に陥ります。なので、本当はGX用のROMをAXに焼くという無茶はやめて欲しいのです。たまたまTXのカーネルにはAXのパネルドライバが含まれていて、リカバリ処理も無効になっているので問題になっていませんが。
画面反転問題への対処
ストックROMではこの状態のままどうしようもないので、端末を上下反対に見ることになりますが、CM12.1ならば、救済策があります。画面描画を担当しているSurfaceflinger内で、画面描画を反転するフラグがあります。
android_frameworks_native/services/surfaceflinger/DisplayDevice.cpp内でpersist.panel.inversemountedというプロパティを見て、値に応じて描画するので、
persist.panel.inversemounted=1というようにbuild.propにでも書いておけばまともに使えるようになります。
7 コメント
Write コメントAXにTX ROMを焼いていたものです（前に2chで報告していました）
Reply上下逆さになる可能性があるのですね…知らぬが仏ですw
どの辺りのソースに書いてあるのか少し読み解いてみます。
またこの投稿にすべきコメントではないのかもしれませんがデバイスツリーを公開する予定はありますか？あればそれを参考にLBL SP用CM13や12.1を組みたかったりします。長文コメント失礼しました。
私も不勉強だった頃はクロスフラッシングなどかなり無茶をしたので、気持ちはよく分かります。
Replyソースについては、9.2.A.0.295のdefconfigにCONFIG_FB_MSM_RECOVER_PANELというのがあって、これが有効だと危ないです。
デバイスツリーは公開すべきなのですが、書き散らしていて管理も悪いので人に見せるのも恥ずかしいなと。もう少し綺麗になったらGithubにでも上げたいとは思っています。
もっともLBLのSP用なら、もともと私がhijack-ramdiskのアイデアを拝借してきたxdaのbagyuszという人がCM12.0用にBitbucketに上げています。実際、デバイスツリー自体はUBL用をほとんどそのまま使えて、本当に必要なのはHALのパッチとhijack-ramdiskのコードですね。
なるほど。
Replykernelをビルドしないように設定すればデバイススツリーは最新のもの（LBL向け）で良いのでしょうか。（またはビルドしてramdiskを取り出してhijack-ramdiskに突っ込む？）
hijack-ramdiskは赤星さん、Bugyaszさんを参考にしてうまく起動時に呼び出されるように（install-recovery.sh、chargemon?）すればいいという理解です。
HALのパッチが訳が分からなくて断念したのですが、kernelとの整合性が取れなくなったパッチがあるとZ1fのスレに書かれていたのを見ました。どのようにして整合性がない、と判断するのでしょうか？
また長文失礼しました...
カーネルについては公式からストックのソースを手に入れて、ビルドしたあとにramdiskだけ使います。
ReplyストックカーネルをCMのソースと合わせてビルドする時に、CM側のHALでこのカーネルソースには必要な定義がないとエラーが出たり(=カーネルヘッダーが古い)するので、HALの機能を削ることでカーネルが持っていない定義を使用しないようにして(=パッチを当てる)、ビルドを通します。
どの定義が問題になるかは、実際にビルドしてエラー箇所のコミットログを遡ったり、起動した後におかしな動作があれば目星を付けて関連する関数や構造体を修正します。
hijack-ramdiskについては、以前どこかで説明を書きましたが、簡単なシェルスクリプトになっているので機種ごとに適した処理をするように微調整すれば良いです。
いろいろとありがとうございます。
Reply現在Stockのカーネルソース(GitHubのXperiaDevから拝借）、Cyanogenmod 12.1公式Huashanソース、The MuppletのVendorを使ってビルドし、struct venc_entropycfgのエラーで止まったところです。
Omniなどの例を検索すると見かけましたが、Kernelにパッチをあてろということですがこれはカーネルに当てるのですか？それともこの変更をmedia-cafからロールバックし問題を発生させなくするのですか？
カーネルをいじったら起動できるイメージができないのではという危惧、しかしramdiskをhijackしている以上修正は効きそのまま起動できるのではという希望の２つでわかりませんでした。できれば享受お願いいたします。
またもし可能であればどのように調べるのか教えていただきたいです。Gerritでcommitを探す、で良ければいいのですが...
エラーの全容です。
http://imgur.com/A9O6qDo
http://imgur.com/L3hbRZz
カーネルソースに変更を加えても出来上がったカーネルは使わないので、あくまでROM側のmedia-cafとdisplay-cafを変更します。コミットを探すときはgerritよりもgithubの履歴を見る方が分かりやすいと思います。
Replyエラーが出る度に返信するのも大変なので先に答えを教えますが、SPもGXと同じBlueプラットフォームなので、HALは共通のものを使えます。リバートすべきコミットは以下の二つです。
http://git.io/vRUac
http://git.io/vRUaE
前者がmedia-cafのビルドを通すために必要で、後者は無くてもビルドは通りますが、そのままだと画面が黄色に変色するので修正のために必要です。
ISTweakさんがこれらのコミットをリバート済みのリポジトリを管理されているので、それらを直接使っても良いでしょう。
http://git.io/vRUwi
http://git.io/vRUwr
Blueに関してはこれで良いですが、カーネルソースが古くなるほど、リバートするコミットが増えて難しくなります。
逆にXperia Zの4.4程度に新しければ、何もせずともビルドが通ったりします。(実際にSO-02E用のLocked向けROMを以前作りましたし、SO-02Fも同じような方法でビルドしました。)
これより先はソースの処理を理解して自分で編集するだけの知識が必要になるので、他の端末への応用は難しいかも知れませんが、頑張ってください。
もう一点。蛇足かも知れませんが、カーネルをビルドする時に躓くかも知れないので一応。
ReplyストックのカーネルはGCC4.7でビルドされていますが、CM12.1以降はGCC4.9がデフォルトになっています。
GCC4.8から-Wsizeof-pointer-memaccessというフラグが追加されて一部のソースがエラー扱いされるので、Makefileにこのエラーを無視するように追記します。以下のフラグをUSBまわりとBluetoothのソースに適宜追加してください。
KBUILD_CFLAGS += -Wno-sizeof-pointer-memaccess
/drivers/usb/gadget/Makefile
/net/bluetooth/Makefile
Emoticon Emoticon