KVMのゲストマシン上でSSHのポート閉じてしまいシリアル接続もできないのでディスクイメージをホストにマウントしてどうにかする
どうも、まるさ@maruuusa83です．
KVMで複数の仮想マシンを立てて色々な実験環境を運用しているのですが，そのうちの一つでオペミスでSSHのポートを閉じてしまい，シリアル接続用の設定もしていなかったせいでコンソールに接続することが全くできなくなってしまいました．
試行錯誤しつつ解決したのでメモ．
状況と方針
ゲストOSの側は全てのポートが閉じてしまっているので，ネットワークからはなす術がありません．
また，シリアル通信でコンソールにログインを試みるも，事前の設定がなされていないためにこれも失敗．
というわけで，一旦ゲストOSを落としてイメージファイルをホストOSにマウントしてゴニョゴニョいじります．
最後にオマケで非常用にシリアルコンソールが使えるように設定する方法を書いておきます．
イメージファイルについて調べる
KVMで動作するゲストOSのディスクは，基本的にはqemu-imgで作られるraw形式かqcow2形式になっているはずです．
とりあえず，次のコマンドでディスクイメージの形式を調べます．
# qemu-img info disk.img
image: disk.img
file format: qcow2
virtual size: 300G (322122547200 bytes)
disk size: 57G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
raw形式であれば kpartx -av disc.img して mount /dev/mapper/loop0p1 /mnt 的なことをすれば簡単にマウントできますが，qcow2形式の場合には圧縮が施されているのでそいつを何とかしてあげる必要があります．
ぐう・・・
qemu-nbdを使えるようにする
qcow2形式のディスクイメージのマウントには， qemu-nbd を使うとよいです．
これでraw形式の時のようにループバックマウントして中身を覗けるようになります．
これを利用するためまずは nbd モジュールを読み込みます．
# modprobe nbd modprobe: FATAL: Module nbd not found.
やめてくれmodprobe その術はオレに効く
Linuxカーネルをビルドしてnbdを手に入れる
CentOS7ではnbdのビルドと組込みは行われないようなので，カーネルを落としてきて頑張って自分でビルドします．
とりあえずソースコードをゲットしましょう．
uname -r とかで自分のカーネルのバージョンを調べて同じバージョンのソースコードをゲットしてください．
# uname -r # wget http://vault.centos.org/7.2.1511/updates/Source/SPackages/kernel-3.10.0-327.28.3.el7.src.rpm # rpm -ivh kernel-3.10.0-327.28.3.el7.src.rpm
次にビルドの準備をします．
頑張って依存性を解決しながら rpmbuild を進めてください．
# mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
# echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros
# cd ~/rpmbuild/SPECS
# rpmbuild -bp --target=$(uname -m) kernel.spec
# cd ~/rpmbuild/BUILD/kernel-3.10.0-327.28.3.el7/linux-3.10.0-327.28.3.el7.centos.x86_64/
make menuconfig で Device Driver > Block devices とたどって， Network block device support に M をセットしてください．
menuconfigができたら，makeしましょう．
# make prepare && make modules_prepare && make ... CC [M] drivers/block/nbd.o error: ‘REQ_TYPE_SPECIAL’ undeclared (first use in this function) sreq.cmd_type = REQ_TYPE_SPECIAL; ^
やめてくれ・・・
nbdはRedhatのサポート外なので，このバージョンではどうもうまくコンパイルできないらしい・・・
REQ_TYPE_SPECIAL は REQ_TYPE_DRV_PRIV に変更されているので， nbd.c 内の該当箇所を修正してもう一度ビルドします．
fsync_bdev(bdev); mutex_lock(&nbd->tx_lock); blk_rq_init(NULL, &sreq); sreq.cmd_type = REQ_TYPE_DRV_PRIV; // これを修正した nbd_cmd(&sreq) = NBD_CMD_DISC;
改めてビルドを進める・・・
# make prepare && make modules_prepare && make # make M=drivers/block -j8
通った！のでmodを読み込んでいく．
# modinfo drivers/block/nbd.ko filename: /root/rpmbuild/BUILD/kernel-3.10.0-862.el7/linux-3.10.0-862.el7.centos.x86_64/drivers/block/nbd.ko license: GPL description: Network Block Device retpoline: Y rhelversion: 7.5 srcversion: A36E8E32685072269226933 depends: vermagic: 3.10.0 SMP mod_unload modversions parm: nbds_max:number of network block devices to initialize (default: 16) (int) parm: max_part:number of partitions per device (default: 0) (int) parm: debugflags:flags for controlling debug output (int) # cp drivers/block/nbd.ko /lib/modules/3.10.0-327.28.3.el7.x86_64/extra/ # depmod -a && modprobe nbd
modprobe で invalid argument 的な事を言われてしまう場合はソースのバージョンとOSのカーネルのバージョンがちゃんとマッチしているか確認してください．
正しくnbdが読み込まれたか確認するために /dev を覗いてみます．
# ls /dev |grep nbd nbd0 nbd1 nbd10 nbd11 nbd12 ...
よしよし
qcow2イメージをループバックマウントする
nbdが使えるようになったので， qemu-nbd を使ってマッピング接続します．
# qemu-nbd -c /dev/nbd0 disk.img
とりあえず fdisk して正しくパーティションが読めてるか確認してみます．
# fdisk -lu /dev/nbd0 WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion. Disk /dev/nbd0: 322.1 GB, 322122547200 bytes, 629145600 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: gpt Disk identifier: 49524BB2-F36A-41E3-BB7D-9C5ED6ABA100 # Start End Size Type Name 1 2048 4095 1M BIOS boot 2 4096 629143551 300G Linux filesyste
きちんと認識できているようなので，ループバックマウントします．
パーティション分けがなされているので， kpartx でバチッと分けてあげてからマウントします．
# kpartx -av /dev/nbd0 add map nbd0p1 (253:3): 0 2048 linear /dev/nbd0 2048 add map nbd0p2 (253:4): 0 629139456 linear /dev/nbd0 4096 # これが本体っぽい # mkdir /mnt/nbd0p2 # mount -o loop /dev/mapper/nbd0p2 /mnt/nbd0p2
ls してみる
# ls /mnt/nbd0p2 bin dev home ... boot etc initrd.img ...
やったーファイルシステムが読めるようになったぞー！！！
chroot して設定を書き換えていく
方針としては，chroot で強引にゲストOSのシェルを起動して nfw で22番をこじ開ける感じです．
今回ホスト側がCentOS7でゲスト側がUbunt18だったので，さすがに無理かなーと思いつつ試しましたが，結論から言うとこれでうまくいきました．
chroot コマンドでルートをすげ替えます．OSが違ったり /dev の中身が無かったりするので色々と具合が悪いこともありますが，とにかく試します．
# chroot /mnt/nbd0p2 # ufw allow 22 Rule added Rule added (v6)
えっめっちゃあっさり通った・・・！
アンマウントして再起動
マウントの時と逆の手順を踏んでアンマウントしていきます．
# umount /mnt/nbd0p2 # kpartx -dv disk.img # qemu-nbd -d /dev/nbd0
あとは仮想環境を立ち上げてみてsshを繋ぐなりしてみて設定が正しく行われているか確認してください．
【おまけ】非常用にシリアルコンソールから接続できるように設定する
今回シリアルでつながってればこんなに大変なことにはならなかったに違いないので，シリアルコンソール接続ができるように設定します．
grubに起動オプションを設定
イメージファイルの中のgrubの設定を書き換えていきます．
/mnt/nbd0p2/etc/default/grub に起動オプション console=tty0 console=ttyS0,115200n8r を追加します．
# cd /mnt/nbd0p2/etc/default/ # vim grub ... GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8r" # ここに書く
mkconfigして接続テストしてみる
そして grub-mkconfig -o /boot/grub2/grub.cfg します．
再起動して，接続テストをしてみてください．
今回はこのへんで．
つかれた ノ
まるさ
grub.cfgをぶっ壊したのでgrubプロンプトから頑張ってブートして復元する
どうも，まるさ@maruuusa83です．
悲しいオペミスで grub.cfg を壊してしまってブートしなくなってしまったので，grubのプロンプトから頑張って復元しました．
grubが動かない
仮想環境でゲストOSの grub.cfg をいじろうと思って grub2-mkconfig したらホストOSの情報でconfigが生成されて壊れてしまいました．
かなしい．
とりあえずゲストOSを起動しようとしたら「デバイスが見つからない」と怒られてしまうので，grubプロンプトから手動でブートして grub.cfg を復元します．
とりあえずブートする
ルートファイルシステムのあるパーティションを探す
ls で認識しているパーティションを一覧表示します．
grub> ls (hd0) (hd0,gpt2) (hd0,gpt1)
ls (hd0,2) とかすると中身が見れるので，どれがルートファイルシステムなのか探します．
gptとかはフォーマットの種類で，後ろの数字がパーティション番号なようです．フォーマットの種類の部分は省略できます．
まるさの環境では (hd0,2) がルートでした．
ブートしてみる
次に，ブートします．
grub> set root=(hd0,gpt2) grub> linux /boot/vmlinuz-4.15.0-47-generic root=/dev/sda2 grub> initrd /boot/initrd.img-4.15.0-47-generic grub> boot
- 1行目：ルートFSのあるパーティションを指定します
- 2行目：
vmlinuzはTab補完しながら探してください．root=でルートFSを指定しますが，正しいデバイスを選んでください（後述） - 3行目：
initrdもTab補完しながら探してください
(hd0,2) なら sda2，(hd1,1) なら sdb1 という風にデバイス名が決まります．
あと，HDDなら hdXY，SSDなら sdXX，仮想環境なら vdXX みたいな感じでプレフィクスも変化します．
この指定を間違えるとうまくブートはしないのですが，OSの簡易版のシェルが立ち上がります．
デバイス名がわからないときにはこのシェルで ls /dev とかしてあげるとデバイス一覧が出るので，それらしいデバイス名を探すと良いです．
grab.cfgを元に戻す
壊したgrab.cfgを元に戻します．
正しくブートができてログインまでできてしまえば簡単です．
grub2-mkconfig -o /boot/grub/grub.cfg のように，出力先を指定してmkconfigするだけです．
mkconfigしてリブートしてみて正しく立ち上がるようになっていれば復元成功．
というわけで，今回はこのへんで ノ
まるさ
CentOS6入れたHDDを別のブレードに差し替えたらNICみえなくなった（それはそう）
どうも，まるさ@maruuusa83です．
色々サービスが動いてるブレードサーバの調子が悪くなってついに落ちました．
HDDは大丈夫そうだったので，同じラックの別のブレードとHDDを入れ替えてサービスを継続する戦略をとりました．
さすがに入れ替えるだけじゃすぐには動かなかったよ，という話．
SSHがつながらない
外からSSHでつなげなかったので，直接操作してチェックしました．
[marusa@server ~]$ ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
...
あれ， eth0 と eth1 が見えるハズなんだけどなあ・・・
NICをさがせ
まぁ確かに元の eth0 とかは今のマシンとは異なるデバイスなので，違うデバイスに見えてるのかもしれない．
というわけで ifconfig - a する．
[marusa@server ~]$ ifconfig -a
eth4 Link encap:Ethernet HWaddr --:--:--:--:--:--
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:16
eth5 Link encap:Ethernet HWaddr --:--:--:--:--:--
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:17
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
...
おー、いたいた．やっぱり違うデバイスになってた．
実はあれこれトライしてる最中に別のブレードにも刺したので eth2 と eth3 も虚空に消えている．
最初からこの手順を踏んでいれば2と3だったのだろう．
設定を引き継いでくる
あとは /eth/sysconfig/network-scripts/ifcfg-eth0 あたりの必要な設定を引き継いでくる．
[marusa@server ~]$ cp /eth/sysconfig/network-scripts/ifcfg-eth0 /eth/sysconfig/network-scripts/ifcfg-eth4 [marusa@server ~]$ sudo vim /eth/sysconfig/network-scripts/ifcfg-eth4
物理アドレスとか指定されてると怒られが生まれるのでそのあたりを適宜修正して完了．
[marusa@server ~]$ ifconfig
eth4 Link encap:Ethernet HWaddr --:--:--:--:--:--
inet addr:-.-.-.- Bcast:-.-.-.- Mask:-.-.-.-
inet6 addr: -:-:-:-:-:-/- Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53470 errors:0 dropped:0 overruns:0 frame:0
TX packets:34097 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:50636677 (48.2 MiB) TX bytes:8380875 (7.9 MiB)
Interrupt:16
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
...
おーうごいたうごいた．めでたしめでたし．
それでは こんかいはこのへんで ノ
まるさ
SystemCのSC_CTHREADはメソッド抜けちゃいけないらしい
どうも，まるさです．
SystemCのSC_CTHREAD使っててちょっと詰んだので覚書
開発環境
Windows版Vivado HLS 2016.3を使って，SystemCを記述していました．
OSはWindows10です．
ちょっとした実験がしたかった
SystemCを使って次のようなハードウェアを書いていました．
- データの入力をトリガに動く
- 実行は一度だけ
- valid信号を使って外部から入力を待つ必要があった
具体的には，次のような記述をしました．
SC_MODULE(sample)
{
sc_in_clk CLK;
sc_in<bool> RST;
sc_in<int> din;
sc_in<bool> din_valid;
SC_CTOR(sample):
CLK("CLK"),
RST("RST"),
din("din"),
din_valid("din_valid")
{
SC_CTHREAD(thread, CLK.pos());
reset_signal_is(RST, false);
}
void thread(){
// dinが入るまで待つ
while (din_valid.read()){
wait();
}
// データを受け取る
int data = din.read();
/* やりたい処理 */
wait();
}
};
このコードだと，次のようなエラーがでました．
Found exit operation(s) (<上記コードthreadの2行目>) in the main loop of SC_CTHREAD 'sample::thread'.
exitしてねえし，と思いましたが，どうもSC_CTHREADやSC_THREADで指定したメソッドは
終了してはいけないということのようです．
whileで無限ループを作るのが必須なので，while文に対してエラーがついてしまうということかな？
解決策
というわけで，threadのメソッドが終了しないようにすれば動くようになりました．
void thread(){ bool flag = false; while (true){ // 無限ループにする if (!flag){ // 一度だけ実行されるようにするためのフラグ // dinが入るまで待つ while (din_valid.read()){ wait(); } // データを受け取る int data = din.read(); /* やりたい処理 */ flag = true; } wait(); } }
まちがった解決策
次のようなコードは，解決策とはなりませんでした．
最初と同じエラーが出てしまいます．
void thread(){ // dinが入るまで待つ while (din_valid.read()){ wait(); } // データを受け取る int data = din.read(); /* やりたい処理 */ while (true) wait(); // 終了しないように無限ループ }
メソッド直下のwhileが終了してはいけないようです．
ループを含まないような場合ならこれでもよいかもしれませんが，
今回はdinのためのビジーウェイトが入っているのでこのコードでは解決できませんでした．
それでは，
こんかいはこのへんで ノ
まるさ
Zynqberryを観察する（２）
どうも，まるさ@maruuusa83です．
前の記事に引き続いてZynqberryを観察していきます．
Zynqberryには何が書き込まれるのか
Zynqberry用のVivadoプロジェクトを自動生成するスクリプトvivado_create_project_guimode.cmdがあるので，
こいつを使ってみます．
ただし，block_design\zsys_bd.tclはVivado 2016.2で吐かれているので，scripts_vivado_versionの値を2016.3に
変更しておく必要があります．
すると，こんなBoard Designが書き込まれたプロジェクトができました．
Board Design
PS部に加えて，RasPi2のGPIOを実現するIPと， こいつをコンフィグするための信号をAXIからデコードするようなIPが追加されています．
クロック周りがどうなっているかチェックしました．
Clock Configuration
チュートリアルではPSは33.3333MHzで動いていると書いてありますが，やはりInput Frequencyが33MHzなだけであって， CPUは666MHzで動いているようです．
33MHzっておそすぎでしょ（#^ω^）
FCLKは50MHzのCLK0と100MHzのCLK1が生成されていますが，なぜかCLK1は使われていません．PLには50MHzが供給されていました．
とりあえずImplementしてみる
リファレンス・デザインそのままでImplementしてみました．
ハードウェア使用率（post-implementation）
GPIOに引っ張り出すためにI/Oの消費量が伸びていますが，ほかに特に不思議はありませんでした．
XC7Z020版がほしいなあ・・・
それでは
今回はこのへんで ノ
まるさ
Zynqberryを観察する
どうも，まるさ@maruuusa83です．
Zynqberryってなんだ
トレンツエレクトロニック社が作っているシングルボードコンピュータ的なやつです．
Raspberry Pi2互換で，SoCにZynq XC7Z010を積んだボードです．
こんなかんじのやつ
今回は外観とか中身とかあれこれ観察してみます．
外観
かなりPi2とそっくりですね．
Raspberry Pi 2(奥)とZynqberry TE0726(手前)
実際基板サイズやねじ穴，各コネクタの位置もそっくり同じでした．
ですからRaspberry Pi 2が入るケースに収めることが・・・
できないこともあるかもしれません．
若干浮いてしまっている
基板が本家よりも若干厚く，手元のケースだと手で押さえないと土台から若干浮いてしまいました．
まぁきちんとケースを閉じることはできるのでそれほど気になりませんが．
いちおう普通に閉まった
表面
Zynqberry表面
USBとEthernetのコントローラはRasPi2と同じLAN9514ですね．
Lattice社のCPLDであるLCMXO2とFTDI社のUSB-UART変換ICのFT2232HQが乗っています． MicroUSBでUSB-JTAGをするために乗せているようです． 実際RasPiと違ってUSBでPCとつながっていればアレコレできちゃうので良い感じです．
他にも，SPIFlashが乗っています．ZynqのBootModeがQSPIに固定されており，このFlashから読みだされます． Linuxが動くようにするには，ここにSDを読みだすu-bootを置く必要がありました．
ところでZynqが乗っている位置はRasPiのSoCと微妙にずれているので，ケースに収めたとき若干カッコ悪くなりますｗ
若干右に寄っている
裏面
Zynqberry裏面
RasPi2と違ってRAMが表に移動しているので，裏はあっさりしていますね．
SDカードスロットですがが，SDを取り出すときに押し込んでもバネで飛び出してくれませんでした．
まんまRasPi2の代用になりそう
それでは
今回はこのへんで ノ
まるさ
Zynqberryで公式Debianを動かしてみる
どうも，まるさ@maruuusa83です．
なにかボードを振り回したい
なんかRasPiとかArduinoとか流行りのアイテムって，買うだけ買って放置しちゃう系なので， たまにはちゃんと使いたいなあなんておもいます．
というわけで，最近研究がら使えるようになったZynqberryをとりあえず動かせるようにします．
Zynqberryってなんだ
トレンツエレクトロニック社が作っているシングルボードコンピュータ的なやつです．
Raspberry Pi2互換で，SoCにZynq XC7Z010を積んだボードです．
なぜだかBoot ModeがQSPIモードに固定されているので，Linuxを起動するにはそれらしいブートローダを 内蔵のフラッシュに書き込む必要があります．
最初が大変．
Zynqberryってこんなの
でも日本語のチュートリアルもあるのでちょっぴり安心．
とりあえずSDにイメージを焼く
ここからは，チュートリアルの内容に基いて進めていきます． 筆者なりに内容をまとめなおしていますが，基本的にはチュートリアルと変わらないことを書いています．
トレンツのサポートから必要な諸々を落としてきます．
http://www.trenz-electronic.de/download/d0/Trenz_Electronic/d1/TE0726/d2/Reference_Design.htmlwww.trenz-electronic.de
次のものを落としてください．
- Debian 8.4 > SD Content > image.ub
- Debian 8.4 > SD Content > system.dtb
- Debian 8.4 > SD Image > zynq-debian.img
zynq-debian.imgをWin32DiskImagerとかで適当なmicro SDに焼きます．
2GBしか消費しないのであまり大きくないmicro SDで大丈夫です．
diskmgmt.mscで見た様子
Windowsではリムーバブルドライブの類は先頭のパーティションしか見えませんから，11MBくらいのドライブに見えます．
ここに先ほど落としてきた残りのimage.ubとsystem.dtbを置いてください．
これでSDの準備は完了しました．
内蔵Flashにu-bootを突っ込む
ZynqではいくつかBoot Modeがあります．が，なぜかZynqberryではQSPIモードに固定されているので，ブートさせたいソフト は必ず内蔵のSPIフラッシュメモリに置く必要があります．
このフラッシュは，USBで繋いだらFAT32のディスクに見えるとかそういう便利な機能はついてないので，がんばって書き込む 必要があります．
今回はLinuxを動かしたいので，フラッシュにブートローダを置いてあげる必要があります．
とりあえず先ほどのページからブートローダとリファレンスデザインを持ってきます．
- Debian8.4 > Flash > BOOT.bin
- 2016.2 > test_board > te0726-test_board-vivado_2016.2-build_xxxxx.zip
zipを展開するとtest_boardフォルダができます．
test_bard/prebuilt/boot_images/te0726-mの下にu-boot-debianフォルダを作って，その中にBOOT.binを置いてください．
test_board直下のdesign_basic_settings.cmdを編集します．
- @set VIVADO_VERSION=2016.2 + @set VIVADO_VERSION=2016.3 - @set PARTNUMBER=LAST_ID + @set PARTNUMBER=3 - @set SWAPP=NA + @set SWAPP=u-boot-debian
お察しの通り，フラッシュの書き込みにVivadoを要求してきます．
もしVivadoが入ってないのであれば，インストールする必要があります．
設定が完了したので，同じくtest_board直下のprogram_flash_binfile.cmdを実行します．
ありれ，なにやらエラーが．
Booting from configuration memory device unsuccessful
なんか書き込みが止まってしまいます．
色々試してみましたが，どうも同じところで止まってしまいます．
仕方がないので，とりあえず無視してTeraTermでつないで，SDを挿して再起動してみました．
すると・・・
ブートするじゃないか
ログインして色々調べる
なんかよくわからないエラーがありましたが，無事Debianがブートしました（笑） Vivadoが2016.2じゃないことが原因でしょうか・・・
Baud rateを115200でシリアルで接続して，最初に作ったSDを挿してZynqberryを再起動すればアクセスできます．
root/rootでログインできました．ちょっと色々みていきます．
なんかこの時点で既にボードがほくほく温かいです．
ネットワークとか
LANのケーブルつないで，とりあえずifconfigしてみる．
ifconfigの結果
普通にDHCPでIPもらってきてますね．すばらしい．
というかシリアルで接続できるとディスプレイ用意しなくてもネットワーク設定できて最高ですね！！！！！
CPUとかメモリとか
nproc，cpuinfo，meminfoを見てみました．
上からnproc-cpuinfo-meminfo
あっクロック出ないのか・・・
トレンツのチュートリアルでは次のように言っているけど，こんなに遅いの？ほんと？
PS(CPU部分)のクロックは33.3333MHzですが、PLへはボード上ではクロックが接続されていないので、PLを動作させるにはPSが動作して、内部でFCLKをもらう必要があります。
参考になるかわかりませんが，ウチのi3-4130@3.40GHzのBogoMIPSは6799.62でした．
メモリはきちんと512MB全部みえるみたいですね．
/devのなかみ
どんなデバイスがいるのか覗いてみました．
ls /devの結果
おっ，xdevcfgがいますね．ということはPLのコンフィグ用のドライバが入っているってことかな？
あとで実験してみたいですね．
というわけで，ZynqberryをLinuxとして動くようにするまでやってみました．
これから少しずつ色々やってみようと思います．
ZedBoardとかより全然楽カモ
それでは
今回はこのへんで ノ
まるさ
