Old regression with MTD devices disappearing from a Kurobox HD/HG

Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Hi.

I just revived a Kurobox HG to use as a NAS (I also have a simpler Kurobox
HD here, not being used at this moment) and I am having problems that didn't
happen before.  I will describe the first problem here and further problems
in later e-mails.

During the 2.6.27 to 2.6.29 era (I may be mistaken in the range, as this is
not new) the kernel had a regression where the MTD device of the Kurobox
used to show about 5 partitions and, with kernels later than that, only one
partition is shown, namely, /dev/mtd0.

Here is what I used to see (just booted the kernel from flash), with a
2.4.33.3 kernel (if desired, I can, of course, send the full dmesg log, but
I don't have the corresponding config):

,----
| LinkStation flash device: 400000 at ffc00000
| NO QRY response
|  Amd/Fujitsu Extended Query Table v1.3 at 0x0040
| LinkStation Flash: Swapping erase regions for broken CFI table.
| number of CFI chips: 1
| cfi_cmdset_0002: Disabling fast programming due to code brokenness.
| Creating 5 MTD partitions on "LinkStation Flash":
| 0x00000000-0x00300000 : "mtd0: kernel+ramdisk"
| 0x00300000-0x00370000 : "mtd1: bootloader"
| 0x00370000-0x00380000 : "mtd2: configuration"
| 0x00380000-0x00400000 : "mtd3: user space"
| 0x00000000-0x00400000 : "mtd4: all flash"
| LinkStation flash device initialized
`----

As I have trouble booting kernels older than 3.x due to my userspace having
udev and libc requirements, I found a dmesg log that is similar to what I
used to get with early 2.6 kernels---this is from a kernel 2.6.15 (this part
is copied from: http://genbako.vodapone.com/old/dmesg-20060117-kuro-NG.txt):

,----
| physmap flash device: 400000 at ffc00000
| phys_mapped_flash: Found 1 x16 devices at 0x0 in 8-bit bank
|  Amd/Fujitsu Extended Query Table at 0x0040
| phys_mapped_flash: Swapping erase regions for broken CFI table.
| number of CFI chips: 1
| cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
| cmdlinepart partition parsing not available
| RedBoot partition parsing not available
| Using physmap partition definition
| Creating 5 MTD partitions on "phys_mapped_flash":
| 0x00000000-0x00400000 : "mtd_allflash"
| 0x00000000-0x00300000 : "mtd_firmimg"
| 0x00300000-0x00370000 : "mtd_bootcode"
| 0x00370000-0x00380000 : "mtd_status"
| 0x00380000-0x00400000 : "mtd_conf"
| usbmon: debugfs is not available
`----

Note that, in particular, the boundary addresses of the MTD device are
exactly the same as the ones on my device.

Unfortunately, right now, what I see with Linus's tree
(4.0.0-rc6-00009-g6c310bc) is the following:

,----
| physmap platform flash device: 00400000 at ffc00000
| physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
| Amd/Fujitsu Extended Query Table at 0x0040
|   Amd/Fujitsu Extended Query version 1.3.
| physmap-flash.0: Swapping erase regions for top-boot CFI table.
| number of CFI chips: 1
`----

I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
first lines, the following comment: [0][1]

    XXXX add flash parts, rtc, ??

[0]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
[1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17

Is this a problem that can be fixed via additions to the DTS files?  Or
would the problem be solved in a different way?


Thanks in advance,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Scott Wood]

On Sat, 2015-04-04 at 02:40 -0300, Rogério Brito wrote:
> Unfortunately, right now, what I see with Linus's tree
> (4.0.0-rc6-00009-g6c310bc) is the following:
> 
> ,----
> | physmap platform flash device: 00400000 at ffc00000
> | physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
> | Amd/Fujitsu Extended Query Table at 0x0040
> |   Amd/Fujitsu Extended Query version 1.3.
> | physmap-flash.0: Swapping erase regions for top-boot CFI table.
> | number of CFI chips: 1
> `----
> 
> I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
> first lines, the following comment: [0][1]
> 
>     XXXX add flash parts, rtc, ??
> 
> [0]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> [1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> 
> Is this a problem that can be fixed via additions to the DTS files?  Or
> would the problem be solved in a different way?

What are your bootargs?

I suggest putting the flash device into the dts (instead of using
physmap), and specifying the partitions on the command-line using
mtdparts.  Putting the partitions in the dts is an option as well, but
less flexible if users may want to change the partition layout -- though
that may be less of a concern here than with reference boards.

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Dear Scott.

First of all, thank you so very much for your reply.

On Apr 07 2015, Scott Wood wrote:
> On Sat, 2015-04-04 at 02:40 -0300, Rogério Brito wrote:
> > ,----
> > | physmap platform flash device: 00400000 at ffc00000
> > | physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
> > | Amd/Fujitsu Extended Query Table at 0x0040
> > |   Amd/Fujitsu Extended Query version 1.3.
> > | physmap-flash.0: Swapping erase regions for top-boot CFI table.
> > | number of CFI chips: 1
> > `----
> > 
> > I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
> > first lines, the following comment: [0][1]
> > 
> >     XXXX add flash parts, rtc, ??
> > 
> > [0]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > [1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > 
> > Is this a problem that can be fixed via additions to the DTS files?  Or
> > would the problem be solved in a different way?
> 
> What are your bootargs?

My kernel command line is (specified via uboot) is the following:

,----
| root=/dev/sda1 netconsole=6666@192.168.11.150/,@192.168.11.149/ rtc-rs5c372.probe=0,0x32
`----

Only that.

> I suggest putting the flash device into the dts (instead of using
> physmap), and specifying the partitions on the command-line using
> mtdparts.

This is good to know. Is there any reasonable dts that I can copy/adapt? I
just started to read on the syntax of the dts files and I am still not
confident that I can write my own without messing everything.

Another question: would putting the description of the flash device into the
dts file be helpful to remove any code from the kernel? That would be super
nice, as the kernels with equivalent configurations are getting so much
bigger during time. The smallest one that I have here is 2.6.28 and its
uImage was 1.5MB, while kernel 4.0 is about 1.9MB with essentially
everything pruned from the kernel (only the bare minimum compiled in). :(

(Everything here is compiled with the very same compiler).

> Putting the partitions in the dts is an option as well, but less flexible
> if users may want to change the partition layout -- though that may be
> less of a concern here than with reference boards.

I think that I would go for the partitions in the dts, mainly because these
machines are not really flexible.  Furthermore, I would need the mtd devices
working so that I can use fw_setenv to change the boot options. :)

In the end, I would like (perhaps) to automate the installation/support of
such machines and offer a way to install Debian on those (or any other
distribution that is interested in these).

Once again, thank you so much for your comments and I hope that you can
guide me some more to fix this for good.


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Scott Wood]

On Tue, 2015-04-07 at 20:58 -0300, Rogério Brito wrote:
> Dear Scott.
> 
> First of all, thank you so very much for your reply.
> 
> On Apr 07 2015, Scott Wood wrote:
> > On Sat, 2015-04-04 at 02:40 -0300, Rogério Brito wrote:
> > > ,----
> > > | physmap platform flash device: 00400000 at ffc00000
> > > | physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
> > > | Amd/Fujitsu Extended Query Table at 0x0040
> > > |   Amd/Fujitsu Extended Query version 1.3.
> > > | physmap-flash.0: Swapping erase regions for top-boot CFI table.
> > > | number of CFI chips: 1
> > > `----
> > > 
> > > I note that arch/powerpc/boot/dts/kuroboxH{D,G}.dts have, as one of their
> > > first lines, the following comment: [0][1]
> > > 
> > >     XXXX add flash parts, rtc, ??
> > > 
> > > [0]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHD.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > > [1]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/dts/kuroboxHG.dts?id=1cced5015b171415169d938fb179c44fe060dc15#n17
> > > 
> > > Is this a problem that can be fixed via additions to the DTS files?  Or
> > > would the problem be solved in a different way?
> > 
> > What are your bootargs?
> 
> My kernel command line is (specified via uboot) is the following:
> 
> ,----
> | root=/dev/sda1 netconsole=6666@192.168.11.150/,@192.168.11.149/ rtc-rs5c372.probe=0,0x32
> `----
> 
> Only that.
> 
> > I suggest putting the flash device into the dts (instead of using
> > physmap), and specifying the partitions on the command-line using
> > mtdparts.
> 
> This is good to know. Is there any reasonable dts that I can copy/adapt?

I'm not familiar with how flash is connected on this chip, so I don't
have a specific recommendation other than to read the binding and look
at several examples.

>  I just started to read on the syntax of the dts files and I am still
> not confident that I can write my own without messing everything.
> 
> Another question: would putting the description of the flash device into the
> dts file be helpful to remove any code from the kernel?

If you currently have a custom flash map driver, you could get rid of
that, but I suspect that's already gone away due to the fact that it's
no longer working.

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Dear Scott,

Once again, thank you very much for your answer.

On Apr 07 2015, Scott Wood wrote:
> On Tue, 2015-04-07 at 20:58 -0300, Rogério Brito wrote:
> > This is good to know. Is there any reasonable dts that I can copy/adapt?
> 
> I'm not familiar with how flash is connected on this chip, so I don't
> have a specific recommendation other than to read the binding and look
> at several examples.

How can I discover how the flash is connected? I'm really showing here that
I am only a luser, but I am willing to find any specs so that this can be
fixed.

> > Another question: would putting the description of the flash device into the
> > dts file be helpful to remove any code from the kernel?
> 
> If you currently have a custom flash map driver, you could get rid of
> that, but I suspect that's already gone away due to the fact that it's
> no longer working.

I see. If I do some "archaeology" (read: bisect when it stopped working),
would that help to discover how the flash is connected?


Thanks once again,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Scott Wood]

