Hello Boris,
thanks for the fast response.
Am 15.11.2018 um 16:15 schrieb Boris Brezillon:
Hi Heiko,
On Thu, 15 Nov 2018 15:21:31 +0100 Boris Brezillon boris.brezillon@bootlin.com wrote:
Looks like spi_flash_mtd_register() is doing something really bad here
Yes!
[1]: memsetting the global sf_mtd_info object without testing if this object has already been registered, and then registering it again to the MTD layer. So any partition that had been attached to the mtd object through mtd_probe_devices() are lost, and mtdparts/mtdids are not parsed again because they haven't changed since the last time mtd_probe_devices() was called.
Yep...
[1]https://elixir.bootlin.com/u-boot/v2018.11/source/drivers/mtd/spi/sf_mtd.c#L...
Can you try with the following diff applied?
The patch do not apply for me, so I added it from hand.
But it crashes for me (output with some debug printfs) and U-Boot Environment in SPI NOR:
U-Boot 2018.11-00042-g48b013532c-dirty (Nov 16 2018 - 06:31:16 +0000)
CPU: Freescale i.MX6ULL rev1.0 528 MHz (running at 396 MHz) CPU: Industrial temperature grade (-40C to 105C) at 45C Reset cause: WDOG [...] DRAM: 128 MiB NAND: 128 MiB Loading Environment from SPI Flash... SF: Detected s25f064l with page size 256 Bytes, erase size 64 KiB, total 8 MiB spi_flash_mtd_register === start: 749000 spi_flash_mtd_register === name : <NULL> spi_flash_mtd_register === start spi_flash_mtd_register === ret: 0 spi_flash_read_dm === reloc_offset: 749000 dev:00000c00 off: d0000 len: 16384 data abort pc : [<87f69226>] lr : [<87f69223>] reloc pc : [<87820226>] lr : [<87820223>] sp : 86f44e50 ip : 00000000 fp : 00000017 r10: 878006cc r9 : 86f44ee0 r8 : 86f50600 r7 : 87fdb78c r6 : 00004000 r5 : 000d0000 r4 : 00000c00 r3 : 49e2e00d r2 : 00004000 r1 : 86f44c24 r0 : 0000004e Flags: Nzcv IRQs off FIQs off Mode SVC_32 Code: e9cd4603 48081600 f02c4908 6823fa66 (6bdb4632) Resetting CPU ...
It crashes in:
8782018c T board_nand_init 87820200 t spi_flash_post_bind 87820204 T spi_flash_read_dm <- 87820244 T spi_flash_write_dm 87820252 T spi_flash_erase_dm
dev pointer seems bogus to me ...
I try to find out more, but may I have only next week time for it... sorry.
bye, Heiko