Re: [uClinux-dev] [PATCH/RFC] mtd/uclinux: Use generic __bss_stop instead of _ebss
On Thu, May 31, 2012 at 10:55:39PM +0200, Geert Uytterhoeven wrote:
The standard (see BSS_SECTION() in asm-generic/vmlinux.lds.h and
asm-generic/sections.h) symbol for the end of BSS is __bss_stop.
This allows to remove all local declarations that have been added to
several architectures just to please CONFIG_MTD_UCLINUX.
Not-Yet-Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
This is a prerequisite for some future m68k changes:
- replacing the m68k-specific _[se]bss by the generic __bss_{start,stop},
- using the asm-generic version of asm/sections.h.
I like it. The only reason we have _ebss on sh at all is for the mtd map
anyways.
Acked-by: Paul Mundt let...@linux-sh.org
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] NOMMU: support SMP dynamic percpu_alloc
On Tue, Mar 22, 2011 at 04:41:46PM -0400, Mike Frysinger wrote: From: Graf Yang graf.y...@analog.com The percpu code requires more functions to be implemented in the mm core which nommu currently does not provide. So add inline implementations since these are largely meaningless on nommu systems. Signed-off-by: Graf Yang graf.y...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org Looks ok to me. I've got a couple other fixes I'm working on at the moment, so I'll roll this in to my nommu tree and send it along. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Userspace command line gcc options troubles
(Adding superh-gnu-discuss to the Cc..)
On Fri, Jun 18, 2010 at 09:20:13AM +0200, Fabio Giovagnini wrote:
This is the result (i suppose):
*asm:
%(subtarget_asm_endian_spec) %{mrelax:-relax
%(subtarget_asm_relax_spec)}%(subtarget_asm_isa_spec) %(subtarget_asm_spec)
%{m2a:--isa=sh2a} %{m2a-single:--isa=sh2a} %{m2a-single-only:--isa=sh2a}
%{m2a-nofpu:--isa=sh2a-nofpu} %{m5-compact*:--isa=SHcompact} %{m5-32media*:--
isa=SHmedia --abi=32} %{m5-64media*:--isa=SHmedia --abi=64} %{m4al:-dsp}
%{mcut2-workaround:-cut2-workaround}
Nowhere I can see :
--fdpic--isa=sh2a
I think it should be
--fdpic --isa=sh2a
at most (with a blank space in between)
In data gioved? 17 giugno 2010 23:03:47, Daniel Gl?ckner ha scritto:
: On Thu, Jun 17, 2010 at 12:32:56PM +0200, Fabio Giovagnini wrote:
uclinux/bin/as: unrecognized option '--fdpic--isa=sh2a'
How could I solve?
cd /home/fgiovagnini/sh7203/sh7203-uclinux-4.4-206/build/target/
./bin/sh-uclinux-gcc -dumpspecs lib/gcc/sh-uclinux/4.4.1/specs
sed -i 's/subtarget_asm_spec)/ /' lib/gcc/sh-uclinux/4.4.1/specs
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] FLAT: allow arches to declare a larger alignment than the slab
On Tue, May 25, 2010 at 03:24:27PM -0400, Mike Frysinger wrote: This stems from the alignment usage in the FLAT loader. The behavior before was that FLAT would default to ARCH_SLAB_MINALIGN only if it was defined, and this was only defined by arches when they wanted a larger alignment value. Otherwise it'd default to pointer alignment. Arguably, this is kind of hokey that the FLAT is semi-abusing defines it shouldn't. This needs some explaining. What exactly do you find problematic with ARCH_SLAB_MINALIGN in this case? For the case that was introduced leading up to the wrapping of the minalign value it was absolutely the proper thing to use. If blackfin has special alignment requirements on top of that, then that's certainly fine, but it doesn't negate the validity of the minalign wrapping for the other platforms. /* - * User data (stack, data section and bss) needs to be aligned - * for the same reasons as SLAB memory is, and to the same amount. + * User data (stack, data section and bss) needs to be aligned. + * If ARCH_FLAT_DATA_ALIGN is defined, use it. + */ If you're going to update the comment, the update should at least serve some purpose. This not only obscures the reason for the slab minalign wrapping, it also fails to suggest why anyone would deviate from that. If the intention is that ARCH_FLAT_DATA_ALIGN provides cacheline alignment on blackfin, then use ARCH_KMALLOC_MINALIGN like everyone else. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] FLAT: allow arches to declare a larger alignment than the slab
On Wed, May 26, 2010 at 03:23:02AM -0400, Mike Frysinger wrote: On Wed, May 26, 2010 at 02:59, Geert Uytterhoeven wrote: From looking at linux/flat.h, it looks like the FLAT binary format doesn't contain any alignment information? So if I put __attribute__((aligned(4096))) in a file, there's still no guarantee it will actually be in memory at a 4Ki-aligned address? i believe that is correct. FLAT behavior today provides alignment of either sizeof(unsigned long) or ARCH_SLAB_MINALIGN. i imagine something like this would work today because everyone defines it to a constant: -#ifdef ARCH_SLAB_MINALIGN +#if defined(ARCH_SLAB_MINALIGN) ARCH_SLAB_MINALIGN != 0 but this would break if someone tried using gcc sizeof/alignof/etc... alignof is used by SLUB/SLOB to set the ARCH_SLAB_MINALIGN value if the architecture hasn't already specified one, so that wouldn't work. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH] FLAT: allow arches to declare a larger alignment than the slab
On Tue, May 25, 2010 at 07:17:16PM -0400, Mike Frysinger wrote: FLAT is using ARCH_SLAB_MINALIGN to align the stack and align the data section. as such, Blackfin needs 4 byte alignment here. the previous FLAT behavior was use arch slab sizes if defined, otherwise use sizeof(void*). this worked fine for us size sizeof(void*) == 4. now with ARCH_SLAB_MINALIGN being in global space, this defaults to 0 for us and the manual stack data alignment no longer work. i'm a schlub when it comes to these allocators, so i know as much as the documentation states. slab_def.h says: * Enforce a minimum alignment for all caches. * Intended for archs that get misalignment faults even for BYTES_PER_WORD * aligned buffers. this comment does not seem to apply to Blackfin as BYTES_PER_WORD is 4 and we can work with anything aligned to 4 bytes. The comment here is a bit misleading, it's true that SLAB will happily align to BYTES_PER_WORD as a default if nothing else is specified, but it's also true that a growing number of structures contain 64-bit values that need to be accessed on 64-bit boundaries on 32-bit platforms. If this doesn't apply to blackfin then simply sticking with the default is fine. SLAB/SLOB will align to 4 bytes while SLUB will presently align to 8. to be sure, we dont need 0x20 alignment in general. i just figured kill two birds with one patch here. and Blackfin is already setting ARCH_KMALLOC_MINALIGN to cacheline size, but that wouldnt make any difference in these issues. I have no objections to adding a new alignment value for binfmt_flat, but given the confusion that exists around things like ARCH_SLAB_MINALIGN and ARCH_KMALLOC_MINALIGN already today it should be quite obvious what exactly the new value is for and what case it is specifically addressing. My guess is that the issues you are seeing with the gcc testsuite will also pop up on other nommu platforms, so it may be something we want to just deal with generically. At least I suspect you guys are running the gcc testsuite a lot more frequently than the rest of us! ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: smc9118 problem
On Mon, Mar 22, 2010 at 08:19:48PM +0100, Fabio Giovagnini wrote: Hi all, II have a problem with smc9118 chip; I do not make any eeprom initialitazione because I do not have any eeprom on my board. When occurs an rx overrun the chip stops to receive, and I have experienced that doing ~ cat /proc/smc911x/resetphy ~ cat /proc/smc911x/resetsmc ~ cat /proc/smc911x/enable it restart properly. I'm using kernel 2.6.17; does any of you have suggetion about I nedd to check for discover which bits I have to set in case of rx overrun? Please verify whether you can reproduce this with 2.6.34-rc2, thanks. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 4/4] elf_fdpic_core_dump(): fix build break in 2.6.33-rc1
On Wed, Jan 06, 2010 at 05:23:33PM +, David Howells wrote: From: Daisuke HATAYAMA d.hatay...@jp.fujitsu.com Commit f6151dfea21496d43dbaba32cfcd9c9f404769bc causes ELF-FDPIC to break during building, so this patch fixes it together with a correction for the printk format. Signed-off-by: Daisuke HATAYAMA d.hatay...@jp.fujitsu.com Reviewed-by: Masami Hiramatsu mhira...@redhat.com Acked-by: Paul Mundt let...@linux-sh.org Signed-off-by: David Howells dhowe...@redhat.com I already pushed this through my tree, so you can just ignore this one. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] NOMMU: use copy_*_user_page() in access_process_vm()
On Wed, Nov 25, 2009 at 02:27:22PM +0800, Jie Zhang wrote: On 11/25/2009 02:16 PM, Jamie Lokier wrote: Mike Frysinger wrote: From: Jie Zhangjie.zh...@analog.com The mmu code uses the copy_*_user_page() variants in access_process_vm() rather than copy_*_user() as the former includes an icache flush. This is important when doing things like setting software breakpoints with gdb. So switch the nommu code over to do the same. Reasonable, but it's a bit subtle don't you think? How about a one-line comment saying why it's using copy_*_user_page()? (If it was called copy_*_user_flush_icache() I wouldn't say anything, but it isn't). But I think it's well known in Linux kernel developers that copy_to_user_page and copy_from_user_page should do cache flushing. It's documented in Documentation/cachetlb.txt. I don't think it's necessary to replicate it here. Documenting it in the changelog is sufficient I think. Platforms that need the I-cache flush can deal with it there, and those that don't aren't going to notice any difference regardless. The change in semantics is subtle, but as it's bringing it in line with MMU behaviour it's not really worth noting the fact that NOMMU behaviour used to be different for no particular reason. Acked-by: Paul Mundt let...@linux-sh.org ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v2] NOMMU: fix malloc performance by adding uninitialized flag
On Tue, Oct 13, 2009 at 07:20:21AM -0400, Mike Frysinger wrote: From: Jie Zhang jie.zh...@analog.com The NOMMU code currently clears all anonymous mmapped memory. While this is what we want in the default case, all memory allocation from userspace under NOMMU has to go through this interface, including malloc() which is allowed to return uninitialized memory. This can easily be a significant performance penalty. So for constrained embedded systems were security is irrelevant, allow people to avoid clearing memory unnecessarily. This also alters the ELF-FDPIC binfmt such that it obtains uninitialised memory for the brk and stack region. Signed-off-by: Jie Zhang jie.zh...@analog.com Signed-off-by: Robin Getz rg...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org Signed-off-by: David Howells dhowe...@redhat.com Acked-by: Paul Mundt let...@linux-sh.org ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
On Fri, Jun 12, 2009 at 09:01:09PM -0400, Mike Frysinger wrote: From: Jie Zhang jie.zh...@analog.com The Blackfin port has custom program header flags/addresses for automatically loading regions into the dedicated on-chip SRAM. So add a hook for ports to leverage. Signed-off-by: Jie Zhang jie.zh...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org CC: Bernd Schmidt bernds_...@t-online.de Acked-by: Paul Mundt let...@linux-sh.org ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems
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.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems
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.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems
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,
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 2/2] mtd/maps: uclinux: support Blackfin systems
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. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 1/3] mtd/maps: uclinux: allow systems to override map addr/size
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 vap...@gentoo.org CC: Paul Mundt let...@linux-sh.org CC: Greg Ungerer g...@uclinux.org CC: uclinux-dev@uclinux.org CC: linux-...@lists.infradead.org Signed-off-by: Paul Mundt let...@linux-sh.org ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 1/3] mtd/maps: uclinux: allow systems to override map addr/size
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. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 1/3] mtd/maps: uclinux: allow systems to override map addr/size
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. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
