Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver forMCF547x/MCF548x
On Wed, Sep 26, 2012 at 01:23:21AM +0200, Stany MARCEL wrote: Helo, Flushing all caches for each sent frame might not be a good solution. I think that performances will be very bad. I'll look at this point in my tests. It might be more interesting to use caches in write through mode, or forcing theses explicit data out of cache. I (and the default for M54xx) use the write through mode. Philippe If kmalloc with GFP_DMA returns data that is not write cached (ideally SRAM for performances) there is no need to flush caches. Regards, -Original Message- From: Philippe De Muyter [mailto:p...@macqel.be] Sent: Tue 9/25/2012 10:34 PM To: Stany MARCEL Cc: uclinux-dev@uclinux.org Subject: Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver forMCF547x/MCF548x On Tue, Sep 25, 2012 at 10:20:07PM +0200, Philippe De Muyter wrote: You should rather use 'mcf_cache_push'. I should have written: You should rather use '__flush_cache_all' And that should probably go in arch/m68k/include/asm/cacheflush_mm.h, as long as arch/m68k/include/asm/cacheflush_mm.h and arch/m68k/include/asm/cacheflush_no.h are separate files. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ___ 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 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x
On 09/26/2012 06:20 AM, Philippe De Muyter wrote: Hello Stany [CCing uclinux-dev] On Tue, Sep 25, 2012 at 06:07:45PM +0200, Stany MARCEL wrote: Hello Philippe, I have to do the following modification to compile your drivers with MMU enabled : diff --git a/drivers/net/ethernet/freescale/fec_m54xx.c b/drivers/net/ethernet/freescale/fec_m54xx.c index 4204a14..f6cafc6 100644 --- a/drivers/net/ethernet/freescale/fec_m54xx.c +++ b/drivers/net/ethernet/freescale/fec_m54xx.c @@ -41,6 +41,10 @@ */ #define flush_and_invalidate_dcache() flush_cache_all() +#ifdef CONFIG_MMU +#defineflush_dcache_range(A, L) flush_cf_dcache(A, L) Drivers shouldn't be calling these architecture flush functions at all. They must use the DMA API and the functions it defines. See Documentation/DMA-API.txt For example look at the use of dma_map_single()/dma_unmap_single() in drivers/net/ethernet/freescale/fec.c. (Ignore the almost certainly bogus cache_flush_all() for CONFIG_M532x). Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close,FAX: +61 7 3891 3630 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ 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] __stack_start for ColdFire uClinux
Hi Larry,
On 09/26/2012 12:49 PM, Larry Baker wrote:
I have been chasing what I suspect are stack overflows in NTP. I spotted
mention of that there was a gcc option, -fstack-check-symbol=__stack_start, for
run-time stack checking on uClinux. I tried that, but it caused an internal
compiler error. My development environment is the Sourcery (now Mentor
Graphics) CodeBench Lite for ColdFire uClinux SDK. I modified their GCC source
to add support for -fstack-limit-symbol. Unfortunately, using the
__stack_start symbol to detect stack overflow does not seem to be working out.
For my test uClinux executable, stack-overflow.c:
#include stdio.h
void overflow( int i ) {
/* Allocate automatic array j[256] so stack limit checking works. */
int j[256];
/* Stack limit checking tests only whether the stack is large enough for */
/* the initial stack allocation: saved registers and automatic variables. */
/* Stack limit checking does not test for stack overflow in the body of a */
/* function. That is what happens when j[] is not present. When j[] is */
/* too large, the program will abnormally terminate on its own (illegal */
/* instruction trap?). j[256] works. */
i++;
printf( i = %i\n, i );
overflow( i );
}
int main() {
overflow( 0 );
return 0;
}
the stack is allocated 4K (0x1000).
How are you setting the app stack size?
When I hacked the .s file to print out the stack pointer and __stack start, it
shows that there is more than 4K between the value in the stack pointer and
__stack_start:
%sp = 0x405f3ee4
__stack_start = 0x405f08b4
That is not what I was expecting.
Can someone shed some light on why %sp is not roughly __stack_start + 0x1000?
__stack_start is defined in the linker script from the Sourcery SDK,
m68k-uclinux/lib/elf2flt.ld, right after .bss and before .junk:
.bss : {
. = ALIGN(0x4) ;
_sbss = ALIGN(0x4) ;
__bss_start = . ;
*(.dynsbss)
*(.sbss)
*(.sbss.*)
*(.scommon)
*(.dynbss)
*(.bss)
*(.bss.*)
*(.bss*)
*(.gnu.linkonce.b*)
*(COMMON)
. = ALIGN(0x10) ;
_ebss = . ;
_end = . ;
end = . ;
} flatmem
.stack : {
. = ALIGN(0x4);
__stack_start = .;
}
This is a little deceptive, and not completely accurate in general.
If you look at what binfmt_flat.c does when loading a flat format file
you will see that that point is labeled the start of the brk region.
When allocating the memory for the process (text, data, stack) we may
get a larger region than requested(1). We use the extra space if we get
it, and that will push the stack further away from the end of the data
region if we do. This is probably what you are seeing. A little trace
in binfmt_flat.c will let you see the exact regions and addresses you
are getting on process start.
(1) Page aligning or buddy allocator rounding means we may get a bit
more, or even potentially a lot more.
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close,FAX: +61 7 3891 3630
Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com
___
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] __stack_start for ColdFire uClinux
Greg,
Hi Larry,
On 09/26/2012 12:49 PM, Larry Baker wrote:
I have been chasing what I suspect are stack overflows in NTP. I spotted
mention of that there was a gcc option, -fstack-check-symbol=__stack_start,
for run-time stack checking on uClinux. I tried that, but it caused an
internal compiler error. My development environment is the Sourcery (now
Mentor Graphics) CodeBench Lite for ColdFire uClinux SDK. I modified their
GCC source to add support for -fstack-limit-symbol. Unfortunately, using
the __stack_start symbol to detect stack overflow does not seem to be
working out. For my test uClinux executable, stack-overflow.c:
#include stdio.h
void overflow( int i ) {
/* Allocate automatic array j[256] so stack limit checking works. */
int j[256];
/* Stack limit checking tests only whether the stack is large enough for */
/* the initial stack allocation: saved registers and automatic variables. */
/* Stack limit checking does not test for stack overflow in the body of a */
/* function. That is what happens when j[] is not present. When j[] is */
/* too large, the program will abnormally terminate on its own (illegal */
/* instruction trap?). j[256] works. */
i++;
printf( i = %i\n, i );
overflow( i );
}
int main() {
overflow( 0 );
return 0;
}
the stack is allocated 4K (0x1000).
How are you setting the app stack size?
I take the default. I build two images: one with and one without
-fstack-limit-symbol=__stack_start:
# toolchains/freescale-coldfire-2011.09-patched/bin/m68k-uclinux-gcc -mcpu=5208
-fomit-frame-pointer -fno-common -fno-builtin -fno-dwarf2-cfi-asm -msep-data -o
no-check-stack-overflow stack-overflow.c
# toolchains/freescale-coldfire-2011.09-patched/bin/m68k-uclinux-gcc -mcpu=5208
-fomit-frame-pointer -fno-common -fno-builtin -fno-dwarf2-cfi-asm -msep-data
-fstack-limit-symbol=__stack_start -o check-stack-overflow stack-overflow.c
The executable says the stack size is 0x1000:
# toolchains/freescale-coldfire-2011.09-patched/bin/m68k-uclinux-flthdr -p
check-stack-overflow
check-stack-overflow
Magic:bFLT
Rev: 4
Build Date: Wed Sep 26 11:54:28 2012
Entry:0x44
Data Start: 0x3c60
Data End: 0x44e4
BSS End: 0x6590
Stack Size: 0x1000
Reloc Start: 0x44e4
Reloc Count: 0x29
Flags:0x2 ( Has-PIC-GOT )
When I hacked the .s file to print out the stack pointer and __stack start,
it shows that there is more than 4K between the value in the stack pointer
and __stack_start:
%sp = 0x405f3ee4
__stack_start = 0x405f08b4
That is not what I was expecting.
This is a little deceptive, and not completely accurate in general.
If you look at what binfmt_flat.c does when loading a flat format file
you will see that that point is labeled the start of the brk region.
When allocating the memory for the process (text, data, stack) we may
get a larger region than requested(1). We use the extra space if we get
it, and that will push the stack further away from the end of the data
region if we do. This is probably what you are seeing.
If this were the case, __stack_start would still be an accurate value for
detecting stack overrun. I see signs of stack overrun before the stack check
trips. When I force a trap (trap #7), I get no messages from the O/S on the
console, and the shell prompt reappears. (Should I see something? Is there a
kernel build option I should enable?) When I run my stack checking test
program with j[32], the hardware watchdog timer trips. I'll have to hack the
.s file some more to print out __stack_start and %sp when this happens.
Perhaps the stack check for j[32] (128 bytes) passes, but the printf library
routine is using more stack and is actually causing the system failure.
There should be nothing but stack between __stack_start and the end of the
region, where the initial %sp points, correct? If not, I can't use
__stack_start as a sentinel.
A little trace
in binfmt_flat.c will let you see the exact regions and addresses you
are getting on process start.
(1) Page aligning or buddy allocator rounding means we may get a bit
more, or even potentially a lot more.
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close,FAX: +61 7 3891 3630
Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
___
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
Re: [uClinux-dev] __stack_start for ColdFire uClinux
Greg,
I hacked the .s file for my stack check test program.
The C code:
# cat stack-overflow.c#include stdio.h
void overflow( int i ) {
/* Allocate automatic array j[256] so stack limit checking works. */
int j[256];
/* Stack limit checking tests only whether the stack is large enough for */
/* the initial stack allocation: saved registers and automatic variables. */
/* Stack limit checking does not test for stack overflow in the body of a */
/* function. That is what happens when j[] is not present. When j[] is */
/* too large, the program will abnormally terminate on its own (illegal */
/* instruction trap?). j[256] works. */
i++;
printf( i = %i\n, i );
overflow( i );
}
int main() {
overflow( 0 );
return 0;
}
# toolchains/freescale-coldfire-2011.09-patched/bin/m68k-uclinux-gcc -mcpu=5208
-fomit-frame-pointer -fno-common -fno-builtin -fno-dwarf2-cfi-asm -msep-data
-fstack-limit-symbol=__stack_start -S -o stack-overflow.s stack-overflow.c
The original .s file:
# cat stack-overflow.s
#NO_APP
.file stack-overflow.c
.section.rodata
.LC0:
.string i = %i\n
.text
.align 2
.globl overflow
.type overflow, @function
overflow:
move.l __stack_start@GOT(%a5),%a0
lea (1028,%a0),%a0
cmp.l %sp,%a0
bls.s .+4
trap #7
lea (-1024,%sp),%sp
move.l %a5,-(%sp)
addq.l #1,1032(%sp)
move.l .LC0@GOT(%a5),%d0
move.l 1032(%sp),-(%sp)
move.l %d0,-(%sp)
move.l printf@GOT(%a5),%d0
move.l %d0,%a0
jsr (%a0)
addq.l #8,%sp
move.l 1032(%sp),-(%sp)
move.l overflow@GOT(%a5),%d0
move.l %d0,%a0
jsr (%a0)
addq.l #4,%sp
move.l (%sp)+,%a5
lea (1024,%sp),%sp
rts
.size overflow, .-overflow
.align 2
.globl main
.type main, @function
main:
move.l __stack_start@GOT(%a5),%a0
addq.l #4,%a0
cmp.l %sp,%a0
bls.s .+4
trap #7
move.l %a5,-(%sp)
clr.l -(%sp)
move.l overflow@GOT(%a5),%d0
move.l %d0,%a0
jsr (%a0)
addq.l #4,%sp
clr.l %d0
move.l (%sp)+,%a5
rts
.size main, .-main
.ident GCC: (GNU) 4.6.1 20120905 (patched)
.section.note.GNU-stack,,@progbits
My hacked .s file to add printf's:
# cat stack-overflow.s
#NO_APP
.file stack-overflow.c
.section.rodata
.LC0:
.string i = %i\n
.LC1:
.string __stack_start = %p\n
.LC2:
.string %%sp = %p\n
.text
.align 2
.globl overflow
.type overflow, @function
overflow:
move.l __stack_start@GOT(%a5),%a0
lea (1028,%a0),%a0
cmp.l %sp,%a0
bls.s .+4
trap #7
lea (-1024,%sp),%sp
move.l %a5,-(%sp)
addq.l #1,1032(%sp)
move.l .LC0@GOT(%a5),%d0
move.l 1032(%sp),-(%sp)
move.l %d0,-(%sp)
move.l printf@GOT(%a5),%d0
move.l %d0,%a0
jsr (%a0)
addq.l #8,%sp
move.l %sp,-(%sp)
move.l .LC2@GOT(%a5),-(%sp)
move.l printf@GOT(%a5),%a0
jsr (%a0)
addq.l #8,%sp
move.l 1032(%sp),-(%sp)
move.l overflow@GOT(%a5),%d0
move.l %d0,%a0
jsr (%a0)
addq.l #4,%sp
move.l (%sp)+,%a5
lea (1024,%sp),%sp
rts
.size overflow, .-overflow
.align 2
.globl main
.type main, @function
main:
move.l __stack_start@GOT(%a5),%a0
addq.l #4,%a0
cmp.l %sp,%a0
bls.s .+4
trap #7
move.l %a5,-(%sp)
move.l __stack_start@GOT(%a5),-(%sp)
move.l .LC1@GOT(%a5),-(%sp)
move.l printf@GOT(%a5),%a0
jsr (%a0)
addq.l #8,%sp
move.l %sp,-(%sp)
move.l .LC2@GOT(%a5),-(%sp)
move.l printf@GOT(%a5),%a0
jsr (%a0)
addq.l #8,%sp
clr.l -(%sp)
move.l overflow@GOT(%a5),%d0
move.l %d0,%a0
jsr (%a0)
addq.l #4,%sp
clr.l %d0
move.l (%sp)+,%a5
rts
.size main, .-main
.ident GCC: (GNU) 4.6.1 20120905 (patched)
.section.note.GNU-stack,,@progbits
# toolchains/freescale-coldfire-2011.09-patched/bin/m68k-uclinux-gcc -mcpu=5208
-fomit-frame-pointer -fno-common -fno-builtin -fno-dwarf2-cfi-asm -msep-data
-fstack-limit-symbol=__stack_start -o check-stack-overflow stack-overflow.s
When I run the hacked version, the stack pointer is nowhere near __stack_start,
yet I suspect a stack overflow has clobbered something and caused the hardware
watchdog timer to trip:
/ # /usr/bin/check-stack-overflow
__stack_start = 0x406148b4
%sp = 0x40617ee4
i = 1
