section .data..init_task

section .data..init_task

[Sean MacLennan]

Anybody else seeing these messages?

ppc_4xxFP-ld: .tmp_vmlinux1: section .data..init_task lma 0xc0374000 overlaps previous sections
ppc_4xxFP-ld: .tmp_vmlinux2: section .data..init_task lma 0xc03a2000 overlaps previous sections
ppc_4xxFP-ld: vmlinux: section .data..init_task lma 0xc03a2000 overlaps previous sections

Or does anybody know what they mean? They started showing up in 2.6.35.

Very easy to reproduce, so don't hesitate to ask for more info.

Cheers,
   Sean

Re: section .data..init_task

[Sean MacLennan]

On Mon, 28 Jun 2010 00:59:00 -0400
Sean MacLennan <smaclennan@pikatech.com> wrote:

> Anybody else seeing these messages?
> 
> ppc_4xxFP-ld: .tmp_vmlinux1: section .data..init_task lma 0xc0374000
> overlaps previous sections ppc_4xxFP-ld: .tmp_vmlinux2:
> section .data..init_task lma 0xc03a2000 overlaps previous sections
> ppc_4xxFP-ld: vmlinux: section .data..init_task lma 0xc03a2000
> overlaps previous sections
> 
> Or does anybody know what they mean? They started showing up in
> 2.6.35.
> 
> Very easy to reproduce, so don't hesitate to ask for more info.

I had a bit of time, so I tracked this down. This patch seems to be
the culprit: http://lkml.org/lkml/2010/2/19/366

Specifically, this code:

 	/* The initial task and kernel stack */
-	.data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
-		INIT_TASK_DATA(THREAD_SIZE)
-	}
+	INIT_TASK_DATA_SECTION(THREAD_SIZE)

If I change it back to:

	/* The initial task and kernel stack */
	.data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) {
		INIT_TASK_DATA(THREAD_SIZE)
	}

not only do the warnings go away, but the kernel now boots again!

Cheers,
   Sean

Re: section .data..init_task

[Sam Ravnborg]

On Mon, Jul 12, 2010 at 08:34:35PM -0400, Sean MacLennan wrote:
> On Mon, 28 Jun 2010 00:59:00 -0400
> Sean MacLennan <smaclennan@pikatech.com> wrote:
> 
> > Anybody else seeing these messages?
> > 
> > ppc_4xxFP-ld: .tmp_vmlinux1: section .data..init_task lma 0xc0374000
> > overlaps previous sections ppc_4xxFP-ld: .tmp_vmlinux2:
> > section .data..init_task lma 0xc03a2000 overlaps previous sections
> > ppc_4xxFP-ld: vmlinux: section .data..init_task lma 0xc03a2000
> > overlaps previous sections
> > 
> > Or does anybody know what they mean? They started showing up in
> > 2.6.35.
> > 
> > Very easy to reproduce, so don't hesitate to ask for more info.
> 
> I had a bit of time, so I tracked this down. This patch seems to be
> the culprit: http://lkml.org/lkml/2010/2/19/366
> 
> Specifically, this code:
> 
>  	/* The initial task and kernel stack */
> -	.data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
> -		INIT_TASK_DATA(THREAD_SIZE)
> -	}
> +	INIT_TASK_DATA_SECTION(THREAD_SIZE)
> 
> If I change it back to:
> 
> 	/* The initial task and kernel stack */
> 	.data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) {
> 		INIT_TASK_DATA(THREAD_SIZE)
> 	}
> 
> not only do the warnings go away, but the kernel now boots again!

It looks like a missing AT() in the output section.
The following patch should also fix it.

Please test and let us know.

Thanks,
	Sam


diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 48c5299..3c4bf03 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -435,7 +435,7 @@
  */
 #define INIT_TASK_DATA_SECTION(align)					\
 	. = ALIGN(align);						\
-	.data..init_task : {						\
+	.data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) {	\
 		INIT_TASK_DATA(align)					\
 	}
 

Re: section .data..init_task

[Sean MacLennan]

On Tue, 13 Jul 2010 10:54:19 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> It looks like a missing AT() in the output section.
> The following patch should also fix it.
> 
> Please test and let us know.
> 
> Thanks,
> 	Sam

Applied the patch and it solves the problem. Thanks.

Cheers,
   Sean

Re: section .data..init_task

[Sam Ravnborg]

On Tue, Jul 13, 2010 at 11:26:10AM -0400, Sean MacLennan wrote:
> On Tue, 13 Jul 2010 10:54:19 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > It looks like a missing AT() in the output section.
> > The following patch should also fix it.
> > 
> > Please test and let us know.
> > 
> > Thanks,
> > 	Sam
> 
> Applied the patch and it solves the problem. Thanks.

Thanks for the quick feedback!

	Sam

