目次: 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ボード持ってないので、詳細はわかりません。
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)が作れません。困った。
現状、ブートローダーを変更したい積極的な理由も特にないので、ブートローダーのビルドはまた今度ですね。
目次: 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が表示されないのかなと思ってググってみたら、ボーレートがまさかの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カーネルに入れ替えてみましょうか。
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と返ってくれば成功です。
シリアルの設定を変更するコマンドもあります。興味があれば仕様書を見てくださいまし。
「エアコンの嫌なニオイが完全に消えた」 "窓全開、16度で1時間つけっぱなし" で本当にニオイが取れる理由 - ねとらぼ を読んで。
こんなの嘘だろ…、と思ってうちの8年モノ(2010年製)のエアコンにやってみたら、素晴らしい効き目でした。運転開始から冷風がでるまでの、放置した雑巾のような臭いが、完全に消えました。
この効果はいつまで持つのか気になるので、また臭くなった時に備えて、いつ浄化したか思い出せるようにしておきます。
ちなみにエアコンを16度で全開運転すると、壊れるんじゃないかと思うくらい、室外機が唸り始めて、非常にうるさいです。
暑いけれど、昼にやった方が良いと思います。夜やると近所迷惑です。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: GCC
目次: Linux
昨日の続きです。AArch64(64ビットARM)向けのLinux開発環境を構築しました。使用するツールは下記の通りです。
カーネルのビルドまで終わりましたので、次はルートファイルシステムです。
ルートファイルシステムの構築には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オプションか、指定しているファイルをご確認ください。
目次: GCC
目次: Linux
AArch64(64ビットARM)向けのLinux開発環境を構築しました。超有名ツールの組み合わせだし、簡単だろうと思っていたのですが、意外とハマって1日掛かってしまったのでメモしておきます。使用するツールは下記の通りです。
クロスコンパイラを生成するため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という名前のファイルが作られていると思います。このイメージファイルを後で使います。
< | 2018 | > | ||||
<< | < | 07 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 | - | - | - | - |
合計:
本日: