BeagleBone Black, booten von 16 GB SD-Karte geht manchmal nicht

[K. H. (hegy)]

Hello,

wir haben bzw. wollen diverse BeagleBone Black (BBB) mit einem Image von 
der SD-Karte booten und dabei soll noch Platz über sein für User-Daten, 
deswegen wurde beschlossen, dass ausschließlich 16GB SD-Karten zum 
Einsatz kommen. Das Problem ist jetzt etwas skurril, denn manchmal 
bootet das BBB nicht von der SD-Karte sondern vom eMMC. Woran liegt das? 
Ich habe die betreffenden Boot-Pins (LCD_DATA0...15) schon gecheckt, ob 
die bei dem 4er-Stack an Capes irgendwie einen Einfluss haben könnten 
aber die Eingänge sind nicht beschaltet. Nach bisherigen Erkenntnissen 
scheint es an der Betriebsspannung der SD-Karte zu liegen (SanDisk Ultra 
microSD HC I, Klasse 10). Einer aus unserem Team meinte, dass das 
womöglich daran liegt, dass beim booten bzw. im entscheidenen Moment die 
Spannung an der SD-Karte zu gering ist dass diese vom BBB dann nicht 
erkannt wird (Bootmelungen unten).

Wenn ich mit einen UART-USB-Konverter mir die Bootmeldungen ansehe, 
könnte das stimmen, es könnte aber auch schlichtweg ein Falschmeldung 
sein bzw. ein Bug in uBoot.

Die Bootmeldungen (nur der Anfang), wenn BBB von der SD-Karte bootet:

U-Boot SPL 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19)
bad magic

U-Boot 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19 -0600), Build: jenkins-github_Bootloader-Builder-274

       Watchdog enabled

I2C:   ready
DRAM:  512 MiB
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   <ethaddr> not set. Validating first E-fuse MAC
cpsw

Hit any key to stop autoboot:  1 
\0x08\0x08\0x08 0 
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK  
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1

Checking for: /uEnv.txt ...
1179 bytes read in 9 ms (127.9 KiB/s)
gpio: pin 55 (gpio 55) value is 1

Loaded environment from uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
[...]

Und wenn das BBB vom eMMC bootet sieht es so aus wie hier drunter. Der 
Anfang, der gleich ist mit oben habe ich weggelassen und den ersten 
Unterschied markiert:

Hit any key to stop autoboot:  1 
\0x08\0x08\0x08 0 
gpio: pin 53 (gpio 53) value is 1
Card did not respond to voltage select!   *Unterschiedlich*
Card did not respond to voltage select!   *Unterschiedlich*
gpio: pin 56 (gpio 56) value is 0   *Unterschiedlich*
gpio: pin 55 (gpio 55) value is 0   *Unterschiedlich*
gpio: pin 54 (gpio 54) value is 0   *Unterschiedlich*

switch to partitions #0, OK
mmc1(part 0) is current device   *Unterschiedlich*.....

gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
gpio: pin 55 (gpio 55) value is 1
1800 bytes read in 15 ms (117.2 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
gpio: pin 56 (gpio 56) value is 1
Running uname_boot ...
loading /boot/vmlinuz-3.8.13-bone79 ...
[...]

Ich frage mich, was ist mmc0 und was ist mmc1? Lt. den Bootmeldungen ist 
mmc0 = SD-Karte und mmc1 = eMMC, andersherum wäre es logischer, finde 
ich.

Und was sind die Pins GPIO 53, 54, 55 und 56? Vermutlich die, die die 
Bootquelle festlegen, also irgendwo im Bereich LCD_DATA0 bis LCD_DATA15.

Könnte es helfen, wenn man an der Taktfrequenz der SD-Karte 
(SYSBOOT[15:14]) am BBB "schraubt"?

Das Bootimage kommt übrigens später mal ins eMMC aber selbst wenn das 
jetzt schon der Fall wäre und BBB hätte nicht von der SD-Karte gebootet, 
dann wäre auch nach dem booten die SD-Karte nicht sichtbar = nicht 
gemounted und das sollte auch nicht sein.

[Jim M. (turboj)]

K. H. schrieb:
> Das Bootimage kommt übrigens später mal ins eMMC aber selbst wenn das
> jetzt schon der Fall wäre und BBB hätte nicht von der SD-Karte gebootet,
> dann wäre auch nach dem booten die SD-Karte nicht sichtbar = nicht
> gemounted und das sollte auch nicht sein.

Ein Trugschuss. Dem Linux Kernel muss man sagen wo sein Root device ist,
und dann lädt er den Rest auch nur von da. Das bedeutet dass Du die SD 
Karte selbst dann benutzen kannst, wenn Kernel und InitRD vom EMMC 
geladen werden.

> Ich frage mich, was ist mmc0 und was ist mmc1?

Eins ist die interne EMMC, eins ist die SD Karte. SD ist zum alten MMC 
Standard abwärtskompatibel (jedenfalls bis 1G) deswegen hat man hier MMC 
als interne Busbezeichnung gewählt.

K. H. schrieb:
> Lt. den Bootmeldungen ist
> mmc0 = SD-Karte und mmc1 = eMMC, andersherum wäre es logischer, finde
> ich.

Die Hardware sagt: mmc0 =  SD, und der würde ich erstmal glauben.

Eventuell war so herum das Layouten leichter, SD hat weniger 
Datenleitungen als eMMC.

[K. H. (hegy)]

Jim M. schrieb:
> Ein Trugschuss. Dem Linux Kernel muss man sagen wo sein Root device ist,
> und dann lädt er den Rest auch nur von da. Das bedeutet dass Du die SD
> Karte selbst dann benutzen kannst, wenn Kernel und InitRD vom EMMC
> geladen werden.

Das ist richtig, aber wenn nach dem Booten nach allen verfügbaren bzw. 
mountbaren Geräten gesucht wird, ist die SD-Karte nicht dabei. Vllt. 
gibt es eine Möglichkeit dass die später doch noch verfügbar ist bspw. 
Module entladen und wieder neu laden.

***

Bzgl. des Problems bin ich mittlerweile der Auffassung, dass das ein 
Design-Problem vom BeagleBone ist bzw. vom gesamten Aufbau. Der Aufbau 
des BeagleBone-Stack ist so von oben gesehen (Bildchen oben):
(1) BBB
(2) darunter ein selfmade Cape, sind nur ein paar Stecker drauf
(3) wieder ein selfmade Cape mit Stecker (CAN, 5V)
(4) wieder eins mit Stecker (24V), DCDC Konverter (5V), RTC und LEDs
(5) wie (4) nur ohne RTC und DCDC Konverter (nicht bestückt)

Die Versorgungsspannung des BBB geschieht über (4) mit 24V. Der 
DCDC-Konverter macht da die 5V raus (bei 0,5A Last ca. 4,8V). Über die 
Steckerleiste P9, Pin 5 und 6 geht es über den Stack nach oben und das 
ist auf dem BBB der Spannungseingang +5V, liegt auch parallel an der +5V 
Buchse am BBB. Damit kommen die +5V vor das PowerManagement (TPS65217C) 
rein, also richtig soweit. Aber hier scheint es ein Problem zu geben. 
Wenn man auf (2) ein paar Stecker reinsteckt (mehr als 3 von 6 
möglichen) kommt es zu den Bootproblemen auf den BBB. Ich vermute, weil 
an diesen Steckern STM32F2xx und STM32F072-Boards hängen, dass es auf 
der +5V Schiene zu erheblichen Störungen kommt und diese in den BBB 
kommen, was dann eben zu solchen "ausrastern" führt.
Aber einige andere Pins haben scheinbar einen Einfluss auf das BBB, 
nicht nur die fürs booten zuständigen Pins LCD_DATA0...15.