BeagleBoneのオンボードLED制御
BeagleBoneでLED４つ実装している。それぞれの名称はusr0、usr1、usr2、usr3だ。 LEDはトリガー(trigger)によって制御されている。
下記のフォルダにそれぞれLEDの制御フォルダがある /sys/class/leds/ しかし、本体は/sys/devices/platform/leds-gpio/leds に指しているシンボリックリンクだ beaglebone::usr0 -> ../../devices/platform/leds-gpio/leds/beaglebone::usr0 beaglebone::usr1 -> ../../devices/platform/leds-gpio/leds/beaglebone::usr1 beaglebone::usr2 -> ../../devices/platform/leds-gpio/leds/beaglebone::usr2 beaglebone::usr3 -> ../../devices/platform/leds-gpio/leds/beaglebone::usr3
それぞれのLED制御フォルダに下記にファイルがある： １，brightness 説明：値が0なら消灯、値が1なら点灯となる。 例：echo 1 > brightness ２，device -> ../../../leds-gpio 説明：特に使い道なし ３，max_brightness 説明：(TBD) ４，power 説明：(TBD) ５、subsystem -> ../../../../../class/leds 説明：特に使い道なし ６，trigger 説明：LED制御トリガー トリガーはnone mmc0 timer heartbeat backlight gpio default-on７種類だ。 設定するため、viで編集するのではなく、echo で変更する 例：$ echo none > trigger 有効中の設定は四角カッコで囲っている 例： $ cat trigger [none] mmc0 timer heartbeat backlight gpio default-on none:未設定 mmc0:SDカードスロット（SDカードにアクセスした場合LED点灯） timer:LEDのon,offタイマー設定 $ echo timer > trigger この設定を有効にした場合、delay_offとdelay_onファイルが作成される。 delay_off：消灯間隔(ms) delay_on：点灯間隔(ms) 例：点灯５秒消灯１秒のパターン $ echo 5000 > delay_on $ echo 1000 > delay_off 設定しない場合デフォルトはどちらも500msとなっている。 heartbeat:生存監視 backlight:(TBD) gpio:(TBD) default-on:(TBD) ７，uevent 説明：(TBD)
デフォルトで付属のAngstromLinuxでは下記の動作となっている。 usr0：heartbeat usr1：mmc（つまりSDカードアクセス） usr2：未使用 usr3：未使用
LEDテストスクリプトを作成した：testled.sh
#!/bin/sh led="/sys/class/leds/beaglebone::" get_led_state () { usr0_trigger=`cat ${led}usr0/trigger | sed -e "s/^.*\[\(.*\)\].*$/\1/"` usr1_trigger=`cat ${led}usr1/trigger | sed -e "s/^.*\[\(.*\)\].*$/\1/"` usr2_trigger=`cat ${led}usr2/trigger | sed -e "s/^.*\[\(.*\)\].*$/\1/"` usr3_trigger=`cat ${led}usr3/trigger | sed -e "s/^.*\[\(.*\)\].*$/\1/"` usr0_brightness=`cat ${led}usr0/brightness` usr1_brightness=`cat ${led}usr1/brightness` usr2_brightness=`cat ${led}usr2/brightness` usr3_brightness=`cat ${led}usr3/brightness` echo "USR0 LED state ($usr0_brightness) [$usr0_trigger]" echo "USR1 LED state ($usr1_brightness) [$usr1_trigger]" echo "USR2 LED state ($usr2_brightness) [$usr2_trigger]" echo "USR3 LED state ($usr3_brightness) [$usr3_trigger]" } get_led_state save0t="$usr0_trigger" save0b="$usr0_brightness" save1t="$usr1_trigger" save1b="$usr1_brightness" save2t="$usr2_trigger" save2b="$usr2_brightness" save3t="$usr3_trigger" save3b="$usr3_brightness" echo "Turning LEDs on for 3 seconds..." echo "none" > ${led}usr0/trigger echo "none" > ${led}usr1/trigger echo "none" > ${led}usr2/trigger echo "none" > ${led}usr3/trigger echo "1" > ${led}usr0/brightness echo "1" > ${led}usr1/brightness echo "1" > ${led}usr2/brightness echo "1" > ${led}usr3/brightness get_led_state sleep 3 echo "Turning USR0 LED off for 3 seconds..." echo "0" > ${led}usr0/brightness get_led_state sleep 3 echo "Turning USR1 LED off for 3 seconds..." echo "0" > ${led}usr1/brightness get_led_state sleep 3 echo "Turning USR2 LED off for 3 seconds..." echo "0" > ${led}usr2/brightness get_led_state sleep 3 echo "Turning USR3 LED off for 3 seconds..." echo "0" > ${led}usr3/brightness get_led_state sleep 3 echo "Restoring LEDs to their original state..." echo "$save0b" > ${led}usr0/brightness echo "$save1b" > ${led}usr1/brightness echo "$save2b" > ${led}usr2/brightness echo "$save3b" > ${led}usr3/brightness echo "$save0t" > ${led}usr0/trigger echo "$save1t" > ${led}usr1/trigger echo "$save2t" > ${led}usr2/trigger echo "$save3t" > ${led}usr3/trigger get_led_state
BeagleBoneのSDに最新のOSイメージを入れる
http://www.beagleboard.org/angstrom-mirror/www.angstrom-distribution.org/demo/beaglebone/ から最新のAngstrom-Cloud9-・・・.img.gzをダウンロードする。
SDカードに書きこむ $ zcat ・・・.img.gz | sudo dd of=/dev/sdc bs=8M
再度、BeagleBoneに挿し戻して起動を確認する。
rootユーザのパスワードを変更する passwd root ユーザを作成 useradd user01 passwd user01
opkgを使ったオンラインソフトのバージョンアップが可能だが、 安定性、信頼性が落ちる可能性があり、最悪起動できなくなる可能性もあるので、 バックアップしてから行ったほうが良いでしょう。 （実際私のほうはドライバがLoadできなくなり、起動できなくなった・・・） opkg update opkg upgrade 2>&1 | tee /var/log/opkgupgrade.log
BeagleBone RevA4のイーザ問題の解決
現在BeagleBoneのRevA4において、抵抗R219をPCBに追加したせいで、eth0のDHCPが機能しない不具合が発生しています。 解決方法はいたって簡単、背面USB OTG近くのR219を強引に取ってしまうことだ！
参考動画： http://www.youtube.com/watch?v=Ak30G-shiYY
PlayStationVita の主な部品リスト
Sony CXD5315GG – Quad-core processor with two Samsung K4P2G324EC 256 MB Mobile DDR2-S4 SDRAM Memory die (512MB total memory)
Toshiba THGBM3G5D1FBAIE - Multichip Memory Package – Memory and Memory Controller
Marvell 88W878S-BKB2 - Avastar WLAN/Bluetooth/FM Single-Chip System-on-Chip
Fujitsu MB44C026A – Possible Multichannel Switching Controller
Sony 1144KM427 – suspected AKM Magnetic Compass
Wolfson Micro WM1803E – Audio Codec
Qualcomm MDM6200 – Gobi Single-mode Modem
Qualcom PM8028 – Power Management IC
Toshiba TY890A111222KA - Mobile SDR SDRAM Memory
Kionix KXTC9 - Three-axis MEMS accelerometer
Avago ACPM-7868 - GSM Power Amplifier
Avago ACPM-5005 - W-CDMA Band V Power Amplifier Module
Avago ACPM-5001 - W-CDMA Band I Power Amplifier Module
Avago ACPM-5002 - W-CDMA Band II Power Amplifier Module
Avago ACPM-5008 - W-CDMA Band VIII Power Amplifier Module
EPCOS B7429 - SAW Duplexer
Sony CXM3555ER - SP10T Antenna Switch Module
Atmel MXT224 – 224-Channel Touchscreen Sensor
STMicroelectronics 32P10SOD
STMicroelectronics 3GA51H - Gyroscope
GDBでSegmentation Faultの原因を突き止める
Linuxのプログラムをデバッグするとき、一番困ることはあの有名の「Segmentation Fault」ですね。 プログラムが膨大でマルチプロセス等を使っていたら、どこで問題を起こしているのかすらわからないです。 本編はLinuxのCore Dump機能で問題発生行を特定する方法を紹介します。
まず、前提としてはSegmentation Faultは再現できること。（当たり前ですよね） 下記のプログラムを例とします。
#include<stdio.h> #include<string.h> #define DATA "TEST" char mngfile[2][50]; int main() { memset( mngfile, '\0', sizeof(mngfile) ); GetMngFile(mngfile); return 0; } int GetMngFile( mngfile ) char mngfile[2][50]; { int i=0; char file[128]; for(i=0;i<999;i++) { memset( file, '\0', sizeof(file) ); strcpy(file,"abc"); sprintf(mngfile[i],"%s_%s",file,DATA); printf("%d,%s\n",i,mngfile[i]); } return 0; }
次に、コンパイルオプションに「-g」を付けてコンパイルします。 gcc test2.c -g -o test2
多くのLinuxではデフォルトCoreDump機能を無効にしてあるため、有効にします。 ulimit -c unlimited （生成するCoreのサイズを制限しない）
プログラムを実行してみます。 ./test2 セグメンテーション違反です (core dumped)
この時、カレントディレクトリで「core.11504」のようなファイルが生成されます。 このCoreをGDBでデバッグしてみましょう。 gdb ./test2 core.11504 ・・・ Core was generated by `./test2'. （test2がCoreを吐いている） Program terminated with signal 11, Segmentation fault. （シグナル11でプログラムが終了され、セグメンテーション違反発生） Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x0058668b in _IO_default_xsputn_internal () from /lib/tls/libc.so.6 （最終実行ステップはlibc.so.6ライブラリの_IO_default_xsputn_internal()関数内にある）
(gdb)bt （BackTraceしてみます。） #0 0x0058668b in _IO_default_xsputn_internal () from /lib/tls/libc.so.6 #1 0x005645fa in vfprintf () from /lib/tls/libc.so.6 #2 0x0057c71b in vsprintf () from /lib/tls/libc.so.6 #3 0x0056995b in sprintf () from /lib/tls/libc.so.6 #4 0x080484ce in GetMngFile (mngfile=0x8049740) at test2.c:27 #5 0x08048441 in main () at test2.c:12
わたしのソースにのみ興味があるので、先頭にあるStack Frame番号の詳細をみます。 (gdb) frame 4 #4 0x080484ce in GetMngFile (mngfile=0x8049740) at test2.c:27 27 sprintf(mngfile[i],"%s_%s",file,DATA); これでソースの27行目のsprintfで問題があることを判明しました。 このソースをよく見ると、配列mngfileの定義数を超えたメモリー領域のデータ改ざんのあったので、 これで問題判明です。
知ってる人は知っているSQLPLUSの小技
１、put_lineの空白問題 set serveroutput on exec dbms_output.put_line(' abc'); 頭の空白を表示したいなら「format wrapped」オプションを使えばOK set serveroutput on format wrapped exec dbms_output.put_line(' abc');
２、空行エラー このSQL文をコピーして実行してみてください。 select deptno, empno, ename from emp where empno = '7788'; すると、空行があるため下記のようにエラーになる SQL> select deptno, empno, ename 2 from emp 3 SQL> where empno = '7788'; SP2-0734: unknown command beginning "where empn..." - rest of line ignored. 解決策として下記のコマンドを使う SET SQLBLANKLINES ON
３、 こんな経験ないでしょうか？ SQL文を打ってる最中にカラム名が忘れて、 今まで打ったSQL文を消してカラム名を探す・・・ この場合「#」を利用すればOK SQL> select 2 #desc test Name Null? Type ---------------------- -------- ------------ ID NUMBER NAME VARCHAR2(30) 2 name from test; no rows selected
４、HTML出力 8iよりHTML出力が可能となった set markup html on spool on spool /tmp/test.html select * from v$database; spool off
５、前回SQL文の部分置換 SQL> select 'abc' from dual; 'AB --- abc SQL> c/'abc'/sysdate 1* select sysdate from dual SQL> / SYSDATE --------- 25-MAY-10
６、前回SQL文の条件追加 SQL> select sysdate from dual; SYSDATE --------- 25-MAY-10 SQL> a where 1=2 1* select sysdate from dual where 1=2 SQL> / no rows selected 注意：コマンド「a」の後にスペース２個が必要です！！
Oracle 11g のアンインストール
[oracle@CentOS53 ~]$ /u01/oracle/app/product/11.2.0/dbhome_1/deinstall/deinstall Checking for required files and bootstrapping ... Please wait ... Location of logs /tmp/deinstall2010-05-24_11-13-21-午前/logs/ ############ ORACLE DEINSTALL & DECONFIG TOOL START ############ ######################## CHECK OPERATION START ######################## インストールの構成確認の開始 Oracleホームの場所が存在するかどうかを確認しています /u01/oracle/app/product/11.2.0/dbhome _1 選択された削除対象のOracleホームのタイプ: SIDB 選択された削除対象のOracleベース: /u01/oracle/app 中央インベントリの場所が存在するかどうかを確認しています /u01/oracle/oraInventory インストールの構成確認の終了 ネットワーク構成チェック構成START ネットワーク構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/logs/ netdc_check3056000027903696288.log 構成解除するすべての単一インスタンス・リスナーを指定してください[LISTENER1,LISTENER]: ネットワーク構成チェック構成END データベース・チェック構成START データベース構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/logs/ databasedc_check2296607471997779796.log 値のリストを入力として指定する場合、セパレータとしてカンマを使用してください このOracleホームで構成されているデータベース名のリストを指定してください [o11g2]: ###### データベース'o11g2' ###### 単一インスタンス・データベース データベースの診断先の場所: /u01/oracle/app/diag/rdbms/o11g2 データベースによって使用される記憶域タイプ: FS データベース・ファイルの場所: /u01/oracle/app/oradata/o11g2,/u01/oracle/app/flash_recovery _area/o11g2 フラッシュ・リカバリ領域の場所: /u01/oracle/app/flash_recovery_area/O11G2 データベースのspfileの場所: /u01/oracle/app/product/11.2.0/dbhome_1/dbs/spfileo11g2.ora データベースo11g2の詳細は自動的に検出されました。o11g2データベースの詳細を変更しますか。 [ n]: y ###### データベース'o11g2' ###### このデータベース(1.単一インスタンス・データベース|2.Oracle Restart対応のデータベース)のタ イプを指定してください [1]: データベースの診断先の場所を指定してください [/u01/oracle/app/diag/rdbms/o11g2]: データベースASM|FSによって使用される記憶域タイプを指定してください [FS]: 共有ファイルシステムにデータベース・ファイルが存在する場合、ディレクトリのリストを指定して ください。'o11g2'サブディレクトリが見つかった場合、これが削除されます。見つからなかった場 合、指定したディレクトリが削除されます。また、フルパスを使用してデータベース・ファイルのリ ストを指定できます [/u01/oracle/app/oradata/o11g2,/u01/oracle/app/flash_recovery_area/o11g 2]: フラッシュ・リカバリ領域がファイルシステムで構成されている場合、これを指定してください。'o 11g2'サブディレクトリが見つかった場合、これが削除されます。 [/u01/oracle/app/flash_recover y_area/O11G2]: データベースのspfileの場所を指定してください [/u01/oracle/app/product/11.2.0/dbhome_1/dbs/ spfileo11g2.ora]: データベース・チェック構成END Enterprise Manager Configuration Assistant START EMCA構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/logs/emcadc_c heck.log データベースo11g2の構成を確認しています Enterprise Manager Configuration Assistant END Oracle Configuration Manager check START OCM check log file location : /tmp/deinstall2010-05-24_11-13-21-午前/logs//ocm_check9696.l og Oracle Configuration Manager check END ######################### CHECK OPERATION END ######################### ####################### CHECK OPERATION SUMMARY ####################### 選択された削除対象のOracleホーム: /u01/oracle/app/product/11.2.0/dbhome_1 Oracleホームが登録されているインベントリの場所: /u01/oracle/oraInventory 次の単一インスタンス・リスナーが構成解除されます: LISTENER1,LISTENER 次のデータベースが構成解除対象として選択されました: o11g2 一意のデータベース名: o11g2 使用済記憶域: FS 次のデータベースのEnterprise Managerの構成を更新しますか: o11g2 更新するEnterprise Manager ASMターゲットはありません 移行するEnterprise Managerのリスナー・ターゲットはありません Checking the config status for CCR Oracle Home exists with CCR directory, but CCR is not configured CCR check is finished 続行しますか (y - はい、n - いいえ)[n]: y このセッションのログは/tmp/deinstall2010-05-24_11-13-21-午前/logs/deinstall_deconfig2010-0 5-24_11-15-05-AM.outに書き込まれます このセッションのすべてのエラー・メッセージは/tmp/deinstall2010-05-24_11-13-21-午前/logs/de install_deconfig2010-05-24_11-15-05-AM.errに書き込まれます ######################## CLEAN OPERATION START ######################## Enterprise Manager Configuration Assistant START EMCA構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/logs/emcadc_c lean.log データベースo11g2のEnterprise Manager Database Controlの構成の更新 Enterprise Manager ASMターゲットを更新しています(ある場合) Enterprise Managerのリスナー・ターゲットを更新しています(ある場合) Enterprise Manager Configuration Assistant END データベース構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/ logs/databasedc_clean2778161591155929234.log データベース・クリーンアップ構成START o11g2 この操作には数分かかります。 データベース・クリーンアップ構成END o11g2 ネットワーク構成クリーニング構成START ネットワーク構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/ logs/netdc_clean2539645679609291858.log 単一インスタンス・リスナーの構成解除: LISTENER1,LISTENER リスナーの構成解除: LISTENER1 リスナーを停止しています: LISTENER1 リスナーの停止に成功しました。 リスナーを削除しています: LISTENER1 リスナーは正常に削除されました。 リスナーは正常に構成解除されました。 リスナーの構成解除: LISTENER リスナーを停止しています: LISTENER 警告: リスナーの停止に失敗しました。 リスナーが実行されていない可能性があります。 リスナーを削除しています: LISTENER リスナーは正常に削除されました。 リスナーは正常に構成解除されました。 ネーミング・メソッド構成ファイルの構成解除中です... ネーミング・メソッド構成ファイルが正常に構成解除されました。 ローカル・ネット・サービス名構成ファイルの構成解除中です... ローカル・ネット・サービス名構成ファイルが正常に構成解除されました。 バックアップ・ファイルの構成解除中です... バックアップ・ファイルが正常に構成解除されました。 ネットワーク構成が正常にクリーンアップされました。 ネットワーク構成クリーニング構成END Oracle Configuration Manager clean START OCM clean log file location : /tmp/deinstall2010-05-24_11-13-21-午前/logs/ /ocm_clean9696.log Oracle Configuration Manager clean END Oracle Universal Installerクリーンアップの開始 Oracleホーム'/u01/oracle/app/product/11.2.0/dbhome_1'をローカル・ノードの中央インベントリからデタッチします : 終了 ローカル・ノードのディレクトリ'/u01/oracle/app/product/11.2.0/dbhome_1'を削除します : 終了 ローカル・ノードのディレクトリ'/u01/oracle/oraInventory'を削除します : 終了 ローカル・ノード上でOracleベース・ディレクトリ'/u01/oracle/app'は削除されません。ディレクトリは空ではありません。 Oracle Universal Installerのクリーンアップが成功しました。 Oracle Universal Installerクリーンアップの終了 Oracleインストール・クリーンアップの開始 インストールのクリーンアップ操作により、ノードCentOS53の一時ディレクトリ/tmp/installを削除しています Oracleインストール・クリーンアップの終了 ######################### CLEAN OPERATION END ######################### ####################### CLEAN OPERATION SUMMARY ####################### データベースo11g2のEnterprise Managerの構成を更新しました 次のデータベース・インスタンスが正常に構成解除されました: o11g2 次の単一インスタンス・リスナーが正常に構成解除されました: LISTENER1,LISTENER Cleaning the config for CCR As CCR is not configured, so skipping the cleaning of CCR configuration CCR clean is finished Oracleホーム'/u01/oracle/app/product/11.2.0/dbhome_1'がローカル・ノードの中央インベントリから正常にデタッチされました。 ローカル・ノードのディレクトリ'/u01/oracle/app/product/11.2.0/dbhome_1'が正常に削除されました。 ローカル・ノードのディレクトリ'/u01/oracle/oraInventory'が正常に削除されました。 Oracle Universal Installerのクリーンアップが成功しました。 セッション終了時にノード'CentOS53'でrootとして'rm -rf /etc/oraInst.loc'を実行します。 Oracleインストールにより、一時ディレクトリが正常にクリーンアップされました。 ####################################################################### ############# ORACLE DEINSTALL & DECONFIG TOOL END #############
