Hello,
A jelenlegi Factory image-ekben egy kis hackre van szukseg, hogy bootoljon az eszkoz. Sajnos nincs TTL kabelem, se HDMI-m, ezert kenytelen voltam ezek segitsege nelkul 'rajonni' a megoldasra. Koszonet az #opensuse-arm IRC csatornanak a tippekert! Mint kiderult, az nem sokat jelent, hogy ugyanaz az image mit muvel a QEMU-ban...
Ird ki az image-et:
# xzcat openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2016.11.23-Build4.37.raw.xz | dd bs=4M of=/dev/mmcblk0 iflag=fullblock oflag=direct
Mountold fel a ROOT es a BOOT labellel rendelkezo particiokat:
# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/mmcblk0p3 btrfs 2194368 660216 1367272 33% /run/media/user/ROOT
/dev/mmcblk0p2 ext3 202173 80020 111504 42% /run/media/user/BOOT
Masold at a device tree file-okat, amik hianyoznak innen:
# ls -F /run/media/user/BOOT/boot/
0xbd84b952 boot.scr boot.script grub2/ initrd.vmx linux.vmx mbrid unicode.pf2
# cp -rp /run/media/user/ROOT/boot/dtb* /run/media/user/BOOT/boot/
Umountold a FS-eket es bootold az SD-rol az rpi-t.
Ami a Raspbianhoz kepest szokatlan, hogy az install alatt az ACT LED nem villog, nem vilagit. Kb 3 perc utan viszont eletre kel a LAN LED es be lehet jelentkezni a default root/linux user/jelszoval (!), ha van DHCP a halozaton es tudod, hogy mi lett az eszkoz IP cime.
En a JeOS image-et tettem fel, hat ez tenyleg eleg alap, pl nincs benne wpa_supplicant, igy a WiFi interface sem el, de szerencsere ami kellett, mind volt repoban.
udv
LGee
Hozzászólások
A wifi mas miatt nem megy... ket kulonbozo SDHCI driver van, es az ujabb okoz gondot a wifivel.
https://lists.opensuse.org/opensuse-arm/2016-10/msg00097.html
https://lists.opensuse.org/opensuse-arm/2016-10/msg00051.html
Kíváncsi leszek a 64 bites rendszerre váltás kapcsán szerzett tapasztalataidra.
Jelfeldolgozás terén nekem elsőre tetszett a váltás gondolata, mert több NEON regisztert kapok, ráadásul az AArch64 NEON-ja támogatja a double-t. Valójában AArch64 utasításkészlet esetén enyhe lassulást tapasztaltam. Okát keresve a memóriához jutottam, amire Rpi3 esetén figyelni kell.
Tesztem: for() ciklusban integeres memóriabirizgálás.
mem[(i<<4) & memlimit]++
Raspberry3:
3,4 nsec 32 kB alatt
6,6 nsec 512 kB alatt
62 nsec 512 kB felett <---- 512 kB felett erősen belassul. Vesd össze a legalsó tesztemmel.
Konkurenciával összevetve (Odroid-C2):
2,7 nsec 32 kB alatt
5,3 nsec 512 kB alatt
44 nsec 512 kB felett <---- 512 kB felett erősen belassul ez is.
És összevetettem az x86 architektúrával: i5-3337U laptop
0,8 nsec 32 kB alatt
2,4 nsec 256 kB alatt
3,4 nsec 4096 kB alatt <----- 8-szor nagyobb méretű cache
6,6 nsec 4 MB felett <----- felette sincs az ARM-nál tapasztalható erőteljes belassulás
Afenti tesztek lineár olvasásnál nem okoznak ekkora eltérést, de amint össze-vissza kell adatok után kapirgálni (esetemben FFT-nél bukott ki), rögtön kijönnek ezek az architektúrabeli különbségek.
Ha gyors lesz valamikor a RAM elérés, akkor majd tempó terén is előnyös lehet a 64 bites utasításkészlet.
Egy, csak egy cég van széles e vidéken, ahol rendelkezésre áll a megfelelő know-how a sávkeskenység nélküli I/O- valamint memóriakezeléshez ARM64-en, és az termékben is megjelent. Igen, az Apple által felvásárolt P.A. Semi mérnökgárdára, meg pár egyéb odavándorolt RISC-fejlesztőmérnökre gondolok. Érdekes lenne lefuttatni a tesztjeidet A(9|10)X-en.
Attol tartok, az en ugynevezett tapasztalataim nemigen terjednek tul a home server feladatain...
Mivel meg mindig openSUSE-parti vagyok es az elodje is azon futott, igy a disztro adott volt, es ok alapbol aarch64-et szallitanak erre a 'lapra'.
sub
http://www.zdnet.com/article/raspberry-pi-hands-on-with-suse-and-opensu…
TL;DR elegge negativ tapasztalatok, a Tumbleweed el se indul. Szoval ha valaki ilyesmire vagyik, akkor garantaltan van vele szivas.