Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell
[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 <rogershimizu@gmail.com> wrote:
> Dear Arnaud,
>
> Thanks for your information!
>
> On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard
> <arnaud.patard@rtp-net.org> wrote:
>> Roger Shimizu <rogershimizu@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
Reply to: