Dear Ben, Thanks for your comments!
On Wed, Mar 23, 2016 at 8:47 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > On Wed, 2016-03-23 at 18:29 +0900, Roger Shimizu wrote: >> > On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard >> > <arnaud.pat...@rtp-net.org> wrote: >> > > Roger Shimizu <rogershim...@gmail.com> writes: >> > > > >> > > > 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. > > I wonder if there's any way we can discover which of these cfi_cmdset > modules is needed... I agree. If initramfs-tools can help to do this, we can safely make those all to modules without issue. > >> 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. > [...] > > Please go ahead. In the longer term I think we ought to make > initramfs-tools include these, but I don't want the kernel to be tied > to newer initramfs-tools as that will make backporting very difficult.. Thanks for your understanding! I know this is just a quick fix. Your initramfs-tools way is final solution, which just need some time to sort out. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