On Tue, 2015-04-07 at 21:37 -0300, Rogério Brito wrote:
> Dear Scott,
> 
> Once again, thank you very much for your answer.
> 
> On Apr 07 2015, Scott Wood wrote:
> > On Tue, 2015-04-07 at 20:58 -0300, Rogério Brito wrote:
> > > This is good to know. Is there any reasonable dts that I can copy/adapt?
> > 
> > I'm not familiar with how flash is connected on this chip, so I don't
> > have a specific recommendation other than to read the binding and look
> > at several examples.
> 
> How can I discover how the flash is connected? I'm really showing here that
> I am only a luser, but I am willing to find any specs so that this can be
> fixed.
>
> > > Another question: would putting the description of the flash device into the
> > > dts file be helpful to remove any code from the kernel?
> > 
> > If you currently have a custom flash map driver, you could get rid of
> > that, but I suspect that's already gone away due to the fact that it's
> > no longer working.
> 
> I see. If I do some "archaeology" (read: bisect when it stopped working),
> would that help to discover how the flash is connected?

It will probably give you the address and size of the flash, which is
good enough to get something working.  Does your config (for the old
kernel) have anything with PHYSMAP in it?  I suspect it probably broke
with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
make physmap compat explicit").

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Hi, Scott.

On Apr 07 2015, Scott Wood wrote:
> On Tue, 2015-04-07 at 21:37 -0300, Rogério Brito wrote:
> > I see. If I do some "archaeology" (read: bisect when it stopped
> > working), would that help to discover how the flash is connected?
> 
> It will probably give you the address and size of the flash, which is
> good enough to get something working.  Does your config (for the old
> kernel) have anything with PHYSMAP in it?  I suspect it probably broke
> with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
> make physmap compat explicit").

