Skip to content

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

Hardware
3 1 2.1k
  • 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 - Debian Bullseye Teil 2

    Verschoben ROCKPro64 debian linux rockpro64
    3
    0 Stimmen
    3 Beiträge
    521 Aufrufe
    FrankMF
    Gestern mal das Ganze mit einem Cinnamon Desktop ausprobiert. Eine verschlüsselte Installation auf eine PCIe NVMe SSD. So weit lief das alles reibungslos. Der Cinnamon Desktop hat dann leider keine 3D Unterstützung. Sieht so aus, als wenn keine vernünftigen Grafiktreiber genutzt würden. Da ich auf diesem Gebiet aber eine Null bin, lassen wir das mal so. Außerdem mag ich sowieso keine Desktops auf diesen kleinen SBC. Da fehlt mir einfach der Dampf Gut, was ist mir so aufgefallen? Unbedingt die Daten des Daily Images erneuern, keine alten Images nutzen. Ich hatte da jetzt ein paar Mal Schwierigkeiten mit. Da das ja nun keine Arbeit ist, vorher einfach neu runterladen und Image bauen. Warum zum Henker bootet eigentlich. außer meiner Samsung T5, nichts vom USB3 oder USB-C Port??
  • ROCKPro64 - Kamils neuer 0.10.x Release

    ROCKPro64 linux rockpro64
    1
    1
    0 Stimmen
    1 Beiträge
    258 Aufrufe
    Niemand hat geantwortet
  • FTDI Support (ayufan Kernel 5.0)

    Ungelöst Probleme? ayufan ftdi rockpro64
    8
    0 Stimmen
    8 Beiträge
    670 Aufrufe
    K
    Hi, leider habe ich bisher keine Antwort von Kamil erhalten. So habe ich selbst mal einen Kernel kompiliert. Als Vorlage habe ich den Ayufan 5.3 rc4 1118 genommen. Also gleiche config nur zusätzlich den FTDI und den CH341 (Arduino clones) Treiber hinzugefügt. Könnt ihr ja mal bei Lust und Laune testen. Für meine Zwecke funktioniert er gut. Gruss https://drive.google.com/file/d/1kJarihL7bAqN9y6tK-m1V4zHCSEiEWtf/view?usp=sharing
  • ROCKPro64 - Das erste Mal

    Angeheftet Verschoben Hardware rockpro64
    5
    2
    1 Stimmen
    5 Beiträge
    969 Aufrufe
    FrankMF
    Ich kann heute die Fragen aller Fragen beantworten Damit ist leider die Frage immer noch unbeantwortet ob WLan und PCIe zusammen nutzbar ist!! Es geht!! Ich habe von MrFixit ein Testimage der RecalBox, benutzt das selbe Debian wie oben. Die Tage konnte man im IRC verfolgen, wie man dem Grundproblem näher kam und wohl einen Fix gebastelt hat, damit beides zusammen funktioniert. Mr.Fixit hat das in RecalBox eingebaut und ich durfte testen. # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP8000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether ac:83:f3:e6:1f:b2 brd ff:ff:ff:ff:ff:ff inet 192.168.178.27/24 brd 192.168.178.255 scope global wlan0 valid_lft forever preferred_lft forever inet6 2a02:908:1262:4680:ae83:f3ff:fee6:1fb2/64 scope global dynamic valid_lft 7145sec preferred_lft 3545sec inet6 fe80::ae83:f3ff:fee6:1fb2/64 scope link valid_lft forever preferred_lft forever # ls /mnt bin etc media recalbox sd.img test2.img boot home mnt root selinux tmp crypthome lib opt run srv usr dev lost+found proc sbin sys var # fdisk BusyBox v1.27.2 (2019-02-01 22:43:19 EST) multi-call binary. Usage: fdisk [-ul] [-C CYLINDERS] [-H HEADS] [-S SECTORS] [-b SSZ] DISK Change partition table -u Start and End are in sectors (instead of cylinders) -l Show partition table for each DISK, then exit -b 2048 (for certain MO disks) use 2048-byte sectors -C CYLINDERS Set number of cylinders/heads/sectors -H HEADS Typically 255 -S SECTORS Typically 63 # fdisk -l Disk /dev/mmcblk0: 15 GB, 15931539456 bytes, 31116288 sectors 486192 cylinders, 4 heads, 16 sectors/track Units: cylinders of 64 * 512 = 32768 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/mmcblk0p1 * 2,10,9 10,50,40 32768 163839 131072 64.0M c Win95 FAT32 (LBA) Partition 1 does not end on cylinder boundary /dev/mmcblk0p2 * 16,81,2 277,102,17 262144 4456447 4194304 2048M 83 Linux Partition 2 does not end on cylinder boundary /dev/mmcblk0p3 277,102,18 1023,254,63 4456448 31115263 26658816 12.7G 83 Linux Partition 3 does not end on cylinder boundary Disk /dev/nvme0n1: 233 GB, 250059350016 bytes, 488397168 sectors 2543735 cylinders, 12 heads, 16 sectors/track Units: cylinders of 192 * 512 = 98304 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/nvme0n1p1 1,0,1 907,11,16 2048 488397167 488395120 232G 83 Linux # Oben sieht man eine funktionierende WLan-Verbindung, das LAN-Kabel war entfernt. Unten sieht man die PCIe NVMe SSD, gemountet nach /mnt und Inhaltsausgabe. Das sollte beweisen, das der Ansatz der Lösung funktioniert. Leider kann ich nicht sagen, das es zum jetzigen Zeitpunkt stabil läuft. Ich habe einfach so Reboots, kann den Fehler aktuell aber nicht fangen. Mal sehen ob ich noch was finde. Aber, es ist ein Anfang!
  • VON USB 4TB HD BOOTEN GEHT NICHT

    ROCKPro64 rockpro64
    5
    0 Stimmen
    5 Beiträge
    653 Aufrufe
    W
    Hallo FrankM, schade das Du mir nicht weiter helfen kannst, aber danke für Deine schnelle Antwort. Mit dem Bugreport kenne ich nicht aus, bin noch leihe. Einen schönen Abend noch. Winne
  • [HOWTO]ROCKPro64 - NAS bauen Teil 1

    Angeheftet ROCKPro64 howto rockpro64
    5
    5
    0 Stimmen
    5 Beiträge
    2k Aufrufe
    FrankMF
    Die Pinne für den Adapter liegen ja nur parallel zum Eingang des Steckers vom Netzteil. Also, solange da nichts abfackelt kann man da eine Menge Strom drüber jagen Wenn es funktioniert ist ja alles gut.
  • Ubuntu Bionic - Namen der Interfaces umstellen

    ROCKPro64 howto rockpro64
    1
    0 Stimmen
    1 Beiträge
    597 Aufrufe
    Niemand hat geantwortet
  • 0.6.59 released

    Verschoben Archiv rockpro64
    1
    0 Stimmen
    1 Beiträge
    569 Aufrufe
    Niemand hat geantwortet