[add Ben to CC list] Dear Arnaud,
My apology to my previous email. You were absolutely right! On Tue, Mar 22, 2016 at 10:07 PM, Roger Shimizu <rogershim...@gmail.com> wrote: > Dear Arnaud, > > Thanks for your information! > > On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard > <arnaud.pat...@rtp-net.org> wrote: >> Roger Shimizu <rogershim...@gmail.com> writes: >> >> Hi, >> >>> Dear Ian, Martin, >>> >>> May I know your comment regarding to this armel/orion5x related bug? >>> I don't know whether qnap also uses MTD to store u-boot related stuff >>> or not. Just guessing it may have the same issue. >> >> From a quick look at your logs, your mtd device is needing support for >> cmdset 2, provided by cfi_cmdset_0002.ko (CONFIG_MTD_CFI_AMDSTD). Maybe >> it's not available when the mtd chip is probed ? >> Eg missing in the initrd or should be built-in or something like that ? Yes. After appending "cfi_cmdset_0002" to /etc/initramfs-tools/modules, do an "update-initramfs -u", then the MTD becomes probing OK. And -kirkwood flavour usually takes CONFIG_MTD_CFI_AMDSTD=m while -orion5x flavour usually takes CONFIG_MTD_CFI_AMDSTD=y After merging to -marvell, it should take the superset [0], and set CONFIG_MTD_CFI_AMDSTD=y I'll make this change if nobody is against with it. > I haven't tried your idea yet. > But I did confirm that for 4.4.0-trunk-orion5x (4.4-1~exp1), > cfi_cmdset_0002.ko is never loaded, but MTD is OK. > > Please also be noted that both kernel (-orion5x and -marvell) are > doing the MTD probe in around 1.7-1.8 second after kernel boots, at > which time the modules are not loaded yet. > So the driver compiled in the module should be irrelevant. I think the > root cause may be something else. Sorry for my bad human memory. And thanks again for your favour! [0] https://lists.debian.org/debian-arm/2016/03/msg00036.html -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
