コグノスケ

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

目次: GCC

目次: Linux

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

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

クロスコンパイラ

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

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

$ git clone https://github.com/crosstool-ng/crosstool-ng
$ 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/android-ndk.in'
INFO  :: Generating 'config/versions/autoconf.in'
...(snip)...
INFO  :: Generating comp_libs.in (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
...(snip)...
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
...(snip)...
/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/ct-ng.1.in >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オプションを付けています。

$ ./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以下は下記のようになっているはずです。

$ cd ~/x-tools

$ ls
aarch64-unknown-linux-gnu

$ 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-cpp           aarch64-unknown-linux-gnu-ld.gold
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を選択したほうが良いかもしれません（ビルド時に警告が出てくると邪魔なので…）。

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.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
...(snip)...
  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以下は下記のようになっているはずです。

$ cd arch/arm64/boot

$ ls
Image  Image.gz  Makefile  dts  install.sh

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

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

目次: GCC

目次: Linux

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

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

カーネルのビルドまで終わりましたので、次はルートファイルシステムです。

ルートファイルシステム

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

$ git clone https://git.buildroot.net/buildroot
$ 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
...(snip)...

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

$ 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-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.23.0.418-d590)) #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.
...(snip)...
[    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)
done.
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を指定し忘れると、起動はしますが下記のようなメッセージを表示して停止します。

$ 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.23.0.418-d590)) #1 SMP PREEMPT Mon Jul 16 14:38:51 JST 2018
[    0.000000] Machine model: linux,dummy-virt
...(snip)...
[    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オプションか、指定しているファイルをご確認ください。

エアコンが臭い

「エアコンの嫌なニオイが完全に消えた」 "窓全開、16度で1時間つけっぱなし" で本当にニオイが取れる理由 - ねとらぼ を読んで。

こんなの嘘だろ…、と思ってうちの8年モノ（2010年製）のエアコンにやってみたら、素晴らしい効き目でした。運転開始から冷風がでるまでの、放置した雑巾のような臭いが、完全に消えました。

この効果はいつまで持つのか気になるので、また臭くなった時に備えて、いつ浄化したか思い出せるようにしておきます。

騒音に注意

ちなみにエアコンを16度で全開運転すると、壊れるんじゃないかと思うくらい、室外機が唸り始めて、非常にうるさいです。

暑いけれど、昼にやった方が良いと思います。夜やると近所迷惑です。

メモ: 技術系の話はFacebookから転記しておくことにした。

Bluetooth UART変換

UARTをBluetoothに変換してくれるHC-06（モジュールの販売サイト、仕様書も置いてある）モジュール搭載ボードを買いました。技適マークが無いように見えます、これ日本で使ったらダメな奴かな…？

電源は5Vで、UARTは3.3Vです。ArduinoとかRaspberry Pi用のUSB - UART変換ケーブルを使えば、電源からUARTまで全ての線が揃っているはずです。Raspberry Piに繋いでも動きます。

私が購入したボード（HiLetgo製ZS-040）の場合、電源を入れるとLEDが点滅し始めます。この状態でBluetoothデバイスの検索を行うとHC-06という名前（変更可）のデバイスが見つかりますので、ペアリングします。PINは1234です（変更可）。

ペアリングするとCOMが2つ増えると思います。なぜ2つなのか良くわかりません。片方はうんともすんとも言いませんので、使いません。もうひとつのやや接続に時間が掛かる方を使います。

2つのCOMのどちらを使うべきかは、LEDで見分けることができます。LEDが点滅→点灯に変わる方が本物（？）です。まあ、両方繋いでも問題は起きないようなので、面倒なら両方繋いでしまえば良いと思います。

設定の変更

ペアリングを解除した状態（LEDが点滅）にすると、HC-06の設定を変更することができます。シリアルの設定は、ボーレート9600、8ビット、パリティなしにします。

このデバイスは送った文字をエコーバックしないので、ローカルエコーを強制的にONにしてください。またキーボードで入力すると、ATコマンド先頭のAT二文字を打った段階で「OK」が返ってきてしまい、コマンド発行ができません。コマンド全体をメモ帳などに打ち、コピペで貼り付けるとうまくいきます。

メモ帳からコピペはイマイチなので、ライン編集モードをONにすれば良いだろと思ったら、行の最後にCRが送られてしまうためか、AT+PINコマンドなどがうまくいかなくなります。

デバイス名、つまりBluetoothデバイスの検索のときに出てくる名前です。デバイス名を変更するにはAT+NAMEの後に名前を打ちます。例えば "HC-06-1" に変えたければAT+NAMEHC-06-1を送ります。大文字と小文字は区別されます。返事にOKsetnameと返ってくれば成功です。

またPINを変える際はAT+PINを送ります。例えば8888に変えたければAT+PIN8888です。返事にOKsetPINと返ってくれば成功です。

シリアルの設定を変更するコマンドもあります。興味があれば仕様書を見てくださいまし。

ROCK64購入

目次: ROCK64/ROCKPro64

Rockchip RK3328搭載のシングルボードコンピュータ、ROCK64 4GB版を買いました。秋月電子で6,500円くらいでした。メモリの少ない1GB版にすると、さらにお安いです。

ROCK64はSDカードから起動できます。OSイメージは開発元が用意しているEtcherを使うと（GitHubからダウンロードできます）ダウンロード＋SDカードへの書き込みが簡単にできます。便利です。

しかし手持ちのSDカードが4GBだったため、Etcherに8GBのカードを入れろと言われてしまい、OSイメージが書き込めませんでした。

最近は暑すぎて、電器屋に行くのさえ辛いですが、こればかりは行くしかないですね。昼の外出は危険だと思い、夕方にしましたが、それでも暑いです。

汗だくになりつつ16GBのSDカードを買ってきてDebianを書き込み、起動しましたがシリアルが出ません。何でだ。

ROCK64の爆速UART

どうしてROCK64のUARTが表示されないのかなと思ってググってみたら、ボーレートがまさかの1.5Mbpsでした（サポートフォーラムへのリンク）。UARTで1.5Mbpsなんてボーレート初めて使いました。

偶然、手持ちのFT232R（USB-UART変換チップ）が1.5Mbpsに対応していてラッキーでした。一方のHC06（Bluetooth-UART変換チップ）は1.5Mbpsに対応しておらず、UARTを無線化しようと思ってせっかく買いましたが撃沈です…。

シリアルを見ていると、独自ローダー（？）、ATF（ARM Trusted Firmware）、U-Bootの順に動いており、U-Bootはdistro bootを使ってLinux 4.4.77をロードしているようです。

DDR version 1.06 20170424
In
SRX
LPDDR3
786MHz
Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB
ddrconfig:7
OUT
Boot1 Release Time: 2017-05-18, version: 2.43
ChipType = 0x11, 187
emmc reinit
emmc reinit
SdmmcInit=2 20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=14832MB
FwPartOffset=2000 , 0
StorageInit ok = 48105
Raw SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit ret = 0, SecureMode = 0
LoadTrustBL
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0x92d74
RunBL31 0x10000
NOTICE:  BL31: v1.3(debug):f947c7e
NOTICE:  BL31: Built : 09:28:45, May 31 2017
NOTICE:  BL31:Rockchip release version: v1.3
INFO:    ARM GICv2 driver initialized
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 1
INFO:    plat_rockchip_pmu_init: pd status 0xe
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9

U-Boot 2017.09-g5aef9f7 (Oct 12 2017 - 09:11:39 +0000), Build: jenkins-linux-build-rock-64-136

Model: Pine64 Rock64
DRAM: 4 GiB
MMC: rksdmmc@ff500000: 1, rksdmmc@ff520000: 0
*** Warning - bad CRC, using default environment

In: serial@ff130000
Out: serial@ff130000
Err: serial@ff130000
Model: Pine64 Rock64
Net: eth0: ethernet@ff540000
Hit any key to stop autoboot: 0

U-Bootの日付は2017年で、まだ新し目ですが、Linuxはかなり古いですね。後でUpstreamカーネルに入れ替えてみましょうか。

ROCK64とU-Bootのdistro boot

目次: ROCK64/ROCKPro64

昨日（2018年7月22日の日記参照）に引き続き、ROCK64をいじっています。

私も先日知ったばかりで、さほど詳しくありませんが、distro bootはかなり便利です。ROCK64のSDカードはmmc 1です（※）ので、SDカードにFATかext2のパーティション（例えば6番目だとする）を切ってmkfsしておいて、

sysboot mmc 1:6 fat 0x500000 /extlinux/extlinux.conf

このようなコマンドを実行すると、extlinux.confに書いてある設定に従ってカーネルをロードしてくれます。Debianなどもこの設定ファイルを使えば起動できて便利です。

アプリの開発者ならばdistro bootの方が速いし楽でしょう。カーネルの開発者ならばTFTPブートの方が嬉しいかもしれません。SDカードを抜き差しせずに済みます。

一応ROCK64でカーネルをセルフコンパイルすれば、PC要らずで自己完結できますし、SDカードの抜き差しも要りません。しかしROCK64は、さすがにコンパイルに使うには遅いので、クロスコンパイル＋TFTPブートの方が効率は良さそうです……。

（※）ROCK64のU-Bootから見ると、SDカードはmmc 1です。オプションで売っているeMMCボードがmmc 0らしいです。私はeMMCボード持ってないので、詳細はわかりません。

Upstreamカーネル

U-Bootのdistro bootのお陰で、カーネルの入れ替えはとても楽です。ROCK64のカーネルを4.4からupstreamのlinux-nextに入れ替えてみたところ、本当に入れ替えたのか不安になるくらい、何も問題なく起動しました。Rockchipやるなあ…。

RockchipはOpenSourceプロジェクトWiki（Wikiへのリンク）があり、ブートローダーから全てOSSで動かせるようです。ブートローダーは隠されていて、ソースコードを見るなんて有り得なかった時代に比べると、隔世の感です。

Rockchip以外にもAllWinnerもLinuxへのupstream活動は盛んなようで、upstreamカーネルが動く可能性が高そうです。AllWinnerのボードは何が良いんでしょうね？お手頃感ではNanoPi NEO 2でしょうか？

RockchipもAllWinnerもシングルボードコンピュータに多く採用されており、性能もなかなかですし、とても安く手に入ります。決して速くないマイコンボードが1枚何万円もしていた時代に比べると、ありがたい時代になったと思います。

ブートローダーにもチャレンジ

ブートローダーも最新版に入れ替えようと思い、Rockchip Opensource Wikiに乗っていた手順を試しましたが、ちょっと内容が古いのかU-Bootのビルドは通りますが、ATFのビルドはコケてしまいました。

Wiki曰くSDカードの0x40セクタに2ndブートローダーを置けば良いらしいですが、U-Boot SPLは廃止されてしまいましたし、ATFはビルドが通らなかったため、肝心のブートローダー（U-Boot SPLもしくはATF BL31）が作れません。困った。

現状、ブートローダーを変更したい積極的な理由も特にないので、ブートローダーのビルドはまた今度ですね。

レガシィの4回目の車検

目次: 車

先週、大阪スバル（高槻店）にレガシィの車検をお願いしていました。今日は納車です。

JR高槻駅からディーラーまで歩きましたが、もう、とにかく暑い暑い。暑くてやってられません。将来、車を買い替えるとしたら、夏には絶対、車は買わないぞ、絶対だ。心に決めました。

料金は自賠責＆税金込みで13万円くらいでした。特に大きな故障もなかったし、そんなもんでしょう。ね。

微妙に壊れてるThinkPad E480のキーボード

先日購入（2018年6月14日の日記参照）したThinkPad E480ですが、キーボードのカーソルキー、しかも上カーソルキーだけが微妙に壊れています。

キーを押すとキーが傾いてしまい、引っかかって戻ってこないときがあります。

キーを分解してみた

何が引っかかっているのか調べるために分解してみました。キートップをてこなどで外すと、パンタグラフが入っています。パンタグラフは2つの部品からできています。

キーボードのパンタグラフ、分解

2つの部品を組み合わせると、I字型（畳んでいるとき）もしくはX字型（開いているとき）になります。

キーボードのパンタグラフ、畳んだ状態

キーボードのパンタグラフ、開いた状態

良く見るとこの部品、軸が折れてしまっています。

キーボードのパンタグラフ、分解、軸が折れている

軸が片側なくなっているため、パンタグラフを開いても綺麗なX字型にならず、捻じれてしまいます。

キーボードのパンタグラフ、開いた状態、軸が折れているので歪む

これによってキートップが若干傾いてキーボードのフレームに引っかかり、元の位置に戻らなくなるようです。

対策

修理に出そうかどうか迷って、いろいろ押し方を試しているうちに、比較的引っかかりにくい押し方があることを見つけました。今は押し方を工夫することで凌いでいます。

さらに最近は、普通にキーを押しても引っかかりにくくなった気がします。パンタグラフが壊れているのは相変わらずなので、キートップ側が削れたのか、変形したのかな？

久しぶりに自作ARMエミュレータ

久しぶりに自作ARMエミュレータememuを（ソースコードはこちら）動かそうと思い、Linux 4.4のlatestである、Linux 4.4.146をダウンロードしました。

このememuではARM Versatile PB/APボードの一部デバイスと、CPU ARM926EJ-Sの一部、アーキテクチャで言えばARMv5T相当をエミュレーションしています。

クロスビルドできない

巷で手に入るコンパイラはARMv5Tより新しい命令を出力してしまい、エミュレータで実行できませんので、最初にcrosstool-ngで、ARMv5T向けのgcc 8.1.0を作成しました。

いざLinux 4.4.146をクロスビルドしましたが、エラーになり、コンパイルできませんでした。

エラーの意味が良く分からなかったので、さっくり諦めましてcrostool-ngでgcc 7.3を作成しなおし、ビルドをやり直したところ、無事コンパイルが通りました。

Linuxが動かない

Linux 4.4.146は起動しませんでした。偶然持っていた少し古いバージョン（Linux 4.4.77）に戻したりもしましたが、結果は同じで全く起動しません。

デバッグすると、ドライバの作りが変わったのかAACIとMMCIというハードウェアに対して、今まで叩いていなかったはずのレジスタをガンガン叩いていました。ememuは存在しないI/Oレジスタを叩くと、エミュレータが例外で落ちてしまい、動かなくなるんです…。

とりあえずレジスタ定義だけ適当に追加したところ、エラーが出まくりますが、起動はしました。適当でも動いてくれるLinuxは強い子です。

buildrootが動かない

しかし今度はbuildrootで作成したbusyboxと愉快な仲間たちが起動しません。/dev/nullが無いよ？と永遠にエラーが出続けます。

調べてみるとLinux 4.4.146のdefconfigだとCONFIG_DEVTMPFSがnつまり無効なんですね。最近の感覚でdevtmpfsはあって当然くらいに思っていたので、盲点でした。コンフィグでdevtmpfsを有効にしてカーネル再ビルドしたところ、やっとbuildrootが動きました。

端末の色がおかしい

対応していない制御文字を送ってきているらしく、ememuの端末（独自実装です）の色がおかしくなります。

これはすぐ直せそうになかったので、しばらくは変な表示と付き合うことになりそうです。

エディタ

誰しもお気に入りのエディタがあると思いますが、私は割とメチャクチャです。

C言語系は読むときはVim + GNU Global、書くときはサクラエディタを使うことが多いです。

Vimはタグジャンプやヒストリが優秀で、検索もしやすいので、コードを読む際にはとても便利だと思います。ログを差し込んだり、コードを多少書き換える程度であればVimで済ませます。

しかし1から全て書くような場合は、サクラエディタが多いです。何ででしょうね？関数表示が便利なのかな？そんなサクラエディタもC++ を書くときはイマイチで、ラムダがまともに表示されず不便です。

GVimでtabと :Tlistを使うとサクラエディタの関数表示に近くて、個人的には良い感じですが、常用には至っていません。何が悪いのかわからない…。

Javaは読むことはあまり無いけどVimですかね、書くときはIntelliJ IDEAです。スクリプト系はVimで読むし、書きます。

こうして並べてみると、かなり支離滅裂です。どうしてこうなった…？？

VimとEmacsの思い出

VimもEmacsも初めて使ったとき「は？何だこれ……？？」と思いました。どちらも終了方法がわからず、まともに使えませんでした。今はIDEもVimも適度に使っています。

でもEmacsは完全に使い方を忘れてしまった。ごめんねEmacs…。

地震保険

AIG損害保険から「大阪北部地震で被害を受けた方はご連絡ください」という手紙が来て、地震保険に加入していたことを知りました。ずっと火災保険だと思ってたよ……。

人生初の地震保険です。

保険会社に被害を申請（電話、Webでも可能）すると、調査員さんが家に来てくれます。調査員の方は、かなり積極的に被害としてカウントしてくれます。むしろ、こちらが「いやー、そこは特に被害無かったですね…」と断るような形になるくらいでした。

家財の場合、壊れなくても、地震で倒れたりズレたら被害としてカウントされるそうです。あと、地震保険で特徴的なのは、被害を受けた「種類」が大事なことです。本が1冊でも100冊でも、カウントは「本」の1種類のみですが、棚とテレビと冷蔵庫が地震でズレたり倒れたりすれば3種類としてカウントされ、被害が大きいとみなされるようです。

地震保険の査定額

地震保険は火災保険と違い損害額ではなく、保険金額（契約時に決めている額面）の何割という形で支払われます（地震保険 | 個人のお客さま | AIG損保へのリンク）。

我が家の場合、家財の「一部損」判定でした。この場合、地震保険金額の5%が支払われることになります。契約していた保険金額は100万円くらいだった（それも知らなかった…）ので、支払われる額は大体5万円です。

大阪北部在住で、地震保険に加入している人は、とりあえず被害申請をしてみるといいですね。判定結果が一部損（一番低い）でも、地震でグチャグチャにされた部屋の片づけ手間賃くらいにはなると思います。

査定方法

査定は結構面白いです。馬のフィギュアがテーブルから落ちてたら「被害です」、お皿が落ちたり転げたら割れてなくても「被害です」。逆に言うと、壊れた物の金額は勘案しないので、被害の受け方によっては被害額と保険の査定額が全く合いません。

しかし元々そういう保険なんです。火災保険や自動車保険とは仕組みが違うのですね。

保険会社がんばってる

AIG損害保険の調査員の方曰く、大阪北部地震と7月豪雨の被害調査を迅速に行うため、全国の調査員が応援に駆けつけているのだとか。今日来ていただいた方も北海道から応援に来ていると言っていました。

最近は特に暑いし、特に豪雨の地域では道路がやられていて、被災地を駆け回るにもとても大変らしいです。頭が下がる思いです。

ARM PCで開発できるか？

最近のARM搭載SoCはかなり速くなっています。もしかしてx86 PCの代わりに使えるのではないでしょうか？開発に使うことを想定して、コンパイル速度を比較してみたいと思います。

比較に使うのはLinux Kernelの開発ツリー（linux-next）です。コンフィグはデフォルトを使い、ビルドターゲットはallを指定します。ビルドしているアーキテクチャが違う（ROCK64: arm64, AMD A10: x86）ので、時間の単純比較はできませんが、参考にはなると思います。

AMD A10 7800、32GB DDR3-1600のPCでlinux-next x86のtime make -j4 allを実行しますと、

• real 10m33.584s
• user 33m37.811s
• sys 4m7.908s

不遇のBulldozer系コア、もはや4年落ちとなったCPUで、大して速くはありませんが、十分実用的というか、待っていられるレベルです。

Intel Pentium J4205、16GB DDR3L-1600のPCでlinux-next x86のtime make -j4 allを実行すると、

• real 14m45.968s
• user 51m57.967s
• sys 5m47.331s

Pentium JはAtom系列で遅いと思いきや、予想より何倍も速かったです…。ナメてました、ごめんなさい。

ROCK64、Rockchip RK3328、Cortex A53 x 4、4GB DDR3でlinux-next arm64のtime make -j4 allすると、

• real 179m33.126s
• user 266m0.254s
• sys 22m52.046s

PCと比較するとほぼ1桁遅いです。さすがにこれは待っていられません。ROCK64は普段使いには十分速いですが、開発に使うのは辛そうですね…。

Raspberry Pi 3、Broadcom BCM2837、Cortex A53 x 4、1GB LPDDR2でlinux-next armのtime make -j4 allすると、

• real 146m46.807s
• user 236m43.970s
• sys 10m41.310s

ビルドしているアーキテクチャが違う（ROCK64はarm64、RasPi 3はarm）ので、単純比較はできませんけど、ROCK64と大差ないですね。

もっと速いARM SoCは？

今のところスマホ、TV/STB系ARM SoCはA72 x 4、A53 x 4が最強クラスのようです。サーバー系ARM SoCに目を向ければA72 x 16（NXP LX2160A）もしくはA53 x 24やA53 x 48（Cavium ThunderX）といった桁違いメニーコアがありますが、そんなに要らないんですよね…。

中間の製品はありません。買う人いないんでしょうね。

ARM SoC搭載ボード

今後のお買い物の参考に、ざざっと調べてみました。

Tegra系

ボードJetson TX2、Denver x 2、A57 x 4、8GB LPDDR4、$600日本だと販売店のぼったくりで10万円。

HiSilicon Kirin 960

ボードHiKey 960、A72 x 4、A53 x 4、3GB LPDDR4、$239良いんだけど、メモリがもう一声欲しかった…。

Rockchip RK3399

ボードNanoPC-T4、A72 x 2、A53 x 4、4GB LPDDR3-1866、$109 DDR3ではあるけど、良さそう。

Samsung S5P6818

ボードNanoPC-T3 Plus、A53 x 8、2GB DDR3、$75可もなく不可もなく？

Amlogic S912

ボードが見当たらない、A53 x 8、どこか発売してくれないかな。

Amlogic S905

ボードODROID C2、A53 x 4、2GB DDR3、$39 S912の一世代前ですね。

AllWinner H6

ボードPINE H64、A53 x 4、2GB LPDDR3-1600、$36安くて素敵だけど、さすがに見劣りしてしまうなあ。

性能だけ求めるならJetsonかHiKey 960で、コスパならNanoPC-T4ですかね。Jetsonなら流行りのAIとか、GPGPUも実験できますね。お値段はべらぼうですけど…。