[PATCH 1/2] mtd/maps: uclinux: fix building when partition support is disabled

[PATCH 1/2] mtd/maps: uclinux: fix building when partition support is disabled

[Mike Frysinger]

From: Timofei Bondarenko <tim@ipi.ac.ru>

The uClinux map driver doesn't even use partitions, so we shouldn't require
it in order to work properly.

Signed-off-by: Timofei Bondarenko <tim@ipi.ac.ru>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
CC: Greg Ungerer <gerg@uclinux.org>
CC: uclinux-dev@uclinux.org
CC: linux-mtd@lists.infradead.org
---
 drivers/mtd/maps/uclinux.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
index 81756e3..57699c2 100644
--- a/drivers/mtd/maps/uclinux.c
+++ b/drivers/mtd/maps/uclinux.c
@@ -87,7 +87,11 @@ static int __init uclinux_mtd_init(void)
 	mtd->priv = mapp;
 
 	uclinux_ram_mtdinfo = mtd;
+#ifdef CONFIG_MTD_PARTITIONS
 	add_mtd_partitions(mtd, uclinux_romfs, NUM_PARTITIONS);
+#else
+	add_mtd_device(mtd);
+#endif
 
 	return(0);
 }
@@ -97,7 +101,11 @@ static int __init uclinux_mtd_init(void)
 static void __exit uclinux_mtd_cleanup(void)
 {
 	if (uclinux_ram_mtdinfo) {
+#ifdef CONFIG_MTD_PARTITIONS
 		del_mtd_partitions(uclinux_ram_mtdinfo);
+#else
+		del_mtd_device(uclinux_ram_mtdinfo);
+#endif
 		map_destroy(uclinux_ram_mtdinfo);
 		uclinux_ram_mtdinfo = NULL;
 	}
-- 
1.6.3.1

[PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[Mike Frysinger]

Due to a processor anomaly (05000263 to be exact), most Blackfin parts
cannot keep the embedded filesystem image directly after the kernel in
RAM.  Instead, the filesystem needs to be relocated to the end of memory.
As such, we need to tweak the initial filesystem address for Blackfin
systems.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Greg Ungerer <gerg@uclinux.org>
CC: uclinux-dev@uclinux.org
CC: linux-mtd@lists.infradead.org
---
 drivers/mtd/maps/uclinux.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
index 57699c2..dcb552f 100644
--- a/drivers/mtd/maps/uclinux.c
+++ b/drivers/mtd/maps/uclinux.c
@@ -55,8 +55,13 @@ static int __init uclinux_mtd_init(void)
 {
 	struct mtd_info *mtd;
 	struct map_info *mapp;
+#ifdef CONFIG_BLACKFIN
+	extern unsigned long memory_mtd_start;
+	unsigned long addr = (unsigned long) memory_mtd_start;
+#else
 	extern char _ebss;
 	unsigned long addr = (unsigned long) &_ebss;
+#endif
 
 	mapp = &uclinux_ram_map;
 	mapp->phys = addr;
-- 
1.6.3.1

Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[Paul Mundt]

On Tue, May 26, 2009 at 05:46:31AM -0400, Mike Frysinger wrote:
> diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
> index 57699c2..dcb552f 100644
> --- a/drivers/mtd/maps/uclinux.c
> +++ b/drivers/mtd/maps/uclinux.c
> @@ -55,8 +55,13 @@ static int __init uclinux_mtd_init(void)
>  {
>  	struct mtd_info *mtd;
>  	struct map_info *mapp;
> +#ifdef CONFIG_BLACKFIN
> +	extern unsigned long memory_mtd_start;
> +	unsigned long addr = (unsigned long) memory_mtd_start;
> +#else
>  	extern char _ebss;
>  	unsigned long addr = (unsigned long) &_ebss;
> +#endif
>  
>  	mapp = &uclinux_ram_map;
>  	mapp->phys = addr;

NAK.

I know there's no accounting for taste, but it would be nice to at least
see some minimal amount of effort going in to fixing these things
sanely rather than just lazily shoving ifdefs in wherever possible.

In this case you should just kill all of that crap off, and have the
platforms that use this set uclinux_ram_map up themselves, it's already
a global. Of course you can use _ebss as a default value for
uclinux_ram_map.phys and just override it in your platform.

Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[Mike Frysinger]

On Tue, May 26, 2009 at 07:31, Paul Mundt wrote:
> On Tue, May 26, 2009 at 05:46:31AM -0400, Mike Frysinger wrote:
>> diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
>> index 57699c2..dcb552f 100644
>> --- a/drivers/mtd/maps/uclinux.c
>> +++ b/drivers/mtd/maps/uclinux.c
>> @@ -55,8 +55,13 @@ static int __init uclinux_mtd_init(void)
>>  {
>>       struct mtd_info *mtd;
>>       struct map_info *mapp;
>> +#ifdef CONFIG_BLACKFIN
>> +     extern unsigned long memory_mtd_start;
>> +     unsigned long addr = (unsigned long) memory_mtd_start;
>> +#else
>>       extern char _ebss;
>>       unsigned long addr = (unsigned long) &_ebss;
>> +#endif
>>
>>       mapp = &uclinux_ram_map;
>>       mapp->phys = addr;
>
> NAK.
>
> I know there's no accounting for taste, but it would be nice to at least
> see some minimal amount of effort going in to fixing these things
> sanely rather than just lazily shoving ifdefs in wherever possible.
>
> In this case you should just kill all of that crap off, and have the
> platforms that use this set uclinux_ram_map up themselves, it's already
> a global. Of course you can use _ebss as a default value for
> uclinux_ram_map.phys and just override it in your platform.

i would agree if it were a board-specific issue, but it's an arch
issue, so pushing it to the boards level is wrong.  i can however
replace the addr with a global weak and add a symbol into the Blackfin
arch code to override it.

the structs being global in this file is simply wrong from what i can
tell ... everything in there should be static.  i'll send a patch for
that later on.
-mike

Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[Paul Mundt]

On Tue, May 26, 2009 at 12:42:48PM -0400, Mike Frysinger wrote:
> On Tue, May 26, 2009 at 07:31, Paul Mundt wrote:
> > On Tue, May 26, 2009 at 05:46:31AM -0400, Mike Frysinger wrote:
> >> diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
> >> index 57699c2..dcb552f 100644
> >> --- a/drivers/mtd/maps/uclinux.c
> >> +++ b/drivers/mtd/maps/uclinux.c
> >> @@ -55,8 +55,13 @@ static int __init uclinux_mtd_init(void)
> >> ??{
> >> ?? ?? ?? struct mtd_info *mtd;
> >> ?? ?? ?? struct map_info *mapp;
> >> +#ifdef CONFIG_BLACKFIN
> >> + ?? ?? extern unsigned long memory_mtd_start;
> >> + ?? ?? unsigned long addr = (unsigned long) memory_mtd_start;
> >> +#else
> >> ?? ?? ?? extern char _ebss;
> >> ?? ?? ?? unsigned long addr = (unsigned long) &_ebss;
> >> +#endif
> >>
> >> ?? ?? ?? mapp = &uclinux_ram_map;
> >> ?? ?? ?? mapp->phys = addr;
> >
> > NAK.
> >
> > I know there's no accounting for taste, but it would be nice to at least
> > see some minimal amount of effort going in to fixing these things
> > sanely rather than just lazily shoving ifdefs in wherever possible.
> >
> > In this case you should just kill all of that crap off, and have the
> > platforms that use this set uclinux_ram_map up themselves, it's already
> > a global. Of course you can use _ebss as a default value for
> > uclinux_ram_map.phys and just override it in your platform.
> 
> i would agree if it were a board-specific issue, but it's an arch
> issue, so pushing it to the boards level is wrong.  i can however
> replace the addr with a global weak and add a symbol into the Blackfin
> arch code to override it.
> 
I obviously meant architectures setting up the address, not the board
code, as this has nothing at all to do with boards. There are already
plenty of cases in setup_arch() for filling in uclinux mtd data, one more
isn't going to make a difference.

I don't see anything wrong with keeping uclinux_ram_map as a global
however, particularly since platforms that need to special case the
mapping can easily do this under the existing ifdef. Adding weak symbols
for something like this just seems silly.

Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[Mike Frysinger]

On Tue, May 26, 2009 at 12:47, Paul Mundt wrote:
> On Tue, May 26, 2009 at 12:42:48PM -0400, Mike Frysinger wrote:
>> On Tue, May 26, 2009 at 07:31, Paul Mundt wrote:
>> > On Tue, May 26, 2009 at 05:46:31AM -0400, Mike Frysinger wrote:
>> >> diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
>> >> index 57699c2..dcb552f 100644
>> >> --- a/drivers/mtd/maps/uclinux.c
>> >> +++ b/drivers/mtd/maps/uclinux.c
>> >> @@ -55,8 +55,13 @@ static int __init uclinux_mtd_init(void)
>> >> ??{
>> >> ?? ?? ?? struct mtd_info *mtd;
>> >> ?? ?? ?? struct map_info *mapp;
>> >> +#ifdef CONFIG_BLACKFIN
>> >> + ?? ?? extern unsigned long memory_mtd_start;
>> >> + ?? ?? unsigned long addr = (unsigned long) memory_mtd_start;
>> >> +#else
>> >> ?? ?? ?? extern char _ebss;
>> >> ?? ?? ?? unsigned long addr = (unsigned long) &_ebss;
>> >> +#endif
>> >>
>> >> ?? ?? ?? mapp = &uclinux_ram_map;
>> >> ?? ?? ?? mapp->phys = addr;
>> >
>> > NAK.
>> >
>> > I know there's no accounting for taste, but it would be nice to at least
>> > see some minimal amount of effort going in to fixing these things
>> > sanely rather than just lazily shoving ifdefs in wherever possible.
>> >
>> > In this case you should just kill all of that crap off, and have the
>> > platforms that use this set uclinux_ram_map up themselves, it's already
>> > a global. Of course you can use _ebss as a default value for
>> > uclinux_ram_map.phys and just override it in your platform.
>>
>> i would agree if it were a board-specific issue, but it's an arch
>> issue, so pushing it to the boards level is wrong.  i can however
>> replace the addr with a global weak and add a symbol into the Blackfin
>> arch code to override it.
>>
> I obviously meant architectures setting up the address, not the board
> code, as this has nothing at all to do with boards. There are already
> plenty of cases in setup_arch() for filling in uclinux mtd data, one more
> isn't going to make a difference.
>
> I don't see anything wrong with keeping uclinux_ram_map as a global
> however, particularly since platforms that need to special case the
> mapping can easily do this under the existing ifdef. Adding weak symbols
> for something like this just seems silly.

the point of the weak symbol was so that the map could provide a sane
default that works for most everyone out there without having to copy
& paste the same code to every arch, and to make new arch porters
worry about what needs to be done to use this very trivial map
-mike

Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[Paul Mundt]

On Tue, May 26, 2009 at 12:50:51PM -0400, Mike Frysinger wrote:
> On Tue, May 26, 2009 at 12:47, Paul Mundt wrote:
> > On Tue, May 26, 2009 at 12:42:48PM -0400, Mike Frysinger wrote:
> >> > In this case you should just kill all of that crap off, and have the
> >> > platforms that use this set uclinux_ram_map up themselves, it's already
> >> > a global. Of course you can use _ebss as a default value for
> >> > uclinux_ram_map.phys and just override it in your platform.
> >>
> >> i would agree if it were a board-specific issue, but it's an arch
> >> issue, so pushing it to the boards level is wrong. ??i can however
> >> replace the addr with a global weak and add a symbol into the Blackfin
> >> arch code to override it.
> >>
> > I obviously meant architectures setting up the address, not the board
> > code, as this has nothing at all to do with boards. There are already
> > plenty of cases in setup_arch() for filling in uclinux mtd data, one more
> > isn't going to make a difference.
> >
> > I don't see anything wrong with keeping uclinux_ram_map as a global
> > however, particularly since platforms that need to special case the
> > mapping can easily do this under the existing ifdef. Adding weak symbols
> > for something like this just seems silly.
> 
> the point of the weak symbol was so that the map could provide a sane
> default that works for most everyone out there without having to copy
> & paste the same code to every arch, and to make new arch porters
> worry about what needs to be done to use this very trivial map

Did you purposely only read the parts of my email that you felt like?
Note the original quoted part that mentions using _ebss as a default and
simply overriding it in your platform.

Use the attached, and then just set uclinux_ram_map.phys = your_address_here
in your setup_arch(). Having weak symbols in drivers that are supposed to
be overriden by the architecture code is just way too backwards for
words. Globals suffice fine for this sort of thing, if you are not going
to go to the effort to pass this information to the driver directly that
is.

---

diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
index 81756e3..12f822d 100644
--- a/drivers/mtd/maps/uclinux.c
+++ b/drivers/mtd/maps/uclinux.c
@@ -22,8 +22,11 @@
 
 /****************************************************************************/
 
+extern char _ebss;
+
 struct map_info uclinux_ram_map = {
 	.name = "RAM",
+	.phys = (unsigned long)&_ebss,
 };
 
 struct mtd_info *uclinux_ram_mtdinfo;
@@ -55,12 +58,9 @@ static int __init uclinux_mtd_init(void)
 {
 	struct mtd_info *mtd;
 	struct map_info *mapp;
-	extern char _ebss;
-	unsigned long addr = (unsigned long) &_ebss;
 
 	mapp = &uclinux_ram_map;
-	mapp->phys = addr;
-	mapp->size = PAGE_ALIGN(ntohl(*((unsigned long *)(addr + 8))));
+	mapp->size = PAGE_ALIGN(ntohl(*((unsigned long *)(mapp->phys + 8))));
 	mapp->bankwidth = 4;
 
 	printk("uclinux[mtd]: RAM probe address=0x%x size=0x%x\n",

Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[Mike Frysinger]

On Tue, May 26, 2009 at 13:06, Paul Mundt wrote:
> On Tue, May 26, 2009 at 12:50:51PM -0400, Mike Frysinger wrote:
>> On Tue, May 26, 2009 at 12:47, Paul Mundt wrote:
>> > On Tue, May 26, 2009 at 12:42:48PM -0400, Mike Frysinger wrote:
>> >> > In this case you should just kill all of that crap off, and have the
>> >> > platforms that use this set uclinux_ram_map up themselves, it's already
>> >> > a global. Of course you can use _ebss as a default value for
>> >> > uclinux_ram_map.phys and just override it in your platform.
>> >>
>> >> i would agree if it were a board-specific issue, but it's an arch
>> >> issue, so pushing it to the boards level is wrong. ??i can however
>> >> replace the addr with a global weak and add a symbol into the Blackfin
>> >> arch code to override it.
>> >>
>> > I obviously meant architectures setting up the address, not the board
>> > code, as this has nothing at all to do with boards. There are already
>> > plenty of cases in setup_arch() for filling in uclinux mtd data, one more
>> > isn't going to make a difference.
>> >
>> > I don't see anything wrong with keeping uclinux_ram_map as a global
>> > however, particularly since platforms that need to special case the
>> > mapping can easily do this under the existing ifdef. Adding weak symbols
>> > for something like this just seems silly.
>>
>> the point of the weak symbol was so that the map could provide a sane
>> default that works for most everyone out there without having to copy
>> & paste the same code to every arch, and to make new arch porters
>> worry about what needs to be done to use this very trivial map
>
> Did you purposely only read the parts of my email that you felt like?
> Note the original quoted part that mentions using _ebss as a default and
> simply overriding it in your platform.

if i wanted to piss you off, i imagine that would be what i was doing.
 but considering my purpose is to get merged, there's a more logical
conclusion.  we envisioned different solutions, so having the ideas in
our minds not line up isnt terribly surprising.

> Use the attached, and then just set uclinux_ram_map.phys = your_address_here
> in your setup_arch(). Having weak symbols in drivers that are supposed to
> be overriden by the architecture code is just way too backwards for
> words. Globals suffice fine for this sort of thing, if you are not going
> to go to the effort to pass this information to the driver directly that
> is.

i was thinking something else, but obviously this is nicer than what i
was thinking
-mike

Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[Paul Mundt]

On Tue, May 26, 2009 at 01:24:46PM -0400, Mike Frysinger wrote:
> On Tue, May 26, 2009 at 13:06, Paul Mundt wrote:
> > Use the attached, and then just set uclinux_ram_map.phys = your_address_here
> > in your setup_arch(). Having weak symbols in drivers that are supposed to
> > be overriden by the architecture code is just way too backwards for
> > words. Globals suffice fine for this sort of thing, if you are not going
> > to go to the effort to pass this information to the driver directly that
> > is.
> 
> i was thinking something else, but obviously this is nicer than what i
> was thinking

Unfortunately there is the problem that the map driver itself is a
tristate, so if this is built as a module, the symbol will not be
available to you. On the other hand, if it doesn't need to ever really be
a module, converting it to a bool ought to be workable. There are no
in-tree users that enable this as a module anyways.

Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[Mike Frysinger]

On Tue, May 26, 2009 at 19:19, Paul Mundt wrote:
> On Tue, May 26, 2009 at 01:24:46PM -0400, Mike Frysinger wrote:
>> On Tue, May 26, 2009 at 13:06, Paul Mundt wrote:
>> > Use the attached, and then just set uclinux_ram_map.phys = your_address_here
>> > in your setup_arch(). Having weak symbols in drivers that are supposed to
>> > be overriden by the architecture code is just way too backwards for
>> > words. Globals suffice fine for this sort of thing, if you are not going
>> > to go to the effort to pass this information to the driver directly that
>> > is.
>>
>> i was thinking something else, but obviously this is nicer than what i
>> was thinking
>
> Unfortunately there is the problem that the map driver itself is a
> tristate, so if this is built as a module, the symbol will not be
> available to you. On the other hand, if it doesn't need to ever really be
> a module, converting it to a bool ought to be workable. There are no
> in-tree users that enable this as a module anyways.

weaks would address that, but there is no real point as you say.  it
isnt like the rootfs image gets loaded as part of the module loading.
i'll send a patch for that too.  the Blackfin code all depends on
CONFIG_MTD_UCLINUX, so the rootfs area wouldnt be setup anyways if it
were built as a module ...
-mike

Re: [uClinux-dev] Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems

[David McCullough]

Jivin Paul Mundt lays it down ...
> On Tue, May 26, 2009 at 01:24:46PM -0400, Mike Frysinger wrote:
> > On Tue, May 26, 2009 at 13:06, Paul Mundt wrote:
> > > Use the attached, and then just set uclinux_ram_map.phys = your_address_here
> > > in your setup_arch(). Having weak symbols in drivers that are supposed to
> > > be overriden by the architecture code is just way too backwards for
> > > words. Globals suffice fine for this sort of thing, if you are not going
> > > to go to the effort to pass this information to the driver directly that
> > > is.
> > 
> > i was thinking something else, but obviously this is nicer than what i
> > was thinking
> 
> Unfortunately there is the problem that the map driver itself is a
> tristate, so if this is built as a module, the symbol will not be
> available to you. On the other hand, if it doesn't need to ever really be
> a module, converting it to a bool ought to be workable. There are no
> in-tree users that enable this as a module anyways.

Based on how it relocates the rootfs,  I don't believe a module can ever
be work,  so a boolean would be a better choice IMO,

Cheers,
Davidm

-- 
David McCullough,  david_mccullough@securecomputing.com,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

[PATCH 1/3] mtd/maps: uclinux: allow systems to override map addr/size

[Mike Frysinger]

Due to a processor anomaly (05000263 to be exact), most Blackfin parts
cannot keep the embedded filesystem image directly after the kernel in
RAM.  Instead, the filesystem needs to be relocated to the end of memory.
As such, we need to tweak the map addr/size during boot for Blackfin
systems.  This can be done in any early arch/board init code.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Paul Mundt <lethal@linux-sh.org>
CC: Greg Ungerer <gerg@uclinux.org>
CC: uclinux-dev@uclinux.org
CC: linux-mtd@lists.infradead.org
---
 drivers/mtd/maps/uclinux.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
index 81756e3..61d4087 100644
--- a/drivers/mtd/maps/uclinux.c
+++ b/drivers/mtd/maps/uclinux.c
@@ -22,8 +22,12 @@
 
 /****************************************************************************/
 
+extern char _ebss;
+
 struct map_info uclinux_ram_map = {
 	.name = "RAM",
+	.phys = (unsigned long)&_ebss,
+	.size = 0,
 };
 
 struct mtd_info *uclinux_ram_mtdinfo;
@@ -55,12 +59,10 @@ static int __init uclinux_mtd_init(void)
 {
 	struct mtd_info *mtd;
 	struct map_info *mapp;
-	extern char _ebss;
-	unsigned long addr = (unsigned long) &_ebss;
 
 	mapp = &uclinux_ram_map;
-	mapp->phys = addr;
-	mapp->size = PAGE_ALIGN(ntohl(*((unsigned long *)(addr + 8))));
+	if (!mapp->size)
+		mapp->size = PAGE_ALIGN(ntohl(*((unsigned long *)(mapp->phys + 8))));
 	mapp->bankwidth = 4;
 
 	printk("uclinux[mtd]: RAM probe address=0x%x size=0x%x\n",
-- 
1.6.3.1

Re: [PATCH 1/3] mtd/maps: uclinux: allow systems to override map addr/size

[Paul Mundt]

On Tue, May 26, 2009 at 07:33:16PM -0400, Mike Frysinger wrote:
> Due to a processor anomaly (05000263 to be exact), most Blackfin parts
> cannot keep the embedded filesystem image directly after the kernel in
> RAM.  Instead, the filesystem needs to be relocated to the end of memory.
> As such, we need to tweak the map addr/size during boot for Blackfin
> systems.  This can be done in any early arch/board init code.
> 
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> CC: Paul Mundt <lethal@linux-sh.org>
> CC: Greg Ungerer <gerg@uclinux.org>
> CC: uclinux-dev@uclinux.org
> CC: linux-mtd@lists.infradead.org

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

Re: [PATCH 1/3] mtd/maps: uclinux: allow systems to override map addr/size

[Paul Mundt]

On Tue, May 26, 2009 at 07:33:16PM -0400, Mike Frysinger wrote:
> +extern char _ebss;
> +
Also, it would be nice if the remaining architectures that define _ebss
could shove this in their asm/sections.h so we can kill this off from the
driver itself.

Re: [PATCH 1/3] mtd/maps: uclinux: allow systems to override map addr/size

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

On Tuesday 26 May 2009 19:46:16 Paul Mundt wrote:
> On Tue, May 26, 2009 at 07:33:16PM -0400, Mike Frysinger wrote:
> > +extern char _ebss;
> > +
>
> Also, it would be nice if the remaining architectures that define _ebss
> could shove this in their asm/sections.h so we can kill this off from the
> driver itself.

well, everyone would still have to define the _ebss symbol otherwise they'd 
get an undefined error due to how the map is initialized.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/3] mtd/maps: uclinux: allow systems to override map addr/size

[Paul Mundt]

On Tue, May 26, 2009 at 08:46:24PM -0400, Mike Frysinger wrote:
> On Tuesday 26 May 2009 19:46:16 Paul Mundt wrote:
> > On Tue, May 26, 2009 at 07:33:16PM -0400, Mike Frysinger wrote:
> > > +extern char _ebss;
> > > +
> >
> > Also, it would be nice if the remaining architectures that define _ebss
> > could shove this in their asm/sections.h so we can kill this off from the
> > driver itself.
> 
> well, everyone would still have to define the _ebss symbol otherwise they'd 
> get an undefined error due to how the map is initialized.

Yes, but that is not the issue. The issue is that the section
extern has no place in a driver, this is precisely what asm/sections.h is
for. Only microblaze and sh define it there today, and there is already
inconsistency. Having the others define it for themselves and agreeing on
a type would permit us to kill it off from the driver.

Re: [PATCH 1/3] mtd/maps: uclinux: allow systems to override map addr/size

[Artem Bityutskiy]

On Tue, 2009-05-26 at 19:33 -0400, Mike Frysinger wrote:
> Due to a processor anomaly (05000263 to be exact), most Blackfin parts
> cannot keep the embedded filesystem image directly after the kernel in
> RAM.  Instead, the filesystem needs to be relocated to the end of memory.
> As such, we need to tweak the map addr/size during boot for Blackfin
> systems.  This can be done in any early arch/board init code.
> 
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> CC: Paul Mundt <lethal@linux-sh.org>
> CC: Greg Ungerer <gerg@uclinux.org>
> CC: uclinux-dev@uclinux.org
> CC: linux-mtd@lists.infradead.org
> ---
>  drivers/mtd/maps/uclinux.c |   10 ++++++----
>  1 files changed, 6 insertions(+), 4 deletions(-)

I've added your patches to my tree.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

[PATCH 2/3] mtd/maps: uclinux: mark local stuff static

[Mike Frysinger]

The uclinux_ram_mtdinfo, uclinux_romfs, and uclinux_point symbols do not
need to be visible outside of this module, so mark them static.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Greg Ungerer <gerg@uclinux.org>
CC: uclinux-dev@uclinux.org
CC: linux-mtd@lists.infradead.org
---
 drivers/mtd/maps/uclinux.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
index 61d4087..d4314fb 100644
--- a/drivers/mtd/maps/uclinux.c
+++ b/drivers/mtd/maps/uclinux.c
@@ -30,11 +30,11 @@ struct map_info uclinux_ram_map = {
 	.size = 0,
 };
 
-struct mtd_info *uclinux_ram_mtdinfo;
+static struct mtd_info *uclinux_ram_mtdinfo;
 
 /****************************************************************************/
 
-struct mtd_partition uclinux_romfs[] = {
+static struct mtd_partition uclinux_romfs[] = {
 	{ .name = "ROMfs" }
 };
 
@@ -42,7 +42,7 @@ struct mtd_partition uclinux_romfs[] = {
 
 /****************************************************************************/
 
-int uclinux_point(struct mtd_info *mtd, loff_t from, size_t len,
+static int uclinux_point(struct mtd_info *mtd, loff_t from, size_t len,
 	size_t *retlen, void **virt, resource_size_t *phys)
 {
 	struct map_info *map = mtd->priv;
-- 
1.6.3.1

Re: [PATCH 2/3] mtd/maps: uclinux: mark local stuff static

[Greg Ungerer]

Mike Frysinger wrote:
> The uclinux_ram_mtdinfo, uclinux_romfs, and uclinux_point symbols do not
> need to be visible outside of this module, so mark them static.
> 
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> CC: Greg Ungerer <gerg@uclinux.org>

Acked-by: Greg Ungerer <gerg@uclinux.org>


> CC: uclinux-dev@uclinux.org
> CC: linux-mtd@lists.infradead.org
> ---
>  drivers/mtd/maps/uclinux.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
> index 61d4087..d4314fb 100644
> --- a/drivers/mtd/maps/uclinux.c
> +++ b/drivers/mtd/maps/uclinux.c
> @@ -30,11 +30,11 @@ struct map_info uclinux_ram_map = {
>  	.size = 0,
>  };
>  
> -struct mtd_info *uclinux_ram_mtdinfo;
> +static struct mtd_info *uclinux_ram_mtdinfo;
>  
>  /****************************************************************************/
>  
> -struct mtd_partition uclinux_romfs[] = {
> +static struct mtd_partition uclinux_romfs[] = {
>  	{ .name = "ROMfs" }
>  };
>  
> @@ -42,7 +42,7 @@ struct mtd_partition uclinux_romfs[] = {
>  
>  /****************************************************************************/
>  
> -int uclinux_point(struct mtd_info *mtd, loff_t from, size_t len,
> +static int uclinux_point(struct mtd_info *mtd, loff_t from, size_t len,
>  	size_t *retlen, void **virt, resource_size_t *phys)
>  {
>  	struct map_info *map = mtd->priv;

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

[PATCH 3/3] mtd/maps: uclinux: do not allow to be built as a module

[Mike Frysinger]

There isn't any benefit to building the uClinux MTD map as a module as the
rootfs it requires in order to actually be usable is appended to the
kernel image, not the module.  No known system builds it this way either,
so change the option to "bool".

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Paul Mundt <lethal@linux-sh.org>
CC: Greg Ungerer <gerg@uclinux.org>
CC: uclinux-dev@uclinux.org
CC: linux-mtd@lists.infradead.org
---
 drivers/mtd/maps/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 82923bd..907873b 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -501,7 +501,7 @@ config MTD_BFIN_ASYNC
 	  If compiled as a module, it will be called bfin-async-flash.
 
 config MTD_UCLINUX
-	tristate "Generic uClinux RAM/ROM filesystem support"
+	bool "Generic uClinux RAM/ROM filesystem support"
 	depends on MTD_PARTITIONS && MTD_RAM && !MMU
 	help
 	  Map driver to support image based filesystems for uClinux.
-- 
1.6.3.1

Re: [uClinux-dev] [PATCH 3/3] mtd/maps: uclinux: do not allow to be built as a module

[Greg Ungerer]

Mike Frysinger wrote:
> There isn't any benefit to building the uClinux MTD map as a module as the
> rootfs it requires in order to actually be usable is appended to the
> kernel image, not the module.  No known system builds it this way either,
> so change the option to "bool".
> 
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> CC: Paul Mundt <lethal@linux-sh.org>
> CC: Greg Ungerer <gerg@uclinux.org>

Acked-by: Greg Ungerer <gerg@uclinux.org>


> CC: uclinux-dev@uclinux.org
> CC: linux-mtd@lists.infradead.org
> ---
>  drivers/mtd/maps/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> index 82923bd..907873b 100644
> --- a/drivers/mtd/maps/Kconfig
> +++ b/drivers/mtd/maps/Kconfig
> @@ -501,7 +501,7 @@ config MTD_BFIN_ASYNC
>  	  If compiled as a module, it will be called bfin-async-flash.
>  
>  config MTD_UCLINUX
> -	tristate "Generic uClinux RAM/ROM filesystem support"
> +	bool "Generic uClinux RAM/ROM filesystem support"
>  	depends on MTD_PARTITIONS && MTD_RAM && !MMU
>  	help
>  	  Map driver to support image based filesystems for uClinux.

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: [uClinux-dev] [PATCH 1/2] mtd/maps: uclinux: fix building when partition support is disabled

[Greg Ungerer]

Mike Frysinger wrote:
> From: Timofei Bondarenko <tim@ipi.ac.ru>
> 
> The uClinux map driver doesn't even use partitions, so we shouldn't require
> it in order to work properly.
> 
> Signed-off-by: Timofei Bondarenko <tim@ipi.ac.ru>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> CC: Greg Ungerer <gerg@uclinux.org>

Acked-by: Greg Ungerer <gerg@uclinux.org>


> CC: uclinux-dev@uclinux.org
> CC: linux-mtd@lists.infradead.org
> ---
>  drivers/mtd/maps/uclinux.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
> index 81756e3..57699c2 100644
> --- a/drivers/mtd/maps/uclinux.c
> +++ b/drivers/mtd/maps/uclinux.c
> @@ -87,7 +87,11 @@ static int __init uclinux_mtd_init(void)
>  	mtd->priv = mapp;
>  
>  	uclinux_ram_mtdinfo = mtd;
> +#ifdef CONFIG_MTD_PARTITIONS
>  	add_mtd_partitions(mtd, uclinux_romfs, NUM_PARTITIONS);
> +#else
> +	add_mtd_device(mtd);
> +#endif
>  
>  	return(0);
>  }
> @@ -97,7 +101,11 @@ static int __init uclinux_mtd_init(void)
>  static void __exit uclinux_mtd_cleanup(void)
>  {
>  	if (uclinux_ram_mtdinfo) {
> +#ifdef CONFIG_MTD_PARTITIONS
>  		del_mtd_partitions(uclinux_ram_mtdinfo);
> +#else
> +		del_mtd_device(uclinux_ram_mtdinfo);
> +#endif
>  		map_destroy(uclinux_ram_mtdinfo);
>  		uclinux_ram_mtdinfo = NULL;
>  	}

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com