【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/

>>262
>armなクロスビルド環境あるんじゃね？
こんなのを使う奴はクロスビルド環境はやろうと思えば自分で構築できるだろう

LLVMのビルドはx86PCでも重処理なのに、arm機でビルドとなると長時間の激重処理になるだろうな
こんな安いのは長時間の激重処理をやらせるのに十分な冷却機構を搭載してないだろうから
冷却は自分でなんとかしてねだろう

上に、USBファンでも乗っけておけばいいだけだからな

ヒートシンクは気休め程度、ファン無しだと直に あっちち になる

ENIAC比で言ってくれ

１００倍じゃなかった
２００倍

価格は０．５万円として２００倍ぐらいだから、
コストパフォーマンスは、４００００倍

1コアで同じくらいの性能のVPSが年数$で借りられるんだがなぁ

いくら早くても使い道がなければ無用の長物＠1GB（まだ言ってる）

ソフトのメンテが長くされるか疑問
ラズパイは納得のいくレベル。

カーネルのビルドくらいできるやろ？

x64でできそうなのでビルドを試していた

暇つぶしにアチコチ拾い読みしてたらこんなものが
https://forum.armbian.com/topic/7613-boot-problem-with-rock64/

中ほどにあるイメージを発見、早速書き込んで起動…

____ ___ ____ _ ____ _ _
| _ \ / _ \ / ___| |/ / /_ | || |
| |_) | | | | | | ' / '_ \| || |_
| _ <| |_| | |___| . \ (_) |__ _|
|_| \_\\___/ \____|_|\_\___/ |_|


Welcome to ARMBIAN 5.51.180704 nightly Debian GNU/Linux 9 (stretch) 4.4.138-rk3328
System load: 0.12 0.14 0.06 Up time: 2 min
Memory usage: 6 % of 920MB IP: 192.168.1.13
CPU temp: 51°C
Usage of /: 7% of 15G

Last login: Sun Jul 8 13:25:40 2018

MEM1Gマシンにも風吹いてキター！！！　次に期待つないだー！！！
そんでまだビルド終わってねー！！！　もうええわー！！！

PINE64, ROCK64, ROCKPRO64の比較が出ていた

https://forum.pine64.org/showthread.php?tid=6158

ビデオエンコードの速度の比較で

PINE64
Real 2m49s

ROCK64
Real 2m32s

ROCKPRO64
real 0m56s

PINE64の3倍近い速度

ROCK系がmicroUSB給電だったら買うんだけど
流石にきついか

糞仕様を望むきついオツムはお前だけだからなw

きついオムツは嫌いか？ベビーちゃん

バブバブー(^q^)

PCIe x4スロット搭載のシングルボードコンピュータ「ROCKPro64」が入荷
2018年7月28日 00:00
https://akiba-pc.watch.impress.co.jp/docs/news/news/1135312.html
PCIe x4スロットを搭載したPINE64のシングルボードコンピュータ「ROCKPro64」の
メモリ4GBモデルがテクノハウス東映に入荷した。
ただし、初回入荷分は28日（土）に売り切れ。次回入荷は8月を予定している。
ヒートシンクとケースとのセット品で、店頭価格は税込13,900円。
このほか、オプションの64GB eMMCモジュールとUSBアダプタのセット
「PINE64 64GB eMMCモジュールキット」も販売予定だ。
ただし、同店は「ノンサポート商品」としている。店頭価格は税込5,900円。

>テクノハウス東映 ...
この値段なら、急ぎでもない限り 直接PINE64から買うだろ

前回もそうだったが
ここが仕入れてるなら、秋月でも扱う可能性大とみた
適切な価格でな。

armbianのbionic、グラフ半分ぐらいまで行ってなかったっけ？
いま完全にゼロに戻ってる

ごめ、>>280はrock64の話

Rock64と3.5HDDで常用NAS作りたいけれど
ACアダプタよりATX電源用意して5V引っ張ってくる方が良いのかな？

まあまて焦るな
消費電力がどれくらいなのかよく観察したほうが良い
それによっちゃmini-ITXのatomマザボに勝てないということになりかねない

>>282
3.5インチUSB-HDDケース（電源付き）＋Rock64の組み合わせ
消費電力的にも安定的にも一番いいハズ

１つのアダプタだけから電源供給したかったら、HDDの電源＋15Wぐらいのアダプタから
Rock64分だけ降圧でもかませばいけんじゃねーの的な
http://akizukidenshi.com/catalog/g/gK-07728/
電流制限どうやってかけるか、もしくは要らないか知らんけどー
っていうか2.5だけど、HDDケースに電源入れたらUSBから逆流する（RaspberryPi実績、運用時限定）

俺はRock64本体の電源供給からの2.5インチHDD起動で、armbianで３日ぐらい連続駆動成功してる
基本電源切り忘れただけだけともいうが、外部からssh接続でshutdownコマンド使って切ってる
なお電源接続は基本的に秋月推奨方式、理由は察せよ

Rock64が通関中でまもなく届きます
LinuxでGUIありで一通り触るには、どのOSがお薦めでしょうか？
（ラズパイからでLinuxには疎いです）

ちなみにayufanさんのは一人でアップデートとかやられてるんですか？

>>285
Armbian

>>286
やっぱりarmbianがとっつきやすいですそうですかね！
しかしお盆のせいか昨日から通関中が動かない…

秋月推奨の電源工作供給しないとどうなっちゃうの？
ラズパイみたいにカミナリマークとか出るのかな？

単に、秋月では1.35/3.5mmの変換プラグを扱ってないってだけの理由だな

秋月の普通の5V-ACアダプタ+変換プラグ、 or プラグ径=1.35/3.5mmのACアダプタで動くよ
aitendoのこれとか -> http://www.aitendo.com/product/7372
amazonで売ってる プラグ径=1.35/3.5mmのACアダプタとか

usbに電気食いのHDDとかぶら下げない限り、3Aも必要ない　5V/2.5Aで十分動く
本体＋MicroSDだけの構成なら、例えフル・ロードで回しても2Aは超えない

>>289
どもです
中国からメーカー違いでサイズの合う電源2つ、PINE公式から念のためケーブルを購入しました

Armbianの2つ、Bionic LXDE、DietPiと試したのですが、どれもカーネルパニックというんでしょうか、インストール途中で止まってしまうんですよね
1時間以上放置しても進まないので電源抜いちゃうんですが…
その後インストールできたように見えても不安定で　

ひとまず電源は原因から外せそうです
microSDも4枚試してるので外してますが、他に何か思い当たりますか？

> 中国からメーカー違いでサイズの合う電源2つ
思い当たるのは↑↑これだな、表示と実力が全く異なるヤツとか平気で売ってる。

俺の処にも、手元にchainaのハズレ品が一つあるよ
5V2Aとか提示しておきながら 実測したら1Aの能力にも満たない、こんなの当然動かんわな
全てがそうだと言は言わないが、平気でこういう事するのが普通のお国柄だから
買うなら、そのつもりで買わないと。

あと、最低限 クラッシュ直前のログでも貼らないと どんな腕自慢のヤツだって解らんよ
起動絡みのトラブルなら、シリアル・コンソールは必須。

>>291
出力やサイズの粗さも考慮して異なる製造元のを購入したんですが2つともハズレ引いた可能性もありですね…
一応公式USBケーブルに手持ちの5V/2.5Aでトライはしてみました

現状の停止状態はこちらです
https://i.imgur.com/ozkGHfX.jpg

BUG : spinlock lockup suspected on CPU
と
Exception stackはよく見る気がします

全部見せてくれないとあんま意味ない

全部お見せする何か良い手段ありますか？
途中でログが止まる場合の動画撮るにも最初は早いスピードでログが流れます

1/4で起動し
1/4で起動せず
1/4で再起動かかるも画面真っ暗でログすら出ず
1/4で途中のログで止まる
な感じで後ろ3つは電源抜くしかありません

シリアルコンソール繋ぐ

>>294

https://www.amazon.co.jp/dp/B01LVXGT04/
http://akizukidenshi.com/catalog/g/gM-08461/

シリアル接続ボードとして、3MBPSをサポートしてる上記２点をお勧めしておく
ここの住人が勧めるような２〜３百円はお勧めしない（血涙）

それ以外にmicroUSBなケーブルとジャンパーケーブルが必要
秋月の方はこれに加えハンダ付けが必要

…なんかこの時点でもうグッタリ感

たぶんレスつかないのは、UART知らない素人にはあまりに距離が遠いから
この機材を指定のポートに接続、teratermなどでログを取る必要がある
ごく当然に相応の説目や操作が必要

なのでその前に、手が届きやすい以下を確認したい

・使用したイメージ（xxx.imgのファイル名全部）
・使用したSDカード（class10以上かどうか、メーカーがどこか）
・使用したモデル（rock64のメモリサイズ）
・使用した書き込みソフト、もしくは書き込みコマンド

>>294
なんか電源の問題のように思えるけどなあ…。
電圧・電流は計ってみましたか？

>>296
入れ違いで数百円のシリアルコンソールポチってしまいましたorz

［使用したイメージ］
Armbian_5.42_Rock64_Debian_stretch_default_4.4.124_desktop.img
Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img
bionic-lxde-rock64-0.7.8-1061-arm64.img
stretch-minimal-rock64-0.7.8-1061-arm64.img
DietPi_v6.7_Rock64-ARMv8-Stretch.img

［使用したSDカード］(ともにUHS-�T)
・東芝 Exceria 32GB
・東芝 M203 16GB
・SunDisk 16GB

［使用したモデル］
・Rock64 4GB *2

［書き込みソフト］
・Etcher
・Win32DiskImager

>>297
そうなんですよね
初めてのラズパイのときも電源不足でつまづいた記憶はあります
カミナリマークのようなものが出ればいいんですが…
手元にあるのは簡易ワットモニターと、USBの電流チェッカーです
AC電源（5V3A）は2台とも4-6Wのワット表示しか物理的にできません
USB電源(5V2.5A)+公式で購入したケーブル&経由では5V0.3-1.2A程度の推移です

>入れ違いで数百円のシリアルコンソールポチってしまいましたorz
FTD1232（FTDI232の誤植）のシルク印刷があるならまだワンチャンあるんだけど…
Jtw32.exeでググると、UARTドライバ経由ではない接続で1.5Mに対応できる…らしい
理屈はともかくrock64でUART確認済み

さておき、他は問題なさそうに見える

rock64で実測できる環境持ってないけど、raspberry pi2B+、nanopi neoとも
なにもつながないで5.2V/0.3A程度
Lチカナイトライダーやったけど一緒、普段つながないHDMI（CUI）でも一緒

GUIやったことないけどってそんなにバカ食いなの？　ってのが私の限界

ちなみにUSB計測器を使ったけど、3Aまで対応している（質問主は気にしなくていい話）

> ［使用したSDカード］(ともにUHS-�T)
> ・東芝 Exceria 32GB
> ・東芝 M203 16GB
> ・SunDisk 16GB

新しいヤツ(kernel)にはバグがあって、
少なくとも "東芝　Exceria 16GB" がダメなのは 俺の処でも確認できているる(read-error)
本家スレにもが同様の報告複数ある。

どの道、IFの速度制限 25MB/s で頭打ちだから、はっきり言って "UHS-�T" なんか無意味
むしろ、UHS-I非対応の遅いやつの方が安定してるぐらい。

問題切り分けのために、古いヤツ↓で試してみ
https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15
stretch-minimal-rock64-0.5.15-136-arm64.img.xz


> シリアル接続ボードとして、3MBPSをサポートしてる上記２点をお勧めしておく
> ここの住人が勧めるような２〜３百円はお勧めしない（血涙）

コイツも変なヤツだな
それって、単に自分が不勉強でハズレを引いたから　ってだけの理由じゃないか
一年前に買った、俺のPL2303HX(amazon@180円)のヤツは　今でも問題無く使えてるぞ

そもそも本家のはCH340Gを搭載の$1.99なので、FTDIの話はどこから出てきたか不明。
中華通販でポチればCH340Gを引いてる可能性の方が高い。
3MBPSでなく1.5MBPSのようだから、ん、と思うような速度ではある。
OPiは115200だったので１桁間違ってるかと思った。

