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

>>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インチをポチってみたよ

Ubuntu Weekly TopicsでRockPro64⁠の話題が

http://gihyo.jp/admin/clip/01/ubuntu-topics/201809/07

PINE64が提供する“⁠RockPro64⁠”ボードでUbuntu 18.04 LTS + LXDEを動かしたレビュー。

https://www.cnx-software.com/2018/08/27/rockpro64-rk3399-board-linux-review-ubuntu-18-04/

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
USB3.0の使い道。

>>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も変わるんだからこの話題に幕を下ろして無視してれば良いのよ

かみ合ってないなw

嘘つきの相手はしたくない

俺のRock64が到着するまでには仲良くなってくれよ
月曜注文したのがやっと発送されたみたいなんで

>>396
知らなかったて言ってるだろ。
どんだけ純真無垢な童貞なんだよw

知らなかったら無罪なんだな

当初はですます口調で謙虚なヤツだったのにな・・・

>>399
子供かw

お前が絡んできた原因は、嘘までついてケチつけられた（と感じた）からだよな。
で、ケチつけられた対象ってrock64なの？それともpiなのかな？
今更だけどw

最近良く居る
謝ったら死ぬ病なんだろうね

必死すぎるｗ

何も知らずに言ったとしたら、それこそ全くの作り話
大嘘吐きのチョウセン人

>>403
Twitterでもよく見かけるよね
本人の中ではテンション上がって何かを成してる充実感や楽しくなってるのだろうけど
周りは良い迷惑だという事に気が付いていないという

価格の間違いを指摘されただけなのに、今度はケチ付けられた事に対し、
その次は付けられた対象は何だと拡大解釈していって収拾がつかなくなってる
次は何だ？名称の綴りがどうとか？それとも国語の文法が〜に発展していくのか？
案の定>>405の様に人種差別まで始める始末、どうなってるんだろうね

ここもIDコロコロ変えてる「マヌケ」が口癖のキチガイの自演か
集中砲火浴びてるやつ（ように見えてる奴）気にすんな

蛇足の一行で自援護

>>407
ワロタ
さっそくIDコロコロですか

底辺おっさんスレらしい盛り上がりだな
底辺おっさんはこんなことでぐらいでしか盛り上がらないんだろうな

>>410
底辺底辺うるせえぞ上辺
参加できてない底辺もいるんだからな

日付見れば分かるだろ
一人浮いてるお前が去れば静かなもんよ

>>412
日付？浮いてる？、、、ごめん聞きたいんだけど、なんか心の病持ってる？

NASで発狂した子がまた暴れてるのか

ヽ(｀Д´#)ﾉ ｷｰｯ!!

シングルボードも何だかリッチ化しちゃってるし
既存のはオーディオマニアに売り込みしてるだけだし、盛り上がりも終わりかなぁ

盛り上がりは終わっても衰退ではない。定着したということ。

4枚買ったのでもうお腹いっぱい
用途限られるからもう故障以外で
買わないと思う

俺は、 RAM 1G/2G/4G と　３個
HDDで使ってる分には、RAM大小差はあまり感じない

逆に、MicroSDで使うなら RAMの大小に関わらずもっさり
書込みが絶望的に遅いから、これはもう どうしようもない

結局、RAM=1G版のコスパが最も高い　という結論になった。

--
あと eMMC、速くて文句は無いんだが、とっても壊れやすい
要注意な

>あと eMMC、速くて文句は無いんだが、とっても壊れやすい

マジか！
スキップしながら到着を待ってるというのに・・・

そもそもBGAで直接繋ぐのが普通だからあんまりノイズとか変な電圧に強くない