link もっと前
   2018年 7月 7日 -
      2018年 7月 16日  
link もっと後

link 未来から過去へ表示
link 過去から未来へ表示(*)


link permalink

Android と MPEG2-TS その 3

その 1その 2その 3その 4


デスクランブル処理 Java 側(たぶん)


    public final int descramble(
            @NonNull ByteBuffer srcBuf, @NonNull ByteBuffer dstBuf,
            @NonNull MediaCodec.CryptoInfo cryptoInfo) {
        try {
            return native_descramble(
                    srcBuf, srcBuf.position(), srcBuf.limit(),
                    dstBuf, dstBuf.position(), dstBuf.limit());
        } catch (ServiceSpecificException e) {
            MediaCasStateException.throwExceptionIfNeeded(e.errorCode, e.getMessage());
        } catch (RemoteException e) {
        return -1;

ここで呼び出している native_descramble() は native であると宣言されています。つまり JNI 経由で呼び出します。メディアフレームワーク(の JNI 実装は frameworks/base/media/jni に配置されているようです。

デスクランブル処理 JNI 側


static jint android_media_MediaDescrambler_native_descramble(
        JNIEnv *env, jobject thiz, jbyte key, jint numSubSamples,
        jintArray numBytesOfClearDataObj, jintArray numBytesOfEncryptedDataObj,
        jobject srcBuf, jint srcOffset, jint srcLimit,
        jobject dstBuf, jint dstOffset, jint dstLimit) {
    sp<JDescrambler> descrambler = getDescrambler(env, thiz); //★★★★ descrambler は JDescrambler 型
    if (descrambler == NULL) {
        jniThrowException(env, "java/lang/IllegalStateException",
                "Invalid descrambler object!");
        return -1;

    hidl_vec<SubSample> subSamples;
    ssize_t totalLength = getSubSampleInfo(
            env, numSubSamples, numBytesOfClearDataObj,
            numBytesOfEncryptedDataObj, &subSamples);
    if (totalLength < 0) {
        jniThrowException(env, "java/lang/IllegalArgumentException",
                "Invalid subsample info!");
        return -1;
    err = descrambler->descramble(
            key, totalLength, subSamples,
            srcPtr, srcOffset, dstPtr, dstOffset,
            &status, &bytesWritten, &detailedError); //★★★★

status_t JDescrambler::descramble(
        jbyte key,
        ssize_t totalLength,
        const hidl_vec<SubSample>& subSamples,
        const void *srcPtr,
        jint srcOffset,
        void *dstPtr,
        jint dstOffset,
        Status *status,
        uint32_t *bytesWritten,
        hidl_string *detailedError) {
    auto err = mDescrambler->descramble(
            (ScramblingControl) key,
            [&status, &bytesWritten, &detailedError] (
                    Status _status, uint32_t _bytesWritten,
                    const hidl_string& _detailedError) {
                *status = _status;
                *bytesWritten = _bytesWritten;
                *detailedError = _detailedError;
            }); //★★★★

ここで出てくる mDescrambler は IDescrambler 型のポインタです。パッと見では、何がセットされているのか良くわかりませんが、このインタフェースを実装しているのは下記しかなさそうです。



class DescramblerImpl : public IDescrambler {


Return<void> DescramblerImpl::descramble(
        ScramblingControl scramblingControl,
        const hidl_vec<SubSample>& subSamples,
        const SharedBuffer& srcBuffer,
        uint64_t srcOffset,
        const DestinationBuffer& dstBuffer,
        uint64_t dstOffset,
        descramble_cb _hidl_cb) {
    ALOGV("%s", __FUNCTION__);

    // Get a local copy of the shared_ptr for the plugin. Note that before
    // calling the HIDL callback, this shared_ptr must be manually reset,
    // since the client side could proceed as soon as the callback is called
    // without waiting for this method to go out of scope.
    std::shared_ptr<DescramblerPlugin> holder = std::atomic_load(&mPluginHolder); //★★★★ holder = mPluginHolder
    if (holder.get() == nullptr) {
        _hidl_cb(toStatus(INVALID_OPERATION), 0, NULL);
        return Void();


    // Casting hidl SubSample to DescramblerPlugin::SubSample, but need
    // to ensure structs are actually idential

    int32_t result = holder->descramble(
            dstBuffer.type != BufferType::SHARED_MEMORY,

この mPluginHolder は DescramblerPlugin 型です。DescramblerImpl が生成される時に設定されます。DescramblerImpl を生成するのは MediaCasService::createDescrambler() のみ?のように見えます。

次に出てくる holder には DescramblerPlugin のポインタが入ります。Plugin の実装を探してみると ClearKey にそれらしき処理があります。

Descrambler plugin の実装


ssize_t ClearKeyDescramblerPlugin::descramble(
        bool secure,
        ScramblingControl scramblingControl,
        size_t numSubSamples,
        const SubSample *subSamples,
        const void *srcPtr,
        int32_t srcOffset,
        void *dstPtr,
        int32_t dstOffset,
        AString *errorDetailMsg) {

    ALOGV("descramble: secure=%d, sctrl=%d, subSamples=%s, "
            "srcPtr=%p, dstPtr=%p, srcOffset=%d, dstOffset=%d",
          (int)secure, (int)scramblingControl,
          subSamplesToString(subSamples, numSubSamples).string(),
          srcPtr, dstPtr, srcOffset, dstOffset);

    if (mCASSession == NULL) {
        ALOGE("Uninitialized CAS session!");

    return mCASSession->decrypt(
            secure, scramblingControl,
            numSubSamples, subSamples,
            (uint8_t*)srcPtr + srcOffset,
            dstPtr == NULL ? NULL : ((uint8_t*)dstPtr + dstOffset),

ここで出てくる mCASSession は ClearKeyCasSession を指すようです。setMediaCasSession() にて設定されています。これは後で追ってみます。

ClearKey によるデスクランブル


// Decryption of a set of sub-samples
ssize_t ClearKeyCasSession::decrypt(
        bool secure, DescramblerPlugin::ScramblingControl scramblingControl,
        size_t numSubSamples, const DescramblerPlugin::SubSample *subSamples,
        const void *srcPtr, void *dstPtr, AString * /* errorDetailMsg */) {

    AES_KEY contentKey;

        // Hold lock to get the key only to avoid contention for decryption
        Mutex::Autolock _lock(mKeyLock);

        int32_t keyIndex = (scramblingControl & 1);
            ALOGE("decrypt: key %d is invalid", keyIndex);
            return ERROR_CAS_DECRYPT;
        contentKey = mKeyInfo[keyIndex].contentKey; //★★★★ ClearKeyCasSession::updateECM() で設定する鍵だと思う
        // Don't decrypt if len < AES_BLOCK_SIZE.
        // The last chunk shorter than AES_BLOCK_SIZE is not encrypted.
        if (scramblingControl != DescramblerPlugin::kScrambling_Unscrambled
                && subSamples[i].mNumBytesOfEncryptedData >= AES_BLOCK_SIZE) {
            err = decryptPayload(
                    (char *)dst);

// Decryption of a TS payload
status_t ClearKeyCasSession::decryptPayload(
        const AES_KEY& key, size_t length, size_t offset, char* buffer) const {

    // Invariant: only call decryptPayload with TS packets with at least 16
    // bytes of payload (AES_BLOCK_SIZE).

    CHECK(length >= offset + AES_BLOCK_SIZE);

    return TpBlockCtsDecrypt(key, length - offset, buffer + offset);

// AES-128 CBC-CTS decrypt optimized for Transport Packets. |key| is the AES
// key (odd key or even key), |length| is the data size, and |buffer| is the
// ciphertext to be decrypted in place.
status_t TpBlockCtsDecrypt(const AES_KEY& key, size_t length, char* buffer) {

CBC モードで AES 暗号を復号しているようです。

まとめると、MediaDescrambler(ドキュメントはここ)の descrambler() によって、スクランブルされたデータのデスクランブルができそう、ということがわかりました。


[編集者: すずき]
[更新: 2018年 7月 17日 22:46]
link 編集する


  • コメントはありません。
open/close この記事にコメントする

link permalink

Android と MPEG2-TS その 4

その 1その 2その 3その 4


その 3 にて「DescramblerImpl を生成するのは MediaCasService::createDescrambler() のみ?のように見えます。」と書きました。この関数に至る経路がわかると、デスクランブラがどの暗号系を選択するのか?いつ選択するのか?などがわかるようになります。

で、今回は createDescrambler() が呼ばれる経路を見つけたのでメモします。しかしながら Extractor の setMediaCas() を呼び出すのは誰なのか?まだ謎のままなので、いまいちスッキリしませんけども。

Extractor の setMediaCas()


status_t MPEG2TSExtractor::setMediaCas(const HInterfaceToken &casToken) {
    HalToken halToken;
    halToken.setToExternal((uint8_t*), casToken.size());
    sp<ICas> cas = ICas::castFrom(retrieveHalInterface(halToken));
    ALOGD("setMediaCas: %p", cas.get());

    status_t err = mParser->setMediaCas(cas); //★★★★ mParser
    if (err == OK) {
        ALOGI("All tracks now have descramblers");
    return err;

ここで出てくる mParser の型は ATSParser でしたので、ATSParser の実装を見てみます。

ATSParser setMediaCas()


status_t ATSParser::setMediaCas(const sp<ICas> &cas) {
    status_t err = mCasManager->setMediaCas(cas); //★★★★ mCasManager
    if (err != OK) {
        return err;
    for (size_t i = 0; i < mPrograms.size(); ++i) {
    return OK;

ここで出てくる mCasManager の型は ATSParser::CasManager でした。CasManager を見てみましょう。

CasManager setMediaCas()


status_t ATSParser::CasManager::setMediaCas(const sp<ICas> &cas) {
    if (cas == NULL) {
        ALOGE("setMediaCas: received NULL object");
        return BAD_VALUE;
    if (mICas != NULL) {
        ALOGW("setMediaCas: already set");
        return ALREADY_EXISTS;
    for (size_t index = 0; index < mProgramCasMap.size(); index++) {
        status_t err;
        if ((err = mProgramCasMap.editValueAt(
                index)->setMediaCas(cas, mCAPidToSessionIdMap)) != OK) { //★★★★ mProgramCasMap
            return err;
    mICas = cas; //★★★★ mICas
    return OK;

Extractor から渡されてきた cas は、CasManager のメンバ変数 mICas に保存されるようです。ちなみにこの mICas はその 2 の CasManager::parsePID() にて、mICas->processEcm(mCAPidToSessionIdMap[index], ecm); の呼び出し時に出てきました。ここで保存されていたんですね。

話を戻して mProgramCasMap は unsigned がキー、ProgramCasManager のポインタが値の KeyedVector です。

ProgramCasManager setMediaCas()

status_t ATSParser::CasManager::ProgramCasManager::setMediaCas(
        const sp<ICas> &cas, PidToSessionMap &sessionMap) {
    if (mHasProgramCas) {
        return initSession(cas, sessionMap, &mProgramCas); //★★★★
    // TODO: share session among streams that has identical CA_descriptors.
    // For now, we open one session for each stream that has CA_descriptor.
    for (size_t index = 0; index < mStreamPidToCasMap.size(); index++) {
        status_t err = initSession(
                cas, sessionMap, &mStreamPidToCasMap.editValueAt(index)); //★★★★
        if (err != OK) {
            return err;
    return OK;

status_t ATSParser::CasManager::ProgramCasManager::initSession(
         const sp<ICas>& cas,
         PidToSessionMap &sessionMap,
         CasSession *session) {
    sp<IMediaCasService> casService = IMediaCasService::getService("default"); //★★★★ IMediaCasService 型
    if (casService == NULL) {
        ALOGE("Cannot obtain IMediaCasService");
        return NO_INIT;
    returnDescrambler = casService->createDescrambler(descriptor.mSystemID); //★★★★ createDescrambler()
    if (!returnDescrambler.isOk()) {
        ALOGE("Failed to create descrambler: trans=%s",
        goto l_fail;
    descramblerBase = (sp<IDescramblerBase>) returnDescrambler;
    if (descramblerBase == NULL) {
        ALOGE("Failed to create descrambler: null ptr");
        goto l_fail;

やっと createDescrambler() が出てきました。casService は IMediaCasService 型ですが、このインタフェースを実装しているクラスは 1つしかなさそうです。

MediaCasService setMediaCas()


class MediaCasService : public IMediaCasService {


Return<sp<IDescramblerBase>> MediaCasService::createDescrambler(int32_t CA_system_id) {

    ALOGV("%s: CA_system_id=%d", __FUNCTION__, CA_system_id);

    sp<IDescrambler> result;

    DescramblerFactory *factory;
    sp<SharedLibrary> library;
    if (mDescramblerLoader.findFactoryForScheme(
            CA_system_id, &library, &factory)) { //★★★★ DescramblerPlugin を探す処理はこの辺にありそう
        DescramblerPlugin *plugin = NULL;
        if (factory->createPlugin(CA_system_id, &plugin) == OK
                && plugin != NULL) {
            result = new DescramblerImpl(library, plugin); //★★★★ DescramblerImpl を生成している箇所があった

    return result;

ここでゴールのようです。まとめると Extractor の setMediaCas() を呼ぶと、

  • ATSParser::CasManager::parsePID() が呼び出している mICas->processEcm() の mICas が設定される。
    つまり ECM の処理方法が決まる
  • DescramblerImpl::mPluginHolder が設定される。
[編集者: すずき]
[更新: 2018年 7月 17日 22:44]
link 編集する


  • コメントはありません。
open/close この記事にコメントする

link permalink

AArch64 向け Linux 開発環境の構築 その 1

その 1その 2

AArch64(64 ビット ARM)向けの Linux 開発環境を構築しました。超有名ツールの組み合わせだし、簡単だろうと思っていたのですが、意外とハマって 1日掛かってしまったのでメモしておきます。使用するツールは下記の通りです。

  • クロスコンパイラ: crosstool-NG
  • カーネル: linux-next
  • ルートファイルシステム: buildroot
  • エミュレータ: qemu


クロスコンパイラを生成するため crosstool-NG(GitHub へのリンク)を使います。crosstool-NG は ARM 向け以外にもクロスコンパイラやツールチェインの構築が簡単にできて便利です。

私の環境(Debian Testing)だと libtool-bin パッケージがインストールされていなくてハマったので、インストールしておくと良いかもしれません。

crosstool-NG コード取得、セットアップ
$ git clone
$ cd crosstool-ng

$ ./bootstrap
INFO  :: *** Generating package version descriptions
INFO  :: Master packages: android-ndk autoconf automake avr-libc binutils cloog duma elf2flt expat gcc gdb gettext glibc-ports glibc gmp isl libelf libiconv libtool linux ltrace m4 make mingw-w64 mpc mpfr musl ncurses newlib strace uClibc zlib
INFO  :: Generating 'config/versions/'
INFO  :: Generating 'config/versions/'
INFO  :: Generating (menu)
INFO  :: *** Gathering the list of data files to install
INFO  :: *** Running autoreconf
INFO  :: *** Done!

$ ./configure --enable-local
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands

$ make
/usr/bin/make  all-recursive
make[1]: Entering directory '/home/katsuhiro/share/projects/oss/crosstool-ng'
Making all in kconfig
make[2]: Entering directory '/home/katsuhiro/share/projects/oss/crosstool-ng/kconfig'
bison -y -l -b zconf -p zconf  -ozconf.c zconf.y
/bin/mkdir -p docs && ( /bin/sed -e 's,[@]docdir[@],/usr/local/share/doc/crosstool-ng,g' -e 's,[@]pkgdatadir[@],/usr/local/share/crosstool-ng,g' -e 's,[@]pkglibexecdir[@],/usr/local/libexec/crosstool-ng,g' -e 's,[@]progname[@],'`echo ct-ng | sed 's,x,x,'`',g' | /bin/bash config.status --file=- ) < docs/ >docs/ct-ng.1-t && mv -f docs/ct-ng.1-t docs/ct-ng.1
make[2]: Leaving directory '/home/katsuhiro/share/projects/oss/crosstool-ng'
make[1]: Leaving directory '/home/katsuhiro/share/projects/oss/crosstool-ng'

カレントディレクトリに ct-ng という名前のファイルが生成されます。通常はクロスコンパイラをインストールして使いますが、私はインストールしないで欲しい(適宜入れ替えたいから)ので、--enable-local オプションを付けています。

crosstool-NG ビルド
$ ./ct-ng menuconfig
- Target options  --->
    Target Architecture (alpha)  --->
      arm に変更する

    Bitness: (32-bit)  --->
      64-bit に変更する

- Operating System  --->
    Target OS (bare-metal)  --->
      linux に変更する

- C compiler  --->
    C++ (NEW) を選択する

$ ./ct-ng build
[00:34] /

ビルド中は多少メッセージも出ますが、基本的に経過時間と棒がくるくる回るだけです。ログが見たい方は、ct-ng と同じディレクトリにある build.log を tail -f などで表示すると良いでしょう。

マシン性能によりますが、./ct-ng build によるクロスコンパイラのビルドは 1時間くらい掛かると思います。ビルドが終わると、ホームディレクトリに x-tools というディレクトリが作られていると思います。AArch64 用のクロスコンパイラ(gcc 8)をビルドした場合、x-tools 以下は下記のようになっているはずです。

crosstool-NG 生成物
$ cd ~/x-tools

$ ls

$ ls aarch64-unknown-linux-gnu
aarch64-unknown-linux-gnu  bin  build.log.bz2  include  lib  libexec  share

$ ls aarch64-unknown-linux-gnu/bin
aarch64-unknown-linux-gnu-addr2line     aarch64-unknown-linux-gnu-gcov-dump
aarch64-unknown-linux-gnu-ar            aarch64-unknown-linux-gnu-gcov-tool
aarch64-unknown-linux-gnu-as            aarch64-unknown-linux-gnu-gfortran
aarch64-unknown-linux-gnu-c++           aarch64-unknown-linux-gnu-gprof
aarch64-unknown-linux-gnu-c++filt       aarch64-unknown-linux-gnu-ld
aarch64-unknown-linux-gnu-cc            aarch64-unknown-linux-gnu-ld.bfd
aarch64-unknown-linux-gnu-ct-ng.config  aarch64-unknown-linux-gnu-ldd
aarch64-unknown-linux-gnu-dwp           aarch64-unknown-linux-gnu-nm
aarch64-unknown-linux-gnu-elfedit       aarch64-unknown-linux-gnu-objcopy
aarch64-unknown-linux-gnu-g++           aarch64-unknown-linux-gnu-objdump
aarch64-unknown-linux-gnu-gcc           aarch64-unknown-linux-gnu-populate
aarch64-unknown-linux-gnu-gcc-7.3.0     aarch64-unknown-linux-gnu-ranlib
aarch64-unknown-linux-gnu-gcc-ar        aarch64-unknown-linux-gnu-readelf
aarch64-unknown-linux-gnu-gcc-nm        aarch64-unknown-linux-gnu-size
aarch64-unknown-linux-gnu-gcc-ranlib    aarch64-unknown-linux-gnu-strings
aarch64-unknown-linux-gnu-gcov          aarch64-unknown-linux-gnu-strip

クロスコンパイラは ~/x-tools/aarch64-unknown-linux-gnu/bin 以下にあります。今後、このクロスコンパイラを使います。


カーネルは Linux の開発版 linux-next を使います(Git リポジトリへのリンク)。Stable カーネルや LTS カーネルも同じ手順で良いと思いますが、古いカーネルをビルドするときは、crosstool-NG で gcc 7 か gcc 6 を選択したほうが良いかもしれません(ビルド時に警告が出てくると邪魔なので…)。

linux-next コード取得、セットアップ、ビルド
$ git clone git://
$ cd linux-next

$ export ARCH=arm64
$ export CROSS_COMPILE=~/x-tools/aarch64-unknown-linux-gnu/bin/aarch64-unknown-linux-gnu-

$ make defconfig

$ make all
scripts/kconfig/conf  --syncconfig Kconfig
  WRAP    arch/arm64/include/generated/uapi/asm/ioctl.h
  WRAP    arch/arm64/include/generated/uapi/asm/errno.h
  WRAP    arch/arm64/include/generated/uapi/asm/ioctls.h
  LD [M]  sound/soc/generic/snd-soc-simple-card-utils.ko
  LD [M]  sound/soc/generic/snd-soc-simple-card.ko
  LD [M]  sound/soc/sh/rcar/snd-soc-rcar.ko

マシン性能によりますが、カーネルのビルドは数十分くらい掛かると思います。AArch64 用のカーネルをビルドした場合、arch/arm64/boot 以下は下記のようになっているはずです。

linux-next 生成物
$ cd arch/arm64/boot

$ ls
Image  Image.gz  Makefile  dts

ビルドが終わると、arch/arm64/boot 以下に Image という名前のファイルが作られていると思います。このイメージファイルを後で使います。

[編集者: すずき]
[更新: 2018年 7月 16日 16:05]
link 編集する


  • コメントはありません。
open/close この記事にコメントする

link permalink

AArch64 向け Linux 開発環境の構築 その 2

その 1その 2

昨日の続きです。AArch64(64 ビット ARM)向けの Linux 開発環境を構築しました。使用するツールは下記の通りです。

  • クロスコンパイラ: crosstool-NG
  • カーネル: linux-next
  • ルートファイルシステム: buildroot
  • エミュレータ: qemu



ルートファイルシステムの構築には buildroot を使います(Git リポジトリへのリンク)。

buildroot コード取得、セットアップ、ビルド
$ git clone
$ cd buildroot

$ make menuconfig
- Target options  --->
    Target Architecture (i386)  --->
      AArch64 (little endian) に変更する

- Toolchain  --->
    Toolchain type (Buildroot toolchain)  --->
      External toolchain に変更する

    Toolchain (Linaro AArch64 2018.05)  --->
      Custom toolchain に変更する

    () Toolchain path (NEW)
      /home/username/x-tools/aarch64-unknown-linux-gnu に変更する(チルダ ~ は使えないので、注意)

    ($(ARCH)-linux) Toolchain prefix
      aarch64-unknown-linux-gnu に変更する

    External toolchain gcc version (4.3.x)  --->
      8.x に変更する(crosstool-NG の設定と合わせる)

    External toolchain kernel headers series (2.6.x)  --->
      4.16.x に変更する(crosstool-NG の設定と合わせる)

    External toolchain C library (uClibc/uClibc-ng)  --->
      glibc/eglibc に変更する(crosstool-NG の設定と合わせる)

    Toolchain has C++ support? (NEW)

- Filesystem images  --->
    cpio the root filesystem (for use as an initial RAM filesystem)

$ make
/usr/bin/make -j1 O=/home/katsuhiro/share/projects/oss/buildroot/output HOSTCC="/usr/lib/ccache/gcc" HOSTCXX="/usr/lib/ccache/g++" silentoldconfig

マシン性能によりますが、ほぼ busybox しかビルドしませんので、カーネルよりは短い時間で終わるはずです。生成されたファイルは output ディレクトリに集められています。output 以下は下記のようになっているはずです。

buildroot 生成物
$ ls output
build  host  images  staging  target

$ ls output/images/
rootfs.cpio  rootfs.tar

ディレクトリには 2つファイルがありますが、cpio フォーマットの方(rootfs.cpio)を使います。


エミュレータは qemu(Git リポジトリへのリンク)を使います。qemu のビルドは後回しにして、とりあえず今までビルドしてきたカーネル+ルートファイルシステムを実行してみます。

Debian の場合は apt-get install qemu-system でインストール可能です。

qemu 実行
$ qemu-system-aarch64 -machine virt -cpu cortex-a57 -kernel linux-next/arch/arm64/boot/Image -initrd buildroot/output/images/rootfs.cpio -serial stdio
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
[    0.000000] Linux version 4.18.0-rc4-next-20180713 (katsuhiro@blackbird) (gcc version 8.1.0 (crosstool-NG #1 SMP PREEMPT Mon Jul 16 14:38:51 JST 2018
[    0.000000] Machine model: linux,dummy-virt
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    3.409356] ALSA device list:
[    3.410631]   No soundcards found.
[    3.419281] uart-pl011 9000000.pl011: no DMA platform data
[    3.534574] Freeing unused kernel memory: 1344K
Starting logging: OK
Initializing random number generator... [    5.446846] random: dd: uninitialized urandom read (512 bytes read)
Starting network: OK

Welcome to Buildroot
buildroot login: root

# uname -a
Linux buildroot 4.18.0-rc4-next-20180713 #1 SMP PREEMPT Mon Jul 16 14:38:51 JST 2018 aarch64 GNU/Linux

オプションでハマったのは -cpu cortex-a57 です。省略すると AArch64 に対応していない CPU がデフォルトで選ばれるようで、全く動かないです。明示的に ARMv8 の CPU を指定してください。また -serial stdio を付けないと、シリアルが出力されません。

このとき initramfs を指定し忘れると、起動はしますが下記のようなメッセージを表示して停止します。

Linux が panic で止まる
$ qemu-system-aarch64 -machine virt -cpu cortex-a57 -kernel linux-next/arch/arm64/boot/Image -serial stdio
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
[    0.000000] Linux version 4.18.0-rc4-next-20180713 (katsuhiro@blackbird) (gcc version 8.1.0 (crosstool-NG #1 SMP PREEMPT Mon Jul 16 14:38:51 JST 2018
[    0.000000] Machine model: linux,dummy-virt
[    2.777433] ALSA device list:
[    2.777760]   No soundcards found.
[    2.785662] uart-pl011 9000000.pl011: no DMA platform data
[    2.793530] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    2.794033] Please append a correct "root=" boot option; here are the available partitions:
[    2.794757] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.796280] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-next-20180713 #1
[    2.796760] Hardware name: linux,dummy-virt (DT)
[    2.797221] Call trace:
[    2.797472]  dump_backtrace+0x0/0x148
[    2.797837]  show_stack+0x14/0x20
[    2.798087]  dump_stack+0x90/0xb4
[    2.798352]  panic+0x120/0x27c
[    2.798577]  mount_block_root+0x1a0/0x250
[    2.798875]  mount_root+0x11c/0x148
[    2.799126]  prepare_namespace+0x128/0x16c
[    2.799423]  kernel_init_freeable+0x208/0x228
[    2.799732]  kernel_init+0x10/0x100
[    2.800005]  ret_from_fork+0x10/0x18
[    2.800694] Kernel Offset: disabled
[    2.801107] CPU features: 0x21806082
[    2.801400] Memory Limit: none
[    2.802136] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

このように mount_root で panic する場合は、qemu の -initrd オプションか、指定しているファイルをご確認ください。

[編集者: すずき]
[更新: 2018年 7月 17日 22:46]
link 編集する


  • コメントはありません。
open/close この記事にコメントする

link もっと前
   2018年 7月 7日 -
      2018年 7月 16日  
link もっと後


link 記事を新規作成

合計:  counter total
本日:  counter today

link About
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 2/21 00:46



最近のコメント 5件

  • link 18年12月11日
    すずき 「確認いただいてありがとうございます。直っ...」
    (更新:12/27 00:22)
  • link 18年12月11日
    T4 「再現しませんね\n\n確かに、過去にそう...」
    (更新:12/25 12:45)
  • link 18年12月11日
    すずき 「失礼しました。Rock64 の方は、\n...」
    (更新:12/22 02:10)
  • link 18年12月11日
    T4 「私は、Tinker Board を持って...」
    (更新:12/21 10:14)
  • link 18年12月11日
    すずき 「> 但し、これもう一年以上前の話で...」
    (更新:12/19 11:54)

最近の記事 3件

link もっとみる
  • link 19年02月19日
    すずき 「[RISC-V のコンパイラ] Crosstool-NG は RI...」
    (更新:02/21 00:46)
  • link 19年02月18日
    すずき 「[RockPro64 のシリアル出力] RockPro64 のシリ...」
    (更新:02/21 00:43)
  • link 19年02月20日
    すずき 「[RockPro64 の HDMI Audio] RK3399 の...」
    (更新:02/21 00:33)


open/close wiki
open/close Java API


open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 過去日記について


open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報