Here is what my 2.6.27 kernel has in the section regarding physmap:

,----
| #
| # Mapping drivers for chip access
| #
| # CONFIG_MTD_COMPLEX_MAPPINGS is not set
| CONFIG_MTD_PHYSMAP=y
| CONFIG_MTD_PHYSMAP_START=0xffc00000
| CONFIG_MTD_PHYSMAP_LEN=0x400000
| CONFIG_MTD_PHYSMAP_BANKWIDTH=1
| # CONFIG_MTD_PHYSMAP_OF is not set
| # CONFIG_MTD_INTEL_VR_NOR is not set
| # CONFIG_MTD_PLATRAM is not set
`----

Here is what my 4.0-rc6 kernel has:

,----
| #
| # Mapping drivers for chip access
| #
| # CONFIG_MTD_COMPLEX_MAPPINGS is not set
| CONFIG_MTD_PHYSMAP=y
| CONFIG_MTD_PHYSMAP_COMPAT=y
| CONFIG_MTD_PHYSMAP_START=0xffc00000
| CONFIG_MTD_PHYSMAP_LEN=0x400000
| CONFIG_MTD_PHYSMAP_BANKWIDTH=1
| CONFIG_MTD_PHYSMAP_OF=y
| # CONFIG_MTD_INTEL_VR_NOR is not set
| # CONFIG_MTD_PLATRAM is not set
`----

