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

["Rogério Brito" <rbrito@ime.usp.br>]

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