Skip to content

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

Hardware
  • 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 !?!?!?

  • SATA Karte Marvell 88SE9230 Chipsatz mit 0.9.16

    Hardware
    8
    0 Stimmen
    8 Beiträge
    599 Aufrufe
    FrankMF

    Gestern hat Kamil einen neuen Kernel released, so das ich das heute mal auf dem NAS probiert habe. Durch den Boot von der USB-SSD sollten die Pfade ja alle passen und man problemlos den Kernel updaten können.

    root@rockpro64:/usr/local/sbin# df -h Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf udev 992M 0 992M 0% /dev tmpfs 199M 5,5M 194M 3% /run /dev/sdc7 459G 3,3G 437G 1% / tmpfs 995M 0 995M 0% /dev/shm tmpfs 5,0M 4,0K 5,0M 1% /run/lock tmpfs 995M 0 995M 0% /sys/fs/cgroup /dev/sdc6 112M 4,0K 112M 1% /boot/efi /dev/md0 3,6T 485G 3,0T 14% /mnt/nas tmpfs 199M 0 199M 0% /run/user/1000

    Gut, /boot liegt auf der USB-SSD. Also, wie bekannt, den Kernel heruntergeladen und installiert. Nach dem Neustart geht nix 😞 Mittels HDMI Monitor angeschlossen um den Fehler sehen zu können, da macht es auch schon Klick. Der Parameter

    pci=nomsi

    ist durch das Kernel-Update überschrieben worden. Ich hatte dann die USB-SSD ausgebaut und das Problem am lokalen Rechner gelöst. Aber, man ist ja faul.....;)

    Da es überschrieben wird, müssen auch irgendwo die Informationen dazu liegen.......

    /usr/local/sbin/update-extlinux.sh

    Da ist das File, was Kamil dafür angelegt hat.

    #!/bin/bash TIMEOUT="" DEFAULT="" APPEND="rw" APPEND="$APPEND panic=10" APPEND="$APPEND init=/sbin/init" APPEND="$APPEND coherent_pool=1M" APPEND="$APPEND ethaddr=\${ethaddr} eth1addr=\${eth1addr} serial=\${serial#}" APPEND="$APPEND cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 pci=nomsi" [..........gekürzt.........]

    Hier seht ihr das File schon mit meiner Änderung, in der Hoffnung das es dann beim nächsten Mal ohne Probleme funktioniert. Bleibt nur noch das Problem, wann ändert Kamil das File, weil dann ist die Änderung wieder weg!?!?

  • FTDI Support (ayufan Kernel 5.0)

    Ungelöst Probleme?
    8
    0 Stimmen
    8 Beiträge
    540 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

  • VON USB 4TB HD BOOTEN GEHT NICHT

    ROCKPro64
    5
    0 Stimmen
    5 Beiträge
    563 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

  • 0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF

    This repo contains the tn40xx Linux driver for 10Gbit NICs based on the TN4010 MAC from Tehuti Networks.

    This driver enables the following 10Gb SFP+ NICs:

    D-Link DXE-810S
    Edimax EN-9320SFP+
    StarTech PEX10000SFP
    Synology E10G15-F1
    ... as well as the following 10GBase-T/NBASE-T NICs:

    D-Link DXE-810T
    Edimax EN-9320TX-E
    EXSYS EX-6061-2
    Intellinet 507950
    StarTech ST10GSPEXNB

    Quelle: https://github.com/ayufan-rock64/tn40xx-driver/tree/master

  • ROCKPro64 - SD-Karte

    Hardware
    1
    0 Stimmen
    1 Beiträge
    520 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    1 Beiträge
    637 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    2 Beiträge
    2k Aufrufe
    FrankMF
    Ergänzung

    Eine andere SATA-Karte und eine Riser-Karte mit angeschlossener GPU startet nicht.

    rock64@rockpro64v2_1:~$ uname -a Linux rockpro64v2_1 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
  • u-boot-erase-spi-rockpro64.img.xz

    Verschoben Tools
    1
    0 Stimmen
    1 Beiträge
    877 Aufrufe
    Niemand hat geantwortet