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.
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!
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 !?!?!?