I may try to revert locally that patch here to see if things improve or not,
but it will take me some time to compile it (I hope not much).


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

)

[Scott Wood]

On Tue, 2015-04-07 at 22:13 -0300, Rogério Brito wrote:
> Hi, Scott.
> 
> On Apr 07 2015, Scott Wood wrote:
> > On Tue, 2015-04-07 at 21:37 -0300, Rogério Brito wrote:
> > > I see. If I do some "archaeology" (read: bisect when it stopped
> > > working), would that help to discover how the flash is connected?
> > 
> > It will probably give you the address and size of the flash, which is
> > good enough to get something working.  Does your config (for the old
> > kernel) have anything with PHYSMAP in it?  I suspect it probably broke
> > with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
> > make physmap compat explicit").
> 
> Here is what my 2.6.27 kernel has in the section regarding physmap:
> 
> ,----
> | #
> | # Mapping drivers for chip access
> | #
> | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> | CONFIG_MTD_PHYSMAP=y
> | CONFIG_MTD_PHYSMAP_START=0xffc00000
> | CONFIG_MTD_PHYSMAP_LEN=0x400000
> | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> | # CONFIG_MTD_PHYSMAP_OF is not set
> | # CONFIG_MTD_INTEL_VR_NOR is not set
> | # CONFIG_MTD_PLATRAM is not set
> `----
> 
> Here is what my 4.0-rc6 kernel has:
> 
> ,----
> | #
> | # Mapping drivers for chip access
> | #
> | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> | CONFIG_MTD_PHYSMAP=y
> | CONFIG_MTD_PHYSMAP_COMPAT=y
> | CONFIG_MTD_PHYSMAP_START=0xffc00000
> | CONFIG_MTD_PHYSMAP_LEN=0x400000
> | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> | CONFIG_MTD_PHYSMAP_OF=y
> | # CONFIG_MTD_INTEL_VR_NOR is not set
> | # CONFIG_MTD_PLATRAM is not set
> `----
> 
> I may try to revert locally that patch here to see if things improve or not,
> but it will take me some time to compile it (I hope not much).

Oh right, it's the partitions that are missing, rather than the flash
device itself.  It was probably commit
13e0fe49f676607688da7475c33540ec5dac53b5 ("mtd: drop physmap_configure")
that broke your out-of-tree kernel.  Maybe you (or someone) dropped a
call to physmap_set_partitions() to stop the build error, and didn't
replace it with anything?

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Hi, Scott.

Once again, thank you for being patient with this newbie. It is really
appreciated that you're willing to educate me.

On Apr 07 2015, Scott Wood wrote:
> On Tue, 2015-04-07 at 22:13 -0300, Rogério Brito wrote:
> > On Apr 07 2015, Scott Wood wrote:
> > > It will probably give you the address and size of the flash, which is
> > > good enough to get something working.  Does your config (for the old
> > > kernel) have anything with PHYSMAP in it?  I suspect it probably broke
> > > with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
> > > make physmap compat explicit").
> > 
> > Here is what my 2.6.27 kernel has in the section regarding physmap:
> > 
> > ,----
> > | #
> > | # Mapping drivers for chip access
> > | #
> > | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> > | CONFIG_MTD_PHYSMAP=y
> > | CONFIG_MTD_PHYSMAP_START=0xffc00000
> > | CONFIG_MTD_PHYSMAP_LEN=0x400000
> > | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> > | # CONFIG_MTD_PHYSMAP_OF is not set
> > | # CONFIG_MTD_INTEL_VR_NOR is not set
> > | # CONFIG_MTD_PLATRAM is not set
> > `----
> > 
> > Here is what my 4.0-rc6 kernel has:
> > 
> > ,----
> > | #
> > | # Mapping drivers for chip access
> > | #
> > | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> > | CONFIG_MTD_PHYSMAP=y
> > | CONFIG_MTD_PHYSMAP_COMPAT=y
> > | CONFIG_MTD_PHYSMAP_START=0xffc00000
> > | CONFIG_MTD_PHYSMAP_LEN=0x400000
> > | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> > | CONFIG_MTD_PHYSMAP_OF=y
> > | # CONFIG_MTD_INTEL_VR_NOR is not set
> > | # CONFIG_MTD_PLATRAM is not set
> > `----
> > 
> > I may try to revert locally that patch here to see if things improve or not,
> > but it will take me some time to compile it (I hope not much).
> 
> Oh right, it's the partitions that are missing, rather than the flash
> device itself.  It was probably commit
> 13e0fe49f676607688da7475c33540ec5dac53b5 ("mtd: drop physmap_configure")
> that broke your out-of-tree kernel.

This kernel is not out-of-tree. I have been compiling things from Linus's
tree since the 2.6.20's (I don't remember precisely).  Perhaps I should just
have shouted at the time, but I thought that it might have, perhaps, been a
problem on my side.

> Maybe you (or someone) dropped a call to physmap_set_partitions() to stop
> the build error, and didn't replace it with anything?

I with that I knew how to code stuff in the kernel besides simply following
the instructions in "make oldconfig", "make menuconfig" and similar. :)

I guess that this would be a good opportunity to learn at least the basics
of writing a dts, though, but I lack the knowledge of the hardware. I do
know what the partition were reported before in previous kernels, if that
helps anything.

Would it help if you had ssh access here, so that you can see how the system
is?  Or, if you want me to, I can try to get as much information as I can
via whatever means you want me to.


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Dear Scott and other people,

On Apr 07 2015, Rogério Brito wrote:
> On Apr 07 2015, Scott Wood wrote:
> > On Tue, 2015-04-07 at 22:13 -0300, Rogério Brito wrote:
> > > On Apr 07 2015, Scott Wood wrote:
> > > > It will probably give you the address and size of the flash, which is
> > > > good enough to get something working.  Does your config (for the old
> > > > kernel) have anything with PHYSMAP in it?  I suspect it probably broke
> > > > with commit dcb3e137ce9be1dfc86e306182b23e3ae5e239c4 ("[MTD] physmap:
> > > > make physmap compat explicit").
> > > 
> > > Here is what my 2.6.27 kernel has in the section regarding physmap:
> > > 
> > > ,----
> > > | #
> > > | # Mapping drivers for chip access
> > > | #
> > > | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> > > | CONFIG_MTD_PHYSMAP=y
> > > | CONFIG_MTD_PHYSMAP_START=0xffc00000
> > > | CONFIG_MTD_PHYSMAP_LEN=0x400000
> > > | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> > > | # CONFIG_MTD_PHYSMAP_OF is not set
> > > | # CONFIG_MTD_INTEL_VR_NOR is not set
> > > | # CONFIG_MTD_PLATRAM is not set
> > > `----
> > > 
> > > Here is what my 4.0-rc6 kernel has:
> > > 
> > > ,----
> > > | #
> > > | # Mapping drivers for chip access
> > > | #
> > > | # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> > > | CONFIG_MTD_PHYSMAP=y
> > > | CONFIG_MTD_PHYSMAP_COMPAT=y
> > > | CONFIG_MTD_PHYSMAP_START=0xffc00000
> > > | CONFIG_MTD_PHYSMAP_LEN=0x400000
> > > | CONFIG_MTD_PHYSMAP_BANKWIDTH=1
> > > | CONFIG_MTD_PHYSMAP_OF=y
> > > | # CONFIG_MTD_INTEL_VR_NOR is not set
> > > | # CONFIG_MTD_PLATRAM is not set
> > > `----
> > > 
> > > I may try to revert locally that patch here to see if things improve or not,
> > > but it will take me some time to compile it (I hope not much).
> > 
> > Oh right, it's the partitions that are missing, rather than the flash
> > device itself.  It was probably commit
> > 13e0fe49f676607688da7475c33540ec5dac53b5 ("mtd: drop physmap_configure")
> > that broke your out-of-tree kernel.
> 
> This kernel is not out-of-tree. I have been compiling things from Linus's
> tree since the 2.6.20's (I don't remember precisely).  Perhaps I should just
> have shouted at the time, but I thought that it might have, perhaps, been a
> problem on my side.
> 
> > Maybe you (or someone) dropped a call to physmap_set_partitions() to stop
> > the build error, and didn't replace it with anything?
> 
> I with that I knew how to code stuff in the kernel besides simply following
> the instructions in "make oldconfig", "make menuconfig" and similar. :)
> 
> I guess that this would be a good opportunity to learn at least the basics
> of writing a dts, though, but I lack the knowledge of the hardware. I do
> know what the partition were reported before in previous kernels, if that
> helps anything.

Just for the record, I am passing now the following command line option to
the kernel:

    mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)

which is, according to my best knowledge, how the flash is laid out.
Unfortunately, it doesn't help: I still have only /dev/mtd0. Here is what
part of my configuration looks like:

,----
| # uname -r
| 4.0.0-rc7-00016-g7b43b47
| # grep -i mtd config-$(uname -r)
| CONFIG_CMDLINE="netconsole=6666@192.168.11.150/,@192.168.11.149/ rtc-rs5c372.probe=0,0x32 root=/dev/sda1 mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)"
| CONFIG_MTD=y
| # CONFIG_MTD_TESTS is not set
| # CONFIG_MTD_REDBOOT_PARTS is not set
| CONFIG_MTD_CMDLINE_PARTS=y
| CONFIG_MTD_OF_PARTS=y
| # CONFIG_MTD_AR7_PARTS is not set
| CONFIG_MTD_BLKDEVS=y
| CONFIG_MTD_BLOCK=y
| (...)
`----

Do the options CONFIG_MTD_CMDLINE_PARTS and CONFIG_MTD_OF_PARTS somehow
"conflict" with each other?

I would appreciate any help here.


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Scott Wood]

On Thu, 2015-04-09 at 18:54 -0300, Rogério Brito wrote:
> Dear Scott and other people,
> 
> Just for the record, I am passing now the following command line option to
> the kernel:
> 
>     mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)

What is "myflash"?  You need to match the device name that the kernel
uses.

What is "allflash"?  If the flash is only 4 MiB and you're trying to
make the first partition refer to the entire flash, it won't work.
It'll see that 4 MiB partition and ignore the rest as being beyond the
end of the device.

> which is, according to my best knowledge, how the flash is laid out.
> Unfortunately, it doesn't help: I still have only /dev/mtd0. Here is what
> part of my configuration looks like:
> 
> ,----
> | # uname -r
> | 4.0.0-rc7-00016-g7b43b47
> | # grep -i mtd config-$(uname -r)
> | CONFIG_CMDLINE="netconsole=6666@192.168.11.150/,@192.168.11.149/ rtc-rs5c372.probe=0,0x32 root=/dev/sda1 mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)"
> | CONFIG_MTD=y
> | # CONFIG_MTD_TESTS is not set
> | # CONFIG_MTD_REDBOOT_PARTS is not set
> | CONFIG_MTD_CMDLINE_PARTS=y
> | CONFIG_MTD_OF_PARTS=y
> | # CONFIG_MTD_AR7_PARTS is not set
> | CONFIG_MTD_BLKDEVS=y
> | CONFIG_MTD_BLOCK=y
> | (...)
> `----
> 
> Do the options CONFIG_MTD_CMDLINE_PARTS and CONFIG_MTD_OF_PARTS somehow
> "conflict" with each other?

No.  CONFIG_MTD_OF_PARTS only matters if you're describing the flash
chip in the device tree, and even then cmdline mtdparts takes precedence
if present.

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Hi, Scott.

On Apr 09 2015, Scott Wood wrote:
> On Thu, 2015-04-09 at 18:54 -0300, Rogério Brito wrote:
> > Dear Scott and other people,
> > 
> > Just for the record, I am passing now the following command line option to
> > the kernel:
> > 
> >     mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> 
> What is "myflash"?  You need to match the device name that the kernel
> uses.

>From the documentation that I read, it *seemed* to be an arbitrary name and,
to be screamingly different from anything else, I just picked "myflash".
So, in my case (see dmesg snippet below), I would use "physmap-flash.0",
right? Or would that be "physmap-flash"? Or something else entirely?

