完成したと思って、ledcont stshw (緑のLEDをHW制御にする)して帰宅したら、LEDが消えていました oTL
点滅はとまったので、何か不足があるってわけです。調べて見ると、緑のLEDをon/off/blink/fastblinkさせることはできます。が、HW制御にはできません。一方赤のLEDの方は一切の制御を受け付けませんし、常にHW制御のようです。HDDへのアクセスでちかちかしますので。
見かけ上の kernel_timer_led_paramの変化は、純正のドライバと、ほぼ同一なのです。何が足りないのだろう……と、カーネルのソースを見ていると、初期化部分にこんなコードがありました。
/* get status LED control */
//CPLD_LEDBRT_CTRL |= CPLD_LEDBRT_CTRL_LED_MODE1;
CPLD_LEDBRT_CTRL |= CPLD_LEDBRT_CTRL_LED_MODE0;
CPLD_LEDBUZ_CTRL |= 3;
ん。このポートに値を出力することで、制御方法(HW/SW)を切り替えるのかな？ ……と、推測して、パラメータに従って、この2bitの値も制御するコードを追加したドライバを起こして見ました。すると、今度は正しく、緑、赤ともに、LEDを制御でき、かつHW/SWの制御の切替えもできるようになりました(^^)/
//CPLD_LEDBRT_CTRL |= CPLD_LEDBRT_CTRL_LED_MODE1;
CPLD_LEDBRT_CTRL |= CPLD_LEDBRT_CTRL_LED_MODE0;
CPLD_LEDBUZ_CTRL |= 3;
himazu
カーネルハックなどまったく縁のないuser landの私には理解できませんが、そういう必要が出た際には弟子入りさせていただくかも知れません。
arakiさんがやっておられることは、ハードウェアの提供元にとって基本的にはいいことのはずですよね。そういうユーザーを大切にする会社であって欲しいものですね。
hiro
今回はkdbなどを駆使するような、よりディープな局面には遭遇しませんでしたが、カーネルを玩ぶのはスリリングで楽しいものです(マゾ?)
その様な必要が訪れたときに、お手伝いできれば幸いです(^^)/
挑戦者、というブランドが、無保証、無サポートだから、情報を出さない、カーネルもほったらかしなのは、仕方ないとしても、だったら、なおのこと、ユーザが自力でメンテするに十分な情報を開示すべきなのに、このメーカの姿勢は問題だと思います。
また、同じソフトウェアをベースとしたGiga Landiskのシリーズは「無保証」と知らん顔を決め込んでいられないはずなのにほったらかしです。こちらは、より企業としての姿勢が問われる問題ではないかと思います。
実は、電源スイッチの状態を監視するbtndrvとbuttondの互換品作成も試みているのですが、IRQ30からうまく、スイッチが操作された割り込みを拾えずにいて、ペンディング中です。この関係でも何度か、GLANTANKをフリーズさせました。まぁ、今回は単純にリブートすれば回復する問題なので、分解を伴う作業に比べて気楽ではあるのですが、情報が不足しすぎるほどに不足していて、どうしたものか思案のしどころです。