Skip to content

ROCKPro64 - eMMC-Modul / SD-Karte auswählen

Hardware
3 1 2.2k
  • Der ROCKPro64 hat ja eine festgelegte Boot Reihenfolge. Nun kann es ja sein, das man bei einem montierten eMMC-Modul mal eben ein Image testen will. Nur bei dem kleinen Modul weiß ich nicht ob das unbedingt sehr gut kommt, wenn man das immer wieder aus- und wieder einbaut. Das selbe hat sich wohl auch der Hersteller gedacht, aus diesem Grund findet man neben dem Platz für das eMMC-Modul einen Pfostenstecker mit zwei Pinnen.

    0_1532770712865_DSC_0036_ergebnis.JPG

    Dieser dient dazu, das eMMC-Modul zu deaktivieren und wieder von SD-Karte zu booten. Sehr praktisch das Ganze! Eine Brücke einlegen und fertig. Vorher den ROCKPro64 ausschalten!

    0_1532770797172_DSC_0037_ergebnis.JPG

    Klappt wunderbar, so kann man schön viele Dinge ausprobieren und mein Hauptsystem auf der eMMC-Karte würde nicht angefasst.

  • Gute Frage heute im IRC "Wie kann man denn was Neues auf das eMMC-Modul schreiben, wenn man den Jumper setzen muss um von SD-Karte zu booten?"

    Die Antwort

    14:27:39) DiscordBot: <pfeerick> If that is the eMMC clock disable jumper like on the rock64, to boot the SD you would put the jumper on, power up the board, and then pull the jumper off after 2-3 seconds. This would make the board boot from the SD card, but still see the eMMC.

    Das musste ich natürlich testen.

    rock64@rockpro64:~$ fdisk -l
    fdisk: cannot open /dev/ram0: Permission denied
    fdisk: cannot open /dev/mtdblock0: Permission denied
    fdisk: cannot open /dev/mtdblock1: Permission denied
    fdisk: cannot open /dev/mtdblock2: Permission denied
    fdisk: cannot open /dev/mmcblk1: Permission denied
    fdisk: cannot open /dev/mmcblk1rpmb: Permission denied
    fdisk: cannot open /dev/mmcblk1boot1: Permission denied
    fdisk: cannot open /dev/mmcblk1boot0: Permission denied
    fdisk: cannot open /dev/mmcblk0: Permission denied
    fdisk: cannot open /dev/sda: Permission denied
    fdisk: cannot open /dev/zram0: Permission denied
    fdisk: cannot open /dev/zram1: Permission denied
    fdisk: cannot open /dev/zram2: Permission denied
    fdisk: cannot open /dev/zram3: Permission denied
    fdisk: cannot open /dev/zram4: Permission denied
    fdisk: cannot open /dev/zram5: Permission denied
    

    Hier sieht man jetzt beide mmcblk0 und mmcblk1. So weit, so gut. Aber, woher weiß ich das er vom richtigen Device gebootet hat?

    rock64@rockpro64:~$ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            992M     0  992M   0% /dev
    tmpfs           200M  508K  199M   1% /run
    /dev/mmcblk0p7   15G  2.4G   12G  18% /
    tmpfs           996M     0  996M   0% /dev/shm
    tmpfs           5.0M  4.0K  5.0M   1% /run/lock
    tmpfs           996M     0  996M   0% /sys/fs/cgroup
    /dev/mmcblk0p6  112M  4.0K  112M   1% /boot/efi
    tmpfs           200M     0  200M   0% /run/user/1000
    

    Diskfree (df) zeigt uns auch die Mountpunkte. Und da sehen wir, das /dev/mmcblk0p7 das Rootdevice ist. Also alles richtig so weit. Nun könnte man die SD-Karte mit dd einfach auf's eMMC-Modul bügeln 🙂

  • Echtes Problem gefunden.

    Wenn die eMMC-Karte verbaut ist, ich mit der SD-Karte starte (Jumper gesetzt), kann ich keinen Kernel updaten. Es ist alles ganz normal installiert, er startet aber immer den letzten vorhandenen.

    Jumper entfernt, eMMC-Modul entfernt!

    Bootvorgang mit unveränderter SD-Karte, neuer Kernel wird geladen.

    OK, das verstehe ich im Moment überhaupt nicht !?!?!?

  • ROCKPro64 - USB-C -> HDMi

    ROCKPro64 rockpro64
    3
    1
    0 Stimmen
    3 Beiträge
    519 Aufrufe
    FrankMF
    @hannescam Hallo! Das ist ja schon ein paar Tage her, gut das wir den Screenshot haben. Du könntest genau diese Kernel-Version vom Kamil suchen und benutzen. Da musste man kein Linux Held sein, Kable einstecken - Bild da. Ob das mit was Aktuellerem geht, weiß ich nicht. Debian kann man ja so installieren, wie findest Du hier im Forum. Ob Debian die USB-C Schnittstelle nutzt weiß ich nicht. muss man ausprobieren. Da für mich die Platinen immer nur ohne Desktop Sinn gemacht haben, habe ich so was immer nur ganz kurz angetestet. Nutze die SOCs eigentlich ausschließlich Headless.
  • ROCKPro64 - Armbian - Boot Ausgabe ändern

    Verschoben Armbian armbian rockpro64
    1
    0 Stimmen
    1 Beiträge
    517 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Samsung 970 NVMe M.2 500GB

    Hardware hardware rockpro64
    1
    1
    0 Stimmen
    1 Beiträge
    1k Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Docker Image

    ROCKPro64 docker rockpro64
    4
    1
    0 Stimmen
    4 Beiträge
    1k Aufrufe
    FrankMF
    Das ganze hat einen furchtbar schönen Vorteil. Mal angenommen, ich habe ein NodeBB-Forum in einem Container laufen. Will das Ding updaten und das crasht einfach mal so. Egal, Container stoppen, Container starten und alles läuft wieder. Mit dem Commit sichere ich mir dann den Zustand nachdem ich weiß, das alles klappt
  • [HOWTO] Verschlüsseltes NAS aufsetzen

    Verschoben ROCKPro64 howto linux rockpro64
    12
    0 Stimmen
    12 Beiträge
    3k Aufrufe
    FrankMF
    Da btrfs bei mir ja nicht so der Bringer war, Fehler im Image vom Kamil?, Fehler in btrfs? Ich weiß es nicht, also weg damit! Da ich das NAS noch richtig produktiv genutzt hatte, waren die Daten schnell gesichert. Danach das NAS neugestartet, nun sind die beiden Platten nicht mehr gemountet und wir können damit arbeiten. ACHTUNG! Ich bitte wie immer darum, das Gehirn ab hier einzuschalten! Sonst droht Datenverlust! Aus Sicherheitsgründen gebe ich hier die Laufwerke so an = sdX1 Das X bitte entsprechend austauschen! Die beiden Platten mit sudo fdisk /dev/sdX neu einrichten. Alte Partition weg, neu einrichten usw. Im Detail gehe ich hier jetzt nicht drauf ein. Ich gehe davon aus, das das bekannt ist. Der Plan raid_pool0 = sdX1 = /dev/mapper/raid_pool0 raid_pool1 = sdX1 = /dev/mapper/raid_pool1 Verschlüsseln sudo cryptsetup --key-size 512 --hash sha256 --iter-time 5000 --use-random luksFormat /dev/sdX1 sudo cryptsetup --key-size 512 --hash sha256 --iter-time 5000 --use-random luksFormat /dev/sdX1 Platten entschlüsseln sudo cryptsetup open /dev/sdX1 raid_pool0 sudo cryptsetup open /dev/sdX1 raid_pool1 RAID1 anlegen sudo mdadm --create /dev/md0 --auto md --level=1 --raid-devices=2 /dev/mapper/raid_pool0 /dev/mapper/raid_pool1 sudo mkfs.ext4 /dev/md0 Script zum Entschlüsseln und Mounten crypt.sh #!/bin/bash ###############################################################################$ # Autor: Frank Mankel # Verschlüsseltes Raid1 einbinden! # # Hardware: # ROCKPro64v2.1 # PCIe SATA Karte # 2St. 2,5 Zoll HDD Platten a 2TB # # Software: # bionic-minimal 0.7.9 # Kontakt: frank.mankel@gmail.com # ###############################################################################$ #Passwort abfragen echo "Passwort eingeben!" read -s password echo "Bitte warten......" #Passwörter abfragen echo -n $password | cryptsetup open /dev/sdX1 raid_pool0 -d - echo -n $password | cryptsetup open /dev/sdX1 raid_pool1 -d - #Raid1 mounten mount /dev/md0 /mnt/raid echo "Laufwerke erfolgreich gemountet!" Bis jetzt sieht das Raid ok aus, ich werde das die nächsten Tage mal ein wenig im Auge behalten. [ 82.430293] device-mapper: uevent: version 1.0.3 [ 82.430430] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: dm-devel@redhat.com [ 108.196397] md/raid1:md0: not clean -- starting background reconstruction [ 108.196401] md/raid1:md0: active with 2 out of 2 mirrors [ 108.240395] md0: detected capacity change from 0 to 2000260497408 [ 110.076860] md: resync of RAID array md0 [ 110.385099] EXT4-fs (md0): recovery complete [ 110.431715] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [57744.301662] md: md0: resync done.
  • SPI funktioniert

    ROCKPro64 rockpro64
    4
    0 Stimmen
    4 Beiträge
    965 Aufrufe
    FrankMF
    Wie ich jetzt mehrmals festgestellt habe, ist das System von der USB3 Platte instabil. [111985.654653] EXT4-fs error (d4: inode #16354: comm systemd: r[111985.837719] EXT4-fs error Das killt dann das komplette System. Ob das an meiner Hardware liegt, weiß ich nicht. Also, wer da draußen so ein System einsetzen will, Vorsicht! Die USB3-Schnittstelle scheint noch einige Bugs zu haben!! Mein NVMe System dagegen ist absolut stabil!
  • Neuer Bootprozeß seit 0.7.x

    ROCKPro64 rockpro64
    1
    0 Stimmen
    1 Beiträge
    882 Aufrufe
    Niemand hat geantwortet
  • Benchmark Mainline 4.17.0-rc6

    Verschoben Archiv rockpro64
    4
    0 Stimmen
    4 Beiträge
    1k Aufrufe
    FrankMF
    iozone 5GT/s x2 rock64@rockpro64:/mnt$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Sat Jun 16 06:34:43 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 48672 104754 115838 116803 47894 103606 102400 16 168084 276437 292660 295458 162550 273703 102400 512 566572 597648 580005 589209 534508 597007 102400 1024 585621 624443 590545 599177 569452 630098 102400 16384 504871 754710 765558 780592 777696 753426 iozone test complete. 2,5GT/s x2 rock64@rockpro64:/mnt$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Sun Jun 17 06:54:02 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 49420 91310 102658 103415 47023 90099 102400 16 138141 202088 224648 225918 141642 202457 102400 512 335055 347517 375096 378596 364668 350005 102400 1024 345508 354999 378947 382733 375315 354783 102400 16384 306262 383155 424403 429423 428670 377476 iozone test complete.