[

[Sam Ravnborg]

>From 851e645a7eee68380caaf026eb6d3be118876370 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@ravnborg.org>
Date: Tue, 13 Jul 2010 11:39:42 +0200
Subject: [PATCH] vmlinux.lds: fix .data..init_task output section (fix popwerpc boot)

The .data..init_task output section was missing
a load offset causing a popwerpc target to fail to boot.

Sean MacLennan tracked it down to the definition of
INIT_TASK_DATA_SECTION().

There are only two users of INIT_TASK_DATA_SECTION()
in the kernel today: cris and popwerpc.
cris do not support relocatable kernels and is thus not
impacted by this change.

Fix INIT_TASK_DATA_SECTION() to specify load offset like
all other output sections.

Reported-by: Sean MacLennan <smaclennan@pikatech.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---

On the assumption that Sean reports that it fixes
the warnings/boot issue here is a real patch.

Ben - will you take it via the popwerpc tree
or shall I ask Michal to take it via kbuild?

	Sam

 include/asm-generic/vmlinux.lds.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 48c5299..cdfff74 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -435,7 +435,7 @@
  */
 #define INIT_TASK_DATA_SECTION(align)					\
 	. = ALIGN(align);						\
-	.data..init_task : {						\
+	.data..init_task :  AT(ADDR(.data..init_task) - LOAD_OFFSET) {	\
 		INIT_TASK_DATA(align)					\
 	}
 
-- 
1.6.0.6

Re: [

[Sean MacLennan]

On Tue, 13 Jul 2010 11:50:24 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> Ben - will you take it via the popwerpc tree
> or shall I ask Michal to take it via kbuild?

Anything happening with this patch?

Cheers,
   Sean

Re: [

[Benjamin Herrenschmidt]

On Thu, 2010-07-22 at 18:27 -0400, Sean MacLennan wrote:
> On Tue, 13 Jul 2010 11:50:24 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > Ben - will you take it via the popwerpc tree
> > or shall I ask Michal to take it via kbuild?
> 
> Anything happening with this patch?

The subject line tripped my spam filter ... 

I'm happy to take it.

Sean, make sure it's on patchwork and it will be in one of my next
batches.

Cheers,
Ben.

[PATCH] powerpc: fix .data..init_task output section

[Sean MacLennan]

On Tue, 13 Jul 2010 11:50:24 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> From 851e645a7eee68380caaf026eb6d3be118876370 Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Tue, 13 Jul 2010 11:39:42 +0200
> Subject: [PATCH] vmlinux.lds: fix .data..init_task output section
> (fix popwerpc boot)
> 
> The .data..init_task output section was missing
> a load offset causing a popwerpc target to fail to boot.
> 
> Sean MacLennan tracked it down to the definition of
> INIT_TASK_DATA_SECTION().
> 
> There are only two users of INIT_TASK_DATA_SECTION()
> in the kernel today: cris and popwerpc.
> cris do not support relocatable kernels and is thus not
> impacted by this change.
> 
> Fix INIT_TASK_DATA_SECTION() to specify load offset like
> all other output sections.
> 
> Reported-by: Sean MacLennan <smaclennan@pikatech.com>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> 
> On the assumption that Sean reports that it fixes
> the warnings/boot issue here is a real patch.
> 
> Ben - will you take it via the popwerpc tree
> or shall I ask Michal to take it via kbuild?
> 
> 	Sam
> 
>  include/asm-generic/vmlinux.lds.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h index 48c5299..cdfff74 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -435,7 +435,7 @@
>   */
>  #define
> INIT_TASK_DATA_SECTION(align)
> \ . = ALIGN(align);						\
> -	.data..init_task :
> {						\
> +	.data..init_task :  AT(ADDR(.data..init_task) - LOAD_OFFSET)
> {	\
> INIT_TASK_DATA(align)					\ }
>  

Re: [PATCH] powerpc: fix .data..init_task output section

[Sam Ravnborg]

On Thu, Jul 22, 2010 at 07:50:08PM -0400, Sean MacLennan wrote:
> On Tue, 13 Jul 2010 11:50:24 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > From 851e645a7eee68380caaf026eb6d3be118876370 Mon Sep 17 00:00:00 2001
> > From: Sam Ravnborg <sam@ravnborg.org>
> > Date: Tue, 13 Jul 2010 11:39:42 +0200
> > Subject: [PATCH] vmlinux.lds: fix .data..init_task output section
> > (fix popwerpc boot)
> > 
> > The .data..init_task output section was missing
> > a load offset causing a popwerpc target to fail to boot.
> > 
> > Sean MacLennan tracked it down to the definition of
> > INIT_TASK_DATA_SECTION().
> > 
> > There are only two users of INIT_TASK_DATA_SECTION()
> > in the kernel today: cris and popwerpc.
> > cris do not support relocatable kernels and is thus not
> > impacted by this change.
> > 
> > Fix INIT_TASK_DATA_SECTION() to specify load offset like
> > all other output sections.
> > 
> > Reported-by: Sean MacLennan <smaclennan@pikatech.com>
> > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> > ---
> > 
> > On the assumption that Sean reports that it fixes
> > the warnings/boot issue here is a real patch.
> > 
> > Ben - will you take it via the popwerpc tree
> > or shall I ask Michal to take it via kbuild?
> > 
> > 	Sam

Sorry for the bad initial subject line!
As Sean reported that the patch fixes his isuse it
deserves a:

Tested-by: Sean MacLennan <smaclennan@pikatech.com>

	Sam

Re: [PATCH] powerpc: fix .data..init_task output section

[Benjamin Herrenschmidt]

> > > 
> > > On the assumption that Sean reports that it fixes
> > > the warnings/boot issue here is a real patch.
> > > 
> > > Ben - will you take it via the popwerpc tree
> > > or shall I ask Michal to take it via kbuild?
> > > 
> > > 	Sam
> 
> Sorry for the bad initial subject line!
> As Sean reported that the patch fixes his isuse it
> deserves a:
> 
> Tested-by: Sean MacLennan <smaclennan@pikatech.com>

Heh. Too late, I already sent it to Linus :-)

Ben.

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