【PINE64】パイン64 part2【ROCK64】
公式:https://www.pine64.org
PINE64はA64を搭載したiPhone6Sサイズのシングルボードコンピュータです
ケースやカメラ,Wi-Fi,タッチパネルモジュールなどもあります
ROCK64はRK3328を搭載し4K60P HDR10対応のクレジットカードサイズのメディアボードコンピュータです
USB3.0がありeMMCも搭載できます
SDカードには必要最低限の書き込みで運用
ハードに使うとSDはサクッと死にます。使い捨て上等！の割切りも時に必要
安定運用な状態のときにSDを複製(バックアップ)しておき、有事に備えましょう
/bootのみのROは理に適います
前スレ
【PINE64】パイン64 part1【ARM64】
http://mao.5ch.net/test/read.cgi/linux/1453481419/ UHS-I だと I/O 電圧が 1.8V になる。SoC が UHS-I に対応してるのに、3.3V からの切り替えが正しく出来ないと誤動作を起こす。
そういうことだと思う。 rock64(rk3328+rk805)は、基板回路上で3.3v 固定されてるから、そういうことはやってない
eMMC / USB3.0 が有るんだから、速いI/Oが必要なら そっち使え
安さが売りだから、たいした効果も見込めないものに金は掛けたくない って事らしい
全うな見解だと思う
rockpro64(rk3399+rk808)だと、追加費用無しで実装可能だから、後はソフト側の対応次第
>>308
近所のコンビニ( ローソン or 7-11)で売ってた 東芝の8G（桃色のパッケージ）、エラー無く正常に動いてる。
[ 3.645141] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[ 3.694669] mmc1: new high speed SDHC card at address 1234
[ 3.695460] mmcblk1: mmc1:1234 SA08G 7.22 GiB
[ 4.042841] mmcblk1: p1 p2 p3 p4 p5 p6 p7
価格は1000円程度と高めではあるが、コンビニなら まぁそんなモンでしょう
他にも手持ちのヤツで、 SPとかTeamとかが正常に動いてるけど何れも 8G。
当面、16G以上は避けたほうが無難だろうね 長文のわりに一般性がないので、読みたくない人はスルーしてくれ
>あくまでも kernel 側の不具合
>そして極めつけは、コードを追って該当箇所を直したらRock64(RAM-4G)でも問題無し
大昔にATAカード（SDとかのフラッシュメディアの先祖）のドライバ開発をしたことがある
前任者のドライバが非常に出来が悪いということで、こちらに回ってきて（ATA仕様見た後
ドライバコード見て眩暈がして思わずゴミ箱に叩き込んで）ゼロから完全改修した
この時の解析結果を当てはめると、上記引用は納得がいく
SDみたいなデバイスは大抵ミリ秒単位でコマンドのキャッチボールをしなければならない
この際の時間調停にnanosleep()の類（OSにより微妙に異なる）のウエイト命令を使う
だがコレが曲者で、私がやった時は、OS標準関数内がただの空ループだった
OSのデフォルトがその状態で、恐らく開発に際してハードウェアクロックに接続するべきなのだろう
だがそこまでの開発権限がなくハード設計ももらえなかったんで、当時のハードでスペック計測して
ソフトでできるタイミングを限界いっぱいまで合わせた
勘が鋭い人はわかると思うけど、これってマルチタスクが干渉するだけでもタイミングが狂う
カーネルが変わったりすると、本来はその計測をやり直さなければならない
たとえばstretch（Debian9)の母体は汎用OSなので、タイミング調停関数が初期状態である可能性がある
また安いSBCは、クロックに関するハードAPIをそもそも持っていないかもしれない
そんな設計思想だと、仕様通りでも本体側のマージンができてしまい、SDのマージンに収まらないと不動
そんな感じで、どうしても相性というものがあり動かないものが発生してしまう
手間かけたくない人は、妥協して動くSDを探すしかないと思う >>311
ROC-RK3328-CC board は UHS-I に対応している。対応していない Rock64 にそのドライバをそのまま使ったら問題がでる。どうせそういうレベルの話だろう。
RK3328は、I/O 電圧切り替えの外部回路が必要で Rock64にはその回路がない。たぶん数行の修正で済むはなし。
ググれば "Add sdmmc UHS support to ROC-RK3328-CC board. " なんてメールが見つかるぞ。 In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by the
vcc_sdio regulator, which is a mux between 1.8V and 3.3V, controlled by
a special output only gpio pin labeled "gpiomut_pmuio_iout",
corresponding bit 1 of the syscon GRF_SOC_CON10.
なんて説明がある。どうやら VCCIO3 への供給電圧を GPIO で切り替えられるようになっているようだ。
ROCK64 は VCCIOx は 3.3V で全部共通。
+ vcc_sdio: sdmmcio-regulator {
+ compatible = "regulator-gpio";
+ gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x1
+ 3300000 0x0>;
+ regulator-name = "vcc_sdio";
+ regulator-type = "voltage";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ }
ここを適当に弄ればよいのかどうか？
俺は、ROCK64 もソーソコードも持ってないんで、ここまでにしとく。 >>312
実は>>311はものすごい古い技術で、PCのATAではDMA（SATA専用の小さいCPUみたいなもん）
が常識になってる
ボルテージの切り替えの可能性を否定するわけではないが、それだと>>306のカーネル変更の
相性の有無や、モデルでコンフィグレーション変更程度で動いちゃう説明がつかない気がする
ともかくソースいじる意思や時間のない一般人は、動くSDを探して使うぐらいしか手がない
ちなみに私のrock64に刺さってるのはtoshibaの30MB/sで16GBという極端に古いもの
当時rock64なんかなく、ラズパイで動くMicroSDを大量にかき集めたものの残骸
ラズパイ、rock64、nanopiNeoあたりで使いまわしてるが、寿命が来ない限り相性は出ない
相性が出るものと比較して、恐らくSD側のマージンが広く汎用性が高いんだと思う 端子の少ないIF規格は時間で機能が切り替わる
そんなものはハードが時間を作って制御しないと無理なので
ハード設計者が決めた手順通りにレジスタを叩いてないってだけでしょ >ハード設計者が決めた手順通りにレジスタを叩いてないってだけでしょ
って話とついでにOS側の初期状況を>>311に長々と書いてる
どちらにしても、相性のいいSD探すぐらいしか手がないと思う >>311 は随分と的外れだよ。
SoC にはコントローラがあって、タイミングはハードでやっている。SD に送るコマンドを指示するだけなんだが、それは Linux の上位レイヤがやっている。
ドライバと言っても 上位レイヤに対してプリミティブを提供するだけで、作ってるのは SoＣ メーカ。
SoC 共通の部分で問題が起きるはずがないんだよ。 探したらSamsungのEVO 32GB（もちろんUHS-I…）も見つけたんですが駄目でした
>>310
秋葉原行く用事があるときに、シリコンパワーの方探してみようかと思います
最近はUHS-Iでもないclass10とか、8GBとか少なくて割高感ありますよね
（1つにはデスクトップ環境入れたいので容量心許無いです…）
難しいこと分かりませんが、0.5.xなら全部動くのに0.7.xだと全滅ってラズパイより格段に相性厳しいなーと >>318
class 10 ですらやめとけと言っておこう。
昔 ポラスマというスマホでおなじような相性問題があってね、
- class 2,4 は 32GB でも確実に動く
- class 10 は動かないものが多いが、16GB なら動く可能性が少し高い。
- UHS-I は全滅
ということだったよ。 class4の遅さでもいいなら昔のガラケーに無名メーカーの16GBが刺さってたような…
最近はclass4でUHS-Iとか訳分からんのも売ってるんですね
使えない場合、遅い小さいだと他の用途に回せないんで購入に躊躇するところです Rock64の4GB版だけど
システムもストレージも全部HDDで
SDは起動にしか使わないからClass4の2GBでも間に合ってるな >>311 は随分と的外れだよ。
>ドライバと言っても 上位レイヤに対してプリミティブを提供するだけ
要するにSDのレジスタを叩かずSoCのレジスタを叩くだけでSDとの通信を確立してる、と
そうなるとSD通信の遅延が極小になり確実性が増すから、相性が出る原因がますます謎になる
SoCのマージン（タイミング）かSD側のマージンがSDの仕様から外れてる？
まさかとは思うけどUHS制御を半端にサポートしてる？
それもラズパイとかnanopiとかみな一様に相性持ってるの？
まぁそこは掘り下げても、OS公式が正しいパッチ当てなきゃあまり意味がないけど
>class 10 ですらやめとけと言っておこう。
悪いが手元の8G以上のSDは１枚除いてすべてClass10以上でUHS対応
既に書いたが、ラズパイで相性出ない極端に古いの（廃版）を大量に買い貯めてて、他でも相性でない
>>318だけでなくできるだけ多くの人への提案なんだが
SD相性に関しては俺みたいに参考にしようのない情報じゃなくて、現状入手できるのでrock64で確実に
動いてるヤツの型番示すべきじゃないの？（高飛車で申し訳ないが、ココが肝のはず）
それがなければ>>290はSDが原因かどうか切り分けられず、延々右往左往することになりかねない 同じようなもん、 通常はHDDで運用
SDは万が一のリカバー or 新しいイメージが出た時の確認 に使う程度で
ブートも SPI-Flash -> HDDだから、普段はSDも抜いてある
それにしても、ちょっと酷い状況だな
俺のには、V2.0、 2017-0713 ってシルクがあるけど
最近になってから、基板変更でもしたのかな
そのせいで、いままでマグレで動いてたのが総崩れとか？ >>323
回避策は、使える microsd を探すんじゃなくて、microsd を使わないじゃないのかね？
SPI FLASH からブートしてUSBカードリーダに入れた microsd から起動する。
そうやって microsd スロットをテストできるようにしておいて、いろんな microsd をテストしてみる。
こうやってはじめて、情報が蓄積できる。 USBブートは嫌だな
それこそ相性で通信の信頼性が心配
一つのUSB rootを専有出来るの？ 色々とご提案ありがとうございます
自分のスキルもありまして、まず一般的なmicroSDに焼いて起動ができないものかと思っています
［構成と考えうる原因］
1）Rock64-RAM4Gが2台：
これが2つとも壊れてる可能性
あるいはRAM4Gモデルゆえの不適合
（バージョンは>>324と同様です）
2）4メーカー5種のmicroSD 16,32GB：
これが全てUHS-I class10のため、いるいは容量が大きいため最新のカーネルで動かない可能性
3）3種の電源：中華2メーカーのAC電源と、USB2.5A出力に公式ケーブル
これらが全て出力不足 v0.5.15は凡そ起動し、v0.7.xは全て動かないという結果から3）の電源は外せるかと思います
1）は他の容量モデルが無いため分かりませんがパーツが変わってない限り、v0.5.15は動くのでこれも外せるかと思っています
動くOSが見つかったので特段急ぎませんが、引き続きRock64 RAM4GBで0.7.xが動くSDのモデルやメーカー、
あるいは全く異なる原因をご提案頂けるようでしたらお願いします >>290 = >>328 あと関係者（？）
ちょっと待って、こっちでもヘンだわ（ちなみに1Gモデル）
普段armbianしか使わないけど、ayufanの最新入れようとしたら起動しない
イメージは、stretch-minimal-rock64-0.7.9-1067-arm64.img
以下にUARTなログ上げた、アレなローダだけどカンベン
https://www.axfc.net/u/3931037.txt
こっちのayufan版はstretch-minimal-rock64-0.6.37-221-arm64.imgまで戻るけど、当時は問題なかった
テスト方法も含みで甘々だけど、時間も時間なんで再検証できない
明日もう一回やってみる 書き忘れ、最終的にコマンドライン的なもので入力可能な状態で先に進まなくなる
電源切ってarmbianに入れ替えてログオン、yahoo.co.jp（意味はない）にping打ったけど通る
つまりDNSは正常、但し固定IPなんでDHCPの状況は検証できてない
こちらのDHCP要因による異常である可能性が否定できない…が、確か昨日あたりにDHCPなラズパイ動いてた >> 329
途中から、boot のパーティションが変更になってる
spi-flash のU-BOOTから boot してるようだがそれを止めて、正規の手法 "mmcからのboot" で試してみぃ
ログを見ると、仕様変更前のU-BOOTを使って仕様変更後のパーティションをbootしようとして失敗してるように見える
>> 327
SD-8Gで良の報告複数、駄目な報告はまだ無し
あと、やってないのは SD-8G で試す事ぐらい PINE64の時も公式にリンク張ってあるUbuntu Mateのイメージでは
起動できるのが5回に1回で、再起動もできないという症状だったのに
Ayufanのイメージなら毎回起動、再起動OKだったよ
AyufanのだとMateを自力で構築しないといけないけど
説明通りにやれば4時間ぐらいでグラフィカルログインできる
似たような話じゃないかな むしろ200あたりでRock64-1GBが動かんってのも290と同じ話の気がする
PINE64の話よりは ROCK64-1GBはOpenMediaVaultでしか使ってないが特に問題はないかも
これもAyufanのイメージでOMV3を使ってるんだったかな
電源は秋月の1.3mmの変換コネクタを店頭で買って
秋月の5V5AのACアダプターをさしてるけど
USB3.0のHDDを2台ぶら下げてるが
NASとしての性能は十分 >>329ですが、確認終了しました。
今回の目的は以下の通りです。
・問題の原因（バージョン）を切り分ける
・評判の悪いUHS対応16Gで実績を作る
・上記に、新規さんでも入手できるSDを使用する
まずバージョンごとの結果は以下です
×：stretch-minimal-rock64-0.7.9-1067-arm64.img
>>329の通り
×：bionic-minimal-rock64-0.7.3-1040-arm64.img
１回目は成功（正規shutdown）したが、２回目は>>329と同じ感じ、詳細未解析（ログ破棄）
〇：stretch-minimal-rock64-0.6.37-221-arm64.img
起動のみ確認、操作はshutdownのみ（単に深追いしてない）
〇：bionic-minimal-rock64-0.6.59-273-arm64.img
apt-get update / apt-get upgrade完走、途中なんか聞いてきたけどよく覚えてない
shutdown後起動、reboot程度を複数回実施したが問題なし
yahoo.co.jpへのpingが通る（＝ネットワーク正常、ping先はネット上の適当なもの）
−：armbian全般
stableは1G非対応のため当方で検証不能
当方のarmbianはnightly（≒beta）で、4Gモデルはstable使うべき
この際のbionic-minimal-rock64-0.6.59-273-arm64で、正常起動するログをアップしておきました。
https://www.axfc.net/u/3931037.txt
･･･続く ログを比較すればわかりますが、mmc1がコケています。
昨日書き忘れましたがSPIにUSB起動を書き込んであります。
またeMMCはありません。
念のため、ブート優先順位は eMMC -> SPI -> SD ->USB20 -> USB3.0 です。
結果的にローダではのmmc0がSPIになっており、SPI1はSDだと思います。
つまりSDがコケていることを示します。
一方でバージョンによっては、同じSD個体でも安定して起動します。
よって今回の起動不能はバージョン依存によるものである可能性が高いと思います。
･･･続く 使用SD：SDSQUNS-016G-GN3MN
入手先一例 http://akibaoo.co.jp/c/item/0619659161613/ （※秋葉原に実店舗あり）
当方のmicroSDはclass10/UHSな16Gが大半です。
んで公言してる通り、microSDはラズパイ実績があったストックのうちの一つです。
手持ちの新品の中から現在入手できるという選別基準で、昨日パッケージ開けました。
個人的経験で言わせてもらうと、実績のあるモデルならだいたいOK、ロットNGとか時期NGはありません。
書き込みは手順、目的、気分次第で、今回はEtcher1.4.4(X64)を使用し、他もヒネクれた手順なしです。
今回はバージョン依存という私の見立てですが、ただSDの相性はそれはそれで確実に存在するものです。
>>331
>正規の手法 "mmcからのboot" で試してみぃ
旧来の方法で、焼いたらmicroSDスロットに突っ込んで放置で試してます。
mmcがないんで、残念ながら言われた方法で試すのが無理です。
逆に0.7.xはmmc以外が無理なのかなぁと。
0.6.xの時はSDだけでなくHDDでも起動できたんですが…
長文連投失礼しました。 >>329 ID:UlIbDYUc
ごめん間違えてた
x "mmcからのboot" -> o "MicroSDからのboot"
> 念のため、ブート優先順位は eMMC -> SPI -> SD ->USB20 -> USB3.0 です。
前の3つはのこの通り、 SDより後ろは U-BOOT の設定次第
SPIにU-BOOTを入れてると、SDを挿しても優先順位の関係で SPIのU-BOOT(古いVer)が立ち上がってしまう
U-BOOTに変更が入っているわけだから、0.7.x に関する報告は 正しいとは言えない
0.7.9 での U-BOOTのバージョンは↓参考(続き)
でも、無理して試す必要は無いよ
SPIのU-BOOTをDisable(消去)しない限りこうなるわけだから
せっかく上手く動いてる環境を壊して、戻せなくなったら目も当てられない
代わりに、わたしの結果を書いておく
以下、駄目で定評の有る "東芝 Exceria 16G" & 0.7.9
U-BOOT -> Kernel 正常
Kernel(ブート途中でRead-Err)
今までの報告通り
あと、"0.7.3, ２回目が・・・" 確かそう言うバグあったよ、だからこれは無視していい
0.7.x は、かなりの頻度で更新されてたから、特別な理由でも無い限りは最後(0.7.9)のだけにした方がいい
ところで、文体が違いすぎるが、ID:UlIbDYUc = ID:q65QTIAR じゃないよね？ 続き
0.7.9 での U-BOOTのバージョン
U-Boot SPL 2017.09-rockchip-ayufan-1025-g482cd6ec8b (Jul 26 2018 - 08:18:32)
setup_ddr_param 1
booted from SD
Trying to boot from MMC2
...
U-Boot 2017.09-rockchip-ayufan-1025-g482cd6ec8b (Jul 26 2018 - 08:18:38 +0000)
...
mmc1 is current device
Scanning mmc 1:7...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
1055 bytes read in 26 ms (39.1 KiB/s)
select kernel
1: kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524
2: kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524-memtest
Enter choice: 1: kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524 >ID:UlIbDYUc = ID:q65QTIAR じゃないよね？
いいえ、両方とも俺様じゃでござ候。
夏休みなんで別スレのIDコロコロな煽りに対抗していた影響です。
>x "mmcからのboot" -> o "MicroSDからのboot"
こちらもSPI1とかチマチマ誤植してるんでお気になさらず。
>SPIのU-BOOT(古いVer)が立ち上がってしまう
こちらで確認した限りでは、0.6.59しかない。
別バージョンがあるんです？
>SPIのU-BOOTをDisable(消去)しない限りこうなるわけだから
逆説的に、>>290の新しいロットにはSPIにブートローダーが書き込まれている可能性があるのかな。
そうなると新規さんにはいろいろヤヤコシイ感じかな。
>でも、無理して試す必要は無いよ
ぶっちゃけNASはラズパイ2B+、メイン開発はnanopi neoになってる。
現状Linuxそのものが目的じゃなく電子工作必須なLinux開発（シグナル合成）が最大の課題。
rock64は基本その辺に転がってて動かしてない。
最後に。
やっぱり新人さんには厳しい状況っぽい。
SPI更新しない前提で、新人さんへのおすすめは
・0.7.9
・0.6.x以前
で大丈夫そう？ > こちらで確認した限りでは、0.6.59しかない。
> 別バージョンがあるんです？
例えば辺りにあるイメージ
https://github.com/ayufan-rock64/linux-build/releases
bionic-containers-rock64-0.7.9-1067-arm64.img.xz
bionic-lxde-rock64-0.7.9-1067-arm64.img.xz
コイツのらの先頭部分には、みなU-BOOTが入ってるわけ
これらには、
U-Boot 2017.09-rockchip-ayufan-1025-g482cd6ec8b (Jul 26 2018 - 08:18:38 +0000)
入っていた ってこと
でも、SPI-FlashにU-BOOTが書かれてると、そっちが優先されて
そちら様、提示ログの通り
U-Boot 2017.09-ga0a2b48 (May 18 2018 - 08:07:44 +0000), Build: jenkins-linux-build-rock-64-221
が起動する
U-BOOT に 前方互換/後方互換が 確保されてれば問題無しだろうけど、残念ながら そうはなってないんだろうね
んで、U-BOOT単体はこちら
https://github.com/ayufan-rock64/linux-u-boot/releases
>> 逆説的に、>>290の新しいロットにはSPIにブートローダーが書き込まれている可能性があるのかな。
ないない
>> SPI更新しない前提で・・・
消去済みで出荷だから、自分で意図的に書いたりしない限りは気にしなくていい・・・ハズ（update等 で強制に変更されたとかないよね？)
SPI-BOOT は、最低限でもシリアル・コンソールもってない人は、手を出すべきじゃない
不可能ではないが、書込みに失敗した場合 復旧に苦労する羽目になる > rock64は基本その辺に転がってて動かしてない。
真逆だな、Pi3、1つは買った当時の箱に入ったまま、もう一つは引き出しの奥
逆にトラブルが少なくて、すぐ飽きちゃった。 最初に、基本俺レスは>>290みたいな新人さんにも取り付いてもらえるように気を付けてる
結論はユルいのがいいと、個人的には思う
>>342
電子工作だと手順ミスで基盤破壊するんで、入手しやすく価格も低いnanopi neoを選んでる
NASはrock64が好ましいんだけど、ayufan共通のioniceなcronが１分おきに走るのがイヤすぎる
スパムログのせいでSDの寿命を縮める
armbianは1Gモデルがstableに入るまで放置しようかと…つまり反映されるであろうbionic待ち
DietPIは日本語回り（？）が弱すぎて断念
>>341
つまり正しい手順は、（事情わかってなくても）
(1) OS変更時にはu-boot-erase-spi-rock64.imgで本体内のSPIお掃除
(2) 目的のOS（ayufanだと0.7.9以降推奨）
ってことかな
これだと強制的にuBOOT（本体内蔵のSPI）とOSのバージョンを合わせられる MicroSD無しで運用でもしない限りは、SPI-FLASHからブートするメリットがないからね
誰もがそうであるように、最初はMicroSDから始まる
この限りにおいては、SPI-FLASHに何も書かれていないから
何も気にする事無く、公式のイメージをカードに焼いてスロットに挿すだけ
そのうち慣れてきて、HDD/SDD/eMMC等 の運用に移行
SDはもう不要なんで、SPI-FLASHにBOOTに切り替えました
この様な場合、U-BOOTの互換性を失うような変更もありうる事 を忘れずに
その点を確認して、必要があれば・・・・
以下、アナタの結論、↓の通り
>> つまり正しい手順は、（事情わかってなくても）
(1) ・・・・
(2) ・・・・
* 0.7.9は、その殆どが rockpro64 のた為のモノ
切羽詰ってたのかどうかは知らなが、日々と言っていいほどの頻度で更新された
（一般への発売開始時期だったから、恐らくそれなりのプレッシャーが有ったものと思う)
つまる処、その必要性（バグ？)があってそうなったわけだから
もし、0.7.x を試してみるなら 現時点での最終版 "0.7.9" 以前のものはかなり怪しいと思ったほうがいい
一方、現時点の最終版 0.7.9 はリリースから20日以上変わってないから、ひとまず一段落 って事と思ってる >>336
> 念のため、ブート優先順位は eMMC -> SPI -> SD ->USB20 -> USB3.0 です。
ユーザマニュアル見ると、boot の優先順位は、
eMMC -> SPI FLASH -> SD ->USB OTG
になってるね。SPI FLASH の書き込みに失敗すると、別のマシンで 書き込んだ eMMC が必要になるわけか。
気を付けないとまずいね。 >>345
>>341氏提供情報だと、0.7.9にSPI更新が入ってる（自分で公式確認しないスタイル）
これってよくよく考えたら、起動失敗でオシャカになるかもしれないのか > 起動失敗でオシャカになるかもしれないのか
これは心配無い
https://github.com/ayufan-rock64/linux-u-boot/releases
しかし↑に有るのは PC等で言う処のBIOS書き換えツールと同じ意味合いのモノ
安易にこれを使って失敗したりすると、仰せの通り お釈迦になって 復旧に苦労する
（復旧の方法を知ってればどうって事無い作業だが、知らない人ならハマル)
もしupdate等で該当物が降ってくるようなら（未確認)、それは止めた方が良い
source.list からは外して置くべきだろう
>>341氏提供情報だと、0.7.9にSPI更新が入ってる（自分で公式確認しないスタイル）
悪いが、私はそんな事は言っていない
MicroSD-Image同梱のU-BOOTは、それなりの頻度で更新されている
しかし、それを "SPI-FLASH-ROM" に書き込むかどうかは全く別次元の話
0.7.9 のImageでも ユーザの同意無しにそのような事（SPI-FLASHの書き換え)をする事はない
覚えが無いのに書き換わってた？、もしそれが有りうるとしたら、update ぐらい
私の場合、まず最初にsource.list からは外すからクチだから これついては確認していない
また、その事を敢えて確認するつもりは無い
>>ID:juqpBEjJ にお尋ねするが、
あなたの掲げたlog、覚えが無いのに "SPI-FLASH-ROM" に書き込まれてた と言う事なのか？ >>>ID:juqpBEjJ にお尋ねするが、
>あなたの掲げたlog、覚えが無いのに "SPI-FLASH-ROM" に書き込まれてた と言う事なのか？
ＮＯ、0.6.xのヤツを手動で落とし手動で書いた
>>>341氏提供情報だと、0.7.9にSPI更新が入ってる（自分で公式確認しないスタイル）
>悪いが、私はそんな事は言っていない
大変行使わけない、誤解だった
SPI-BootとuBootを混同してしまった
>>346は完全に撤回させてほしい
本当に申し訳ありませんでした >>338 も私だが
SPI-FLASH は、それなりにリスクが高いので最初に↓書いていておいた
> でも、無理して試す必要は無いよ
> SPIのU-BOOTをDisable(消去)しない限りこうなるわけだから
> せっかく上手く動いてる環境を壊して、戻せなくなったら目も当てられない
おそらく貴方だろうが、これに対する応答もあったので
"その程度は知ってるよ" との事だろう理解して
そのつもりで種々書いて、まずは誤解が解けたようで一安心
あなたは、電子工作の経験も有るとのことだから
お礼に、お釈迦になった場合の復旧の仕方を一つ書いておくよ
回路図を見れば、SPI-FLASH-ROMの出力端子 "DO" が
40PinヘッダのSPI_RXD_M2に繋がっているの事が見て取れると思う。
コイツをGNDにクランプすれば、SPI-ROMからの応答が届かなくなり
eMMCに対するDisableジャンパと同じ効果が得られる。
結果、MicroSDから起動が可能になるので 後は…
GNDにクランプして壊れないか？ って電子工作の経験がある人からすればこれは愚問
心配なら止めておけ とだけお答えしよう
貴方の場合は、 "rock64? 普段は使ってなく てそこらへんに転がってるって" 事らしいから
そんな心配はなさそうだ。
所詮 大人の遊びと割り切れる、この程度の余裕は欲しいよね >>349
誤解のないようにちょっとだけ
私はとある大規模プロジェクトでドライバ開発を担当しただけで、ICEとか使ったので
ハードは内側から見たことの方が多いが、そのために知識が偏ってる
SPI-FLASHのプログラムを「ブートローダ」と呼ぶのはその時の名残
だが>>349が金言であること（rock64の文鎮化を完全に回避できること、手順によっては
SPI復活も狙える）ぐらいは理解できる
プロジェクトでそうなると、ROM抜いて焼いてた状況（そういうソケットついてた）
そしてその辺に転がってないモノにはGNDをHIGHにしてしまう粗忽者
当方の諸々の誤解、ご容赦いただきたく
雑談につきレス不要 >>349
壊れるのは、SPI FLASH のほうだから 運が悪くてもダメージは大きくないでしょうということで DO ですか。
クランプって書いてあるけども 30 Ωぐらいの抵抗で GND とつなげば良いかな？
ところで、SD の信号も 40pin に出ているね。引きまわしてたり分岐があったりするわけで、クロック落とさないと 不安定かも知れない。
そんな SBC はあんまりないかも。 >>351
横失礼
USBメモリにOS焼いて、UART出力確認しました
(1)ジャンパなし、SDなし、USBにOS
起動OK(SPI)
(2)(1)にSPI_RXD_M2SDを0ΩでGNDに接続
起動不能、UART無反応
(3)(2)にOS書き込み済みSD
起動確認(非SPI)
>>349のSPI_RXD_M2に関しては、SPI出力をすべてゼロに落とすことを目的としてると解釈しました
SPIが破損した場合は(3)の状態で起動し、SPIをddでゼロフィルすれば復旧できるということかと
面倒なんでゼロフィルまでは試してませんが
>ところで、SD の信号も 40pin に出ているね。
内部の内部では出力可能なようですが、SoCのコンフィグレーションがそうなってるかは不明（多分
そうなってない）とかいう話ではないかと
ちなみに私Linuxのほうが得意でどっちかっつーとソース書く人だったりするので、信憑性は微妙です 書き忘れ
＞SPIをddでゼロフィル
この手順の前、OS起動完了後に(2)のジャンパ外さないと、SPI不応答でゼロフィル不能になるかも
ジャンパ外すまではやりましたが、デバイス名探すの面倒だったのでやっぱゼロフィルやってません >>351
電子工作の経験有りそうな人だったから、あんな風に書いたけどソフト屋だとピンと来なかったのかもな
3.3VのI/C端子、地絡程度で壊れるようなデバイスの設計なんて誰もしませんて
んなヤワな物を設計したら量産でトラぶって、自分の身が火の車になるのは目に見えてる
第一、その程度で壊れる物なら、それ以前に身内の社内試験で落とされてしまう
では、それが保障できますか？ と顧客に聞かれてたら
当然 保障などしません 推奨する事もありません、スペックを守ってください と杓子定規に答えるだけ
なぜなら、それを保障しても する側には得られるメリットなど何も無いからだ
当たり前の事だよな、誰だって同じ受け答えになるだろ
いわゆる、本音と建前 ってヤツ。
> 壊れるのは、SPI FLASH のほうだから 運が悪くてもダメージは大きくないでしょうということで DO ですか。
> クランプって書いてあるけども 30 Ωぐらいの抵抗で GND とつなげば良いかな？
どれを潰しても結果は同じだけど、どれか一つ選んで下さいと言われたら D0
既に何度もやってるけど、直線GNDにショートしても壊れんよ >>353
U-BOOTで任意のキー入力
ポーズ状態になるからこの時点でジャンパーを外す
その後、kernelを選んで 起動
後は、従来通り "SPIが普通に読み書きできる状態でkernel が起動" する
> SPIをddでゼロフィルすれば復旧できるということかと
> 面倒なんでゼロフィルまでは試してませんが
フラッシュ物だから、消してからじゃないと正しい値は書けない
dd if=/dev/zero なら 結果論で同じになるけど、普通は "flash_erase" ってツールがあるんでそれで消す
消えた状態は全てのデータが 0xFF >クランプって書いてあるけども 30 Ωぐらいの抵抗で GND とつなげば良いかな？
もし、手元に適切な抵抗が転がってれば
例え壊れないと解っていても 私も同様の事をする
用心するに越した事はないからな。
無きゃ、わざわざ買いに言ったりせずに ポイとやっちゃうけど 雑談なんで無視してもおｋです
>>354
>電子工作の経験有りそうな人だったから、あんな風に書いたけどソフト屋だとピンと来なかったのかもな
ここで嫌味ブチ撒けてもしょうがないですが、お上品な現場で育ってないものでｗ
大規模な現場ではハードがないとソフト動かしようがないので、必然的にソフトが末端工程です
ハードの納品が遅れた分はソフト屋が飲むしかなく、その他の仕打ちもあって常に殺気立ってる現場なんです
たとえばアナログで特定の信号必要なのにエミュレータ貸してくれない（はずすのめんどくさがるハード屋）
なんてのは日常茶飯事で、性質理解してて可能なら別の機材＋素手で強引に再現します
そこまでしても工期の末端の末端でハード改修が入りテスト全滅とかも…
さておき、ここはLinux板でいろんな人がいて、ソフトどころか何も知らないズブの素人さんも入ります
私みたいな両方を知ってて汚い反則が基本の人間じゃなく、ちゃんとした識者の手順書があると有難いです
今回もそもそもが「初めて買いました！ うまく動かないです…」が発端の話のはずです Armbian、実装がおかしいところ多すぎないか?
IPv6が使える環境なんだけど、再起動の度にLink Localアドレスが変わったり、IPv4の固定IPが設定できなかったり・・・
リモートログインすらマトモに機能しない環境ってなんなの? それはmacアドレスが固定されてないからじゃなくて？ >>359
そこは変わってなかったw
Debianにはプライバシー保護のためにIPv6アドレスを再生成する機能があるらしいんで、そっちから当たってみる。
IPv4アドレス(固定)が設定されないことがあるのは要調査。 IPv6が起動毎に変わってしまう件と、IPv4のアドレスが認識されない件
interfacesにeth0の設定を追加したら、解決した。
デフォルトのinterfacesはauto eth0の記述しか無かったが、それではダメで
iface eth0 inet auto ← IPv4の場合
iface eth0 inet6 auto ← IPv6の場合
の両方を記述する必要がある。 Pinebookが今更メールが着たのでIPS液晶の11インチをポチってみたよ ROCK64ってmpegのハードウェアエンコードできないのか…
ubuntuにあるffmpegはh264_omxが使えるようになってるけど、soがなくて使えないってなる… スマホとタブレット出すつもりらしい
Pine64 is Working on a Linux Smartphone Running KDE Plasma | It's FOSS
https://itsfoss.com/pinebook-kde-smartphone/ rock64の用途ってopenmediavaultでNASという人も多いと思うんだけど。
ワンドライブでopenmediavaultの運用に成功された方っていらっしゃいますか？
PCの成功例は見つけたのですが・・・ ワンドライブでって、USB接続のHDDから起動ってこと？ >>367
はい。
USB3.0のHDDから起動までは漕ぎ着けました。で、OVMの仕様で２ドライブが必要と言うことを知りました。
どうしても使いたいので、USB2.0のメモリスティックから起動して、データはUSB3.0のHDDに格納してます。
信頼性から、USB2.0のHDDから起動すべきと思うのですが、これだと一番の目的だった低消費電力になってるのか悩ましいです。 >>368
「Rock64のUSB HDDから起動できたOSは」でググったら
出来たっぽいこと書いてる人の記述が見つかるけど
どうなんだろ >>368
OMVはパーティション切れば1ドライブ起動しなかったっけ？
OSが使う領域とデータ領域を完全に分ける仕様だから2ドライブ必要なはず。
そのままメモリスティックにOS入れる運用が楽だと思う。「今動いてる」って実績は貴重。 >>369
起動は出来てます。
物理的に起動ドライブと別なドライブじゃないと、共有とかの指定ができません。 >>370
sd, emmc, USBスティック, USB-HDD 全てで起動→omv の動作確認までてきてます。気になるのはメモリスティックの耐久性と、ならHDDにしたときの省電力についてです。
それらを全部クリア出来るのが、HDD 一台での稼動です。
で、このスレなら既にクリアしてるひともいるかと思い、アドバイスを頂きたいのです。 >>369
この方は、ラズパイとかrock64ではなく、PCでの成功例のようです。
あちらのページで質問してるのは私です(>_<) それはこのスレじゃなくNAS自作スレに行った方が良いよ >>374
アドバイスありがとう。
rock64ユーザはNAS用途が多いと決めつけて、ここのが良いかと考えてました。 NASにするならSATA出てる方がいいだろ
ROCK64でNASに使ってる奴なんて少数派だよ >>376
つか、SATAていっても中身はUSB2.0でしょ？ orangepiとかのsataは内部USB2.0なので
電源取れる分USB-SATA変換アダプタの方が
ましなレベルだよ >379
> orangepiとかのsataは内部USB2.0なので...
まさにそのとり
USB-SATA変換アダプタ(USB2.0)が、ボードに乗ったのと等価だからな
余分に電源ケーブルが必要になるだけで、メリット無し NAS目的以外に、発売当時ラズパイとかより高くて、長所と言えばギガイーサとUSB3.0しかないrock64を選んで、何の用途に買った人が多いのか知りたいw コイツ、嘘言うなよ
秋月は、最初から ￥3,780 で売ってるし
本家も $24.95 で変わりなしだ。 むしろNAS以外の用途は微妙かもね
Kodi系は動画の再生支援イマイチだし
GPIO使うなら情報量的にラズパイが良いだろうし NAS用途として使ってる事を少数派と言われてイラっとしてたんだろう、そっとしておいてあげて AESアクセラレータのためだけに買った
ラズパイも付けてくれればいいのに eMMCモジュールソケット採用してるのは
コレとODROIDくらいしか無くて >>384
ん？オレ？
気にしてないよw
素朴な疑問。 >>387
まず>>382に対して弁明反論しなはれ Piより高いボッタ価格で買ったマヌケにとっては、それが真実なんだろ
察してやれ >>382
そうか。
嘘つくつもりは無かったけど、オレが物色した当時は秋月では扱ってなかった。
$24?の1Gはともかく、ラズパイがそれより高いとは知らなかった。 しかしラズパイのスレで、ラズパイにケチつけた用なたたかれ方w
rock64ユーザ同士じゃん、なんで？ 自分の意にかなった回答が得られなかった 腹いせに
嘘を付いてまでケチ付けてんだから、叩かれて当然だろう >>392
バカなの？
選択の基準が価格だけならpiも有るだろうけど、USB3.0が必要で選択したんだから、しょうがないだろ？
で、お前はrock64を何に使ってるんだ？ 価格を勘違いしてたよ(・ω<)ﾃﾍﾍﾟﾛ
とすれば良いものを、グチグチと風呂敷を広げていっても喧嘩にしかならないぞぃ
振り上げた手の下ろし方を知らない訳じゃあるまいし
openmediaのNASの作り方は別スレ案件なんだし、IDも変わるんだからこの話題に幕を下ろして無視してれば良いのよ 俺のRock64が到着するまでには仲良くなってくれよ
月曜注文したのがやっと発送されたみたいなんで >>396
知らなかったて言ってるだろ。
どんだけ純真無垢な童貞なんだよw お前が絡んできた原因は、嘘までついてケチつけられた（と感じた）からだよな。
で、ケチつけられた対象ってrock64なの？それともpiなのかな？
今更だけどw 何も知らずに言ったとしたら、それこそ全くの作り話
大嘘吐きのチョウセン人 >>403
Twitterでもよく見かけるよね
本人の中ではテンション上がって何かを成してる充実感や楽しくなってるのだろうけど
周りは良い迷惑だという事に気が付いていないという
価格の間違いを指摘されただけなのに、今度はケチ付けられた事に対し、
その次は付けられた対象は何だと拡大解釈していって収拾がつかなくなってる
次は何だ？名称の綴りがどうとか？それとも国語の文法が〜に発展していくのか？
案の定>>405の様に人種差別まで始める始末、どうなってるんだろうね ここもIDコロコロ変えてる「マヌケ」が口癖のキチガイの自演か
集中砲火浴びてるやつ（ように見えてる奴）気にすんな 
