You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[ 0.951402] m25p80 spi0.0: found s25fl256s1, expected m25p80
[ 0.957203] m25p80 spi0.0: s25fl256s1 (32768 Kbytes)
[ 0.962266] 7 cmdlinepart partitions found on MTD device spi0.0
[ 0.968277] Creating 7 MTD partitions on "spi0.0":
[ 0.973141] 0x000000000000-0x000000040000 : "u-boot"
[ 0.979849] 0x000000040000-0x000000050000 : "u-boot-env"
[ 0.986630] 0x000000050000-0x000000060000 : "art"
[ 0.992712] 0x000000060000-0x0000001c0000 : "kernel"
[ 0.999136] 0x0000001c0000-0x000001fb0000 : "rootfs"
[ 1.005551] mtd: device 4 (rootfs) set to be root filesystem
[ 1.011311] mtdsplit: error occured while reading from "rootfs"
[ 1.017348] 0x000001fb0000-0x000002000000 : "config"
[ 1.023717] 0x000000060000-0x000001fb0000 : "firmware"
As you can see, this uses a 32MB flash chip "s25fl256s1". After weeks of digging I finally found the root of the issue which is this change: torvalds/linux@08922f6. This uses a mmap read request that "Certain SPI controllers may provide", as the author states. Apparently the s25fl256s1 does not, at least not for the whole 32MB (spi_flash_read() works if I manually set the s25fl256s1's size to 16MB in spi-nor.c)
BTW ath79_spi_read_flash_data() which is wired to master->spi_flash_read in spi-ath79.c returns -EOPNOTSUPP for address widths > 3, which might be the reason I am running into this with the flash size set to its native 32MB, but not with 16MB...
The text was updated successfully, but these errors were encountered:
Commenting out
if (msg->addr_width > 3)
return -EOPNOTSUPP;
in ath79_spi_read_flash_data() in drivers/spi/spi-ath79.c makes the boxx boot, but hard crash soon afterwards and then reboot. Seems this is in there for a reason.
bk138:
Hi OpenWRT/LEDE people,
I have a device I am currently adding to OpenWRT (https://wiki.openwrt.org/inbox/engenius/engenius_emr3000v2) that boots just fine with Linux 4.4 but fails under Linux 4.9 with
[ 0.951402] m25p80 spi0.0: found s25fl256s1, expected m25p80 [ 0.957203] m25p80 spi0.0: s25fl256s1 (32768 Kbytes) [ 0.962266] 7 cmdlinepart partitions found on MTD device spi0.0 [ 0.968277] Creating 7 MTD partitions on "spi0.0": [ 0.973141] 0x000000000000-0x000000040000 : "u-boot" [ 0.979849] 0x000000040000-0x000000050000 : "u-boot-env" [ 0.986630] 0x000000050000-0x000000060000 : "art" [ 0.992712] 0x000000060000-0x0000001c0000 : "kernel" [ 0.999136] 0x0000001c0000-0x000001fb0000 : "rootfs" [ 1.005551] mtd: device 4 (rootfs) set to be root filesystem [ 1.011311] mtdsplit: error occured while reading from "rootfs" [ 1.017348] 0x000001fb0000-0x000002000000 : "config" [ 1.023717] 0x000000060000-0x000001fb0000 : "firmware"
As you can see, this uses a 32MB flash chip "s25fl256s1". After weeks of digging I finally found the root of the issue which is this change: torvalds/linux@08922f6. This uses a mmap read request that "Certain SPI controllers may provide", as the author states. Apparently the s25fl256s1 does not, at least not for the whole 32MB (spi_flash_read() works if I manually set the s25fl256s1's size to 16MB in spi-nor.c)
To determine if the chip supports this mmap read, the spi_flash_read_supported(spi) function gets called (https://github.com/torvalds/linux/blob/master/include/linux/spi/spi.h#L1218) which in turn calls a spi->controller->flash_read_supported(spi) callback which for OpenWRT/LEDE got wired up by https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=e0d58157d8e2ec3da0a1fe62a65aa756c5514871. Unfortunately, this commit only disabled the mmap read for multi-chip setups, the issue I kept running into is not taken care of. I guess something needs to be changed in ath79_spi_flash_read_supported() in spi-ath79.c, but I am stuck at this point, hence this bug report.
BTW ath79_spi_read_flash_data() which is wired to master->spi_flash_read in spi-ath79.c returns -EOPNOTSUPP for address widths > 3, which might be the reason I am running into this with the flash size set to its native 32MB, but not with 16MB...
The text was updated successfully, but these errors were encountered: