Skip to content

Booten via eMMC nicht möglich

Ungelöst Probleme?
  • Ich habe mehrere ROCKPRO64 mit eMMC laufen nur ein Board bootet mit eMMC nicht (mehr).

    Folgender Status:

    • Ich habe auf alle eMMC das aktuelle Ubuntu Minimal Image via Etcher geschrieben (Habe einen USB to eMMC Adapter). Die eMMC's funktionieren einwandfrei (Getestet via austausch der eMMC zwischen den Boards)
    • Die rote und weiße LED an meinem Problemboard leuchten nach dem start via eMMC nicht auf.
    • Testhalber das image auf SD karte gespielt: Mein Problemboard bootet tadellos (rote & weiße LED gehen an / SSH Zugang möglich)
    • Nach dem booten via SD Karte kann ich sehen (fdisk) das die eMMC auch gefunden wird - es ist also kein Hardwareproblem

    Ich habe keine Ahnung was dieses Problem verursacht hat. Die Boards laufen als Cluster - sind also komplett identisch konfiguriert. Durch die oben aufgeführten Versuche gehe ich davon aus das der Bootloader nicht (mehr) korrekt funktioniert. Hat jemand eine Idee wie ich den Bootloader wieder reparieren kann?
    Ich habe schon im Pine Forum gefragt aber es scheint mir so als ob die Entwickler sich dort nicht herumtreiben 😞

  • hi,

    ich habe hier gerade auch 5 rockpros laufen und einer hatte auch zicken
    gemacht.

    sofern du das serielle uart interface hast - hilft das ungemein, hier in den bootvorgang rein zu schauen ..

    sofern du dir den uboot / spi "zerschossen" hast, kannst du :

    versuchen dir diesen zu löschen.

    There is a second possibility to jumper your ROCKPro64: If you mess-up your SPI and are unable to boot, jumpering pins 23 (CLK) and 25 pin (GND) on the PI-2-bus header will disable the SPI as a boot device. (This was taken from the IRC logs, 09 August 2018 @ 17:23) You have to remove the jumper 2 seconds after having started your RP64 (before the white LED turns ON) otherwise the SPI will be missing and you won't be able to flash it. Ayudan images contain (at the moment) only one script for the SPI and the RP64, it's "rockpro64_reset_spi_flash". Other SPI scripts are dedicated to the R64 (as it is written on the name) and it will mess-up your RP64 SPI if you use them.

    Eine genaue Ablauffolge hatte ich nicht, aber irgendwann war bei mir wieder ein sauberer spi / uboot aktiv und die beiden leds haben dann auch wieder geleuchtet ...

    Dazwischen hatte ich auch mal ein Armbian :

    und dort den spi boot schreibvorgang (mit dem armbian tool) ausgelöst .. ob dieser die lösung war .. kann ich auch nicht mehr nachvollziehen 🙂

    vielleicht hilft etwas von diesen tipps

  • ich bin mir nicht sicher ob mein SPI wirklich hin ist. Immerhin kann ich via SD Karte booten. Werde denoch den rest versuchen. Wie funktioniert das genau? u-boot-flash-spi-rockpro64.img.xz auf die SD, Pins kurzschließen und dann warten?
    Oder normal es image auf SD und das Skript ausführen (davor Pins kurzschließen?)?

  • Vielleicht liegst am Wetter, aber so richtig kann ich nicht folgen. Ich fasse mal was zusammen.

    • Ein Board bootet nicht vom eMMC
    • Alle RP64 sind gleich?

    Was passiert wenn man ein funktionierendes eMMC in den nicht startenden RP64 steckt?

    Das u-boot-flash-spi-rockpro64.img.xz brauchst du nur, wenn du den SPI mit dem uboot beschreiben möchtest. Dann sucht dieser nach einem Image aus dem Netz (PXE-Boot), oder einem bootbaren Gerät am USB-Port.

    Die Brücke braucht man, wenn man ein eMMC-Modul verbaut hat und mal eben eine SD-Karte booten möchte ohne das eMMC-Modul zu entnehmen. So weit ich mich erinnern kann.

    Serielle Konsole ist bei solchen Fehlern Pflicht. Dann könnte man wenigstens sehen worüber er stolpert.

  • @FrankM sagte in Booten via eMMC nicht möglich:

    Ein Board bootet nicht vom eMMC :fa-check:
    Alle RP64 sind gleich? :fa-check:

    Was passiert wenn man ein funktionierendes eMMC in den nicht startenden RP64 steckt?

    Die power und reset Lampe fangen nicht an zu leuchten und das system ist nicht über ssh zu erreichen. Daraus schlussfolgere ich, dass das Board mit dem eMMC nicht bootet.

  • Ja, die Schlussfolgerung ist korrekt. Aber, wenn das eMMC-Modul in einem anderen RP64 funktioniert und in diesem RP64 nicht bootet, sieht das für mich eher nach einem Hardwaredefekt aus.

  • ich hatte den bootvorgang von unseren rockpro64s so verstanden:

    ROM
    SPI
    U-Boot
    Kernel

    ROM entfällt, da das / sein System ja mit SD Karte bootet und die CPU / die Hardware also
    initialisiert und getaktet wird

    SPI .. hier scheint eventuell der Bock zu sein .. deswegen ... erase SPI ..

    @frank .. der spi disable ist anderst zu brücken als der emmc disable:

    um den emmc zu deaktiveren (ist neben dem emmc) und ich meinte am PI-2 BUS .. dort die pins 23 u 25 mit nem jumper käbelchen brücken... disable spi ..

    Steht alles in der Rockpro Wiki :

    You have to remove the jumper 2 seconds after having started your RP64 (before the white LED turns ON) otherwise the SPI will be missing and you won't

    u-boot-erase-spi-rockpro64.img.xz

    Ja, das spi-erase flash mit etcher auf eine SD karte und dann den boot vorgang abwarten ..
    1-2 Minuten .. bis die weiße led blinkt .. aber dann noch ein wenig warten ..

    ein fehler es zu machen ist es ja nicht .. und kaputt geht dadurch auch nichts (normalerweise 🙂 ) .. wie gesagt .. ich hatte mal einen ähnlichen fall .. und da hatte dieses resetten funktioniert ..

    Und danach ein Armbian Image eingespielt und den SPI boot / copy initialisiert .. Danach lief dieses System (welches auch nicht von einem emmc modul booten wollte - welches in einem anderen rockpro64 funktionierte ) problemlos ... mein rockpro64 Nr. 3 .. der gerade videos konvertiert 😉

    ein hardware fehler bleibt als letztes "mittel" ja noch über ..

    die für den rock passende serielle usb schnittstelle kostet glaub ich .. 8 Euro .. (bei meinem rockpro dealer aus worms ..)

  • @webstudio sagte in Booten via eMMC nicht möglich:

    SPI boot / copy initialisiert

    Den teil habe ich noch nicht ganz verstanden. Erase SPI werde ich gleich einmal ausprobieren.

    Update:
    Habe eben die PINs kurzgeschloßen und das erase SPI image laufen lassen bis die LED geblinkt hat. Danach eMMC eingelegt - bootvorgang funktioniert noch immer nicht.

  • @jwillmer

    und jetzt .. um in meinem (damaligen) reparatur weg zu bleiben:

    dort ein image deiner wahl auf sd "brennen" und
    dann nach dem booten:

    sudo armbian-config (in der shell) eingeben ..

    (das ist ein wirklich super tool von armbian, das ich bei unseren ayufan images wirklich sehr vermisse) ...

    -> dort unter install das image auf emmc kopieren und spi boot initieren (genaue betitelung fällt mir gerade nicht ein .. aber du siehst was ich meine)

    ... wenn das danach immer noch nicht bootet .. das problemboard .. dann gebe ich mich der technik geschlagen ...

  • Der output meiner seriellen Konsole. Hilft euch das?

    U-Boot 2017.09-rockchip-ayufan-1063-g29843fbd42 (Jul 08 2019 - 11:55:49 +0000)
    
    Model: Pine64 RockPro64
    DRAM:  3.9 GiB
    DCDC_REG1@vdd_center: ; enabling
    DCDC_REG2@vdd_cpu_l: ; enabling
    DCDC_REG3@vcc_ddr: ; enabling (ret: -38)
    DCDC_REG4@vcc_1v8: set 1800000 uV; enabling
    LDO_REG1@vcc1v8_dvp: set 1800000 uV; enabling
    LDO_REG2@vcc3v0_touch: set 3000000 uV; enabling
    LDO_REG3@vcc1v8_pmu: set 1800000 uV; enabling
    LDO_REG4@vcc_sd: set 3300000 uV; enabling
    LDO_REG5@vcca3v0_codec: set 3000000 uV; enabling
    LDO_REG6@vcc_1v5: set 1500000 uV; enabling
    LDO_REG7@vcca1v8_codec: set 1800000 uV; enabling
    LDO_REG8@vcc_3v0: set 3000000 uV; enabling
    SWITCH_REG1@vcc3v3_s3: ; enabling (ret: -38)
    SWITCH_REG2@vcc3v3_s0: ; enabling (ret: -38)
    vcc1v8-s0@vcc1v8_s0: set 1800000 uV; enabling (ret: -38)
    dc-12v@dc_12v: set 12000000 uV; enabling (ret: -38)
    vcc-sys@vcc_sys: set 5000000 uV; enabling (ret: -38)
    vcc3v3-sys@vcc3v3_sys: set 3300000 uV; enabling (ret: -38)
    vcc-phy-regulator@vcc_phy: ; enabling (ret: -38)
    vdd-log@vdd_log: ; enabling (ret: -38)
    MMC:   sdhci@fe330000: 0, dwmmc@fe320000: 1
    SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
    *** Warning - bad CRC, using default environment
    
    In:    serial@ff1a0000
    Out:   serial@ff1a0000
    Err:   serial@ff1a0000
    Model: Pine64 RockPro64
    Net:   eth0: ethernet@fe300000
    Hit any key to stop autoboot:  0
    sdhci_transfer_data: Error detected in status(0x208000)!
    mmc_init: -110, time 179
    Card did not respond to voltage select!
    mmc_init: -95, time 10
    starting USB...
    ...
    ..
    
  • Sieht für mich nach einem Hardwaredefekt des eMMC-Slots aus. Da das eMMC-Modul ja in den anderen RP64 läuft, kann es eigentlich nichts anderes sein. Jemand anderer Meinung? 😉

  • hm,
    dem steht -ein wenig- dagegen, dass

    "Nach dem booten via SD Karte kann ich sehen (fdisk) das die eMMC auch gefunden wird - es ist also kein Hardwareproblem"

  • Kannst du auf diese auch zugreifen? Auch größere Dateien?

  • ich bin weiterhin der meinung dass er kein spi / u-boot im system hat
    und "warte" quasi auf die meldung ..

    ja ich habe das arbmian runtergeladen und die emmc installation / spi initialisierung / boot umstellung ausgeführt ..

    (Hinweis: Zur Installation: nicht das armbian auf die emmc per usb adapter "brennen" sondern auf sd karte und mit beiden booten und danach per armbian-config auf emmc installieren)

    wenn es danach nicht funktioniert .. dann .. ja dann .. hmm ...

  • @webstudio

    ja ich habe das arbmian runtergeladen und die emmc installation / spi initialisierung / boot umstellung ausgeführt ..

    • Armbian installiert und gebootet
    • Armbian config geöffnet
    • System auf eMMC kopiert via Armbian:
    • “Install” “Install to/update boot loader” -> Install/Update the bootloader on SD/eMMC

    Gleiches verhalten danach. eMMC wird nicht gebootet 😞

  • Okay .. also .. zusammengefasst:

    • Booten von emmc geht nicht (auch nicht armbian)

    • booten von spi geht / geht nicht ? .. bzw. siehst du in der seriellen ob er PXE boot initiert ?
      (sofern du ein ayufan spi tool eingespielt hat (dies war oben über die spi-flash bzw. spi-erase tools angedacht)

    • booten von sd karte geht und die emmc ist sichtbar ...

    ich gehe mal davon aus, dass der jumper neben der emmc nicht gesetzt ist .. weil der ist für das (globale) abschalten der emmc zuständig .. (dann wäre die emmc aber auch nicht nach dem booten sichtbar ...)

    Latein am Ende .. ggf. noch booten über usb 2 testen .. (usb 3 - geht nicht bzw. nicht mit jedem device, bzw. nicht stabil ...) deswegen .. usb 2 ..

    ist es eine 2.0 oder 2.1 edition ? bei der 2.0 .. gab es etwas wegen der PCIe timing .. widerstand entfernen ..oder so ..)

    Bootorder ist lt. meinem wissen (fyi)

    SPI Flash -> eMMC -> SD -> USB ..

    sofern noch garantie .. ggf. zum händler tauschen schicken .. der aufwand fürs testen überschreitet auch alle "wirtschaftlichen" kosten 🙂

    Alternativ .. die emmc als root laufwerk ummappen (anleitung hier im forum) und von einer billig sd karte booten. problem beim kernel update bzw. muss dann manuell nachgeholt werden.

    oder .. pxe booten einrichten .. sofern der spi boot dir ein pxe boot anzeigt ..

    zu dem spi booten info / ablauf hier noch ein link !! achtung diese ist für den ROCK64 !! also nicht diese images nehmen .. sondern die vom oberen link:

    https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md

    Latein ende 😞

  • RockPro64 bootet nicht mehr von sdcard und/oder emmc

    Ungelöst Probleme?
    6
    0 Stimmen
    6 Beiträge
    205 Aufrufe
    FrankMF

    @gabs5807 Danke für das ausführliche Feedback.

    Das mit Pin 10 habe ich schon lange nicht mehr gehabt, benutze aber auch nur noch selten den SPI.

    Was wäre es doch für ein Traum, wenn man einen vernünftigen uboot hätte und man einfach ein Device anhängen könnte und die Kiste davon bootet...

    Bin aber beim ROCKPro64 auch nicht mehr auf der Höhe der Zeit, ich teste da nur noch selten.

  • RockPro64 als Backup Server

    Ungelöst Probleme?
    5
    1 Stimmen
    5 Beiträge
    307 Aufrufe
    T

    @mabs sagte in RockPro64 als Backup Server:

    Ich versteh nicht wie der PCI-E<=>NVMe Adapter im Odroid H2+ laufen soll

    Er sprach vom JMB585 im M.2-Format. 2 x SATA vom Intel-SoC plus 5 vom JMB585 macht dann 7 SATA-Anschlüsse. Der JMB585 im H2+ ist natürlich auch ausgebremst, weil Intels Gemini Lake (Refresh) auch nur PCIe Gen2 kann und so die 5 SATA-Ports des JMB585 nur hinter zwei Gen2 Lanes hängen.

  • Installationsprobleme wegen unkenntnis

    Ungelöst Probleme?
    7
    0 Stimmen
    7 Beiträge
    220 Aufrufe
    C

    @frankm
    Hallo Frank,
    ich habe mir das was ich habe mal so angeschaut und festgestellt das ich einen Avira AV Blocker aufgespielt habe von daher denke ich ich lass das Gesummse mit VPN . Hat der Anbieter 58 € Gewinn gemacht ohne Leistung , auch nicht schlecht.
    Meinen herzlichsten Dank für Deine Mühe , ist ernst gemeint !
    Der alte Mann mit dem Rocker Rollstuhl
    Uli

  • 1 Stimmen
    7 Beiträge
    727 Aufrufe
    FrankMF

    Freut mich, das es jetzt so problemlos klappt. Das ist echt immer ein Problem mit Linux und Hardware. Es ist zwar besser geworden aber noch nicht optimal. Und auf den kleinen Platinen ist das auch noch eine ganz andere Sache.

    Ich kann die auch heute noch immer wieder empfehlen. Läuft und läuft....

    root@NASrp64:~# uptime 18:58:29 up 66 days, 2:54, 1 user, load average: 0,00, 0,00, 0,00

    Mein NAS läuft 24/7

    Viel Spaß damit!

  • hdparm / SATA Platten spindown und Energiemanagement

    Gelöst Probleme?
    4
    0 Stimmen
    4 Beiträge
    328 Aufrufe
    FrankMF

    Sorry, das Wissen hatte ich vorausgesetzt. Aber schön, das es funktioniert.

    Dann viel Spaß mit deinem NAS 👍

  • Bluetooth Dongle funktioniert unter Armbian nicht

    Verschoben Ungelöst Probleme?
    11
    0 Stimmen
    11 Beiträge
    577 Aufrufe
    FrankMF

    Ich habe immer noch nicht verstanden, welche Kernelmodule jetzt fehlen. Aber ich habe mich mal kurz in Pivccu eingelesen. Das lässt einen LXC Container laufen - gut.

    Ob Armbian an einem Kernel 4.14 arbeitet, weiß ich nicht. Ich habe aber irgendwo gelesen, das man sich mehr auf den Mainline konzentrieren wird!?? Dann wird das wohl nichts. Den selber bauen, wird wohl nur was für Profis sein. Ich habe das schon mal gemacht, ist aber ein extrem komplexes Thema. Erschließt sich mir bis heute nicht 😉

    Wenn nur ein Kernelmodul fehlt, das kann man selber bauen. Oder Kamil kurz mal eine Frage zukommen lassen, dann ist das vermutlich im nächsten Update mit drin.

  • EMMC: boot stuck after reboot

    Ungelöst Probleme?
    5
    0 Stimmen
    5 Beiträge
    534 Aufrufe
    F

    Du liegst vollkommen richtig. Es liegt am RemoteMount, welchen ich über OMV eingebunden habe. Evtl. habe ich da aber auch etwas falsch konfiguriert. Denke nicht, dass es an OMV liegt.
    Ohne diesen geht der headless Boot problemlos.

    Mittlerweile kann ich deine Ansichten bzgl WebUi usw. durchaus nachvollziehen. Per Hand lernt man auch noch dazu.
    Wegen der UART Konsole habe ich Deine Erfahrungen in einem anderen Thread entdeckt. Danke dafür. Werde ich mir bei Gelegenheit näher anschauen.

  • CineS2 am PCIe wird nicht erkannt

    Ungelöst Probleme?
    13
    1 Stimmen
    13 Beiträge
    1k Aufrufe
    K

    heho,
    das kann ich bestätigen: kein gerät eingesteckt, keine bridge sichtbar im lspci.

    die kernelmodule (pcie_rockchip_host, nvme_core, nvme) werden anscheinend aber schon geladen, also irgendwer ist anscheinend da. mir ist noch unklar wie man heraus kriegt, wer das sein könnte. Geholfen hat setpci da auch nicht bislang

    hab aus spaß mal eine karte gesteckt die nicht geht (also issue https://github.com/rockchip-linux/kernel/issues/116, zufällig genau die im letzten kommentar)

    da streikt denn alles:

    lspci -vvvxxx pcilib: Cannot open /sys/bus/pci/devices/0000:00:00.0/config lspci: Unable to read the standard configuration space header of device 0000:00:00.0

    mein sys:

    Linux 4.20.0-gentoo #20 SMP PREEMPT Sun Jan 20 15:42:02 CET 2019 aarch64 GNU/Linux

    gruß