Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell

Roger Shimizu

unread,

Mar 18, 2016, 10:20:02 AM3/18/16

to

Package: src:linux
Version: 4.4.6-1
Severity: normal
Control: notfound -1 4.4-1~exp1
Control: found -1 4.4.1-1~exp1
X-Debbugs-Cc: rogers...@gmail.com

Dear Maintainer,

I found my orion5x based Linkstation started to fail probing MTD
device, which stores u-boot binary and environment, after variant
migration from -orion5x to -marvell.

Kernel log with version info is like the following:

Linux LS-GL 4.4.0-trunk-orion5x #1 Debian 4.4-1~exp1 (2016-01-19)
armv5tel GNU/Linux
====
[ 1.838495] Found: SST 39LF020
[ 1.841662] f4000000.flash: Found 1 x8 devices at 0x0 in 8-bit bank
[ 1.847985] number of JEDEC chips: 1
[ 1.868437] 3 ofpart partitions found on MTD device f4000000.flash
[ 1.874705] Creating 3 MTD partitions on "f4000000.flash":
[ 1.880288] 0x000000000000-0x000000030000 : "header"
[ 1.888806] 0x000000030000-0x00000003f000 : "uboot"
[ 1.897299] 0x00000003f000-0x000000040000 : "uboot_env"
====

Linux LS-GL 4.4.0-trunk-marvell #1 Debian 4.4.1-1~exp1 (2016-02-10)
armv5tel GNU/Linux
====
[ 1.716090] Found: SST 39LF020
[ 1.719184] f4000000.flash: Found 1 x8 devices at 0x0 in 8-bit bank
[ 1.742133] Support for command set 0002 not present
[ 1.747188] gen_probe: No supported Vendor Command Set found
[ 1.752919] of-flash f4000000.flash: do_map_probe() failed for type
jedec_probe
[ 1.771450] of-flash f4000000.flash: do_map_probe() failed
====

I uses the same DTB, which ships with latest sid kernel, to do previous test.
(I put the DTB in /etc/flash-kernel/dtbs/)
It with the patches I applied:
- https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/features/arm/device-tree?h=sid

I also checked the diff of kernel config for the two kernels, but found no clue.
And, the kirkwood based Linkstation doesn't have this issue.

Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Debian Bug Tracking System

unread,

Mar 18, 2016, 10:20:03 AM3/18/16

to

Processing control commands:

> notfound -1 4.4-1~exp1
Bug #818598 [src:linux] src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell
Ignoring request to alter found versions of bug #818598 to the same values previously set
> found -1 4.4.1-1~exp1
Bug #818598 [src:linux] src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell
Marked as found in versions linux/4.4.1-1~exp1.

--
818598: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818598
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Roger Shimizu

unread,

Mar 20, 2016, 11:50:02 AM3/20/16

to

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.
Thank you!

Arnaud Patard

unread,

Mar 22, 2016, 8:30:03 AM3/22/16

to

Roger Shimizu <rogers...@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 ?

Arnaud

Roger Shimizu

unread,

Mar 22, 2016, 9:10:03 AM3/22/16

to

Dear Arnaud,

Thanks for your information!

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.

Cheers,

Roger Shimizu

unread,

Mar 23, 2016, 5:40:03 AM3/23/16

to

[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 <rogers...@gmail.com> wrote:
> Dear Arnaud,
>
> Thanks for your information!
>
> On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard
> <arnaud...@rtp-net.org> wrote:
>> Roger Shimizu <rogers...@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

Ben Hutchings

unread,

Mar 23, 2016, 2:20:03 PM3/23/16

to

On Wed, 2016-03-23 at 18:29 +0900, Roger Shimizu wrote:
> [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 wrote:
> >
> > Dear Arnaud,
> >
> > Thanks for your information!
> >
> > On Tue, Mar 22, 2016 at 9:25 PM, Arnaud Patard
> > <arnaud...@rtp-net.org> wrote:
> > >
> > > Roger Shimizu <rogers...@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.

I wonder if there's any way we can discover which of these cfi_cmdset
modules is needed...

> 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..

Ben.

--
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.

signature.asc

Roger Shimizu

unread,

Mar 23, 2016, 7:40:02 PM3/23/16

to

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...@rtp-net.org> wrote:
>> > > Roger Shimizu <rogers...@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,

Sandy Gould

unread,

Mar 30, 2016, 6:00:03 AM3/30/16

to

Adding the cfi_cmdset_0002 module to /etc/initramfs-tools/modules and an
update-initramfs -u did the trick for me too. Thanks for the info.

Debian Bug Tracking System

unread,

Mar 30, 2016, 6:40:02 AM3/30/16

to

Processing control commands:

> tags -1 +pending

Bug #818598 [src:linux] src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell

Added tag(s) pending.

Roger Shimizu

unread,

Mar 30, 2016, 6:40:02 AM3/30/16

to

Control: tags -1 +pending

On Wed, Mar 30, 2016 at 6:48 PM, Sandy Gould <sjjg...@gmail.com> wrote:
> Adding the cfi_cmdset_0002 module to /etc/initramfs-tools/modules and an
> update-initramfs -u did the trick for me too. Thanks for the info.

Good to know there's other orion5x user, and is benefit from my working.
That module will become built-in on next sid kernel release.