2

This is a section of the log from u-boot running on 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 . . . 

I noticed that the following lines are coming twice:

SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB

This corresponds to the function spi_flash_probe from drivers/mtd/spi/spi_flash.c

I need to know:

1- Why it is probed twice?

2- The name and location of the file from where this function is called (twice).

3- The second time it is being probed it is considerably slow, why it is so?

These are my u-boot environmental variable;

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 

3 Answers 3

0

what is the configuration file name for your board in include/configs/ directory and where is your board specific file reside in board/ directory? I don't have rights to comments so i have to put query as answer. I doubt that spi flash driver initialization is done twice, once from arch/arm/lib/board.c and once from board specific file because of which you see SPI flash probed twice.

0

The first time is probably reading the environment from SPI. That uses the setting CONFIG_ENV_SPI_MAX_HZ.

The second time is booting, and this is running the sfboot line in your environment.

The first command is:

sf probe 0 

That uses the speed CONFIG_SF_DEFAULT_SPEED. Presumably this is slower.

You could update the environment command to read

sf probe 0 10000000 

(10MHz) which is faster. Or you could change CONFIG_SF_DEFAULT_SPEED.

See help sf for help.

0

Seems like, it's the result of resetting some important UBoot's env-var. Can you take two environment snapshots: immediately after first scan, and just before the second one?

I had the same problem with MTD rescan. The reason is mtdids variable, cleared in between. As for me, ubi_part(..) inquires the variable, and if unset, performs second MTD investigation. I suppose, you have the resembling problem.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.