,----
| (...)
| ata1: PATA max UDMA/133 cmd 0xbffed0 ctl 0xbffed8 bmdma 0xbffef0 irq 17
| ata2: PATA max UDMA/133 cmd 0xbffee0 ctl 0xbffee8 bmdma 0xbffef8 irq 17
| physmap platform flash device: 00400000 at ffc00000
| physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
| Amd/Fujitsu Extended Query Table at 0x0040
|   Amd/Fujitsu Extended Query version 1.3.
| physmap-flash.0: Swapping erase regions for top-boot CFI table.
| number of CFI chips: 1
| r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
| (...)
`----

> What is "allflash"?  If the flash is only 4 MiB and you're trying to
> make the first partition refer to the entire flash, it won't work.
> It'll see that 4 MiB partition and ignore the rest as being beyond the
> end of the device.

OK, I was just trying to mimic the layout that you can see here:

    http://buffalo.nas-central.org/wiki/Flash_ROM#Checking_the_layout_.28with_kernel_2.6.x.29

> > Do the options CONFIG_MTD_CMDLINE_PARTS and CONFIG_MTD_OF_PARTS somehow
> > "conflict" with each other?
> 
> No.  CONFIG_MTD_OF_PARTS only matters if you're describing the flash
> chip in the device tree, and even then cmdline mtdparts takes precedence
> if present.

Great to know. I hope that one way or another we can have these partitions
specified in the device tree so that:

* The device tree sources better reflect the reality and describe the
  hardware closer than they do today.
* I can clean up my command line.


Thanks once again,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Hi, Scott and others.

On Apr 09 2015, Rogério Brito wrote:
> On Apr 09 2015, Scott Wood wrote:
> > On Thu, 2015-04-09 at 18:54 -0300, Rogério Brito wrote:
> > >     mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > 
> > What is "myflash"?  You need to match the device name that the kernel
> > uses.
> 
> From the documentation that I read, it *seemed* to be an arbitrary name and,
> to be screamingly different from anything else, I just picked "myflash".
> So, in my case (see dmesg snippet below), I would use "physmap-flash.0",
> right? Or would that be "physmap-flash"? Or something else entirely?

Is there any "proper" way for me to discover what device name the kernel
uses? I have tried the following command lines without success:

1 - mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
2 - mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
3 - mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)

The first one is the one from my previous post. The next ones had the name
of the device changed *and* the 4MB at the start removed.

Do you want my config file? Do you want any dmesg output?  Anything else
that I can provide?

> > What is "allflash"?  If the flash is only 4 MiB and you're trying to
> > make the first partition refer to the entire flash, it won't work.
> > It'll see that 4 MiB partition and ignore the rest as being beyond the
> > end of the device.
> 
> OK, I was just trying to mimic the layout that you can see here:
> 
>     http://buffalo.nas-central.org/wiki/Flash_ROM#Checking_the_layout_.28with_kernel_2.6.x.29

I have removed that parameter from the command line.


Thanks a lot for your help,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Scott Wood]

On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote:
> Hi, Scott and others.
> 
> On Apr 09 2015, Rogério Brito wrote:
> > On Apr 09 2015, Scott Wood wrote:
> > > On Thu, 2015-04-09 at 18:54 -0300, Rogério Brito wrote:
> > > >     mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > > 
> > > What is "myflash"?  You need to match the device name that the kernel
> > > uses.
> > 
> > From the documentation that I read, it *seemed* to be an arbitrary name and,
> > to be screamingly different from anything else, I just picked "myflash".
> > So, in my case (see dmesg snippet below), I would use "physmap-flash.0",
> > right? Or would that be "physmap-flash"? Or something else entirely?
> 
> Is there any "proper" way for me to discover what device name the kernel
> uses? I have tried the following command lines without success:
> 
> 1 - mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> 2 - mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> 3 - mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)

Look in sysfs.

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Dear Scott.

On Apr 16 2015, Scott Wood wrote:
> On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote:
> > Is there any "proper" way for me to discover what device name the kernel
> > uses? I have tried the following command lines without success:
> > 
> > 1 - mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > 2 - mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > 3 - mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> 
> Look in sysfs.

The output that I get from sysfs is:

    # ls -l /sys/block/mtdblock0
    lrwxrwxrwx 1 root root 0 Apr 16 20:42 /sys/block/mtdblock0 -> ../devices/platform/physmap-flash.0/mtd/mtd0/mtdblock0
    # cat /sys/devices/platform/physmap-flash.0/uevent
    DRIVER=physmap-flash
    MODALIAS=platform:physmap-flash
    # cat /sys/devices/platform/physmap-flash.0/driver_override
    (null)

So, it is saying that the driver is physmap-flash, right?  I will compile
now a (new) kernel 4.0 with the parameter passed as my 2nd attempt above
(just to make sure that I have not messed up before).  Just to confirm, this
should (in theory) work, right?

Anything else that I can provide? Again, just ask me and I will do my best
to collect the needed information.


Thanks once again,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Scott Wood]

On Thu, 2015-04-16 at 21:01 -0300, Rogério Brito wrote:
> Dear Scott.
> 
> On Apr 16 2015, Scott Wood wrote:
> > On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote:
> > > Is there any "proper" way for me to discover what device name the kernel
> > > uses? I have tried the following command lines without success:
> > > 
> > > 1 - mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > > 2 - mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > > 3 - mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > 
> > Look in sysfs.
> 
> The output that I get from sysfs is:
> 
>     # ls -l /sys/block/mtdblock0
>     lrwxrwxrwx 1 root root 0 Apr 16 20:42 /sys/block/mtdblock0 -> ../devices/platform/physmap-flash.0/mtd/mtd0/mtdblock0
>     # cat /sys/devices/platform/physmap-flash.0/uevent
>     DRIVER=physmap-flash
>     MODALIAS=platform:physmap-flash
>     # cat /sys/devices/platform/physmap-flash.0/driver_override
>     (null)
> 
> So, it is saying that the driver is physmap-flash, right?

It looks like the device name is "physmap-flash.0".  You're partitioning
the device, not the driver.

-Scott

Re: Old regression with MTD devices disappearing from a Kurobox HD/HG

[Rogério Brito]

Hi, Scott.

On Apr 16 2015, Scott Wood wrote:
> On Thu, 2015-04-16 at 21:01 -0300, Rogério Brito wrote:
> > On Apr 16 2015, Scott Wood wrote:
> > > On Thu, 2015-04-16 at 19:55 -0300, Rogério Brito wrote:
> > > > Is there any "proper" way for me to discover what device name the kernel
> > > > uses? I have tried the following command lines without success:
> > > > 
> > > > 1 - mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > > > 2 - mtdparts=physmap-flash:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > > > 3 - mtdparts=cfi_cmdset_0002:3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> > > 
> > > Look in sysfs.
> > 
> > The output that I get from sysfs is:
> > 
> >     # ls -l /sys/block/mtdblock0
> >     lrwxrwxrwx 1 root root 0 Apr 16 20:42 /sys/block/mtdblock0 -> ../devices/platform/physmap-flash.0/mtd/mtd0/mtdblock0
> >     # cat /sys/devices/platform/physmap-flash.0/uevent
> >     DRIVER=physmap-flash
> >     MODALIAS=platform:physmap-flash
> >     # cat /sys/devices/platform/physmap-flash.0/driver_override
> >     (null)
> > 
> > So, it is saying that the driver is physmap-flash, right?
> 
> It looks like the device name is "physmap-flash.0".  You're partitioning
> the device, not the driver.

Sure, the device, not the driver. :) I simply thought that the trailing .0
was a way to disambiguate from multiple devices that might (perhaps) be
activated by the same driver.

Regardless, I guess that I have already tried this physmap-flash.0 thing,
but I will let you know the results in a few minutes. :) I have just
finished compiling the kernel with that (forced) command line and I'm
rebooting the system now.

----

Yay! It worked:

,----
| physmap platform flash device: 00400000 at ffc00000
| physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
| Amd/Fujitsu Extended Query Table at 0x0040
|   Amd/Fujitsu Extended Query version 1.3.
| physmap-flash.0: Swapping erase regions for top-boot CFI table.
| number of CFI chips: 1
| 4 cmdlinepart partitions found on MTD device physmap-flash.0
| Creating 4 MTD partitions on "physmap-flash.0":
| 0x000000000000-0x000000300000 : "firmimg"
| 0x000000300000-0x000000370000 : "bootcode"
| 0x000000370000-0x000000380000 : "status"
| 0x000000380000-0x000000400000 : "conf"
`----

Now, the next step is to learn this DTS thing and send patches to two DTS
files.  :)


Thank you so very much,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br