>コイツも変なヤツだな
ラズパイ流れでnanopi neoも115.2kなもんで、それ以上のヤツ探したらFTDIの1.5M非対応しかなかった
configでなんとかする手段ないか、あるいはお勧めないかってこのスレで聞いたら書いた通りの固定概念
植え付ける結果になった
>PL2303HX
>CH340G
辛口でも正解のほうが有難いんでこんど買い替える

ということで
>>ID:qiL+uVHc
こちらが足らない知識を披露してしまった様子、申し訳ありませんでした

まぁそんな処だろ、俺も同じようなもんだ

仕様は 3Mbps 以上 & 本家のは CH340G
この2点を調べた上で、何かのついでに該当品を併せ買いした程度のもの

中華製品は当たり外れが多いから念のために3つぐらいポチッたな、確か
最初の1つ目で動いたんで、今となっては残り2つが何処かにいったか不明

ハズレ引いたら、その間の待ち時間がもったいないぐらいのモンで
金額的には、（血涙）とか言って メクジラ立てる程のものではないよ。

シリアルコンソールはググってPL2303のものを買いました
（できれば海外発送が届く前に別の原因解決したいです）

>>301
リンクをもとに上記3つのmicroSDに下記を入れて、
今までカーネルパニックになっていたインストール、update/upgrade、
再起動を確認してみました

stretch-minimal-rock64-0.5.15-136-arm64.img.xz
xenial-mate-rock64-0.5.15-136-arm64.img.xz
xenial-minimal-rock64-0.5.15-136-arm64.img.xz
xenial-minimal-rock64-0.5.15-136-armhf.img.xz

xenial-minimalのarm64版はインストール時の読み込みの時点で失敗、
他の3つは全てすんなり進みました！

指摘の通りmicroSDの問題なのかなと思い、他で使用していた
Trancend 32GBに再度>>298を入れてみたものの失敗しました...
(これもUHF-Iではあるんですが)

少しは役に立ったようで、よかったね

もう少し付け加えて置く
UHF-Iが悪いとか、東芝が駄目だとか言ってる訳じゃないよ
あくまでも kernel 側の不具合
Rock64(RAM-4G)は駄目だけど、Rock64(RAM-2G/1G)なら同一の駄目カードでも問題無し
そして極めつけは、コードを追って該当箇所を直したらRock64(RAM-4G)でも問題無し
kernel の不具合と言ったのはこれが根拠

それともう一つ、同じ "東芝 Exceria" でも MicroSD-8G なら問題無し。
特にRock64(RAM-4G)の場合、kernel の不具合が 症状に大きく出る傾向にあるようだ。（固体差が大きい？）
もし手持ちに 8Gのカードが余ってたらそれで試してみたら、0.7.x でも動いてくれるかもよ？

以下、私見）
0.5.x あまり覚えていないが、"statable" のポジションのに長い間居座ってただけ有って、安定感はある
0.6.x 極初期のは比較的マシ、版を重ねるたびに ↑のMicroSD不具合の症状が 顕著になる傾向
0.7.x その殆どが rockpro64 の為の修正版(とばっちり食らって、rock64では起動せず てのが何度もあったな)

>>306
なるほど
4GRAM2つ買ったのですが、1つは2Gにしておくべきだったのかも
電源やSDカードはバラバラのモデルにしてリスク回避したつもりでしたが無念
カーネル弄るのはまだ敷居が高いです…

もう他に手持ちのMicroSDは無いのでしばらくv0.5.xで遊んでみようと思います
ファイル鯖でUSB3.0、録画鯖で関係カーネル動いてくれるといいなー

ちなみにフォーラムでSamsungのEVO勧めてる方がいましたが使ってる方いますか？
手持ちの東芝2種類、Sandisk、Transcendダメとなるとなかなか同じメーカーには手を出しづらいところであります（Exceria 8GBはｱﾔｼｲ高い販売店しか見つからず…）

v0.7.xでRock64（4GBRAM）で動作実績のあるmicroSDの情報ほかにもお待ちしてます！

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でも間に合ってるな

>>321
SPI FLASH に uboot を焼けば、その microsd も不要に。
　https://qiita.com/masakielastic/items/7fe3ae9ba772e6f74bb4

>>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としての性能は十分

ログを比較すればわかりますが、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インチをポチってみたよ