【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 の上位レイヤがやっている。 ドライバと言っても 上位レイヤに対してプリミティブを提供するだけで、作ってるのは SoC メーカ。 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は1枚除いてすべて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 1回目は成功(正規shutdown)したが、2回目は>>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, 2回目が・・・" 確かそう言うバグあったよ、だからこれは無視していい 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が1分おきに走るのがイヤすぎる スパムログのせいで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" に書き込まれてた と言う事なのか? NO、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 とつなげば良いかな? もし、手元に適切な抵抗が転がってれば 例え壊れないと解っていても 私も同様の事をする 用心するに越した事はないからな。 無きゃ、わざわざ買いに言ったりせずに ポイとやっちゃうけど 雑談なんで無視してもおkです >>354 >電子工作の経験有りそうな人だったから、あんな風に書いたけどソフト屋だとピンと来なかったのかもな ここで嫌味ブチ撒けてもしょうがないですが、お上品な現場で育ってないものでw 大規模な現場ではハードがないとソフト動かしようがないので、必然的にソフトが末端工程です ハードの納品が遅れた分はソフト屋が飲むしかなく、その他の仕打ちもあって常に殺気立ってる現場なんです たとえばアナログで特定の信号必要なのにエミュレータ貸してくれない(はずすのめんどくさがるハード屋) なんてのは日常茶飯事で、性質理解してて可能なら別の機材+素手で強引に再現します そこまでしても工期の末端の末端でハード改修が入りテスト全滅とかも… さておき、ここは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の仕様で2ドライブが必要と言うことを知りました。 どうしても使いたいので、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コロコロ変えてる「マヌケ」が口癖のキチガイの自演か 集中砲火浴びてるやつ(ように見えてる奴)気にすんな read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる