Re: [uClinux-dev] Does anyone have m68knommu running with current uClibc and gcc 4.3?
On Tue, Mar 03, 2009 at 11:59:41AM +1000, Greg Ungerer wrote: Couple of things I notice off-hand. The _start code looks completely different for the 2 cases. How did you configure uClibc for the gcc-4.3.2 case? What .config file did you use? I used the .config from the 0.9.27 build, with as few changes as I could get away with to get it to build. This might of course not be good enough. Pretty much tried to do make oldconfig. I will see if I can grab the .config and post that for both builds. I have attached the config files used for uclibc 0.9.27 (with gcc 4.1.1 and 2.6.16 headers) and for uclibc 0.9.30.1 (with gcc 4.3.3 and 2.6.29-rc3 headers). one thing I am not sure of is, what format to select for m68knommu in 0.9.30. In 0.9.27 there was no choice, no there are 4 choices. FDPIC doesn't compile, flat seems to, so that's what I tried. Compare the disassembly of puts in both cases. Something is screwy with the one generated by gcc-4.3.2: 00d8 puts: d8: 4e56 fff0 linkw %fp,#-16 dc: 48e7044347 de: 2030 2679 movel %a0@(0079,%d2:w:8),%d0 e2: 00 e4: 165c013134 e6: 242b 0024 movel %a3@(36),%d2 ... Why the undecoded words? The disassemble in the gcc-4.1.1 case looks fine. No idea what that even means in this case. I am not used to assembly instructions being that long when decoded. -- Len Sorensen ___ 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] Coldfire: M5271: fec.c: Added conditional compile to initialize MDIO lines.
On Monday, March 02, 2009 11:07:04 Greg Ungerer wrote: Hi Richard, Richard Retanubun wrote: From 0bad7aa337cf16bed99f5f71613e587f61068dde Mon Sep 17 00:00:00 2001 From: Richard Retanubun richardretanu...@ruggedcom.com Date: Mon, 9 Feb 2009 10:41:48 -0500 Subject: [PATCH] Fixed GPIO pin initialization for CONFIG_M5271 FEC. This processor only have one FEC and its MDIO pins are located at a different offset than the code used for the current CONFIG_M527x Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com --- Looks good. But this good is about change quite substantially in the next mainline merge window. The fec driver will become a proper platform driver, and this ColdFire specific code will be moved into the ColdFire arch platform code. Greg, is the new platform driver for fec, etc., currently git'able? -- Steven King -- sfking at fdwdc dot 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] Does anyone have m68knommu running with current uClibc and gcc 4.3?
On Mon, Mar 02, 2009 at 02:50:16PM -0500, Lennart Sorensen wrote: Sorry, I'm late to the thread. We're using gcc 4.3.1 with uClibc snapshot 20081118, and binutils 2.18.50.0.1 I didn't set it up, but we're using buildroot to build it, and it took some fiddling. Target is 2.6.26 on an M5282 cpu. It's working pretty well, actually. Good to know. I wonder if it required any patches. Or if the 5282 is particularly different from a 5270/5271. Hopefully someone documented the required fidling for next time you have to do it. Any change you would have access to the .config used for uclibc on that setup? -- Len Sorensen ___ 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] Does anyone have m68knommu running with current uClibc and gcc 4.3?
On Tue, Mar 03, 2009 at 12:10:56PM -0500, Lennart Sorensen wrote: On Tue, Mar 03, 2009 at 11:59:41AM +1000, Greg Ungerer wrote: Couple of things I notice off-hand. The _start code looks completely different for the 2 cases. How did you configure uClibc for the gcc-4.3.2 case? What .config file did you use? I used the .config from the 0.9.27 build, with as few changes as I could get away with to get it to build. This might of course not be good enough. Pretty much tried to do make oldconfig. I will see if I can grab the .config and post that for both builds. I have attached the config files used for uclibc 0.9.27 (with gcc 4.1.1 and 2.6.16 headers) and for uclibc 0.9.30.1 (with gcc 4.3.3 and 2.6.29-rc3 headers). one thing I am not sure of is, what format to select for m68knommu in 0.9.30. In 0.9.27 there was no choice, no there are 4 choices. FDPIC doesn't compile, flat seems to, so that's what I tried. Compare the disassembly of puts in both cases. Something is screwy with the one generated by gcc-4.3.2: 00d8 puts: d8: 4e56 fff0 linkw %fp,#-16 dc: 48e7044347 de: 2030 2679 movel %a0@(0079,%d2:w:8),%d0 e2: 00 e4: 165c013134 e6: 242b 0024 movel %a3@(36),%d2 ... Why the undecoded words? The disassemble in the gcc-4.1.1 case looks fine. No idea what that even means in this case. I am not used to assembly instructions being that long when decoded. Perhaps actually attaching the files would help. -- Len Sorensen # # Automatically generated make config: don't edit # # TARGET_alpha is not set # TARGET_arm is not set # TARGET_bfin is not set # TARGET_cris is not set # TARGET_e1 is not set # TARGET_frv is not set # TARGET_h8300 is not set # TARGET_i386 is not set # TARGET_i960 is not set TARGET_m68k=y # TARGET_microblaze is not set # TARGET_mips is not set # TARGET_nios is not set # TARGET_nios2 is not set # TARGET_powerpc is not set # TARGET_sh is not set # TARGET_sparc is not set # TARGET_v850 is not set # # Target Architecture Features and Options # HAVE_ELF=y TARGET_ARCH=m68k ARCH_SUPPORTS_BIG_ENDIAN=y UCLIBC_HAS_SOFT_FLOAT=y # ARCH_LITTLE_ENDIAN is not set ARCH_BIG_ENDIAN=y ARCH_HAS_NO_MMU=y UCLIBC_HAS_FLOATS=y # HAS_FPU is not set DO_C99_MATH=y WARNINGS=-Wall KERNEL_SOURCE=/tmp/official-uclinux/ori/linux-2.6.16 UCLIBC_UCLINUX_BROKEN_MUNMAP=y EXCLUDE_BRK=y C_SYMBOL_PREFIX= HAVE_DOT_CONFIG=y # # General Library Settings # # HAVE_NO_PIC is not set # DOPIC is not set HAVE_NO_SHARED=y ARCH_HAS_NO_LDSO=y UCLIBC_CTOR_DTOR=y # HAS_NO_THREADS is not set UCLIBC_HAS_THREADS=y # PTHREADS_DEBUG_SUPPORT is not set # UCLIBC_HAS_LFS is not set MALLOC=y # MALLOC_SIMPLE is not set # MALLOC_STANDARD is not set # MALLOC_GLIBC_COMPAT is not set UCLIBC_DYNAMIC_ATEXIT=y COMPAT_ATEXIT=y # HAS_SHADOW is not set # UNIX98PTY_ONLY is not set ASSUME_DEVPTS=y # UCLIBC_HAS_TM_EXTENSIONS is not set # UCLIBC_HAS_TZ_CACHING is not set UCLIBC_HAS_TZ_FILE=y UCLIBC_HAS_TZ_FILE_READ_MANY=y UCLIBC_TZ_FILE_PATH=/etc/TZ # # Networking Support # # UCLIBC_HAS_IPV6 is not set # UCLIBC_HAS_RPC is not set # # String and Stdio Support # UCLIBC_HAS_STRING_GENERIC_OPT=y UCLIBC_HAS_STRING_ARCH_OPT=y UCLIBC_HAS_CTYPE_TABLES=y UCLIBC_HAS_CTYPE_SIGNED=y UCLIBC_HAS_CTYPE_UNSAFE=y # UCLIBC_HAS_CTYPE_CHECKED is not set # UCLIBC_HAS_CTYPE_ENFORCED is not set # UCLIBC_HAS_WCHAR is not set # UCLIBC_HAS_LOCALE is not set # UCLIBC_HAS_HEXADECIMAL_FLOATS is not set # UCLIBC_HAS_GLIBC_CUSTOM_PRINTF is not set # USE_OLD_VFPRINTF is not set UCLIBC_PRINTF_SCANF_POSITIONAL_ARGS=9 # UCLIBC_HAS_SCANF_GLIBC_A_FLAG is not set # UCLIBC_HAS_STDIO_BUFSIZ_NONE is not set UCLIBC_HAS_STDIO_BUFSIZ_256=y # UCLIBC_HAS_STDIO_BUFSIZ_512 is not set # UCLIBC_HAS_STDIO_BUFSIZ_1024 is not set # UCLIBC_HAS_STDIO_BUFSIZ_2048 is not set # UCLIBC_HAS_STDIO_BUFSIZ_4096 is not set # UCLIBC_HAS_STDIO_BUFSIZ_8192 is not set UCLIBC_HAS_STDIO_BUILTIN_BUFFER_NONE=y # UCLIBC_HAS_STDIO_BUILTIN_BUFFER_4 is not set # UCLIBC_HAS_STDIO_BUILTIN_BUFFER_8 is not set UCLIBC_HAS_STDIO_GETC_MACRO=y UCLIBC_HAS_STDIO_PUTC_MACRO=y UCLIBC_HAS_STDIO_AUTO_RW_TRANSITION=y # UCLIBC_HAS_FOPEN_EXCLUSIVE_MODE is not set # UCLIBC_HAS_GLIBC_CUSTOM_STREAMS is not set UCLIBC_HAS_PRINTF_M_SPEC=y UCLIBC_HAS_ERRNO_MESSAGES=y UCLIBC_HAS_SYS_ERRLIST=y UCLIBC_HAS_SIGNUM_MESSAGES=y # UCLIBC_HAS_SYS_SIGLIST is not set UCLIBC_HAS_GNU_GETOPT=y # # Big and Tall # UCLIBC_HAS_REGEX=y # UCLIBC_HAS_WORDEXP is not set # UCLIBC_HAS_FTW is not set UCLIBC_HAS_GLOB=y # # Library Installation Options # RUNTIME_PREFIX=/usr/$(TARGET_ARCH)-linux-uclibc/ DEVEL_PREFIX=/usr/$(TARGET_ARCH)-linux-uclibc # # uClibc security related options # # UCLIBC_SECURITY is not set # # uClibc development/debugging options # # DODEBUG is not set # DOASSERTS is not set # UCLIBC_MALLOC_DEBUGGING is not set # UCLIBC_MJN3_ONLY is not set # #
Re: [uClinux-dev] Threading and synchronization questions
Mike Frysinger wrote: On Monday 02 March 2009 12:39:07 Jamie Lokier wrote: Michael Schnell wrote: To daemonize, you don't use the same flags as you would to emulate fork() and vfork(), and have to use a little arch-specific assembler. Fully that you need to do this manually. Daemonizing seems quite common, so I would have expected to find it in glibc or such. There is a function in glibc. Try man daemon :-) The only trouble is it's not (yet) found in uClibc for no-MMU archs. I don't know what happened to the version I posted to the Busybox bugzilla. Searching on the Busybox bugzilla yields no results. when did you post it ? the mantis bug tracker was dropped recently and none of the old bugs were moved over to the new bugzilla ... It was a couple of years ago. -- Jamie ___ 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] Question about FlexCAN module and uClinux-dist-20080808
/* Sorry for my poor English */ Hi, I test uClinux on Freescale Coldfire MCF5329. I work with the “Zoom Coldfire SDK Development Kit”. For my first task, I design a CAN-Ethernet bridge. For this, I follow step-by-step the application note “AN3408 – Building a Sample CGI Application” from Freescale. For the moment, I search a build a correct uClinux image (with CAN driver !). A lot of points are OK (I build an uClinux image, I send and run it with dBug program, ...). But, in the uClinux kernel configuration menu, I don't find the “ColdFire FlexCAN module support” option (To have CAN4Linux drivers for the FlexCAN module on MCF5329 - page 10 of the application note). This is the only option (of the application note, pages 6=12) that I can not find. Anyone knows its location ? I work with the latest uClinux-dist (20080808), but I have the same problem with all previous distribution of uClinux (20070130, 20060803, 20051110). Thanks. Val ___ 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] mcfcache patch
Hi Greg, attached patch applied to uclinux-dist-20080808 release(with 20090302 patch applied). CACHE_ENABLE is defined to nop if CONFIG_UCBOOTLOADER is defined. The cache setting is defined in the bootloader in this case. Also I would like to point out that at least the cache setting is not quite correct if RAM size is not 16M for CONFIG_M527x. I did not check other CACHE_ENABLE macro definitions but I doubt they are correct. -- David Wu mcfcache.patch Description: Binary data ___ 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] Does anyone have m68knommu running with current uClibc and gcc 4.3?
On Tue, Mar 03, 2009 at 11:59:41AM +1000, Greg Ungerer wrote: Couple of things I notice off-hand. The _start code looks completely different for the 2 cases. How did you configure uClibc for the gcc-4.3.2 case? What .config file did you use? Compare the disassembly of puts in both cases. Something is screwy with the one generated by gcc-4.3.2: 00d8 puts: d8: 4e56 fff0 linkw %fp,#-16 dc: 48e7044347 de: 2030 2679 movel %a0@(0079,%d2:w:8),%d0 e2: 00 e4: 165c013134 e6: 242b 0024 movel %a3@(36),%d2 ... Why the undecoded words? The disassemble in the gcc-4.1.1 case looks fine. So here is some more info. This is the disassembly of the puts function from uclibc 0.9.27 compiled with gcc 4.1.1 (puts.27.x), from uclibc 0.9.30.1 compiled with gcc 4.3.3 (puts.30.x) and the same two functions as present in my helloworld program (helloworld.puts.411.asm and helloworld.puts.433.asm). It appears that the version done by gcc 4.1.1 has been integrated without damage, while the 4.3.3 version is been mangled and no longer disassembles correctly (probably because it is no longer correct). So is this likely to be a compiler issue, an assembler issues, a linker issue or perhaps an elf2flt issue? Given the files I disassembled where the .gdb elf files, I guess elf2flt might not have been involved, but I don't quite understand all of what it does yet so I am not sure. Where should I go next... -- Len Sorensen 0.9.27/libc/stdio/puts.o: file format elf32-m68k Disassembly of section .text: puts: 0: 4e56 fff4 linkw %fp,#-12 4: 48d7 040c moveml %d2-%d3/%a2,%sp@ 8: 2479 moveal 0 puts,%a2 e: 262a 0024 movel %a2@(36),%d3 12: 660cbnes 20 puts+0x20 14: 486a 0028 pea %a2@(40) 18: 4eb9 jsr 0 puts 1e: 588faddql #4,%sp 20: 2f0amovel %a2,%...@- 22: 2f2e 0008 movel %fp@(8),%...@- 26: 4eb9 jsr 0 puts 2c: 2400movel %d0,%d2 2e: 508faddql #8,%sp 30: 70ffmoveq #-1,%d0 32: b082cmpl %d2,%d0 34: 671abeqs 50 puts+0x50 36: 2f0amovel %a2,%...@- 38: 4878 000a pea a puts+0xa 3c: 4eb9 jsr 0 puts 42: 508faddql #8,%sp 44: 72ffmoveq #-1,%d1 46: b280cmpl %d0,%d1 48: 6604bnes 4e puts+0x4e 4a: 74ffmoveq #-1,%d2 4c: 6002bras 50 puts+0x50 4e: 5282addql #1,%d2 50: 4a83tstl %d3 52: 660cbnes 60 puts+0x60 54: 486a 0028 pea %a2@(40) 58: 4eb9 jsr 0 puts 5e: 588faddql #4,%sp 60: 2002movel %d2,%d0 62: 4cee 040c fff4 moveml %fp@(-12),%d2-%d3/%a2 68: 4e5eunlk %fp 6a: 4e75rts 0.9.30.1/libc/stdio/puts.o: file format elf32-m68k Disassembly of section .text: puts: 0: 4e56 ffe4 linkw %fp,#-28 4: 48d7 040c moveml %d2-%d3/%a2,%sp@ 8: 2479 moveal 0 puts,%a2 e: 262a 0024 movel %a2@(36),%d3 12: 6628bnes 3c puts+0x3c 14: 240amovel %a2,%d2 16: 0682 0028 addil #40,%d2 1c: 2f02movel %d2,%...@- 1e: 4879 pea 0 puts 24: 486e fff0 pea %fp@(-16) 28: 4eb9 jsr 0 puts 2e: 2f02movel %d2,%...@- 30: 4eb9 jsr 0 puts 36: dffc 0010 addal #16,%sp 3c: 2f0amovel %a2,%...@- 3e: 2f2e 0008 movel %fp@(8),%...@- 42: 4eb9 jsr 0 puts 48: 2400movel %d0,%d2 4a: 508faddql #8,%sp 4c: 70ffmoveq #-1,%d0 4e: b082cmpl %d2,%d0 50: 671abeqs 6c puts+0x6c 52: 2f0amovel %a2,%...@- 54: 4878 000a pea a puts+0xa 58: 4eb9 jsr 0 puts 5e: 508faddql #8,%sp 60: 72ffmoveq #-1,%d1 62: b280cmpl %d0,%d1 64: 6604bnes 6a puts+0x6a 66: 74ffmoveq #-1,%d2 68: 6002bras 6c puts+0x6c 6a: 5282addql #1,%d2 6c: 4a83tstl %d3 6e: 6610bnes 80 puts+0x80 70: 4878 0001 pea 1 puts+0x1 74: 486e fff0 pea %fp@(-16) 78: 4eb9 jsr 0 puts 7e: 508faddql #8,%sp 80: 2002movel %d2,%d0 82: 4cee 040c ffe4 moveml %fp@(-28),%d2-%d3/%a2 88: 4e5eunlk %fp 8a: 4e75rts hello.411.gdb: file format elf32-m68k Disassembly of section .text: 01a8 puts: 1a8: 4e56 fff4 linkw %fp,#-12 1ac: 48d7 040c moveml %d2-%d3/%a2,%sp@ 1b0: 2479 1034 moveal 1034
[uClinux-dev] MCF54455
Does anyone know if Freescale's 54455 will work with uClinux? ___ 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] mcfcache patch
Quoth David Wu: CACHE_ENABLE is defined to nop if CONFIG_UCBOOTLOADER is defined. The cache setting is defined in the bootloader in this case. Also I would like to point out that at least the cache setting is not quite correct if RAM size is not 16M for CONFIG_M527x. The settings made by the CACHE_ENABLE macro are overridden fairly quickly by the code in cacheflush.h anyway, so it might be moot :) ___ 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] mcfcache patch
On Tue, 03 Mar 2009 16:20:10 -0500, Gavin Lambert gav...@compacsort.com wrote: Quoth David Wu: CACHE_ENABLE is defined to nop if CONFIG_UCBOOTLOADER is defined. The cache setting is defined in the bootloader in this case. Also I would like to point out that at least the cache setting is not quite correct if RAM size is not 16M for CONFIG_M527x. The settings made by the CACHE_ENABLE macro are overridden fairly quickly by the code in cacheflush.h anyway, so it might be moot :) Those are for invalidate cache, right? for example bellow: #if defined(CONFIG_M527x) || defined(CONFIG_M528x) __asm__ __volatile__ ( movel #0x81000200, %%d0\n\t movec %%d0, %%CACR\n\t nop\n\t : : : d0 ); #endif /* CONFIG_M527x || CONFIG_M528x */ #0x81000200 is for invalidate cache. Also ARC0 and ACR1 registers are not modified in cacheflush.h. ___ 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 -- David Wu ___ 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] MCF54455
Hi Jordan, You will have to use Freescale's ltib development (rpm based) tools if you want to get the latest patches and possibly some help from Freescale. I have used it on a couple of projects and it does have its good points. regards Phil Wilshire Jordan Fuerst wrote: Does anyone know if Freescale’s 54455 will work with uClinux? ___ 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 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] [PATCH] clean links in tools/
In the Blackfin dist, we generate some temp symlinks in the tools/ subdir for utilities. The uClinux-dist doesn't use any symlinks in this subdir, so it shouldn't affect anything there. --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 0be4f16..2f7369f 100644 --- a/Makefile +++ b/Makefile @@ -289,6 +289,7 @@ clean: modules_clean rm -f $(LINUXDIR)/linux rm -f $(LINUXDIR)/include/asm rm -rf $(LINUXDIR)/net/ipsec/alg/libaes $(LINUXDIR)/net/ipsec/alg/perlasm + find ./tools/ -maxdepth 1 -type l | xargs rm -f real_clean mrproper: clean [ -d $(LINUXDIR) ] $(MAKEARCH_KERNEL) -C $(LINUXDIR) mrproper || : -- 1.6.1.3 ___ 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] [PATCH] fix bugreport target for LIBC=none
If the LIBC is set to none, then LIBCDIR expands to nothing and we get an error. So tweak how we optionally install the libc config. Also drop a duplicate install of the kernel config. --- Makefile |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2f7369f..71488d6 100644 --- a/Makefile +++ b/Makefile @@ -318,11 +318,13 @@ bugreport: cp .config bugreport/ mkdir bugreport/$(LINUXDIR) cp $(LINUXDIR)/.config bugreport/$(LINUXDIR)/ - mkdir bugreport/$(LIBCDIR) - [ ! -f $(LIBCDIR)/.config ] || cp $(LIBCDIR)/.config bugreport/$(LIBCDIR)/ + if [ -f $(LIBCDIR)/.config ] ; then \ + set -e ; \ + mkdir bugreport/$(LIBCDIR) ; \ + cp $(LIBCDIR)/.config bugreport/$(LIBCDIR)/ ; \ + fi mkdir bugreport/config cp config/.config bugreport/config/ - cp $(LINUXDIR)/.config bugreport/$(LINUXDIR)/ tar czf bugreport.tar.gz bugreport rm -rf ./bugreport -- 1.6.1.3 ___ 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] fix bugreport target for LIBC=none
Jivin Mike Frysinger lays it down ... If the LIBC is set to none, then LIBCDIR expands to nothing and we get an error. So tweak how we optionally install the libc config. Also drop a duplicate install of the kernel config. Applied, Thanks, Davidm --- Makefile |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2f7369f..71488d6 100644 --- a/Makefile +++ b/Makefile @@ -318,11 +318,13 @@ bugreport: cp .config bugreport/ mkdir bugreport/$(LINUXDIR) cp $(LINUXDIR)/.config bugreport/$(LINUXDIR)/ - mkdir bugreport/$(LIBCDIR) - [ ! -f $(LIBCDIR)/.config ] || cp $(LIBCDIR)/.config bugreport/$(LIBCDIR)/ + if [ -f $(LIBCDIR)/.config ] ; then \ + set -e ; \ + mkdir bugreport/$(LIBCDIR) ; \ + cp $(LIBCDIR)/.config bugreport/$(LIBCDIR)/ ; \ + fi mkdir bugreport/config cp config/.config bugreport/config/ - cp $(LINUXDIR)/.config bugreport/$(LINUXDIR)/ tar czf bugreport.tar.gz bugreport rm -rf ./bugreport -- 1.6.1.3 ___ 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 -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.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
Re: [uClinux-dev] [PATCH] clean links in tools/
Jivin Mike Frysinger lays it down ... In the Blackfin dist, we generate some temp symlinks in the tools/ subdir for utilities. The uClinux-dist doesn't use any symlinks in this subdir, so it shouldn't affect anything there. Ok, I can't apply this one. Lots of uClinux-dist users (in particular us :-) build using sym-link trees, this will trash the good symlinks as well as the temp ones. Perhaps you can beef the tools/... Makefiles to clean specifically the symlinks they install ? Cheers, Davidm --- Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 0be4f16..2f7369f 100644 --- a/Makefile +++ b/Makefile @@ -289,6 +289,7 @@ clean: modules_clean rm -f $(LINUXDIR)/linux rm -f $(LINUXDIR)/include/asm rm -rf $(LINUXDIR)/net/ipsec/alg/libaes $(LINUXDIR)/net/ipsec/alg/perlasm + find ./tools/ -maxdepth 1 -type l | xargs rm -f real_clean mrproper: clean [ -d $(LINUXDIR) ] $(MAKEARCH_KERNEL) -C $(LINUXDIR) mrproper || : -- 1.6.1.3 ___ 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 -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.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
Re: [uClinux-dev] [PATCH] clean links in tools/
On Tuesday 03 March 2009 18:36:59 David McCullough wrote: Jivin Mike Frysinger lays it down ... In the Blackfin dist, we generate some temp symlinks in the tools/ subdir for utilities. The uClinux-dist doesn't use any symlinks in this subdir, so it shouldn't affect anything there. Ok, I can't apply this one. Lots of uClinux-dist users (in particular us :-) build using sym-link trees, this will trash the good symlinks as well as the temp ones. i thought i looked and there were no symlinks in tools/ ... what'd i miss ? Perhaps you can beef the tools/... Makefiles to clean specifically the symlinks they install ? the symlinks are arbitrarily generated -mike ___ 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] Coldfire: M5271: fec.c: Added conditional compile to initialize MDIO lines.
Hi Steven, Steven King wrote: On Monday, March 02, 2009 11:07:04 Greg Ungerer wrote: Hi Richard, Richard Retanubun wrote: From 0bad7aa337cf16bed99f5f71613e587f61068dde Mon Sep 17 00:00:00 2001 From: Richard Retanubun richardretanu...@ruggedcom.com Date: Mon, 9 Feb 2009 10:41:48 -0500 Subject: [PATCH] Fixed GPIO pin initialization for CONFIG_M5271 FEC. This processor only have one FEC and its MDIO pins are located at a different offset than the code used for the current CONFIG_M527x Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com --- Looks good. But this good is about change quite substantially in the next mainline merge window. The fec driver will become a proper platform driver, and this ColdFire specific code will be moved into the ColdFire arch platform code. Greg, is the new platform driver for fec, etc., currently git'able? David Miller said he applied it to his net-next-2.6 tree. So I assume that his his git tree at http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=summary Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: 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] [PATCH] clean links in tools/
Jivin Mike Frysinger lays it down ... On Tuesday 03 March 2009 18:36:59 David McCullough wrote: Jivin Mike Frysinger lays it down ... In the Blackfin dist, we generate some temp symlinks in the tools/ subdir for utilities. The uClinux-dist doesn't use any symlinks in this subdir, so it shouldn't affect anything there. Ok, I can't apply this one. Lots of uClinux-dist users (in particular us :-) build using sym-link trees, this will trash the good symlinks as well as the temp ones. i thought i looked and there were no symlinks in tools/ ... what'd i miss ? A link tree is an out of source tree build where everything except directories is a symlink. For example, to make one, be sure to start with a pristine (never built in tree) and then do: mkdir build1 cd build1 lndir -silent /full/path/to/pristine make config make It allows you to cleanly build multiple targets from a common source tree at the same time. Currently build1 cannot be a directory under pristine. It also means a real clean can become rm -rf build1 :-) Perhaps you can beef the tools/... Makefiles to clean specifically the symlinks they install ? the symlinks are arbitrarily generated If there is some pattern to it at all you may be able to avoid existing filenames. Cheers, Davidm -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.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
Re: [uClinux-dev] [PATCH] use full path for depmod
Jivin Mike Frysinger lays it down ... Using a relative path to busybox's depmod script doesn't work if the kern dir is actually a symlink somewhere else. Using a full path avoids that. Applied, Thanks, Davidm --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 71488d6..9faa7b7 100644 --- a/Makefile +++ b/Makefile @@ -168,7 +168,7 @@ modules_install: . $(CONFIG_CONFIG); \ if [ $$CONFIG_MODULES = y ]; then \ [ -d $(ROMFSDIR)/lib/modules ] || mkdir -p $(ROMFSDIR)/lib/modules; \ - $(MAKEARCH_KERNEL) -C $(LINUXDIR) INSTALL_MOD_CMD=$(ROMFSINST) -S -r \\ INSTALL_MOD_PATH=$(ROMFSDIR) DEPMOD=../user/busybox/examples/depmod.pl modules_install; \ + $(MAKEARCH_KERNEL) -C $(LINUXDIR) INSTALL_MOD_CMD=$(ROMFSINST) -S -r \\ INSTALL_MOD_PATH=$(ROMFSDIR) DEPMOD=$(ROOTDIR)/user/busybox/examples/depmod.pl modules_install; \ rm -f $(ROMFSDIR)/lib/modules/*/build; \ rm -f $(ROMFSDIR)/lib/modules/*/source; \ find $(ROMFSDIR)/lib/modules -type f -name *o | xargs -r $(STRIP) -R .comment -R .note -g --strip-unneeded; \ -- 1.6.1.3 ___ 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 -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.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] [PATCH] split config steps into %_defconfig
The _default target is pretty useful, but sometimes I want to start with the default config. Splitting the default config steps out into a new _defconfig target allows for this code flow w/out breaking it manually with my own CTRL+C: $ make Some/Board_defconfig $ make config_menuconfig $ make --- Makefile | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 9faa7b7..f331838 100644 --- a/Makefile +++ b/Makefile @@ -352,17 +352,19 @@ bugreport: *) $(MAKEARCH) -C $(@:_romfs=) romfs;; \ esac -%_default: conf - @if [ ! -f vendors/$(@:_default=)/config.device ]; then \ - echo vendors/$(@:_default=)/config.device must exist first; \ +%_defconfig: conf + @if [ ! -f vendors/$(@:_defconfig=)/config.device ]; then \ + echo vendors/$(@:_defconfig=)/config.device must exist first; \ exit 1; \ fi -$(MAKE) clean /dev/null 21 - cp vendors/$(@:_default=)/config.device .config + cp vendors/$(@:_defconfig=)/config.device .config chmod u+x config/setconfig yes | config/setconfig defaults config/setconfig final $(MAKE) dep +%_default: conf + $(MAKE) $(@:_default=_defconfig) $(MAKE) config_error: -- 1.6.1.3 ___ 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] clean links in tools/
Jivin Mike Frysinger lays it down ... On Tuesday 03 March 2009 20:06:27 David McCullough wrote: Jivin Mike Frysinger lays it down ... On Tuesday 03 March 2009 18:36:59 David McCullough wrote: Jivin Mike Frysinger lays it down ... In the Blackfin dist, we generate some temp symlinks in the tools/ subdir for utilities. The uClinux-dist doesn't use any symlinks in this subdir, so it shouldn't affect anything there. Ok, I can't apply this one. Lots of uClinux-dist users (in particular us :-) build using sym-link trees, this will trash the good symlinks as : well as the temp ones. i thought i looked and there were no symlinks in tools/ ... what'd i miss A link tree is an out of source tree build where everything except directories is a symlink. For example, to make one, be sure to start with a pristine (never built in tree) and then do: mkdir build1 cd build1 lndir -silent /full/path/to/pristine make config make It allows you to cleanly build multiple targets from a common source tree at the same time. Currently build1 cannot be a directory under pristine. It also means a real clean can become rm -rf build1 :-) is there more info on this ? we've had requests for out-of-tree builds before Not really any more info than above. I can write something up if you like, but it will be short :-) I don't always use it, but others use it religiously. Here is an example of how to use it safely (with a cvs repo): TDIR=`pwd` cvs co -d pristine uClinux-dist mkdir target1 cd target1 lndir -silent $TDIR/pristine make Vendor1/Target1_default cd .. mkdir target2 cd target2 lndir -silent $TDIR/pristine make Vendor2/Target2_default cd .. The original pristine tree will remain largely untouched (there are a few rogue packages that still mess with autogenerated files). All the binaries, images and config etc will be in the targetX dirs. target1 and target2 can build/clean/operate completely independantly (even being built at the same time is ok IIRC). If you update your pristine dir, you may need to rerun lndir to ensure target1 and target2 pick up any new files that need to be linked. lndir automatically leaves out the CVS/RCS/SCCS/SVN control directories as well unless you ask it to keep them. lndir is silent unless it sees something it can't fix, like a link already exists but doesn’t point to the correct file. If it gets messy (lots of changes on a tree update), rm -rf targetX and re-link/build. I tend to use it whenever I have slow source repo access and lots of targets to manage. Is that enough to get you started ? Perhaps you can beef the tools/... Makefiles to clean specifically the symlinks they install ? the symlinks are arbitrarily generated If there is some pattern to it at all you may be able to avoid existing filenames. i can change things to use a dedicated dir and create more symlinks to workaround it. Cheers, Davidm -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.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
Re: [uClinux-dev] [PATCH] clean links in tools/
On Tuesday 03 March 2009 22:22:30 David McCullough wrote: Jivin Mike Frysinger lays it down ... On Tuesday 03 March 2009 20:06:27 David McCullough wrote: A link tree is an out of source tree build where everything except directories is a symlink. For example, to make one, be sure to start with a pristine (never built in tree) and then do: mkdir build1 cd build1 lndir -silent /full/path/to/pristine make config make It allows you to cleanly build multiple targets from a common source tree at the same time. Currently build1 cannot be a directory under pristine. It also means a real clean can become rm -rf build1 :-) is there more info on this ? we've had requests for out-of-tree builds before Not really any more info than above. I can write something up if you like, but it will be short :-) I don't always use it, but others use it religiously. Here is an example of how to use it safely (with a cvs repo): TDIR=`pwd` cvs co -d pristine uClinux-dist mkdir target1 cd target1 lndir -silent $TDIR/pristine make Vendor1/Target1_default cd .. mkdir target2 cd target2 lndir -silent $TDIR/pristine make Vendor2/Target2_default cd .. The original pristine tree will remain largely untouched (there are a few rogue packages that still mess with autogenerated files). All the binaries, images and config etc will be in the targetX dirs. target1 and target2 can build/clean/operate completely independantly (even being built at the same time is ok IIRC). If you update your pristine dir, you may need to rerun lndir to ensure target1 and target2 pick up any new files that need to be linked. lndir automatically leaves out the CVS/RCS/SCCS/SVN control directories as well unless you ask it to keep them. lndir is silent unless it sees something it can't fix, like a link already exists but doesn’t point to the correct file. If it gets messy (lots of changes on a tree update), rm -rf targetX and re-link/build. I tend to use it whenever I have slow source repo access and lots of targets to manage. Is that enough to get you started ? ive never heard of lndir before, so i'll have to install that package on my system ... but otherwise, it seems like it should be enough for me to play with ... -mike signature.asc Description: This is a digitally signed message part. ___ 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] clean links in tools/
Jivin Mike Frysinger lays it down ... On Tuesday 03 March 2009 22:22:30 David McCullough wrote: Jivin Mike Frysinger lays it down ... On Tuesday 03 March 2009 20:06:27 David McCullough wrote: A link tree is an out of source tree build where everything except directories is a symlink. For example, to make one, be sure to start with a pristine (never built in tree) and then do: mkdir build1 cd build1 lndir -silent /full/path/to/pristine make config make It allows you to cleanly build multiple targets from a common source tree at the same time. Currently build1 cannot be a directory under pristine. It also means a real clean can become rm -rf build1 :-) is there more info on this ? we've had requests for out-of-tree builds before Not really any more info than above. I can write something up if you like, but it will be short :-) I don't always use it, but others use it religiously. Here is an example of how to use it safely (with a cvs repo): TDIR=`pwd` cvs co -d pristine uClinux-dist mkdir target1 cd target1 lndir -silent $TDIR/pristine make Vendor1/Target1_default cd .. mkdir target2 cd target2 lndir -silent $TDIR/pristine make Vendor2/Target2_default cd .. The original pristine tree will remain largely untouched (there are a few rogue packages that still mess with autogenerated files). All the binaries, images and config etc will be in the targetX dirs. target1 and target2 can build/clean/operate completely independantly (even being built at the same time is ok IIRC). If you update your pristine dir, you may need to rerun lndir to ensure target1 and target2 pick up any new files that need to be linked. lndir automatically leaves out the CVS/RCS/SCCS/SVN control directories as well unless you ask it to keep them. lndir is silent unless it sees something it can't fix, like a link already exists but doesn’t point to the correct file. If it gets messy (lots of changes on a tree update), rm -rf targetX and re-link/build. I tend to use it whenever I have slow source repo access and lots of targets to manage. Is that enough to get you started ? ive never heard of lndir before, so i'll have to install that package on my system ... but otherwise, it seems like it should be enough for me to play with ... Its comes from xutils-dev under ubuntu, Cheers, Davidm -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.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
Re: [uClinux-dev] mcfcache patch
Hi David, David Wu wrote: On Tue, 03 Mar 2009 16:20:10 -0500, Gavin Lambert gav...@compacsort.com wrote: Quoth David Wu: CACHE_ENABLE is defined to nop if CONFIG_UCBOOTLOADER is defined. The cache setting is defined in the bootloader in this case. Also I would like to point out that at least the cache setting is not quite correct if RAM size is not 16M for CONFIG_M527x. The settings made by the CACHE_ENABLE macro are overridden fairly quickly by the code in cacheflush.h anyway, so it might be moot :) Those are for invalidate cache, right? for example bellow: #if defined(CONFIG_M527x) || defined(CONFIG_M528x) __asm__ __volatile__ ( movel #0x81000200, %%d0\n\t movec %%d0, %%CACR\n\t nop\n\t : : : d0 ); #endif /* CONFIG_M527x || CONFIG_M528x */ #0x81000200 is for invalidate cache. Also ARC0 and ACR1 registers are not modified in cacheflush.h. But it also re-writes all the other control bits in that register. Which is fine if they correspond exactly with what you initially set. But will break you if you use something different. It doesn't make any sense in my mind to not set an initial value for this (in the kernel proper), but then expect the flush code to get it right. Better would be to actually have proper configuration options for enabling instruction and/or data cache. And to work out the proper CACR value (using the calculated value as required for initial setup, and when invalidating/flushing caches). Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: 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] Does anyone have m68knommu running with current uClibc and gcc 4.3?
Hi Lennart, Lennart Sorensen wrote: On Tue, Mar 03, 2009 at 12:10:56PM -0500, Lennart Sorensen wrote: On Tue, Mar 03, 2009 at 11:59:41AM +1000, Greg Ungerer wrote: Couple of things I notice off-hand. The _start code looks completely different for the 2 cases. How did you configure uClibc for the gcc-4.3.2 case? What .config file did you use? I used the .config from the 0.9.27 build, with as few changes as I could get away with to get it to build. This might of course not be good enough. Pretty much tried to do make oldconfig. I will see if I can grab the .config and post that for both builds. I have attached the config files used for uclibc 0.9.27 (with gcc 4.1.1 and 2.6.16 headers) and for uclibc 0.9.30.1 (with gcc 4.3.3 and 2.6.29-rc3 headers). one thing I am not sure of is, what format to select for m68knommu in 0.9.30. In 0.9.27 there was no choice, no there are 4 choices. FDPIC doesn't compile, flat seems to, so that's what I tried. Compare the disassembly of puts in both cases. Something is screwy with the one generated by gcc-4.3.2: 00d8 puts: d8: 4e56 fff0 linkw %fp,#-16 dc: 48e7044347 de: 2030 2679 movel %a0@(0079,%d2:w:8),%d0 e2: 00 e4: 165c013134 e6: 242b 0024 movel %a3@(36),%d2 ... Why the undecoded words? The disassemble in the gcc-4.1.1 case looks fine. No idea what that even means in this case. I am not used to assembly instructions being that long when decoded. Perhaps actually attaching the files would help. From the 0.9.30.1 config you attached: # # Automatically generated make config: don't edit # Version: 0.9.30.1 # Tue Mar 3 16:16:28 2009 # # TARGET_alpha is not set # TARGET_arm is not set # TARGET_avr32 is not set # TARGET_bfin is not set # TARGET_cris is not set # TARGET_e1 is not set # TARGET_frv is not set # TARGET_h8300 is not set # TARGET_hppa is not set # TARGET_i386 is not set # TARGET_i960 is not set # TARGET_ia64 is not set TARGET_m68k=y # TARGET_microblaze is not set # TARGET_mips is not set # TARGET_nios is not set # TARGET_nios2 is not set # TARGET_powerpc is not set # TARGET_sh is not set # TARGET_sh64 is not set # TARGET_sparc is not set # TARGET_v850 is not set # TARGET_vax is not set # TARGET_x86_64 is not set # TARGET_xtensa is not set # # Target Architecture Features and Options # TARGET_ARCH=m68k FORCE_OPTIONS_FOR_ARCH=y TARGET_SUBARCH= # UCLIBC_FORMAT_ELF is not set UCLIBC_FORMAT_FDPIC_ELF=y # UCLIBC_FORMAT_FLAT is not set # UCLIBC_FORMAT_FLAT_SEP_DATA is not set Normally you use FLAT_SEP_DATA for m68knommu. There is no kernel FDPIC support for this yet. # UCLIBC_FORMAT_SHARED_FLAT is not set ARCH_BIG_ENDIAN=y # # Using Big Endian # # ARCH_HAS_MMU is not set UCLIBC_HAS_FLOATS=y # UCLIBC_HAS_FPU is not set UCLIBC_HAS_SOFT_FLOAT=y DO_C99_MATH=y # UCLIBC_HAS_FENV is not set UCLIBC_HAS_LONG_DOUBLE_MATH=y KERNEL_HEADERS=/tmp/official-uclinux/linux-2.6-headers/include UCLIBC_UCLINUX_BROKEN_MUNMAP=y EXCLUDE_BRK=y HAVE_DOT_CONFIG=y # # General Library Settings # # HAVE_NO_PIC is not set # DOPIC is not set # ARCH_HAS_NO_SHARED is not set # ARCH_HAS_NO_LDSO is not set HAVE_SHARED=y I don't bother with shared libraries any more. I always set HAVE_NO_SHARED. # FORCE_SHAREABLE_TEXT_SEGMENTS is not set LDSO_LDD_SUPPORT=y LDSO_CACHE_SUPPORT=y which will change the settings of these too. # LDSO_PRELOAD_FILE_SUPPORT is not set LDSO_BASE_FILENAME=ld.so UCLIBC_STATIC_LDCONFIG=y LDSO_RUNPATH=y UCLIBC_CTOR_DTOR=y # LDSO_GNU_HASH_SUPPORT is not set # HAS_NO_THREADS is not set UCLIBC_HAS_THREADS=y # PTHREADS_DEBUG_SUPPORT is not set LINUXTHREADS_OLD=y UCLIBC_HAS_SYSLOG=y # UCLIBC_HAS_LFS is not set MALLOC=y # MALLOC_SIMPLE is not set # MALLOC_STANDARD is not set # MALLOC_GLIBC_COMPAT is not set UCLIBC_DYNAMIC_ATEXIT=y COMPAT_ATEXIT=y # UCLIBC_SUSV3_LEGACY is not set # UCLIBC_SUSV3_LEGACY_MACROS is not set # UCLIBC_HAS_STUBS is not set UCLIBC_HAS_SHADOW=y # UCLIBC_HAS_PROGRAM_INVOCATION_NAME is not set UCLIBC_HAS_PTY=y ASSUME_DEVPTS=y # UNIX98PTY_ONLY is not set UCLIBC_HAS_GETPT=y # UCLIBC_HAS_TM_EXTENSIONS is not set # UCLIBC_HAS_TZ_CACHING is not set UCLIBC_HAS_TZ_FILE=y UCLIBC_HAS_TZ_FILE_READ_MANY=y UCLIBC_TZ_FILE_PATH=/etc/TZ # # Advanced Library Settings # UCLIBC_PWD_BUFFER_SIZE=256 UCLIBC_GRP_BUFFER_SIZE=256 # # Support various families of functions # UCLIBC_LINUX_MODULE_24=y UCLIBC_LINUX_SPECIFIC=y UCLIBC_HAS_GNU_ERROR=y UCLIBC_BSD_SPECIFIC=y UCLIBC_HAS_BSD_ERR=y # UCLIBC_HAS_OBSOLETE_BSD_SIGNAL is not set # UCLIBC_HAS_OBSOLETE_SYSV_SIGNAL is not set # UCLIBC_NTP_LEGACY is not set # UCLIBC_SV4_DEPRECATED is not set UCLIBC_HAS_REALTIME=y UCLIBC_HAS_ADVANCED_REALTIME=y UCLIBC_HAS_EPOLL=y UCLIBC_HAS_XATTR=y UCLIBC_HAS_PROFILING=y UCLIBC_HAS_CRYPT_IMPL=y UCLIBC_HAS_CRYPT=y UCLIBC_HAS_NETWORK_SUPPORT=y UCLIBC_HAS_SOCKET=y UCLIBC_HAS_IPV4=y # UCLIBC_HAS_IPV6 is not set # UCLIBC_HAS_RPC is
Re: [uClinux-dev] Does anyone have m68knommu running with current uClibc and gcc 4.3?
Hi Lennart, Lennart Sorensen wrote: On Tue, Mar 03, 2009 at 11:59:41AM +1000, Greg Ungerer wrote: Couple of things I notice off-hand. The _start code looks completely different for the 2 cases. How did you configure uClibc for the gcc-4.3.2 case? What .config file did you use? Compare the disassembly of puts in both cases. Something is screwy with the one generated by gcc-4.3.2: 00d8 puts: d8: 4e56 fff0 linkw %fp,#-16 dc: 48e7044347 de: 2030 2679 movel %a0@(0079,%d2:w:8),%d0 e2: 00 e4: 165c013134 e6: 242b 0024 movel %a3@(36),%d2 ... Why the undecoded words? The disassemble in the gcc-4.1.1 case looks fine. So here is some more info. This is the disassembly of the puts function from uclibc 0.9.27 compiled with gcc 4.1.1 (puts.27.x), from uclibc 0.9.30.1 compiled with gcc 4.3.3 (puts.30.x) and the same two functions as present in my helloworld program (helloworld.puts.411.asm and helloworld.puts.433.asm). It appears that the version done by gcc 4.1.1 has been integrated without damage, while the 4.3.3 version is been mangled and no longer disassembles correctly (probably because it is no longer correct). So is this likely to be a compiler issue, an assembler issues, a linker issue or perhaps an elf2flt issue? Given the files I disassembled where the .gdb elf files, I guess elf2flt might not have been involved, but I don't quite understand all of what it does yet so I am not sure. Given that the initial compile of put.o seems correct it is hard to see how this is an assembler of compiler issues. You are disassembly the final .gdb file, and that would pretty much rule out elf2flt - since its input is the ELF object. Are you sure that the uClibc objects you compiled are the ones that are actually being linked into your final .gdb file? Run your app build with verbose gcc output. Check that it is actually using the library objects that you think it is. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: 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] [PATCH] m68knommu: fixing FEC irq caused crashing
Hi Xin,
Xin Xie wrote:
Occasionally the system is crashing when connect to the network runing
30+ hours.
Found out it is due to two consecutive FEC RX irqs cause the stack
corruption of handle_IRQ_event routine. In the current fec RX/TX/MII
handler, spin_unlock_irq() will enable the IRQ at the end of function,
but the those functions will be continued called by the
fec_enet_interrupt as long as there is the IRQ status indicate there is
events. So inside the fec_enet_interrupt, there will be short period of
time IRQ enabled which should not happening because the IRQ handler is
registered with IRQF_DISABLED flags.
Changing the spin_lock_irq/spin_unlock_irq to spin_lock/spin_unlock
solves the problem.
Signed-off-by: Xin Xie x...@nojapower.com.au
Looks good. I'll apply locally, and push to mainline after the
upcoming merge of the fec platform changes.
Regards
Greg
--- a/drivers/net/fec.c 2009-02-10 08:34:04.0 +1000
+++ b/drivers/net/fec.c 2009-02-10 08:35:35.0 +1000
@@ -494,7 +494,7 @@ fec_enet_tx(struct net_device *dev)
struct sk_buff *skb;
fep = netdev_priv(dev);
- spin_lock_irq(fep-hw_lock);
+ spin_lock(fep-hw_lock);
bdp = fep-dirty_tx;
while (((status = bdp-cbd_sc) BD_ENET_TX_READY) == 0) {
@@ -553,7 +553,7 @@ fec_enet_tx(struct net_device *dev)
}
}
fep-dirty_tx = (cbd_t *)bdp;
- spin_unlock_irq(fep-hw_lock);
+ spin_unlock(fep-hw_lock);
}
@@ -580,7 +580,7 @@ fec_enet_rx(struct net_device *dev)
fep = netdev_priv(dev);
fecp = (volatile fec_t*)dev-base_addr;
- spin_lock_irq(fep-hw_lock);
+ spin_lock(fep-hw_lock);
/* First, grab all of the stats for the incoming packet.
* These get messed up if we get called due to a busy condition.
@@ -688,7 +688,7 @@ while (!((status = bdp-cbd_sc) BD_ENE
fecp-fec_r_des_active = 0;
#endif
- spin_unlock_irq(fep-hw_lock);
+ spin_unlock(fep-hw_lock);
}
@@ -702,7 +702,7 @@ fec_enet_mii(struct net_device *dev)
uintmii_reg;
fep = netdev_priv(dev);
- spin_lock_irq(fep-mii_lock);
+ spin_lock(fep-mii_lock);
ep = fep-hwp;
mii_reg = ep-fec_mii_data;
@@ -723,7 +723,7 @@ fec_enet_mii(struct net_device *dev)
ep-fec_mii_data = mip-mii_regval;
unlock:
- spin_unlock_irq(fep-mii_lock);
+ spin_unlock(fep-mii_lock);
}
static int
Xin Xie
Embedded Software Engineer
Noja Power Switchgear Pty Ltd
Tel: +61 7 39078741
Email: x...@nojapower.com.au
___
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
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: 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
