Dies ist ein Ausschnitt aus dem Logbuch vonu-bootläuft auf Avnet Microzed-Board -ARM CORTEX A9:
[Thu Jun 26 17:40:53.656 2014]
[Thu Jun 26 17:40:53.656 2014]
[Thu Jun 26 17:40:53.656 2014] U-Boot 2013.07 (Jun 26 2014 - 17:34:41)
[Thu Jun 26 17:40:53.656 2014]
[Thu Jun 26 17:40:53.656 2014] 1 GiB
[Thu Jun 26 17:40:53.671 2014] SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB
[Thu Jun 26 17:40:53.703 2014] *** Warning - bad CRC, using default environment
[Thu Jun 26 17:40:53.703 2014]
[Thu Jun 26 17:40:53.703 2014] In: serial
[Thu Jun 26 17:40:53.703 2014] Out: serial
[Thu Jun 26 17:40:53.703 2014] Err: serial
[Thu Jun 26 17:40:53.703 2014] U-BOOT for ab
[Thu Jun 26 17:40:53.703 2014]
[Thu Jun 26 17:40:53.703 2014]
[Thu Jun 26 17:40:53.703 2014] SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB
[Thu Jun 26 17:40:54.453 2014] SF: 5242880 bytes @ 0x520000 Read: OK
[Thu Jun 26 17:40:54.453 2014] Description: PetaLinux Kernel
[Thu Jun 26 17:40:54.453 2014] 0x010000f0
[Thu Jun 26 17:40:54.453 2014] 4620145 Bytes = 4.4 MiB
[Thu Jun 26 17:40:54.453 2014] Description: Flattened Device Tree blob
[Thu Jun 26 17:40:54.453 2014] 0x01468114
[Thu Jun 26 17:40:54.453 2014] 9766 Bytes = 9.5 KiB
[Thu Jun 26 17:40:54.453 2014] Hash algo: crc32
[Thu Jun 26 17:40:54.453 2014] Hash value: 9a94aca8
[Thu Jun 26 17:40:54.453 2014] Hash algo: sha1
[Thu Jun 26 17:40:54.453 2014] Hash value:
97b81e3014decb706ff19e61e1227dace97d4232
[Thu Jun 26 17:40:54.453 2014] crc32+ sha1+ Uncompressing Kernel Image ... OK
.
.
.
Mir ist aufgefallen, dass folgende Zeilen zweimal vorkommen:
SF: S25FL129P_64K/S25FL128S_64K mit Seitengröße 64 KiB erkannt, insgesamt 16 MiB
Dies entspricht der Funktionspi_flash_probeaus drivers/mtd/spi/spi_flash.c
Ich muss wissen:
1- Warum wird zweimal geprüft?
2- Der Name und der Speicherort der Datei, von der aus diese Funktion aufgerufen wird (zweimal).
3- Beim zweiten Test ist es erheblich langsamer. Warum ist das so?
Dies sind meine U-Boot-Umgebungsvariablen;
U-Boot-PetaLinux> printenv
autoload=no
baudrate=115200
bootdelay=4
bootenvsize=0x00020000
bootenvstart=0x00500000
bootfile=image.ub
bootsize=0x00500000
bootstart=0x00000000
clobstart=0x1000000
console=console=ttyPS0,115200
cp_dtb2ram=sf probe 0; sf read ${clobstart} ${dtbstart} ${dtbsize}
dtbboot=sf probe 0; sf read ${netstart} ${kernstart} ${kernsize}; sf read ${dtbnetstart} ${dtbstart} ${dtbsize}; bootm ${netstart} - ${dtbnetstart}
dtbnetboot=tftp ${netstart} image.ub; tftp ${dtbnetstart} system.dtb; bootm ${netstart} - ${dtbnetstart}
dtbnetstart=0x1500000
eraseconf=sf probe 0; sf erase ${confstart} ${confsize}
eraseenv=sf probe 0; sf erase ${bootenvstart} ${bootenvsize}
ethact=Gem.e000b000
ethaddr=00:0a:35:00:07:c0
fault=echo $img image size is greater than allocated place - $img is NOT UPDATED
get_dtb=run cp_dtb2ram; fdt addr ${clobstart}
hostname="Peta_MicroZed"
install_dtb=sf probe 0; sf erase ${dtbstart} ${dtbsize};sf write ${clobstart} ${dtbstart} ${filesize}
install_jffs2=sf probe 0; sf erase ${jffs2start} ${jffs2size};sf write ${clobstart} ${jffs2start} ${filesize}
install_kernel=sf probe 0; sf erase ${kernstart} ${kernsize};sf write ${fileaddr} ${kernstart} ${filesize}
install_uboot=sf probe 0; sf erase ${bootstart} ${bootsize};sf write ${clobstart} ${bootstart} ${filesize}
kernsize=0x00500000
kernstart=0x00520000
load_boot=tftp ${clobstart} BOOT.BIN
load_dtb=tftp ${clobstart} system.dtb
load_jffs2=tftp ${clobstart} rootfs.jffs2
load_kernel=tftp ${clobstart} image.ub
loadaddr=0x1000000
mtdids=nor0=0
mtdparts=mtdparts=0:5M(boot),128K(bootenv),851968(image)
nc=setenv stdout nc;setenv stdin nc;
ncip=192.168.1.11
netboot=tftp ${netstart} image.ub && bootm
netstart=0x1000000
psserial0=setenv stdout ttyPS0;setenv stdin ttyPS0
sd_update_boot=echo Updating BOOT from SD;mmcinfo && fatload mmc 0:1 ${clobstart} BOOT.BIN && run install_uboot
sd_update_kernel=echo Updating Kernel from SD;mmcinfo && fatload mmc 0:1 ${clobstart} ${bootfile}&& set fileaddr ${clobstart}&&run install_kernel
sdboot=echo boot Petalinux; mmcinfo && fatload mmc 0 ${netstart} ${bootfile}&& bootm
serial=setenv stdout serial;setenv stdin serial
serverip=192.168.1.11
sfboot=sf probe 0; sf read ${netstart} ${kernstart} ${kernsize}; bootm ${netstart}
silent=1
silent-kinux=yes
silent_linux=yes
test_crc=if imi ${clobstart}; then run test_img; else echo $img Bad CRC - $img is NOT UPDATED; fi
test_img=setenv var "if test ${filesize} -gt ${psize}; then run fault; else run ${installcmd}; fi"; run var; setenv var
update_boot=setenv img BOOT.BIN; setenv psize ${bootsize}; setenv installcmd install_uboot; run load_boot test_img; setenv img; setenv psize; setenv installcmd
update_dtb=setenv img DTB; setenv psize ${dtbsize}; setenv installcmd install_dtb; run load_dtb test_img; setenv img
update_jffs2=setenv img JFFS2; setenv psize ${jffs2size}; setenv installcmd install_jffs2; run load_jffs2 test_img; setenv img; setenv psize; setenv installcmd
update_kernel=setenv img KERNEL; setenv psize ${kernsize}; setenv installcmd "install_kernel"; run load_kernel test_crc; setenv img; setenv psize; setenv installcmd
varify=n
Environment size: 3214/131068 bytes
Antwort1
Wie lautet der Name der Konfigurationsdatei für Ihr Board im include/configs/Verzeichnis und wo befindet sich Ihre boardspezifische Datei im board/Verzeichnis? Ich habe keine Rechte zum Kommentieren, daher muss ich die Abfrage als Antwort eingeben. Ich bezweifle, dass die Initialisierung des SPI-Flash-Treibers zweimal erfolgt, einmal von arch/arm/lib/board.cund einmal von einer boardspezifischen Datei, weshalb Sie sehen, dass der SPI-Flash zweimal geprüft wird.
Antwort2
Beim ersten Mal wird wahrscheinlich die Umgebung von SPI gelesen. Dabei wird die Einstellung verwendet CONFIG_ENV_SPI_MAX_HZ.
Beim zweiten Mal wird gebootet und dabei wird die Zeile sfboot in Ihrer Umgebung ausgeführt.
Der erste Befehl lautet:
sf probe 0
Das nutzt die Geschwindigkeit CONFIG_SF_DEFAULT_SPEED. Vermutlich ist das langsamer.
Sie können den Umgebungsbefehl aktualisieren, um zu lesen
sf probe 0 10000000
(10 MHz), was schneller ist. Oder Sie könnten ändern CONFIG_SF_DEFAULT_SPEED.
help sfHilfe finden Sie unter.
Antwort3
Scheint so, als wäre es das Ergebnis des Zurücksetzens einiger wichtiger UBoot-Umgebungsvariablen. Können Sie zwei Umgebungs-Snapshots erstellen: unmittelbar nach dem ersten Scan und unmittelbar vor dem zweiten?
Ich hatte das gleiche Problem mit MTD Rescan. Der Grund istAbonnierenVariable, zwischendurch gelöscht. Was mich betrifft,ubi_part(..)fragt die Variable ab und führt, wenn sie nicht gesetzt ist, eine zweite MTD-Untersuchung durch. Ich vermute, Sie haben ein ähnliches Problem.