Answering my own question (with some help from IRC): It turns out it will be needed to issue "sf probe" to initialize SPI Flash subsystem. This is not a problem... if you know you need it.
Is there a reason (that I cannot, at moment, see) or would be better to call `spi_flash_probe_bus_cs(CONFIG_SF_DEFAULT_BUS, CONFIG_SF_DEFAULT_CS, CONFIG_SF_DEFAULT_SPEED, CONFIG_SF_DEFAULT_MODE, &dev);` behind the scenes if user tries to access MTD? Should I submit a patch for this? TiA Mauro On 1/4/20 2:19 AM, Mauro Condarelli wrote: > Hi, > I'm facing a strange problem that took quite a while to analyze. > > I'm porting U-Boot to a new board and thus some problem is expected. > I am also trying to configure U-Boot in a useful (for my purposes) way. > > I decided to switch Environment storage from SPI NOR to SD card (in a > file in FAT partition. > > Before switch I had both SPI NOR (MTD) and MMC working. > >> U-Boot 2020.01-rc5-00074-g57fe7de5a3-dirty (Jan 04 2020 - 01:38:21 +0100) >> >> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >> Model: VoCore2 >> DRAM: 128 MiB >> MMC: mmc@10130000: 0 >> Loading Environment from SPI Flash... SF: Detected gd25q128 with page >> size 256 Bytes, erase size 4 KiB, total 16 MiB >> OK >> In: uart2@e00 >> Out: uart2@e00 >> Err: uart2@e00 >> Model: VoCore2 >> => mtd list >> List of MTD devices: >> * nor0 >> - type: NOR flash >> - block size: 0x1000 bytes >> - min I/O: 0x1 bytes >> - 0x000000000000-0x000001000000 : "nor0" >> - 0x000000000000-0x000000050000 : "u-boot" >> - 0x000000050000-0x000000300000 : "kernel" >> - 0x000000300000-0x000000ffe000 : "squash" >> - 0x000000ffe000-0x000000fff000 : "env" >> - 0x000000fff000-0x000001000000 : "factory" >> => mmc part >> >> Partition Map for MMC device 0 -- Partition Type: DOS >> >> Part Start Sector Num Sectors UUID Type >> 1 2048 262144 f31c8249-01 0c >> 2 264192 4194304 f31c8249-02 83 >> 3 4458496 327680 f31c8249-03 83 >> 4 4786176 10737664 f31c8249-04 05 Extd >> 5 4788224 2097152 f31c8249-05 83 >> 6 6887424 2097152 f31c8249-06 83 >> => > I made a minimal change in configuration: > >> mcon@cinderella:/tmp/u-boot$ git diff >> diff --git a/configs/vocore_vocore2_defconfig >> b/configs/vocore_vocore2_defconfig >> index ad1b580431..ece98beea0 100644 >> --- a/configs/vocore_vocore2_defconfig >> +++ b/configs/vocore_vocore2_defconfig >> @@ -1,8 +1,6 @@ >> CONFIG_MIPS=y >> CONFIG_SYS_TEXT_BASE=0x80010000 >> CONFIG_ENV_SIZE=0x00001000 >> -CONFIG_ENV_OFFSET=0x00FFE000 >> -CONFIG_ENV_SECT_SIZE=0x00001000 >> CONFIG_ARCH_MTMIPS=y >> CONFIG_BOARD_VOCORE2=y >> CONFIG_MIPS_BOOT_FDT=y >> @@ -37,8 +35,9 @@ CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" >> >> CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)" >> # CONFIG_ISO_PARTITION is not set >> CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2" >> -CONFIG_ENV_IS_IN_SPI_FLASH=y >> -CONFIG_ENV_ADDR=0x00FFE000 >> +CONFIG_ENV_IS_IN_FAT=y >> +CONFIG_ENV_FAT_INTERFACE="mmc" >> +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" >> # CONFIG_NET is not set >> # CONFIG_DM_DEVICE_REMOVE is not set >> CONFIG_BLK=y >> mcon@cinderella:/tmp/u-boot$ > ... but it seems very destructive for spi: >> U-Boot 2020.01-rc5-00074-g0cac9383d7-dirty (Jan 04 2020 - 01:55:34 +0100) >> >> CPU: MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr) >> Model: VoCore2 >> DRAM: 128 MiB >> MMC: mmc@10130000: 0 >> Loading Environment from FAT... OK >> In: uart2@e00 >> Out: uart2@e00 >> Err: uart2@e00 >> Model: VoCore2 >> => mmc part >> >> Partition Map for MMC device 0 -- Partition Type: DOS >> >> Part Start Sector Num Sectors UUID Type >> 1 2048 262144 f31c8249-01 0c >> 2 264192 4194304 f31c8249-02 83 >> 3 4458496 327680 f31c8249-03 83 >> 4 4786176 10737664 f31c8249-04 05 Extd >> 5 4788224 2097152 f31c8249-05 83 >> 6 6887424 2097152 f31c8249-06 83 >> => mtd list >> Could not find a valid device for spi0.0 >> List of MTD devices: >> No MTD device found >> => > I assume some initialization is not done, but I would like some help to > debug this as I did *not* change anything in SPI (aside from setting it > in .dts). > OTOH I had to change a bit MMC handling, but that shouldn't be relevant, > or is it? > I attach my complete patch against a fairly recent commit (it was "master" > a few hours ago). The patch is to the working ENV_IS_IN_SPI_FLASH version. > Changes for "not working" with ENV_IS_IN_FAT are above. > > Please advise. > Thanks in Advance > Mauro > > >