From gerg at snapgear.com  Thu Oct  1 02:28:37 2009
From: gerg at snapgear.com (Greg Ungerer)
Date: Thu, 01 Oct 2009 16:28:37 +1000
Subject: [uClinux-dev] [PATCH] Add uboot commandline argument passing
	support to m68knommu (Try #2)
In-Reply-To: <20090918174936.GJ23702@csclub.uwaterloo.ca>
References: <20090918162736.GY23700@csclub.uwaterloo.ca>	<1253291944.7060.42.camel@desktop>
	<20090918174936.GJ23702@csclub.uwaterloo.ca>
Message-ID: <4AC44C15.1000007@snapgear.com>

Hi Lennart,

Lennart Sorensen wrote:
> On Fri, Sep 18, 2009 at 09:39:04AM -0700, Daniel Walker wrote:
>> You have a couple of various checkpatch errors in this patch. We use
>> scripts/checkpatch.pl to check for code style issues. Could you run that
>> on your patch and fix any errors it finds? A couple are whitespace
>> related and you can use scripts/cleanpatch or scripts/cleanfile to
>> remove whitespace (so I hear. I've never run those scripts personally)
> 
> Oh dear.  I guess the original patch was a bit messy then.  OK here we
> go again with a checkpatch approved patch.
> 
> ---
> 
> This patch adds m68knommu support for getting the kernel command line
> arguments from uboot, including the passing of an initrd image from uboot.
> 
> We use this on a 5270/5271 based board, and have used it on the 5271evb
> development board.  It is based on a patch found in the linux-2.6-denx
> git tree, although that tree seems to have had lots of other changes
> since which are not in the main Linus kernel.  I believe this will work
> on all coldfires, although other m68knommu might be missing the _init_sp
> stuff in head.S as far as I can tell.  I only have the coldfire to
> test on.
> 
> Signed-off-by: Lennart Sorensen <lsorense at csclub.uwaterloo.ca>

Looks ok to me. I'll go ahead and apply it to the for-next
m68knommu git tree.

Regards
Greg


> diff --git a/arch/m68knommu/Kconfig b/arch/m68knommu/Kconfig
> index e2201b9..064f591 100644
> --- a/arch/m68knommu/Kconfig
> +++ b/arch/m68knommu/Kconfig
> @@ -533,6 +533,13 @@ config AVNET
>  	default y
>  	depends on (AVNET5282)
>  
> +config UBOOT
> +	bool "Support for U-Boot command line parameters"
> +	help
> +	  If you say Y here kernel will try to collect command
> +	  line parameters from the initial u-boot stack.
> +	default n
> +
>  config 4KSTACKS
>  	bool "Use 4Kb for kernel stacks instead of 8Kb"
>  	default y
> diff --git a/arch/m68knommu/kernel/setup.c b/arch/m68knommu/kernel/setup.c
> index 5c2bb3e..ba92b90 100644
> --- a/arch/m68knommu/kernel/setup.c
> +++ b/arch/m68knommu/kernel/setup.c
> @@ -29,6 +29,8 @@
>  #include <linux/bootmem.h>
>  #include <linux/seq_file.h>
>  #include <linux/init.h>
> +#include <linux/initrd.h>
> +#include <linux/root_dev.h>
>  
>  #include <asm/setup.h>
>  #include <asm/irq.h>
> @@ -52,7 +54,6 @@ void (*mach_reset)(void);
>  void (*mach_halt)(void);
>  void (*mach_power_off)(void);
>  
> -
>  #ifdef CONFIG_M68000
>  	#define CPU "MC68000"
>  #endif
> @@ -111,6 +112,69 @@ void (*mach_power_off)(void);
>  extern int _stext, _etext, _sdata, _edata, _sbss, _ebss, _end;
>  extern int _ramstart, _ramend;
>  
> +#if defined(CONFIG_UBOOT)
> +/*
> + * parse_uboot_commandline
> + *
> + * Copies u-boot commandline arguments and store them in the proper linux
> + * variables.
> + *
> + * Assumes:
> + *	_init_sp global contains the address in the stack pointer when the
> + *	kernel starts (see head.S::_start)
> + *
> + *	U-Boot calling convention:
> + *	(*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);
> + *
> + *	_init_sp can be parsed as such
> + *
> + *	_init_sp+00 = u-boot cmd after jsr into kernel (skip)
> + *	_init_sp+04 = &kernel board_info (residual data)
> + *	_init_sp+08 = &initrd_start
> + *	_init_sp+12 = &initrd_end
> + *	_init_sp+16 = &cmd_start
> + *	_init_sp+20 = &cmd_end
> + *
> + *	This also assumes that the memory locations pointed to are still
> + *	unmodified. U-boot places them near the end of external SDRAM.
> + *
> + * Argument(s):
> + *	commandp = the linux commandline arg container to fill.
> + *	size     = the sizeof commandp.
> + *
> + * Returns:
> + */
> +void parse_uboot_commandline(char *commandp, int size)
> +{
> +	extern unsigned long _init_sp;
> +	unsigned long *sp;
> +	unsigned long uboot_kbd;
> +	unsigned long uboot_initrd_start, uboot_initrd_end;
> +	unsigned long uboot_cmd_start, uboot_cmd_end;
> +
> +
> +	sp = (unsigned long *)_init_sp;
> +	uboot_kbd = sp[1];
> +	uboot_initrd_start = sp[2];
> +	uboot_initrd_end = sp[3];
> +	uboot_cmd_start = sp[4];
> +	uboot_cmd_end = sp[5];
> +
> +	if (uboot_cmd_start && uboot_cmd_end)
> +		strncpy(commandp, (const char *)uboot_cmd_start, size);
> +#if defined(CONFIG_BLK_DEV_INITRD)
> +	if (uboot_initrd_start && uboot_initrd_end &&
> +		(uboot_initrd_end > uboot_initrd_start)) {
> +		initrd_start = uboot_initrd_start;
> +		initrd_end = uboot_initrd_end;
> +		ROOT_DEV = Root_RAM0;
> +		printk(KERN_INFO "initrd at 0x%lx:0x%lx\n",
> +			initrd_start, initrd_end);
> +	}
> +#endif /* if defined(CONFIG_BLK_DEV_INITRD) */
> +}
> +#endif /* #if defined(CONFIG_UBOOT) */
> +
>  void __init setup_arch(char **cmdline_p)
>  {
>  	int bootmap_size;
> @@ -128,7 +192,24 @@ void __init setup_arch(char **cmdline_p)
>  #if defined(CONFIG_BOOTPARAM)
>  	strncpy(&command_line[0], CONFIG_BOOTPARAM_STRING, sizeof(command_line));
>  	command_line[sizeof(command_line) - 1] = 0;
> -#endif
> +#endif /* CONFIG_BOOTPARAM */
> +
> +#if defined(CONFIG_UBOOT)
> +	/* CONFIG_UBOOT and CONFIG_BOOTPARAM defined, concatenate cmdline */
> +	#if defined(CONFIG_BOOTPARAM)
> +		/* Add the whitespace separator */
> +		command_line[strlen(CONFIG_BOOTPARAM_STRING)] = ' ';
> +		/* Parse uboot command line into the rest of the buffer */
> +		parse_uboot_commandline(
> +			&command_line[(strlen(CONFIG_BOOTPARAM_STRING)+1)],
> +			(sizeof(command_line) -
> +			(strlen(CONFIG_BOOTPARAM_STRING)+1)));
> +	/* Only CONFIG_UBOOT defined, create cmdline */
> +	#else
> +		parse_uboot_commandline(&command_line[0], sizeof(command_line));
> +	#endif /* CONFIG_BOOTPARAM */
> +	command_line[sizeof(command_line) - 1] = 0;
> +#endif /* CONFIG_UBOOT */
>  
>  	printk(KERN_INFO "\x0F\r\n\nuClinux/" CPU "\n");
>  
> @@ -204,6 +285,13 @@ void __init setup_arch(char **cmdline_p)
>  	free_bootmem(memory_start, memory_end - memory_start);
>  	reserve_bootmem(memory_start, bootmap_size, BOOTMEM_DEFAULT);
>  
> +#if defined(CONFIG_UBOOT) && defined(CONFIG_BLK_DEV_INITRD)
> +	if ((initrd_start > 0) && (initrd_start < initrd_end) &&
> +			(initrd_end < memory_end))
> +		reserve_bootmem(initrd_start, initrd_end - initrd_start,
> +				 BOOTMEM_DEFAULT);
> +#endif /* if defined(CONFIG_BLK_DEV_INITRD) */
> +
>  	/*
>  	 * Get kmalloc into gear.
>  	 */
> diff --git a/arch/m68knommu/platform/coldfire/head.S b/arch/m68knommu/platform/coldfire/head.S
> index 2b0d73c..4b91aa2 100644
> --- a/arch/m68knommu/platform/coldfire/head.S
> +++ b/arch/m68knommu/platform/coldfire/head.S
> @@ -106,6 +106,9 @@
>  .global _ramvec
>  .global	_ramstart
>  .global	_ramend
> +#if defined(CONFIG_UBOOT)
> +.global	_init_sp
> +#endif
>  
>  /*****************************************************************************/
>  
> @@ -124,6 +127,10 @@ _ramstart:
>  .long	0
>  _ramend:
>  .long	0
> +#if defined(CONFIG_UBOOT)
> +_init_sp:
> +.long	0
> +#endif
>  
>  /*****************************************************************************/
>  
> @@ -137,6 +144,9 @@ __HEAD
>  _start:
>  	nop					/* filler */
>  	movew	#0x2700, %sr			/* no interrupts */
> +#if defined(CONFIG_UBOOT)
> +	movel	%sp,_init_sp			/* save initial stack pointer */
> +#endif
>  
>  	/*
>  	 *	Do any platform or board specific setup now. Most boards
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
> 

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg at 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


From lsorense at csclub.uwaterloo.ca  Fri Oct  2 10:32:59 2009
From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen)
Date: Fri, 2 Oct 2009 10:32:59 -0400
Subject: [uClinux-dev] [PATCH] Add uboot commandline argument passing
	support to m68knommu (Try #2)
In-Reply-To: <4AC44C15.1000007@snapgear.com>
References: <20090918162736.GY23700@csclub.uwaterloo.ca>
	<1253291944.7060.42.camel@desktop>
	<20090918174936.GJ23702@csclub.uwaterloo.ca>
	<4AC44C15.1000007@snapgear.com>
Message-ID: <20091002143259.GB26340@csclub.uwaterloo.ca>

On Thu, Oct 01, 2009 at 04:28:37PM +1000, Greg Ungerer wrote:
> Looks ok to me. I'll go ahead and apply it to the for-next
> m68knommu git tree.

Great.  One less patch for me to keep applying.

-- 
Len Sorensen


From lgowris at rediffmail.com  Thu Oct  8 12:08:50 2009
From: lgowris at rediffmail.com (gowri sankar loganathan)
Date: 8 Oct 2009 16:08:50 -0000
Subject: [uClinux-dev] request for support on Armulator 
Message-ID: <1254495710.S.3461.16314.f5mail-236-223.rediffmail.com.1255018130.62759@webmail.rediffmail.com>

Hello All,
        I am new to arm tool chain and Armulator, I followed the procedure as indicated in 

http://www.uclinux.org/pub/uClinux/utilities/armulator/

the host system ubuntu 9.04 

at the end I got the error as indicated below, can some one help me to fix the issue
 

make[1]: Entering directory `/home/armtools/gdb-5.0/libiberty'
make[2]: Entering directory `/home/armtools/gdb-5.0/libiberty/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/armtools/gdb-5.0/libiberty/testsuite'
make[1]: Leaving directory `/home/armtools/gdb-5.0/libiberty'
make[1]: Entering directory `/home/armtools/gdb-5.0/intl'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/armtools/gdb-5.0/intl'
make[1]: Entering directory `/home/armtools/gdb-5.0/bfd'
make  all-recursive
make[2]: Entering directory `/home/armtools/gdb-5.0/bfd'
Making all in doc
make[3]: Entering directory `/home/armtools/gdb-5.0/bfd/doc'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/armtools/gdb-5.0/bfd/doc'
Making all in po
make[3]: Entering directory `/home/armtools/gdb-5.0/bfd/po'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/armtools/gdb-5.0/bfd/po'
make[3]: Entering directory `/home/armtools/gdb-5.0/bfd'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/armtools/gdb-5.0/bfd'
make[2]: Leaving directory `/home/armtools/gdb-5.0/bfd'
make[1]: Leaving directory `/home/armtools/gdb-5.0/bfd'
make[1]: Entering directory `/home/armtools/gdb-5.0/opcodes'
make  all-recursive
make[2]: Entering directory `/home/armtools/gdb-5.0/opcodes'
Making all in po
make[3]: Entering directory `/home/armtools/gdb-5.0/opcodes/po'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/armtools/gdb-5.0/opcodes/po'
make[3]: Entering directory `/home/armtools/gdb-5.0/opcodes'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/armtools/gdb-5.0/opcodes'
make[2]: Leaving directory `/home/armtools/gdb-5.0/opcodes'
make[1]: Leaving directory `/home/armtools/gdb-5.0/opcodes'
make[1]: Entering directory `/home/armtools/gdb-5.0/etc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/armtools/gdb-5.0/etc'
make[1]: Entering directory `/home/armtools/gdb-5.0/mmalloc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/armtools/gdb-5.0/mmalloc'
make[1]: Entering directory `/home/armtools/gdb-5.0/readline'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/armtools/gdb-5.0/readline'
make[1]: Entering directory `/home/armtools/gdb-5.0/sim'
make[2]: Entering directory `/home/armtools/gdb-5.0/sim/common'
make[2]: Nothing to be done for `default'.
make[2]: Leaving directory `/home/armtools/gdb-5.0/sim/common'
make[2]: Entering directory `/home/armtools/gdb-5.0/sim/arm'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/armtools/gdb-5.0/sim/arm'
make[1]: Leaving directory `/home/armtools/gdb-5.0/sim'
make[1]: Entering directory `/home/armtools/gdb-5.0/gdb'
gcc -c -g -O2    -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl -I./../intl -I./tui  -DUSE_INCLUDED_REGEX   gdbtypes.c
gdbtypes.c: In function ?recursive_dump_type?:
gdbtypes.c:2712: error: lvalue required as increment operand
make[1]: *** [gdbtypes.o] Error 1
make[1]: Leaving directory `/home/armtools/gdb-5.0/gdb'
make: *** [all-gdb] Error 2

with Thanks & Regards,
Gowrisankar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091008/1db345f2/attachment.html>

From jocke at vmlinux.org  Sun Oct 11 07:45:15 2009
From: jocke at vmlinux.org (Joachim Nilsson)
Date: Sun, 11 Oct 2009 13:45:15 +0200
Subject: [uClinux-dev] New license for watchdogd
Message-ID: <4AD1C54B.8070705@vmlinux.org>

This may be a bit of good and useful news to some, watchdogd has been 
given a license. The highly permissive ISC License 
<http://en.wikipedia.org/wiki/ISC_license>. The code is currently 
available as a Git repository:

      git clone http://git.vmlinux.org/watchdogd.git

A big thanks to the original author Michele d'Amico, and Mike Frysinger, 
for making this happen!

Attached is a diff of user/watchdogd and the current git repository.

Regards
   /Joachim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-watchdogd-license-and-whitespace.diff
Type: text/x-diff
Size: 6934 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091011/df019947/attachment.bin>

From philipn at engarts.com  Mon Oct 12 06:53:45 2009
From: philipn at engarts.com (Philip Nye)
Date: Mon, 12 Oct 2009 11:53:45 +0100
Subject: [uClinux-dev] building uClibc
Message-ID: <4AD30AB9.2040308@engarts.com>

I am trying to build a system for Coldfire with an up-to-date kernel, tools
and library. I have the latest uClinux dist (patched to 20090810) and
Codesourcery tools 4.3-209. This refused to build with an error of limits.h
not found.

Rather than a symlink hack, this led me to try a recent release of uClibc as
the one in the uClinux dist is not so new (and I found this:
http://gcc.gnu.org/ml/gcc/2008-08/msg00273.html), but I now get failures
down the line because uClibc headers contain lots of libc_hidden_proto()
declarations. As I understand it, these headers should be sanitized to
remove this internal code for public use, but this is not happening, and I
cannot see where it should be carried out. If I simply enter the uClibc
directory and try to build from there, I get a different set of errors with
missing header files.

Can anyone suggest what I am doing wrong? Does the uClibc tree need to be
patched for uClinux? Is there some extra configuration or build stage I need
to do? Is there more to installing Codesourcery toolchain than simply
setting PATH so it can be found?

Philip Nye




From vapier at gentoo.org  Mon Oct 12 09:28:34 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 12 Oct 2009 09:28:34 -0400
Subject: [uClinux-dev] building uClibc
In-Reply-To: <4AD30AB9.2040308@engarts.com>
References: <4AD30AB9.2040308@engarts.com>
Message-ID: <200910120928.35394.vapier@gentoo.org>

On Monday 12 October 2009 06:53:45 Philip Nye wrote:
> Rather than a symlink hack, this led me to try a recent release of uClibc
>  as the one in the uClinux dist is not so new (and I found this:
> http://gcc.gnu.org/ml/gcc/2008-08/msg00273.html), but I now get failures
> down the line because uClibc headers contain lots of libc_hidden_proto()
> declarations. As I understand it, these headers should be sanitized to
> remove this internal code for public use, but this is not happening, and I
> cannot see where it should be carried out. If I simply enter the uClibc
> directory and try to build from there, I get a different set of errors with
> missing header files.

that is because the uClibc headers have to be installed first and the uClinux 
dist build system doesnt install anything.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091012/6d1b0a9b/attachment.sig>

From philipn at engarts.com  Mon Oct 12 10:05:26 2009
From: philipn at engarts.com (Philip Nye)
Date: Mon, 12 Oct 2009 15:05:26 +0100
Subject: [uClinux-dev] building uClibc
In-Reply-To: <200910120928.35394.vapier@gentoo.org>
References: <4AD30AB9.2040308@engarts.com>
	<200910120928.35394.vapier@gentoo.org>
Message-ID: <4AD337A6.1040402@engarts.com>

Mike Frysinger wrote:
> On Monday 12 October 2009 06:53:45 Philip Nye wrote:
>> Rather than a symlink hack, this led me to try a recent release of uClibc
>>  as the one in the uClinux dist is not so new (and I found this:
>> http://gcc.gnu.org/ml/gcc/2008-08/msg00273.html), but I now get failures
>> down the line because uClibc headers contain lots of libc_hidden_proto()
>> declarations. As I understand it, these headers should be sanitized to
>> remove this internal code for public use, but this is not happening, and I
>> cannot see where it should be carried out. If I simply enter the uClibc
>> directory and try to build from there, I get a different set of errors with
>> missing header files.
> 
> that is because the uClibc headers have to be installed first and the uClinux 
> dist build system doesnt install anything

I had rather come to this conclusion - it appears to be "make 
install_headers" in uClibc which calls unifdef to remove all the internal 
stuff from the headers, but this target does not get built by uClinux. 
Neither does it seem to get built by the normal make sequence in uClibc, but 
I may be missing that.

What is the best soltuion to this? Should the uClinux build be installing 
the uClibc headers to some directory within the uClinux build (e.g. by 
setting DEVEL_PREFIX?), or should it define some null macros so that it 
doesn't barf on libc_hidden_proto and the like (this would seem a real hack).

Philip


From vapier at gentoo.org  Mon Oct 12 10:22:18 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 12 Oct 2009 10:22:18 -0400
Subject: [uClinux-dev] building uClibc
In-Reply-To: <4AD337A6.1040402@engarts.com>
References: <4AD30AB9.2040308@engarts.com>
	<200910120928.35394.vapier@gentoo.org>
	<4AD337A6.1040402@engarts.com>
Message-ID: <200910121022.19116.vapier@gentoo.org>

On Monday 12 October 2009 10:05:26 Philip Nye wrote:
> Mike Frysinger wrote:
> > On Monday 12 October 2009 06:53:45 Philip Nye wrote:
> >> Rather than a symlink hack, this led me to try a recent release of
> >> uClibc as the one in the uClinux dist is not so new (and I found this:
> >> http://gcc.gnu.org/ml/gcc/2008-08/msg00273.html), but I now get failures
> >> down the line because uClibc headers contain lots of libc_hidden_proto()
> >> declarations. As I understand it, these headers should be sanitized to
> >> remove this internal code for public use, but this is not happening, and
> >> I cannot see where it should be carried out. If I simply enter the
> >> uClibc directory and try to build from there, I get a different set of
> >> errors with missing header files.
> >
> > that is because the uClibc headers have to be installed first and the
> > uClinux dist build system doesnt install anything
> 
> I had rather come to this conclusion - it appears to be "make
> install_headers" in uClibc which calls unifdef to remove all the internal
> stuff from the headers, but this target does not get built by uClinux.
> Neither does it seem to get built by the normal make sequence in uClibc,
>  but I may be missing that.
> 
> What is the best soltuion to this? Should the uClinux build be installing
> the uClibc headers to some directory within the uClinux build (e.g. by
> setting DEVEL_PREFIX?), or should it define some null macros so that it
> doesn't barf on libc_hidden_proto and the like (this would seem a real
>  hack).

my opinion of how to handle libraries in uclinux-dist (let alone the C 
library), isnt shared by the uclinux-dist maintainers, so you'll have to wait 
for them to give an "official" answer as to how to address this.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091012/80587830/attachment.sig>

From vapier at gentoo.org  Tue Oct 13 03:44:05 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 13 Oct 2009 03:44:05 -0400
Subject: [uClinux-dev] [PATCH] NOMMU: fix malloc performance by adding
	uninitialized flag
In-Reply-To: <12871.1175267477@redhat.com>
References: <12871.1175267477@redhat.com>
Message-ID: <1255419845-30504-1-git-send-email-vapier@gentoo.org>

From: Jie Zhang <jie.zhang at analog.com>

The no-mmu code currently clears all anonymous mmap-ed memory.  While this
is what we want in the default case, all memory allocation from userspace
under no-mmu has to go through this interface, including malloc() which is
allowed to return uninitialized memory.  This can easily be a significant
performance slow down.  So for constrained embedded systems were security
is irrelevant, allow people to avoid unnecessarily clearing memory.

Signed-off-by: Jie Zhang <jie.zhang at analog.com>
Signed-off-by: Robin Getz <rgetz at analog.com>
Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 Documentation/nommu-mmap.txt      |   21 +++++++++++++++++++++
 fs/binfmt_elf_fdpic.c             |    2 +-
 include/asm-generic/mman-common.h |    5 +++++
 init/Kconfig                      |   16 ++++++++++++++++
 mm/nommu.c                        |    7 ++++---
 5 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt
index b565e82..30d09e8 100644
--- a/Documentation/nommu-mmap.txt
+++ b/Documentation/nommu-mmap.txt
@@ -16,6 +16,27 @@ the CLONE_VM flag.
 The behaviour is similar between the MMU and no-MMU cases, but not identical;
 and it's also much more restricted in the latter case:
 
+ (*) Anonymous mappings - general case
+
+	Anonymous mappings are  not  backed  by any file, and according to the
+	Linux man pages (ver 2.22 or later) contents are initialized to zero.
+
+	In the MMU case, regions are backed by arbitrary virtual pages, and the
+	contents are only mapped with physical pages and initialized to zero
+	when a read or write happens in that specific page. This spreads out
+	the time it takes to initialize the contents depending on the
+	read/write usage of the map.
+
+	In the no-MMU case, anonymous mappings are backed by physical pages,
+	and the entire map is initialized to zero at allocation time. This
+	can cause significant delays in userspace during malloc() as the C
+	library does an anonymous mapping, and the kernel is doing a memset
+	for the entire map. Since malloc's memory is not required to be
+	cleared, an (optional) flag MAP_UNINITIALIZE can be passed to the
+	kernel's do_mmap, which will not initialize the contents to zero.
+
+	uClibc supports this to provide a pretty significant speedup for malloc().
+
  (*) Anonymous mapping, MAP_PRIVATE
 
 	In the MMU case: VM regions backed by arbitrary pages; copy-on-write
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 38502c6..85db4a4 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -380,7 +380,7 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
 	down_write(&current->mm->mmap_sem);
 	current->mm->start_brk = do_mmap(NULL, 0, stack_size,
 					 PROT_READ | PROT_WRITE | PROT_EXEC,
-					 MAP_PRIVATE | MAP_ANONYMOUS | MAP_GROWSDOWN,
+					 MAP_PRIVATE | MAP_ANONYMOUS | MAP_UNINITIALIZE | MAP_GROWSDOWN,
 					 0);
 
 	if (IS_ERR_VALUE(current->mm->start_brk)) {
diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h
index 5ee13b2..dddf626 100644
--- a/include/asm-generic/mman-common.h
+++ b/include/asm-generic/mman-common.h
@@ -19,6 +19,11 @@
 #define MAP_TYPE	0x0f		/* Mask for type of mapping */
 #define MAP_FIXED	0x10		/* Interpret addr exactly */
 #define MAP_ANONYMOUS	0x20		/* don't use a file */
+#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZE
+# define MAP_UNINITIALIZE 0x4000000	/* For anonymous mmap, memory could be uninitialized */
+#else
+# define MAP_UNINITIALIZE 0x0		/* Don't support this flag */
+#endif
 
 #define MS_ASYNC	1		/* sync memory asynchronously */
 #define MS_INVALIDATE	2		/* invalidate the caches */
diff --git a/init/Kconfig b/init/Kconfig
index 09c5c64..ae15849 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1069,6 +1069,22 @@ config SLOB
 
 endchoice
 
+config MMAP_ALLOW_UNINITIALIZE
+	bool "Allow mmaped anonymous memory to be un-initialized"
+	depends on EMBEDDED && ! MMU
+	default n
+	help
+	   Normally (and according to the Linux spec) mmap'ed MAP_ANONYMOUS
+	   memory has it's contents initialized to zero. This kernel option
+	   gives you the option of not doing that by adding a MAP_UNINITIALIZE
+	   mmap flag (which uClibc's malloc() takes takes advantage of)
+	   which provides a huge performance boost.
+
+	   Because of the obvious security issues, this option should only be
+	   enabled on embedded devices which you control what is run in
+	   userspace. Since that isn't a problem on no-MMU systems, it is
+	   normally safe to say Y here.
+
 config PROFILING
 	bool "Profiling support (EXPERIMENTAL)"
 	help
diff --git a/mm/nommu.c b/mm/nommu.c
index 5189b5a..b62bd9d 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1143,9 +1143,6 @@ static int do_mmap_private(struct vm_area_struct *vma,
 		if (ret < rlen)
 			memset(base + ret, 0, rlen - ret);
 
-	} else {
-		/* if it's an anonymous mapping, then just clear it */
-		memset(base, 0, rlen);
 	}
 
 	return 0;
@@ -1343,6 +1340,10 @@ unsigned long do_mmap_pgoff(struct file *file,
 		goto error_just_free;
 	add_nommu_region(region);
 
+	/* clear anonymous mappings that don't ask for un-initialized data */
+	if (!(vma->vm_file) && !(flags & MAP_UNINITIALIZE))
+		memset((void *)region->vm_start, 0, region->vm_end - region->vm_start);
+
 	/* okay... we have a mapping; now we have to register it */
 	result = vma->vm_start;
 
-- 
1.6.5



From lethal at linux-sh.org  Tue Oct 13 09:03:36 2009
From: lethal at linux-sh.org (Paul Mundt)
Date: Tue, 13 Oct 2009 22:03:36 +0900
Subject: [uClinux-dev] Re: [PATCH v2] NOMMU: fix malloc performance by
	adding uninitialized flag
In-Reply-To: <1255432821-1104-1-git-send-email-vapier@gentoo.org>
References: <32310.1255428618@redhat.com>
	<1255432821-1104-1-git-send-email-vapier@gentoo.org>
Message-ID: <20091013130336.GA1245@linux-sh.org>

On Tue, Oct 13, 2009 at 07:20:21AM -0400, Mike Frysinger wrote:
> From: Jie Zhang <jie.zhang at 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.zhang at analog.com>
> Signed-off-by: Robin Getz <rgetz at analog.com>
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> Signed-off-by: David Howells <dhowells at redhat.com>

Acked-by: Paul Mundt <lethal at linux-sh.org>


From lsorense at csclub.uwaterloo.ca  Tue Oct 13 10:20:06 2009
From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen)
Date: Tue, 13 Oct 2009 10:20:06 -0400
Subject: [uClinux-dev] building uClibc
In-Reply-To: <4AD30AB9.2040308@engarts.com>
References: <4AD30AB9.2040308@engarts.com>
Message-ID: <20091013142006.GK26340@csclub.uwaterloo.ca>

On Mon, Oct 12, 2009 at 11:53:45AM +0100, Philip Nye wrote:
> I am trying to build a system for Coldfire with an up-to-date kernel, tools
> and library. I have the latest uClinux dist (patched to 20090810) and
> Codesourcery tools 4.3-209. This refused to build with an error of limits.h
> not found.
>
> Rather than a symlink hack, this led me to try a recent release of uClibc as
> the one in the uClinux dist is not so new (and I found this:
> http://gcc.gnu.org/ml/gcc/2008-08/msg00273.html), but I now get failures
> down the line because uClibc headers contain lots of libc_hidden_proto()
> declarations. As I understand it, these headers should be sanitized to
> remove this internal code for public use, but this is not happening, and I
> cannot see where it should be carried out. If I simply enter the uClibc
> directory and try to build from there, I get a different set of errors with
> missing header files.
>
> Can anyone suggest what I am doing wrong? Does the uClibc tree need to be
> patched for uClinux? Is there some extra configuration or build stage I need
> to do? Is there more to installing Codesourcery toolchain than simply
> setting PATH so it can be found?

I am currently using a coldfire (5270/5271) with gcc 4.3.3, binutils
2.19.1, elf2flt (blackfin version from a late april checkout, other
versions didn't work with gcc 4.3 at the time), 2.6.30 kernel, and
uclibc 0.9.30.1 (with daemon() function #ifdef'd out to fix compile
error).

Anything you need?

-- 
Len Sorensen


From rgetz at blackfin.uclinux.org  Tue Oct 13 11:20:59 2009
From: rgetz at blackfin.uclinux.org (Robin Getz)
Date: Tue, 13 Oct 2009 11:20:59 -0400
Subject: [uClinux-dev] [PATCH] NOMMU: fix malloc performance by
	addinguninitialized flag
In-Reply-To: <1255419845-30504-1-git-send-email-vapier@gentoo.org>
References: <12871.1175267477@redhat.com>
	<1255419845-30504-1-git-send-email-vapier@gentoo.org>
Message-ID: <200910131121.00343.rgetz@blackfin.uclinux.org>

On Tue 13 Oct 2009 03:44, Mike Frysinger pondered:
> From: Jie Zhang <jie.zhang at analog.com>
> 
> The no-mmu code currently clears all anonymous mmap-ed memory.  While this
> is what we want in the default case, all memory allocation from userspace
> under no-mmu has to go through this interface, including malloc() which is
> allowed to return uninitialized memory.  This can easily be a significant
> performance slow down.  So for constrained embedded systems were security
> is irrelevant, allow people to avoid unnecessarily clearing memory.
> 
> Signed-off-by: Jie Zhang <jie.zhang at analog.com>
> Signed-off-by: Robin Getz <rgetz at analog.com>

Should be rgetz at blackfin.uclinux.org -- rgetz at analog.com does not exist and will bounce.



From David_Mccullough at securecomputing.com  Tue Oct 13 19:04:29 2009
From: David_Mccullough at securecomputing.com (David McCullough)
Date: Wed, 14 Oct 2009 09:04:29 +1000
Subject: [uClinux-dev] Re: [PATCH v3] NOMMU: fix malloc performance by adding
	uninitialized flag
In-Reply-To: <1255469467-17065-1-git-send-email-vapier@gentoo.org>
References: <3372.1255449822@redhat.com>
	<1255469467-17065-1-git-send-email-vapier@gentoo.org>
Message-ID: <20091013230429.GA32164@securecomputing.com>


Jivin Mike Frysinger lays it down ...
> From: Jie Zhang <jie.zhang at 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.zhang at analog.com>
> Signed-off-by: Robin Getz <robin.getz at analog.com>
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> Signed-off-by: David Howells <dhowells at redhat.com>
> Acked-by: Paul Mundt <lethal at linux-sh.org>

Acked-by: David McCullough <davidm at snapgear.com>

Cheers,
Davidm

> v3
> 	- tweak kconfig desc
> 
>  Documentation/nommu-mmap.txt      |   26 ++++++++++++++++++++++++++
>  fs/binfmt_elf_fdpic.c             |    3 ++-
>  include/asm-generic/mman-common.h |    5 +++++
>  init/Kconfig                      |   22 ++++++++++++++++++++++
>  mm/nommu.c                        |    8 +++++---
>  5 files changed, 60 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt
> index b565e82..8e1ddec 100644
> --- a/Documentation/nommu-mmap.txt
> +++ b/Documentation/nommu-mmap.txt
> @@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP
>       granule but will only discard the excess if appropriately configured as
>       this has an effect on fragmentation.
>  
> + (*) The memory allocated by a request for an anonymous mapping will normally
> +     be cleared by the kernel before being returned in accordance with the
> +     Linux man pages (ver 2.22 or later).
> +
> +     In the MMU case this can be achieved with reasonable performance as
> +     regions are backed by virtual pages, with the contents only being mapped
> +     to cleared physical pages when a write happens on that specific page
> +     (prior to which, the pages are effectively mapped to the global zero page
> +     from which reads can take place).  This spreads out the time it takes to
> +     initialize the contents of a page - depending on the write-usage of the
> +     mapping.
> +
> +     In the no-MMU case, however, anonymous mappings are backed by physical
> +     pages, and the entire map is cleared at allocation time.  This can cause
> +     significant delays during a userspace malloc() as the C library does an
> +     anonymous mapping and the kernel then does a memset for the entire map.
> +
> +     However, for memory that isn't required to be precleared - such as that
> +     returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
> +     indicate to the kernel that it shouldn't bother clearing the memory before
> +     returning it.  Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled
> +     to permit this, otherwise the flag will be ignored.
> +
> +     uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
> +     to allocate the brk and stack region.
> +
>   (*) A list of all the private copy and anonymous mappings on the system is
>       visible through /proc/maps in no-MMU mode.
>  
> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
> index 38502c6..79d2b1a 100644
> --- a/fs/binfmt_elf_fdpic.c
> +++ b/fs/binfmt_elf_fdpic.c
> @@ -380,7 +380,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
>  	down_write(&current->mm->mmap_sem);
>  	current->mm->start_brk = do_mmap(NULL, 0, stack_size,
>  					 PROT_READ | PROT_WRITE | PROT_EXEC,
> -					 MAP_PRIVATE | MAP_ANONYMOUS | MAP_GROWSDOWN,
> +					 MAP_PRIVATE | MAP_ANONYMOUS |
> +					 MAP_UNINITIALIZED | MAP_GROWSDOWN,
>  					 0);
>  
>  	if (IS_ERR_VALUE(current->mm->start_brk)) {
> diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h
> index 5ee13b2..2011126 100644
> --- a/include/asm-generic/mman-common.h
> +++ b/include/asm-generic/mman-common.h
> @@ -19,6 +19,11 @@
>  #define MAP_TYPE	0x0f		/* Mask for type of mapping */
>  #define MAP_FIXED	0x10		/* Interpret addr exactly */
>  #define MAP_ANONYMOUS	0x20		/* don't use a file */
> +#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
> +# define MAP_UNINITIALIZED 0x4000000	/* For anonymous mmap, memory could be uninitialized */
> +#else
> +# define MAP_UNINITIALIZED 0x0		/* Don't support this flag */
> +#endif
>  
>  #define MS_ASYNC	1		/* sync memory asynchronously */
>  #define MS_INVALIDATE	2		/* invalidate the caches */
> diff --git a/init/Kconfig b/init/Kconfig
> index 09c5c64..309cd9a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1069,6 +1069,28 @@ config SLOB
>  
>  endchoice
>  
> +config MMAP_ALLOW_UNINITIALIZED
> +	bool "Allow mmapped anonymous memory to be uninitialized"
> +	depends on EMBEDDED && !MMU
> +	default n
> +	help
> +	  Normally, and according to the Linux spec, anonymous memory obtained
> +	  from mmap() has it's contents cleared before it is passed to
> +	  userspace.  Enabling this config option allows you to request that
> +	  mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
> +	  providing a huge performance boost.  If this option is not enabled,
> +	  then the flag will be ignored.
> +
> +	  This is taken advantage of by uClibc's malloc(), and also by
> +	  ELF-FDPIC binfmt's brk and stack allocator.
> +
> +	  Because of the obvious security issues, this option should only be
> +	  enabled on embedded devices where you control what is run in
> +	  userspace.  Since that isn't generally a problem on no-MMU systems,
> +	  it is normally safe to say Y here.
> +
> +	  See Documentation/nommu-mmap.txt for more information.
> +
>  config PROFILING
>  	bool "Profiling support (EXPERIMENTAL)"
>  	help
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 5189b5a..11e8231 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -1143,9 +1143,6 @@ static int do_mmap_private(struct vm_area_struct *vma,
>  		if (ret < rlen)
>  			memset(base + ret, 0, rlen - ret);
>  
> -	} else {
> -		/* if it's an anonymous mapping, then just clear it */
> -		memset(base, 0, rlen);
>  	}
>  
>  	return 0;
> @@ -1343,6 +1340,11 @@ unsigned long do_mmap_pgoff(struct file *file,
>  		goto error_just_free;
>  	add_nommu_region(region);
>  
> +	/* clear anonymous mappings that don't ask for uninitialized data */
> +	if (!vma->vm_file && !(flags & MAP_UNINITIALIZED))
> +		memset((void *)region->vm_start, 0,
> +		       region->vm_end - region->vm_start);
> +
>  	/* okay... we have a mapping; now we have to register it */
>  	result = vma->vm_start;
>  
> -- 
> 1.6.5
> 
> 
> 

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


From f.cappelletti at selta.it  Wed Oct 14 05:08:08 2009
From: f.cappelletti at selta.it (Cappelletti Fabio)
Date: Wed, 14 Oct 2009 11:08:08 +0200
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD1C54B.8070705@vmlinux.org>
References: <4AD1C54B.8070705@vmlinux.org>
Message-ID: <4AD594F8.1030405@selta.it>

Hi all, I'm tying to  write a simple hush script , but I have a lot of 
problem with two commands : expr and cat!
In particula my script is as follow:
#!/bin/hush
A= `cat /proc/driver/cardtype/BoardAddr`
B= `expr $A \* 2`
C= `expr $B -1`
echo $B
echo $C

but this is the output:
hush: cannot exec '`cat': No such file or directory
expr: syntax error
expr: syntax error

Thanks!

Fabio


From eauth at softsys.co.at  Wed Oct 14 05:15:27 2009
From: eauth at softsys.co.at (Erwin Authried)
Date: Wed, 14 Oct 2009 11:15:27 +0200
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD594F8.1030405@selta.it>
References: <4AD1C54B.8070705@vmlinux.org>  <4AD594F8.1030405@selta.it>
Message-ID: <1255511727.16981.307.camel@justakiss.home.at>

looks like you don't have the "cat" command on your system.

-Erwin

Am Mittwoch, den 14.10.2009, 11:08 +0200 schrieb Cappelletti Fabio:
> Hi all, I'm tying to  write a simple hush script , but I have a lot of 
> problem with two commands : expr and cat!
> In particula my script is as follow:
> #!/bin/hush
> A= `cat /proc/driver/cardtype/BoardAddr`
> B= `expr $A \* 2`
> C= `expr $B -1`
> echo $B
> echo $C
> 
> but this is the output:
> hush: cannot exec '`cat': No such file or directory
> expr: syntax error
> expr: syntax error
> 
> Thanks!
> 
> Fabio
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
-- 
Dipl.-Ing. Erwin Authried
Softwareentwicklung und Systemdesign



From f.cappelletti at selta.it  Wed Oct 14 05:16:13 2009
From: f.cappelletti at selta.it (Cappelletti Fabio)
Date: Wed, 14 Oct 2009 11:16:13 +0200
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <1255511727.16981.307.camel@justakiss.home.at>
References: <4AD1C54B.8070705@vmlinux.org> <4AD594F8.1030405@selta.it>
	<1255511727.16981.307.camel@justakiss.home.at>
Message-ID: <4AD596DD.7010404@selta.it>

no,I have cat command nad expr command on board.

Erwin Authried wrote:
> looks like you don't have the "cat" command on your system.
>
> -Erwin
>
> Am Mittwoch, den 14.10.2009, 11:08 +0200 schrieb Cappelletti Fabio:
>   
>> Hi all, I'm tying to  write a simple hush script , but I have a lot of 
>> problem with two commands : expr and cat!
>> In particula my script is as follow:
>> #!/bin/hush
>> A= `cat /proc/driver/cardtype/BoardAddr`
>> B= `expr $A \* 2`
>> C= `expr $B -1`
>> echo $B
>> echo $C
>>
>> but this is the output:
>> hush: cannot exec '`cat': No such file or directory
>> expr: syntax error
>> expr: syntax error
>>
>> Thanks!
>>
>> Fabio
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev at uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev at uclinux.org
>> To unsubscribe see:
>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>>     


From vapier at gentoo.org  Wed Oct 14 06:21:47 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 14 Oct 2009 06:21:47 -0400
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD594F8.1030405@selta.it>
References: <4AD1C54B.8070705@vmlinux.org> <4AD594F8.1030405@selta.it>
Message-ID: <200910140621.47564.vapier@gentoo.org>

On Wednesday 14 October 2009 05:08:08 Cappelletti Fabio wrote:
> Hi all, I'm tying to  write a simple hush script , but I have a lot of
> problem with two commands : expr and cat!
> In particula my script is as follow:
> #!/bin/hush
> A= `cat /proc/driver/cardtype/BoardAddr`
> B= `expr $A \* 2`
> C= `expr $B -1`

you know you cant go sticking whitespace wherever you like, right ?  shell 
scripts are not make files -- whitespace around the "=" matters.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091014/7f4b7698/attachment.sig>

From mschnell at lumino.de  Wed Oct 14 07:46:25 2009
From: mschnell at lumino.de (Michael Schnell)
Date: Wed, 14 Oct 2009 13:46:25 +0200
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD594F8.1030405@selta.it>
References: <4AD1C54B.8070705@vmlinux.org> <4AD594F8.1030405@selta.it>
Message-ID: <4AD5BA11.6060808@lumino.de>

Cappelletti Fabio wrote:

> hush: cannot exec '`cat': No such file or directory

Either you did not create the cat executable in /bin or the $PATH is not
set correctly.

-Michael


From f.cappelletti at selta.it  Wed Oct 14 07:49:34 2009
From: f.cappelletti at selta.it (Cappelletti Fabio)
Date: Wed, 14 Oct 2009 13:49:34 +0200
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD5BA11.6060808@lumino.de>
References: <4AD1C54B.8070705@vmlinux.org> <4AD594F8.1030405@selta.it>
	<4AD5BA11.6060808@lumino.de>
Message-ID: <4AD5BACE.3080404@selta.it>

An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091014/3e89be0c/attachment.html>

From vapier at gentoo.org  Wed Oct 14 08:04:53 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 14 Oct 2009 08:04:53 -0400
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD5BACE.3080404@selta.it>
References: <4AD1C54B.8070705@vmlinux.org> <4AD5BA11.6060808@lumino.de>
	<4AD5BACE.3080404@selta.it>
Message-ID: <200910140804.53751.vapier@gentoo.org>

On Wednesday 14 October 2009 07:49:34 Cappelletti Fabio wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

-EINVAL
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091014/2f9964df/attachment.sig>

From philipn at engarts.com  Wed Oct 14 09:32:02 2009
From: philipn at engarts.com (Philip Nye)
Date: Wed, 14 Oct 2009 14:32:02 +0100
Subject: [uClinux-dev] building uClibc
In-Reply-To: <20091013142006.GK26340@csclub.uwaterloo.ca>
References: <4AD30AB9.2040308@engarts.com>
	<20091013142006.GK26340@csclub.uwaterloo.ca>
Message-ID: <4AD5D2D2.3030200@engarts.com>

Lennart Sorensen wrote:
> On Mon, Oct 12, 2009 at 11:53:45AM +0100, Philip Nye wrote:
>> ...
>> ... but I now get failures
>> down the line because uClibc headers contain lots of libc_hidden_proto()
>> declarations. As I understand it, these headers should be sanitized to
>> remove this internal code for public use, but this is not happening, and I
>> cannot see where it should be carried out. If I simply enter the uClibc
>> directory and try to build from there, I get a different set of errors with
>> missing header files.
...
> I am currently using a coldfire (5270/5271) with gcc 4.3.3, binutils
> 2.19.1, elf2flt (blackfin version from a late april checkout, other
> versions didn't work with gcc 4.3 at the time), 2.6.30 kernel, and
> uclibc 0.9.30.1 (with daemon() function #ifdef'd out to fix compile
> error).

Does your build process "install" uClibc and use the installed headers? or
do you simply use the uClinux build process with the newest uClibc?

Philip



From philipn at engarts.com  Wed Oct 14 09:35:10 2009
From: philipn at engarts.com (Philip Nye)
Date: Wed, 14 Oct 2009 14:35:10 +0100
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD5BACE.3080404@selta.it>
References: <4AD1C54B.8070705@vmlinux.org>
	<4AD594F8.1030405@selta.it>	<4AD5BA11.6060808@lumino.de>
	<4AD5BACE.3080404@selta.it>
Message-ID: <4AD5D38E.9040603@engarts.com>

Cappelletti Fabio wrote:
> this is my path:
> echo $PATH
> /bin:/usr/bin:/etc:/sbin:/usr/sbin
> but if I execute the command in a prompt line  the result is correct like
> # cat /proc/driver/cardtype/Boardaddr
> 3
> I suppose that the problem is when I use ` ` , but I don't know why!

I don't know hush well so may be right off the track, but could this be 
because cat is a built-in command, not an external executable?

Philip


From lsorense at csclub.uwaterloo.ca  Wed Oct 14 10:04:55 2009
From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen)
Date: Wed, 14 Oct 2009 10:04:55 -0400
Subject: [uClinux-dev] building uClibc
In-Reply-To: <4AD5D2D2.3030200@engarts.com>
References: <4AD30AB9.2040308@engarts.com>
	<20091013142006.GK26340@csclub.uwaterloo.ca>
	<4AD5D2D2.3030200@engarts.com>
Message-ID: <20091014140455.GA5496@csclub.uwaterloo.ca>

On Wed, Oct 14, 2009 at 02:32:02PM +0100, Philip Nye wrote:
> Lennart Sorensen wrote:
>> I am currently using a coldfire (5270/5271) with gcc 4.3.3, binutils
>> 2.19.1, elf2flt (blackfin version from a late april checkout, other
>> versions didn't work with gcc 4.3 at the time), 2.6.30 kernel, and
>> uclibc 0.9.30.1 (with daemon() function #ifdef'd out to fix compile
>> error).
>
> Does your build process "install" uClibc and use the installed headers? or
> do you simply use the uClinux build process with the newest uClibc?

I actually made debian packages for each component and build them with
the proper order.  The uclinux-dist was too old and pretty useless to me.

So I built and installed binutils, elf2flt, gcc (without headers),
kernel headers, uclibc, full gcc (c language only).

i don't have a package for gcc without headers, since I only needed one
for the first time.  Now that I have a full gcc, I can built new uclibc's
with it, and I can build new gcc's with the updated headers as well.
It was just needed to bootstrap the process.

-- 
Len Sorensen


From bob.beers at gmail.com  Wed Oct 14 10:18:24 2009
From: bob.beers at gmail.com (Bob Beers)
Date: Wed, 14 Oct 2009 10:18:24 -0400
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <200910140621.47564.vapier@gentoo.org>
References: <4AD1C54B.8070705@vmlinux.org> <4AD594F8.1030405@selta.it>
	<200910140621.47564.vapier@gentoo.org>
Message-ID: <4f6ba3b0910140718i1b7851c8qa3fd5c197bd8c3f@mail.gmail.com>

On Wed, Oct 14, 2009 at 6:21 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Wednesday 14 October 2009 05:08:08 Cappelletti Fabio wrote:
>> Hi all, I'm tying to ?write a simple hush script , but I have a lot of
>> problem with two commands : expr and cat!
>> In particula my script is as follow:
>> #!/bin/hush
>> A= `cat /proc/driver/cardtype/BoardAddr`
>> B= `expr $A \* 2`
>> C= `expr $B -1`
>
> you know you cant go sticking whitespace wherever you like, right ? ?shell
> scripts are not make files -- whitespace around the "=" matters.

+1

specifically, try removing the space after the "=" in all 3 lines:
A=`cat ...`
B=`expr ...`
C=`expr ...`

and there may also be a problem with the spaces
 in the "expr" lines.

You should be able to try each command on the command
 line, including the 'A=' part until you have the syntax correct,
 then the script should also work.

HTH,


-Bob


From mschnell at lumino.de  Wed Oct 14 10:42:30 2009
From: mschnell at lumino.de (Michael Schnell)
Date: Wed, 14 Oct 2009 16:42:30 +0200
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD5D38E.9040603@engarts.com>
References: <4AD1C54B.8070705@vmlinux.org>	<4AD594F8.1030405@selta.it>	<4AD5BA11.6060808@lumino.de>	<4AD5BACE.3080404@selta.it>
	<4AD5D38E.9040603@engarts.com>
Message-ID: <4AD5E356.8020205@lumino.de>

IIRC, cat is not built-in with hush (unfortunately !).

-Michael


From vapier at gentoo.org  Wed Oct 14 11:39:34 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 14 Oct 2009 11:39:34 -0400
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD5E356.8020205@lumino.de>
References: <4AD1C54B.8070705@vmlinux.org> <4AD5D38E.9040603@engarts.com>
	<4AD5E356.8020205@lumino.de>
Message-ID: <200910141139.34834.vapier@gentoo.org>

On Wednesday 14 October 2009 10:42:30 Michael Schnell wrote:
> IIRC, cat is not built-in with hush (unfortunately !).

no one has requested it nor posted a patch, so if there's no demand, things 
arent likely to change.  the only reason echo/printf were made into builtins 
was because someone put stuff together for it (and showed that there's 
significant performance improvements).

considering the current builtin framework that hush has, i doubt making cat 
into a builtin would be hard.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091014/a2b62f37/attachment.sig>

From Allen.Yang at VitecGroup.com  Wed Oct 14 13:04:17 2009
From: Allen.Yang at VitecGroup.com (Allen Yang)
Date: Wed, 14 Oct 2009 13:04:17 -0400
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <200910140804.53751.vapier@gentoo.org>
References: <4AD1C54B.8070705@vmlinux.org>
	<4AD5BA11.6060808@lumino.de><4AD5BACE.3080404@selta.it>
	<200910140804.53751.vapier@gentoo.org>
Message-ID: <84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>

Hi,

I am working on ARM9 based project with Linux 2.6.22 kernel.

I am using JFFS2 (version 2.2) over NAND flash to store some
configuration XML files. Once a parameter in the configuration XML file
is changed, the XML file will be saved back into NAND flash.

The problem I have now is sometimes the XML files get corrupted when
board is powered down. The corrupt XML file size is 0 or only a portion
of the good file size.

Is JFFS2 supposed to be power down safe? Maybe I missed something when
using JFFS2.

Any suggestion is highly appreciated.

Regards,

Allen

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From lsorense at csclub.uwaterloo.ca  Wed Oct 14 14:05:25 2009
From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen)
Date: Wed, 14 Oct 2009 14:05:25 -0400
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
References: <4AD1C54B.8070705@vmlinux.org>
	<200910140804.53751.vapier@gentoo.org>
	<84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
Message-ID: <20091014180525.GB5496@csclub.uwaterloo.ca>

On Wed, Oct 14, 2009 at 01:04:17PM -0400, Allen Yang wrote:
> I am working on ARM9 based project with Linux 2.6.22 kernel.
> 
> I am using JFFS2 (version 2.2) over NAND flash to store some
> configuration XML files. Once a parameter in the configuration XML file
> is changed, the XML file will be saved back into NAND flash.
> 
> The problem I have now is sometimes the XML files get corrupted when
> board is powered down. The corrupt XML file size is 0 or only a portion
> of the good file size.
> 
> Is JFFS2 supposed to be power down safe? Maybe I missed something when
> using JFFS2.
> 
> Any suggestion is highly appreciated.

Ehm, why is this in reply to an email about hush problems?  Seems
confusing.

Unfortunately I don't know anything about JFFS2.

-- 
Len Sorensen


From vapier at gentoo.org  Wed Oct 14 18:25:08 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 14 Oct 2009 18:25:08 -0400
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <20091014180525.GB5496@csclub.uwaterloo.ca>
References: <4AD1C54B.8070705@vmlinux.org>
	<84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
	<20091014180525.GB5496@csclub.uwaterloo.ca>
Message-ID: <200910141825.08746.vapier@gentoo.org>

On Wednesday 14 October 2009 14:05:25 Lennart Sorensen wrote:
> On Wed, Oct 14, 2009 at 01:04:17PM -0400, Allen Yang wrote:
> > I am working on ARM9 based project with Linux 2.6.22 kernel.
> >
> > I am using JFFS2 (version 2.2) over NAND flash to store some
> > configuration XML files. Once a parameter in the configuration XML file
> > is changed, the XML file will be saved back into NAND flash.
> >
> > The problem I have now is sometimes the XML files get corrupted when
> > board is powered down. The corrupt XML file size is 0 or only a portion
> > of the good file size.
> >
> > Is JFFS2 supposed to be power down safe? Maybe I missed something when
> > using JFFS2.
> >
> > Any suggestion is highly appreciated.
> 
> Ehm, why is this in reply to an email about hush problems?  Seems
> confusing.
> 
> Unfortunately I don't know anything about JFFS2.

because Allen hit "reply" and deleted the subject/body instead of starting a 
new e-mail (i.e. thread hijacking)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091014/bd7ae4f1/attachment.sig>

From rkeller at ubicom.com  Wed Oct 14 17:40:54 2009
From: rkeller at ubicom.com (Rainer Keller)
Date: Wed, 14 Oct 2009 14:40:54 -0700
Subject: [uClinux-dev] memory pressure on no-mmu
Message-ID: <20091014214054.GA10649@rkeller-xpdt.scenix.com>

Hi All,

I am experimenting with one of our uClinux-based no-mmu systems and low 
memory situations. I found several articles about OOM (on linux-mm.org 
and LWN), read man 5 proc (from kernel.org to have the latest) and 
grepped and read through at least part of the Documentation folder in 
the kernel. But I must be missing something and would appreciate a 
pointer to what else to read under Documentation or in a white paper /
web page / mailing list thread that explains the following to me:

I created a test that would do n mallocs of size m, figured that size 
4096 allocs already need two pages via proc/pid/maps but 4092 size 
allocs just use one page, then did cat /proc/zoneinfo and had my little 
app just allocate all the free pages in zone Normal.

Also I had set /proc/sys/vm/overcommit_memory to 2 and overcommit_ratio
to 100. And in my /init script echoed -17 to proc/pid/oom_adj of all
running processes. The idea was that I expected to kernel to start 
failing the mallocs on my usermode code.

To my surprise the kernel just panicked:
/ # memuser -t 0 4092 4900
[  113.910000] Kernel panic - not syncing: Out of memory and no killable processes...
[  113.910000] 

I am still a newbie and this must be and age-old topic so I must be
missing some old and very basic discussions that possibly predate linux
about why a kernel just dies like this. 

Or I have just overlooked some part of the documentation that would
allow me to control at which point user mode allocs should start to fail
and return NULL and that is why it panics now (but lowmem_reserve_ratio
and min_free_kbytes and not documented on
http://www.kernel.org/doc/man-pages/online/pages/man5/proc.5.html
?anymore?).

I can see that disabling the OOM killer means taking away the preferred
way for the kernel to deal with an OOM situation, and I saw a patch
mentioned that does bookkeeping of memory for process groups which might
help, but before I start searching for and applying patches I wanted to
ask here.

RTFM type comments (mentioning a useful M) are highly appreciated!

Best Regards,
- Rainer



From mschnell at lumino.de  Thu Oct 15 03:20:11 2009
From: mschnell at lumino.de (Michael Schnell)
Date: Thu, 15 Oct 2009 09:20:11 +0200
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <200910141139.34834.vapier@gentoo.org>
References: <4AD1C54B.8070705@vmlinux.org> <4AD5D38E.9040603@engarts.com>
	<4AD5E356.8020205@lumino.de> <200910141139.34834.vapier@gentoo.org>
Message-ID: <4AD6CD2B.40808@lumino.de>

Thanks for answering.

I found it "unfortunate" that hush did not have built-in cat, when doing
haserl scripts (otherwise much better with hush than with the
depreciated msh).

Do others agree that it's desirable ?

If yes I might plan to add this feature some day soon.

-Michael



From vapier at gentoo.org  Thu Oct 15 03:46:38 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 15 Oct 2009 03:46:38 -0400
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <4AD6CD2B.40808@lumino.de>
References: <4AD1C54B.8070705@vmlinux.org>
	<200910141139.34834.vapier@gentoo.org> <4AD6CD2B.40808@lumino.de>
Message-ID: <200910150346.39184.vapier@gentoo.org>

On Thursday 15 October 2009 03:20:11 Michael Schnell wrote:
> Thanks for answering.
> 
> I found it "unfortunate" that hush did not have built-in cat, when doing
> haserl scripts (otherwise much better with hush than with the
> depreciated msh).
> 
> Do others agree that it's desirable ?

do you see significant/any performance differences ?  if there's a real perf 
gain, then we can add it.

> If yes I might plan to add this feature some day soon.

i just added printf as a builtin.  should show how easy it would be to add cat 
as a builtin:
http://git.busybox.net/busybox/commit/?id=4ebc76c8a23367eaec29931b77e10e3ee890dd7d
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091015/e2f15345/attachment.sig>

From mschnell at lumino.de  Thu Oct 15 04:57:27 2009
From: mschnell at lumino.de (Michael Schnell)
Date: Thu, 15 Oct 2009 10:57:27 +0200
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <200910150334.57000.vapier@gentoo.org>
References: <4AD1C54B.8070705@vmlinux.org>
	<200910141139.34834.vapier@gentoo.org> <4AD6C2A4.9070907@lumino.de>
	<200910150334.57000.vapier@gentoo.org>
Message-ID: <4AD6E3F7.102@lumino.de>

Mike Frysinger wrote:

> 
> i just added printf as a builtin.  should show how easy it would be to add cat 
> as a builtin:
> http://git.busybox.net/busybox/commit/?id=4ebc76c8a23367eaec29931b77e10e3ee890dd7d

I'll take a look.

I feel that it should be configurable with "make menuconfig" if
additional builtin functions should be enabled.

-Michael



From allon.stern at argonst.com  Thu Oct 15 08:53:20 2009
From: allon.stern at argonst.com (Allon Stern)
Date: Thu, 15 Oct 2009 08:53:20 -0400
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
References: <4AD1C54B.8070705@vmlinux.org>
	<4AD5BA11.6060808@lumino.de><4AD5BACE.3080404@selta.it>
	<200910140804.53751.vapier@gentoo.org>
	<84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
Message-ID: <11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>


On Oct 14, 2009, at 1:04 PM, Allen Yang wrote:
> The problem I have now is sometimes the XML files get corrupted when
> board is powered down. The corrupt XML file size is 0 or only a  
> portion
> of the good file size.
>
> Is JFFS2 supposed to be power down safe? Maybe I missed something when
> using JFFS2.

(thread hijacking aside)

I had a number of problems with JFFS2 on my uClinux board; we ended up  
switching to UBIFS, which seems to handle powerdowns pretty well.

Filesystem notwithstanding, make sure that any changes you want  
committed are followed up with an fsync. If you don't fsync, then  
there's a chance that the write will be cached in memory and lost  
before being stored persistently. This is true for any filesystem.

-
allon


From allon.stern at argonst.com  Thu Oct 15 09:43:39 2009
From: allon.stern at argonst.com (Allon Stern)
Date: Thu, 15 Oct 2009 09:43:39 -0400
Subject: [uClinux-dev] Bug in sys_mount (m68knommu)
Message-ID: <71AAFD65-48B2-4151-867A-DA93B9BB26F9@argonst.com>

The kernel is Linux 2.6.28.6

I had a report of a crash on mounting our UBIFS flash volume on our  
m68knommu (Coldfire 5282) platform;
After tracing it down, I found this code in fs/namespace.c:

/*
  * Some copy_from_user() implementations do not return the exact  
number of
  * bytes remaining to copy on a fault.  But copy_mount_options()  
requires that.
  * Note that this function differs from copy_from_user() in that it  
will oops
  * on bad values of `to', rather than returning a short copy.
  */
static long exact_copy_from_user(void *to, const void __user * from,
				 unsignedlong n)
{
	char *t = to;
	const char __user *f = from;
	char c;

	if (!access_ok(VERIFY_READ, from, n))
		return n;

	while (n) {
		if (__get_user(c, f)) {
			memset(t, 0, n);
			break;
		}
		*t++ = c;
		f++;
		n--;
	}
	return n;
}


The problem is that the from address, which is passed into the  
sys_mount syscall, is within a page of the top of memory (sometimes).  
Sys_mount calls copy_mount_options to copy parameters. That call  
doesn't specify a length to copy - it always copies a page worth of  
data. Since the source address is within a page of the top of memory,  
it causes a memory fault.

On m68knommu, access_ok is a noop.
__get_user() *should* return -EFAULT on an error, but instead an  
exception is raised, I think.
I was able to hack around this problem by changing the __get_user()  
line to:

extern unsigned long _ramend;

		if ((f >= _ramend) || __get_user(c, f)) {

Which causes the code to only copy up to the end of memory without  
going over.
Does this find point to an underlying problem in __get_user() on  
m68knommu?

-
allon


From Allen.Yang at VitecGroup.com  Thu Oct 15 10:28:37 2009
From: Allen.Yang at VitecGroup.com (Allen Yang)
Date: Thu, 15 Oct 2009 10:28:37 -0400
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>
References: <4AD1C54B.8070705@vmlinux.org><4AD5BA11.6060808@lumino.de><4AD5BACE.3080404@selta.it><200910140804.53751.vapier@gentoo.org><84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>
Message-ID: <84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>

I didn't realize I hijack the thread. Sorry about that.

I can use fsync() or sync(). However, power can be turned off at any
time even during the sync() in the embedded systems. So I think using
backup file is necessary to recover from corrupt files.

UBIFS doesn't have this type of problems?

Regards,

Allen


-----Original Message-----
From: uclinux-dev-bounces at uclinux.org
[mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Allon Stern
Sent: Thursday, October 15, 2009 8:53 AM
To: uClinux development list
Subject: Re: [uClinux-dev] JFFS2 file corrupt at power down.


On Oct 14, 2009, at 1:04 PM, Allen Yang wrote:
> The problem I have now is sometimes the XML files get corrupted when
> board is powered down. The corrupt XML file size is 0 or only a  
> portion
> of the good file size.
>
> Is JFFS2 supposed to be power down safe? Maybe I missed something when
> using JFFS2.

(thread hijacking aside)

I had a number of problems with JFFS2 on my uClinux board; we ended up  
switching to UBIFS, which seems to handle powerdowns pretty well.

Filesystem notwithstanding, make sure that any changes you want  
committed are followed up with an fsync. If you don't fsync, then  
there's a chance that the write will be cached in memory and lost  
before being stored persistently. This is true for any filesystem.

-
allon
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


From keithmund at cox.net  Thu Oct 15 14:14:27 2009
From: keithmund at cox.net (Keith Mund (AZ))
Date: Thu, 15 Oct 2009 11:14:27 -0700
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>
References: <4AD1C54B.8070705@vmlinux.org><4AD5BA11.6060808@lumino.de><4AD5BACE.3080404@selta.it><200910140804.53751.vapier@gentoo.org><84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>
	<84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>
Message-ID: <005401ca4dc3$552044a0$ff60cde0$@net>

Here is a link to an article that discusses jffs2. It includes the quote
about NAND flash and buffers that follows.

http://www.linux-mtd.infradead.org/faq/jffs2.html

"On NAND FLASHM and NOR ECC FLASH we have a write-buffer for writing only
full pages to the chips. There could be a loss of data, when the
write-buffer is not flushed before power down. There are some mechanisms to
ensure, that the write-buffer is flushed. You can force the flush of the
write-buffer by using fsync() or sync() in your application. JFFS2 has a
timed flush of the write buffer, which forces the flush of the buffer to
flash, if there are no writes to the filesystem for more than about 5
seconds. The time depends on the cycle-time of kupdated, which can be
adjusted via /proc/sys/vm/dirty_expire_centisecs"

Adjusting kupdated would seem to affect more than just jffs2 so it may not
be the best way to improve this but it is at one person's opinion on a
salution.

This made me rethink why this problem wasn't experienced in the last project
in which I used jffs2. Since that device included NOR flash this buffering
is not used. 

Keith

-----Original Message-----
From: uclinux-dev-bounces at uclinux.org
[mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Allen Yang
Sent: Thursday, October 15, 2009 7:29 AM
To: uClinux development list
Subject: RE: [uClinux-dev] JFFS2 file corrupt at power down.

I didn't realize I hijack the thread. Sorry about that.

I can use fsync() or sync(). However, power can be turned off at any
time even during the sync() in the embedded systems. So I think using
backup file is necessary to recover from corrupt files.

UBIFS doesn't have this type of problems?

Regards,

Allen


-----Original Message-----
From: uclinux-dev-bounces at uclinux.org
[mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Allon Stern
Sent: Thursday, October 15, 2009 8:53 AM
To: uClinux development list
Subject: Re: [uClinux-dev] JFFS2 file corrupt at power down.


On Oct 14, 2009, at 1:04 PM, Allen Yang wrote:
> The problem I have now is sometimes the XML files get corrupted when
> board is powered down. The corrupt XML file size is 0 or only a  
> portion
> of the good file size.
>
> Is JFFS2 supposed to be power down safe? Maybe I missed something when
> using JFFS2.

(thread hijacking aside)

I had a number of problems with JFFS2 on my uClinux board; we ended up  
switching to UBIFS, which seems to handle powerdowns pretty well.

Filesystem notwithstanding, make sure that any changes you want  
committed are followed up with an fsync. If you don't fsync, then  
there's a chance that the write will be cached in memory and lost  
before being stored persistently. This is true for any filesystem.

-
allon
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev




From sfking at fdwdc.com  Thu Oct 15 15:54:41 2009
From: sfking at fdwdc.com (Steven King)
Date: Thu, 15 Oct 2009 12:54:41 -0700
Subject: [uClinux-dev] [PATCH] Coldfire GPIO corrections
Message-ID: <200910151254.41599.sfking@fdwdc.com>

Pin 0 of the EPORT is not connected on the 523x, 5271, 5275 and 528x and the 
TIMER on the 523x has 8 pins, not 4.
-- 
Steven King -- sfking at fdwdc dot com

Signed-off-by: Steven King <sfking at fdwdc.com>

diff --git a/arch/m68knommu/platform/523x/gpio.c b/arch/m68knommu/platform/523x/gpio.c
index f02840d..a8842dc 100644
--- a/arch/m68knommu/platform/523x/gpio.c
+++ b/arch/m68knommu/platform/523x/gpio.c
@@ -30,7 +30,8 @@ static struct mcf_gpio_chip mcf_gpio_chips[] = {
 			.direction_output	= mcf_gpio_direction_output,
 			.get			= mcf_gpio_get_value,
 			.set			= mcf_gpio_set_value,
-			.ngpio			= 8,
+			.base			= 1,
+			.ngpio			= 7,
 		},
 		.pddr				= MCFEPORT_EPDDR,
 		.podr				= MCFEPORT_EPDR,
@@ -244,7 +245,7 @@ static struct mcf_gpio_chip mcf_gpio_chips[] = {
 			.get			= mcf_gpio_get_value,
 			.set			= mcf_gpio_set_value_fast,
 			.base			= 96,
-			.ngpio			= 4,
+			.ngpio			= 8,
 		},
 		.pddr				= MCFGPIO_PDDR_TIMER,
 		.podr				= MCFGPIO_PODR_TIMER,
diff --git a/arch/m68knommu/platform/527x/gpio.c b/arch/m68knommu/platform/527x/gpio.c
index 1028142..0b56e19 100644
--- a/arch/m68knommu/platform/527x/gpio.c
+++ b/arch/m68knommu/platform/527x/gpio.c
@@ -31,7 +31,8 @@ static struct mcf_gpio_chip mcf_gpio_chips[] = {
 			.direction_output	= mcf_gpio_direction_output,
 			.get			= mcf_gpio_get_value,
 			.set			= mcf_gpio_set_value,
-			.ngpio			= 8,
+			.base			= 1,
+			.ngpio			= 7,
 		},
 		.pddr				= MCFEPORT_EPDDR,
 		.podr				= MCFEPORT_EPDR,
@@ -263,7 +264,8 @@ static struct mcf_gpio_chip mcf_gpio_chips[] = {
 			.direction_output	= mcf_gpio_direction_output,
 			.get			= mcf_gpio_get_value,
 			.set			= mcf_gpio_set_value,
-			.ngpio			= 8,
+			.base			= 1,
+			.ngpio			= 7,
 		},
 		.pddr				= MCFEPORT_EPDDR,
 		.podr				= MCFEPORT_EPDR,
diff --git a/arch/m68knommu/platform/528x/gpio.c b/arch/m68knommu/platform/528x/gpio.c
index ec59395..eedaf0a 100644
--- a/arch/m68knommu/platform/528x/gpio.c
+++ b/arch/m68knommu/platform/528x/gpio.c
@@ -31,7 +31,7 @@ static struct mcf_gpio_chip mcf_gpio_chips[] = {
 			.get			= mcf_gpio_get_value,
 			.set			= mcf_gpio_set_value,
 			.base			= 1,
-			.ngpio			= 8,
+			.ngpio			= 7,
 		},
 		.pddr				= MCFEPORT_EPDDR,
 		.podr				= MCFEPORT_EPDR,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo
Type: text/x-diff
Size: 2077 bytes
Desc: not available
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091015/7765ac99/attachment.bin>

From ndprasad at gmail.com  Thu Oct 15 19:47:09 2009
From: ndprasad at gmail.com (Prasad)
Date: Thu, 15 Oct 2009 16:47:09 -0700
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <005401ca4dc3$552044a0$ff60cde0$@net>
References: <4AD1C54B.8070705@vmlinux.org> <4AD5BA11.6060808@lumino.de>
	<4AD5BACE.3080404@selta.it> <200910140804.53751.vapier@gentoo.org>
	<84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>
	<84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>
	<005401ca4dc3$552044a0$ff60cde0$@net>
Message-ID: <3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>

"Since that device included NOR flash this buffering is not used."

Do u mean to say for NOR flash we won't have this problem ? Why?

- prasad

On Thu, Oct 15, 2009 at 11:14 AM, Keith Mund (AZ) <keithmund at cox.net> wrote:
> Here is a link to an article that discusses jffs2. It includes the quote
> about NAND flash and buffers that follows.
>
> http://www.linux-mtd.infradead.org/faq/jffs2.html
>
> "On NAND FLASHM and NOR ECC FLASH we have a write-buffer for writing only
> full pages to the chips. There could be a loss of data, when the
> write-buffer is not flushed before power down. There are some mechanisms to
> ensure, that the write-buffer is flushed. You can force the flush of the
> write-buffer by using fsync() or sync() in your application. JFFS2 has a
> timed flush of the write buffer, which forces the flush of the buffer to
> flash, if there are no writes to the filesystem for more than about 5
> seconds. The time depends on the cycle-time of kupdated, which can be
> adjusted via /proc/sys/vm/dirty_expire_centisecs"
>
> Adjusting kupdated would seem to affect more than just jffs2 so it may not
> be the best way to improve this but it is at one person's opinion on a
> salution.
>
> This made me rethink why this problem wasn't experienced in the last project
> in which I used jffs2. Since that device included NOR flash this buffering
> is not used.
>
> Keith
>
> -----Original Message-----
> From: uclinux-dev-bounces at uclinux.org
> [mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Allen Yang
> Sent: Thursday, October 15, 2009 7:29 AM
> To: uClinux development list
> Subject: RE: [uClinux-dev] JFFS2 file corrupt at power down.
>
> I didn't realize I hijack the thread. Sorry about that.
>
> I can use fsync() or sync(). However, power can be turned off at any
> time even during the sync() in the embedded systems. So I think using
> backup file is necessary to recover from corrupt files.
>
> UBIFS doesn't have this type of problems?
>
> Regards,
>
> Allen
>
>
> -----Original Message-----
> From: uclinux-dev-bounces at uclinux.org
> [mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Allon Stern
> Sent: Thursday, October 15, 2009 8:53 AM
> To: uClinux development list
> Subject: Re: [uClinux-dev] JFFS2 file corrupt at power down.
>
>
> On Oct 14, 2009, at 1:04 PM, Allen Yang wrote:
>> The problem I have now is sometimes the XML files get corrupted when
>> board is powered down. The corrupt XML file size is 0 or only a
>> portion
>> of the good file size.
>>
>> Is JFFS2 supposed to be power down safe? Maybe I missed something when
>> using JFFS2.
>
> (thread hijacking aside)
>
> I had a number of problems with JFFS2 on my uClinux board; we ended up
> switching to UBIFS, which seems to handle powerdowns pretty well.
>
> Filesystem notwithstanding, make sure that any changes you want
> committed are followed up with an fsync. If you don't fsync, then
> there's a chance that the write will be cached in memory and lost
> before being stored persistently. This is true for any filesystem.
>
> -
> allon
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>


From allon.stern at argonst.com  Fri Oct 16 08:44:59 2009
From: allon.stern at argonst.com (Allon Stern)
Date: Fri, 16 Oct 2009 08:44:59 -0400
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>
References: <4AD1C54B.8070705@vmlinux.org> <4AD5BA11.6060808@lumino.de>
	<4AD5BACE.3080404@selta.it> <200910140804.53751.vapier@gentoo.org>
	<84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>
	<84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>
	<005401ca4dc3$552044a0$ff60cde0$@net>
	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>
Message-ID: <EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>


On Oct 15, 2009, at 7:47 PM, Prasad wrote:

> "Since that device included NOR flash this buffering is not used."
>
> Do u mean to say for NOR flash we won't have this problem ? Why?

I think his point was that he had NOR flash, but not NOR ECC flash; If  
you look at the linux-mtd webpage, you see the following sentence just  
above the quoted section:

"On NOR FLASH each write goes directly into the FLASH."

A significant omission to the quote.
-
allon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091016/d7de02fc/attachment.html>

From ndprasad at gmail.com  Fri Oct 16 20:03:50 2009
From: ndprasad at gmail.com (Prasad)
Date: Fri, 16 Oct 2009 17:03:50 -0700
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>
References: <4AD1C54B.8070705@vmlinux.org> <4AD5BA11.6060808@lumino.de>
	<4AD5BACE.3080404@selta.it> <200910140804.53751.vapier@gentoo.org>
	<84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>
	<84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>
	<005401ca4dc3$552044a0$ff60cde0$@net>
	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>
	<EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>
Message-ID: <3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>

Got it. Is there any difference in the linux implementation if you use
NOR-ECC flash against NOR flash along with jffs2.


On Fri, Oct 16, 2009 at 5:44 AM, Allon Stern <allon.stern at argonst.com> wrote:
>
> On Oct 15, 2009, at 7:47 PM, Prasad wrote:
>
> "Since that device included NOR flash this buffering is not used."
>
> Do u mean to say for NOR flash we won't have this problem ? Why?
>
> I think his point was that he had NOR flash, but not NOR ECC flash; If you
> look at the linux-mtd webpage, you see the following sentence just above the
> quoted section:
> "On?NOR FLASH?each write goes directly into the FLASH."
> A significant omission to the quote.
> -
> allon
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>


From keithmund at cox.net  Sat Oct 17 19:01:49 2009
From: keithmund at cox.net (Keith Mund (AZ))
Date: Sat, 17 Oct 2009 16:01:49 -0700
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>
References: <4AD1C54B.8070705@vmlinux.org>
	<4AD5BA11.6060808@lumino.de>	<4AD5BACE.3080404@selta.it>
	<200910140804.53751.vapier@gentoo.org>	<84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>	<84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>	<005401ca4dc3$552044a0$ff60cde0$@net>	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>	<EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>
	<3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>
Message-ID: <001e01ca4f7d$cf081480$6d183d80$@net>

On Friday, October 16, 2009 5:04 PM, Prasad wrote:
>Got it. Is there any difference in the linux implementation if you use
>NOR-ECC flash against NOR flash along with jffs2.

I read the question in more than one way.

Keith Mund





From stano at meduna.org  Sat Oct 17 20:05:28 2009
From: stano at meduna.org (Stanislav Meduna)
Date: Sun, 18 Oct 2009 02:05:28 +0200
Subject: [uClinux-dev] Weak symbols problem
Message-ID: <4ADA5BC8.8020201@meduna.org>

Hi,

This is a repost from last year - in the hope that
someone can help or direct me where to dig for the solution.
Tried to use current elf2flt now with no change.


I am trying to compile a C++ program using templates for uClinux.
I get massive problems with weak symbols - it looks like the
elf2flt and/or ld is not able to use the weak symbols.
The toolchain is a self-compiled binutils 2.17, gcc 4.2.1-based one.

Compiling and linking the files in attach gets me bogus message

ERROR: text=0xbec0 overlaps data=0x0 ?
collect2: ld returned 1 exit status

The code compiles fine with -fno-weak, but this is
an unsupported flag and creates other problems (mainly
code bloat from implicit template instantiation).



objdump gives me (uninteresting debug/comment sections stripped):

weak1.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 _ZN7MyClassIiEC1Ev 00000008  00000000  00000000  00000034  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   1 _ZN7MyClassIiED0Ev 00000008  00000000  00000000  0000003c  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   2 _ZN7MyClassIiED1Ev 00000008  00000000  00000000  00000044  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   3 _ZTV7MyClassIiE 00000008  00000000  00000000  0000004c  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   4 .text         00000070  00000000  00000000  00000054  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   5 .data         00000000  00000000  00000000  000000c4  2**0
                   CONTENTS, ALLOC, LOAD, DATA
   6 .bss          00000000  00000000  00000000  000000c4  2**0
                   ALLOC
  10 .text._ZN7MyClassIiEC1Ev 00000028  00000000  00000000  0000046c 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  11 .text._ZN7MyClassIiED0Ev 00000040  00000000  00000000  00000494 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  12 .text._ZN7MyClassIiED1Ev 00000040  00000000  00000000  000004d4 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  13 .rodata._ZTV7MyClassIiE 00000010  00000000  00000000  00000514  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA


weak2.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 _ZN7MyClassIiEC1Ev 00000008  00000000  00000000  00000034  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   1 _ZN7MyClassIiED0Ev 00000008  00000000  00000000  0000003c  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   2 _ZN7MyClassIiED1Ev 00000008  00000000  00000000  00000044  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   3 _ZTV7MyClassIiE 00000008  00000000  00000000  0000004c  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   4 .text         00000048  00000000  00000000  00000054  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   5 .data         00000000  00000000  00000000  0000009c  2**0
                   CONTENTS, ALLOC, LOAD, DATA
   6 .bss          00000000  00000000  00000000  0000009c  2**0
                   ALLOC
  10 .text._ZN7MyClassIiEC1Ev 00000028  00000000  00000000  000003c8 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  11 .text._ZN7MyClassIiED0Ev 00000040  00000000  00000000  000003f0 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  12 .text._ZN7MyClassIiED1Ev 00000040  00000000  00000000  00000430 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  13 .rodata._ZTV7MyClassIiE 00000010  00000000  00000000  00000470  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA


The elf-linked file as produced by the elf2flt script:


weak.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 _ZN7MyClassIiEC1Ev 00000008  00000000  00000000  00000034  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   1 _ZN7MyClassIiED0Ev 00000008  00000000  00000000  0000003c  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   2 _ZN7MyClassIiED1Ev 00000008  00000000  00000000  00000044  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   3 _ZTV7MyClassIiE 00000008  00000000  00000000  0000004c  2**2
                   CONTENTS, READONLY, EXCLUDE, GROUP, LINK_ONCE_DISCARD
   4 .text         0000bec0  00000000  00000000  00000060  2**4
                   CONTENTS, ALLOC, LOAD, RELOC, CODE
   5 .text._ZN7MyClassIiEC1Ev 00000028  00000000  00000000  0000bf20 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   6 .text._ZN7MyClassIiED0Ev 00000040  00000000  00000000  0000bf48 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   7 .text._ZN7MyClassIiED1Ev 00000040  00000000  00000000  0000bf88 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
   8 .rodata._ZTV7MyClassIiE 00000010  00000000  00000000  0000bfc8  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
   9 .data         00001130  0000bec0  0000bec0  0000bfd8  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, DATA
  10 .bss          00000a50  0000cff0  0000cff0  0000d108  2**2
                   ALLOC
  11 .stack        00000000  00000010  00000010  0000d108  2**0
                   CONTENTS
  18 .note.GNU-stack 00000000  00000000  00000000  0000ef80  2**0
                   CONTENTS, READONLY, CODE


The .gdb linked file looks ok:

weak.gdb:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0000bf60  00000000  00000000  00008000  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .data         00001110  0000bf60  0000bf60  00013f60  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00000a50  0000d070  0000d070  00015070  2**2
                   ALLOC
   3 .comment      000001c6  00000000  00000000  00015070  2**0
                   CONTENTS, READONLY



I don't understand the linker script and flags enough to be able
to debug and fix this - it looks like the elf2flt step has problems
with LINK_ONCE_DISCARD or .text.* symbols and is not able to put
them to the .text section where they belong.

Any hints?

Regards
-- 
                                         Stano


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: weak1.cpp
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091018/4cf2a27d/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: weak2.cpp
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091018/4cf2a27d/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: weak.h
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091018/4cf2a27d/attachment.h>

From sfking at fdwdc.com  Sat Oct 17 21:02:58 2009
From: sfking at fdwdc.com (Steven King)
Date: Sat, 17 Oct 2009 18:02:58 -0700
Subject: [uClinux-dev] [PATCH] Merge m68k and m68knommu
Message-ID: <200910171802.59072.sfking@fdwdc.com>

This is a script and patch to merge the m68knommu arch into m68k.

The script was inspired by the script Sam Ravnborg used to merge the 
includes from m68knommu. For those files common to both arches but 
differing in content, the m68k version of the file is renamed to 
<file>_mm.<ext> and the m68knommu version of the file is moved into the 
corresponding m68k directory and renamed <file>_no.<ext> and a small 
wrapper file <file>.<ext> is used to select between the two version. Files 
that are common to both but don't differ are removed from the m68knommu 
tree and files and directories that are unique to the m68knommu tree are 
moved to the m68k tree. Finally, the arch/m68knommu tree is removed.

To select between the the versions of the files, the wrapper uses

#ifdef CONFIG_MMU
#include <file>_mm.<ext>
#else
#include <file>_no.<ext>
#endif

The patch modifies the toplevel Makefile so that ARCH=m68knommu still works 
(by setting SRCARCH=m68k) and adds the m68knommu Kconfig and Makefile 
to the m68k Kconfig and Makefile, using the definition of ARCH to select 
which values to use.

Thus when building for either a m68k or an m68knommu target, one still 
specifies either ARCH=m68k or ARCH=m68knommu and everything should 
build EXACTLY as it did pre-merge.  (I think).


Signed-off-by: Steven King <sfking at fdwdc.com>

-------------------------------------------------------------------------------

#!/bin/sh


mergefile() {
	BASE=${1%.?}
	EXT=${1#${BASE}}
	git mv ${TARGET}/$1 ${TARGET}/${BASE}_mm${EXT}
	git mv ${SOURCE}/$1 ${TARGET}/${BASE}_no${EXT}
	cat <<-EOF > ${TARGET}/$1
	#ifdef CONFIG_MMU
	#include "${BASE}_mm${EXT}"
	#else
	#include "${BASE}_no${EXT}"
	#endif
	EOF
	git add ${TARGET}/$1
}

mergedir() {
	TARGET=arch/m68k/$1
	SOURCE=arch/m68knommu/$1
	files=${1}_MERGE_FILES
	MERGE_FILES=${!files}

	echo "merging files in $1"
	for F in $MERGE_FILES ; do
		mergefile $F
	done

	files=${1}_NOMERGE_FILES
	NOMERGE_FILES=${!files}

	echo "moving files in $1"
	for F in $NOMERGE_FILES ; do
		git mv ${SOURCE}/$F ${TARGET}/$F
	done

	files=${1}_REMOVE_FILES
	REMOVE_FILES=${!files}

	echo "removing common files in $1"
	for F in $REMOVE_FILES ; do
		git rm ${SOURCE}/$F
	done

	if [ -e ${SOURCE}/Makefile ]; then
	git mv ${TARGET}/Makefile ${TARGET}/Makefile_mm
	git mv ${SOURCE}/Makefile ${TARGET}/Makefile_no
	cat <<-EOF > ${TARGET}/Makefile
	ifdef CONFIG_MMU
	include ${TARGET}/Makefile_mm
	else
	include ${TARGET}/Makefile_no
	endif
	EOF
	git add ${TARGET}/Makefile
	fi
}

configs_MERGE_FILES=""
configs_NOMERGE_FILES="m5208evb_defconfig \
			m5272c3_defconfig \
			m5307c3_defconfig \
			m5249evb_defconfig \
			m5275evb_defconfig \
			m5407c3_defconfig"
configs_REMOVE_FILES=""
kernel_MERGE_FILES="asm-offsets.c \
			dma.c entry.S \
			m68k_ksyms.c \
			module.c \
			process.c \
			ptrace.c \
			setup.c \
			signal.c \
			sys_m68k.c \
			time.c \
			traps.c \
			vmlinux.lds.S"
kernel_NOMERGE_FILES="init_task.c \
			irq.c \
			syscalltable.S"
kernel_REMOVE_FILES=""
lib_MERGE_FILES="checksum.c \
			muldi3.c"
lib_NOMERGE_FILES="delay.c \
			divsi3.S \
			memcpy.c \
			memset.c \
			modsi3.S \
			mulsi3.S \
			udivsi3.S \
			umodsi3.S"
lib_REMOVE_FILES="ashldi3.c \
			ashrdi3.c \
			lshrdi3.c"
mm_MERGE_FILES="fault.c \
			init.c \
			kmap.c \
			memory.c"
mm_NOMERGE_FILES=""
mm_REMOVE_FILES=""

DIRS="configs kernel lib mm"

for dir in $DIRS ; do
	mergedir $dir
done
echo "moving platform"
git mv arch/m68knommu/platform arch/m68k/
echo "removing remaining m68knommu dirs"
git rm -r arch/m68knommu
rm -r arch/m68knommu
exit 0

-------------------------------------------------------------------------------

Signed-off-by: Steven King <sfking at fdwdc.com>

diff --git a/Makefile b/Makefile
index 9425d1d..1de4c0f 100644
--- a/Makefile
+++ b/Makefile
@@ -205,13 +205,14 @@ ifeq ($(ARCH),sh64)
        SRCARCH := sh
 endif

-# Where to locate arch specific headers
-hdr-arch  := $(SRCARCH)
-
+# Additional ARCH settings for m68k
 ifeq ($(ARCH),m68knommu)
-       hdr-arch  := m68k
+       SRCARCH  := m68k
 endif

+# Where to locate arch specific headers
+hdr-arch  := $(SRCARCH)
+
 KCONFIG_CONFIG	?= .config

 # SHELL used by kbuild
diff --git a/arch/m68k/Kconfig.debug b/arch/m68k/Kconfig.debug
index f53b6d5..cec668b 100644
--- a/arch/m68k/Kconfig.debug
+++ b/arch/m68k/Kconfig.debug
@@ -2,4 +2,37 @@ menu "Kernel hacking"

 source "lib/Kconfig.debug"

+if ARCH = "m68knommu"
+
+config FULLDEBUG
+	bool "Full Symbolic/Source Debugging support"
+	help
+	  Enable debugging symbols on kernel build.
+
+config HIGHPROFILE
+	bool "Use fast second timer for profiling"
+	depends on COLDFIRE
+	help
+	  Use a fast secondary clock to produce profiling information.
+
+config BOOTPARAM
+	bool 'Compiled-in Kernel Boot Parameter'
+
+config BOOTPARAM_STRING
+	string 'Kernel Boot Parameter'
+	default 'console=ttyS0,19200'
+	depends on BOOTPARAM
+
+config NO_KERNEL_MSG
+	bool "Suppress Kernel BUG Messages"
+	help
+	  Do not output any debug BUG messages within the kernel.
+
+config BDM_DISABLE
+	bool "Disable BDM signals"
+	depends on (EXPERIMENTAL && COLDFIRE)
+	help
+	  Disable the ColdFire CPU's BDM signals.
+
+endif
 endmenu
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 29dd848..7a27ca7 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -2,6 +2,8 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/kconfig-language.txt.
 #
+if ARCH != "m68knommu"
+
 config M68K
 	bool
 	default y
@@ -64,6 +66,89 @@ config GENERIC_TIME
 config ARCH_USES_GETTIMEOFFSET
 	def_bool y

+endif
+
+if ARCH = "m68knommu"
+
+config M68K
+	bool
+	default y
+	select HAVE_IDE
+
+config MMU
+	bool
+	default n
+
+config NO_DMA
+	bool
+	depends on !COLDFIRE
+	default y
+
+config FPU
+	bool
+	default n
+
+config ZONE_DMA
+	bool
+	default y
+
+config RWSEM_GENERIC_SPINLOCK
+	bool
+	default y
+
+config RWSEM_XCHGADD_ALGORITHM
+	bool
+	default n
+
+config ARCH_HAS_ILOG2_U32
+	bool
+	default n
+
+config ARCH_HAS_ILOG2_U64
+	bool
+	default n
+
+config GENERIC_FIND_NEXT_BIT
+	bool
+	default y
+
+config GENERIC_GPIO
+	bool
+	default n
+
+config GENERIC_HWEIGHT
+	bool
+	default y
+
+config GENERIC_HARDIRQS
+	bool
+	default y
+
+config GENERIC_CALIBRATE_DELAY
+	bool
+	default y
+
+config GENERIC_TIME
+	bool
+	default y
+
+config GENERIC_CMOS_UPDATE
+	bool
+	default y
+
+config TIME_LOW_RES
+	bool
+	default y
+
+config GENERIC_CLOCKEVENTS
+	bool
+	default n
+
+config NO_IOPORT
+	def_bool y
+
+endif
+
 mainmenu "Linux/68k Kernel Configuration"

 source "init/Kconfig"
@@ -72,6 +157,7 @@ source "kernel/Kconfig.freezer"

 menu "Platform dependent setup"

+if ARCH != "m68knommu"
 config EISA
 	bool
 	---help---
@@ -384,15 +470,638 @@ config NODES_SHIFT
 	int
 	default "3"
 	depends on !SINGLE_MEMORY_CHUNK
+endif
+
+
+if ARCH = "m68knommu"
+choice
+	prompt "CPU"
+	default M68EZ328
+
+config M68328
+	bool "MC68328"
+	help
+	  Motorola 68328 processor support.
+
+config M68EZ328
+	bool "MC68EZ328"
+	help
+	  Motorola 68EX328 processor support.
+
+config M68VZ328
+	bool "MC68VZ328"
+	help
+	  Motorola 68VZ328 processor support.
+
+config M68360
+	bool "MC68360"
+	help
+	  Motorola 68360 processor support.
+
+config M5206
+	bool "MCF5206"
+	help
+	  Motorola ColdFire 5206 processor support.
+
+config M5206e
+	bool "MCF5206e"
+	help
+	  Motorola ColdFire 5206e processor support.
+
+config M520x
+	bool "MCF520x"
+	select GENERIC_CLOCKEVENTS
+	help
+	   Freescale Coldfire 5207/5208 processor support.
+
+config M523x
+	bool "MCF523x"
+	select GENERIC_CLOCKEVENTS
+	help
+	  Freescale Coldfire 5230/1/2/4/5 processor support
+
+config M5249
+	bool "MCF5249"
+	help
+	  Motorola ColdFire 5249 processor support.
+
+config M5271
+	bool "MCF5271"
+	help
+	  Freescale (Motorola) ColdFire 5270/5271 processor support.
+
+config M5272
+	bool "MCF5272"
+	help
+	  Motorola ColdFire 5272 processor support.
+
+config M5275
+	bool "MCF5275"
+	help
+	  Freescale (Motorola) ColdFire 5274/5275 processor support.
+
+config M528x
+	bool "MCF528x"
+	select GENERIC_CLOCKEVENTS
+	help
+	  Motorola ColdFire 5280/5282 processor support.
+
+config M5307
+	bool "MCF5307"
+	help
+	  Motorola ColdFire 5307 processor support.
+
+config M532x
+	bool "MCF532x"
+	help
+	  Freescale (Motorola) ColdFire 532x processor support.
+
+config M5407
+	bool "MCF5407"
+	help
+	  Motorola ColdFire 5407 processor support.
+
+endchoice
+
+config M527x
+	bool
+	depends on (M5271 || M5275)
+	select GENERIC_CLOCKEVENTS
+	default y
+
+config COLDFIRE
+	bool
+	depends on (M5206 || M5206e || M520x || M523x || M5249 || M527x || 
M5272 || M528x || M5307 || M532x || M5407)
+	select GENERIC_GPIO
+	select ARCH_REQUIRE_GPIOLIB
+	default y
+
+config CLOCK_SET
+	bool "Enable setting the CPU clock frequency"
+	default n
+	help
+	  On some CPU's you do not need to know what the core CPU clock
+	  frequency is. On these you can disable clock setting. On some
+	  traditional 68K parts, and on all ColdFire parts you need to set
+	  the appropriate CPU clock frequency. On these devices many of the
+	  onboard peripherals derive their timing from the master CPU clock
+	  frequency.
+
+config CLOCK_FREQ
+	int "Set the core clock frequency"
+	default "66666666"
+	depends on CLOCK_SET
+	help
+	  Define the CPU clock frequency in use. This is the core clock
+	  frequency, it may or may not be the same as the external clock
+	  crystal fitted to your board. Some processors have an internal
+	  PLL and can have their frequency programmed at run time, others
+	  use internal dividers. In general the kernel won't setup a PLL
+	  if it is fitted (there are some exceptions). This value will be
+	  specific to the exact CPU that you are using.
+
+config CLOCK_DIV
+	int "Set the core/bus clock divide ratio"
+	default "1"
+	depends on CLOCK_SET
+	help
+	  On many SoC style CPUs the master CPU clock is also used to drive
+	  on-chip peripherals. The clock that is distributed to these
+	  peripherals is sometimes a fixed ratio of the master clock
+	  frequency. If so then set this to the divider ratio of the
+	  master clock to the peripheral clock. If not sure then select 1.
+
+config OLDMASK
+	bool "Old mask 5307 (1H55J) silicon"
+	depends on M5307
+	help
+	  Build support for the older revision ColdFire 5307 silicon.
+	  Specifically this is the 1H55J mask revision.
+
+comment "Platform"
+
+config PILOT3
+	bool "Pilot 1000/5000, PalmPilot Personal/Pro, or PalmIII support"
+	depends on M68328
+	help
+	  Support for the Palm Pilot 1000/5000, Personal/Pro and PalmIII.
+
+config XCOPILOT_BUGS
+	bool "(X)Copilot support"
+	depends on PILOT3
+	help
+	  Support the bugs of Xcopilot.
+
+config UC5272
+        bool 'Arcturus Networks uC5272 dimm board support'
+        depends on M5272
+        help
+          Support for the Arcturus Networks uC5272 dimm board.
+
+config UC5282
+       bool "Arcturus Networks uC5282 board support"
+          depends on M528x
+       help
+          Support for the Arcturus Networks uC5282 dimm board.
+
+config UCSIMM
+	bool "uCsimm module support"
+	depends on M68EZ328
+	help
+	  Support for the Arcturus Networks uCsimm module.
+
+config UCDIMM
+	bool "uDsimm module support"
+	depends on M68VZ328
+	help
+	  Support for the Arcturus Networks uDsimm module.
+
+config DRAGEN2
+	bool "DragenEngine II board support"
+	depends on M68VZ328
+	help
+	  Support for the DragenEngine II board.
+
+config DIRECT_IO_ACCESS
+	bool "Allow user to access IO directly"
+	depends on (UCSIMM || UCDIMM || DRAGEN2)
+	help
+	  Disable the CPU internal registers protection in user mode,
+          to allow a user application to read/write them.
+
+config INIT_LCD
+	bool "Initialize LCD"
+	depends on (UCSIMM || UCDIMM || DRAGEN2)
+	help
+	  Initialize the LCD controller of the 68x328 processor.
+
+config MEMORY_RESERVE
+	int "Memory reservation (MiB)"
+	depends on (UCSIMM || UCDIMM)
+	help
+	  Reserve certain memory regions on 68x328 based boards.
+
+config UCQUICC
+	bool "Lineo uCquicc board support"
+	depends on M68360
+	help
+	  Support for the Lineo uCquicc board.
+
+config ARN5206
+	bool "Arnewsh 5206 board support"
+	depends on M5206
+	help
+	  Support for the Arnewsh 5206 board.
+
+config M5206eC3
+	bool "Motorola M5206eC3 board support"
+	depends on M5206e
+	help
+	  Support for the Motorola M5206eC3 board.
+
+config ELITE
+	bool "Motorola M5206eLITE board support"
+	depends on M5206e
+	help
+	  Support for the Motorola M5206eLITE board.
+
+config M5208EVB
+	bool "Freescale M5208EVB board support"
+	depends on M520x
+	help
+	  Support for the Freescale Coldfire M5208EVB.
+
+config M5235EVB
+	bool "Freescale M5235EVB support"
+	depends on M523x
+	help
+	  Support for the Freescale M5235EVB board.
+
+config M5249C3
+	bool "Motorola M5249C3 board support"
+	depends on M5249
+	help
+	  Support for the Motorola M5249C3 board.
+
+config M5271EVB
+	bool "Freescale (Motorola) M5271EVB board support"
+	depends on M5271
+	help
+	  Support for the Freescale (Motorola) M5271EVB board.
+
+config M5275EVB
+	bool "Freescale (Motorola) M5275EVB board support"
+	depends on M5275
+	help
+	  Support for the Freescale (Motorola) M5275EVB board.
+
+config M5272C3
+	bool "Motorola M5272C3 board support"
+	depends on M5272
+	help
+	  Support for the Motorola M5272C3 board.
+
+config COBRA5272
+	bool "senTec COBRA5272 board support"
+	depends on M5272
+	help
+	  Support for the senTec COBRA5272 board.
+
+config AVNET5282
+	bool "Avnet 5282 board support"
+	depends on M528x
+	help
+	  Support for the Avnet 5282 board.
+
+config M5282EVB
+	bool "Motorola M5282EVB board support"
+	depends on M528x
+	help
+	  Support for the Motorola M5282EVB board.
+
+config COBRA5282
+	bool "senTec COBRA5282 board support"
+	depends on M528x
+	help
+	  Support for the senTec COBRA5282 board.
+
+config SOM5282EM
+	bool "EMAC.Inc SOM5282EM board support"
+	depends on M528x
+	help
+	  Support for the EMAC.Inc SOM5282EM module.
+
+config WILDFIRE
+	bool "Intec Automation Inc. WildFire board support"
+	depends on M528x
+	help
+	  Support for the Intec Automation Inc. WildFire.
+
+config WILDFIREMOD
+	bool "Intec Automation Inc. WildFire module support"
+	depends on M528x
+	help
+	  Support for the Intec Automation Inc. WildFire module.
+
+config ARN5307
+	bool "Arnewsh 5307 board support"
+	depends on M5307
+	help
+	  Support for the Arnewsh 5307 board.
+
+config M5307C3
+	bool "Motorola M5307C3 board support"
+	depends on M5307
+	help
+	  Support for the Motorola M5307C3 board.
+
+config SECUREEDGEMP3
+	bool "SnapGear SecureEdge/MP3 platform support"
+	depends on M5307
+	help
+	  Support for the SnapGear SecureEdge/MP3 platform.
+
+config M5329EVB
+	bool "Freescale (Motorola) M5329EVB board support"
+	depends on M532x
+	help
+	  Support for the Freescale (Motorola) M5329EVB board.
+
+config COBRA5329
+	bool "senTec COBRA5329 board support"
+	depends on M532x
+	help
+	  Support for the senTec COBRA5329 board.
+
+config M5407C3
+	bool "Motorola M5407C3 board support"
+	depends on M5407
+	help
+	  Support for the Motorola M5407C3 board.
+
+config CLEOPATRA
+	bool "Feith CLEOPATRA board support"
+	depends on (M5307 || M5407)
+	help
+	  Support for the Feith Cleopatra boards.
+
+config CANCam
+	bool "Feith CANCam board support"
+	depends on M5272
+	help
+	  Support for the Feith CANCam board.
+
+config SCALES
+	bool "Feith SCALES board support"
+	depends on M5272
+	help
+	  Support for the Feith SCALES board.
+
+config NETtel
+	bool "SecureEdge/NETtel board support"
+	depends on (M5206e || M5272 || M5307)
+	help
+	  Support for the SnapGear NETtel/SecureEdge/SnapGear boards.
+
+config SNAPGEAR
+	bool "SnapGear router board support"
+	depends on NETtel
+	help
+	  Special additional support for SnapGear router boards.
+
+config CPU16B
+	bool "Sneha Technologies S.L. Sarasvati board support"
+	depends on M5272
+	help
+	  Support for the SNEHA CPU16B board.
+
+config MOD5272
+	bool "Netburner MOD-5272 board support"
+	depends on M5272
+	help
+	  Support for the Netburner MOD-5272 board.
+
+config SAVANTrosie1
+	bool "Savant Rosie1 board support"
+	depends on M523x
+	help
+	  Support for the Savant Rosie1 board.
+
+config ROMFS_FROM_ROM
+	bool "ROMFS image not RAM resident"
+	depends on (NETtel || SNAPGEAR)
+	help
+	  The ROMfs filesystem will stay resident in the FLASH/ROM, not be
+	  moved into RAM.
+
+config PILOT
+	bool
+	default y
+	depends on (PILOT3 || PILOT5)
+
+config ARNEWSH
+	bool
+	default y
+	depends on (ARN5206 || ARN5307)
+
+config FREESCALE
+	bool
+	default y
+	depends on (M5206eC3 || M5208EVB || M5235EVB || M5249C3 || 
M5271EVB || M5272C3 || M5275EVB || M5282EVB || M5307C3 || M5329EVB || 
M5407C3)
+
+config HW_FEITH
+	bool
+	default y
+	depends on (CLEOPATRA || CANCam || SCALES)
+
+config senTec
+	bool
+	default y
+	depends on (COBRA5272 || COBRA5282)
+
+config EMAC_INC
+	bool
+	default y
+	depends on (SOM5282EM)
+
+config SNEHA
+        bool
+	default y
+	depends on CPU16B
+
+config SAVANT
+	bool
+	default y
+	depends on SAVANTrosie1
+
+config AVNET
+	bool
+	default y
+	depends on (AVNET5282)
+
+config 4KSTACKS
+	bool "Use 4Kb for kernel stacks instead of 8Kb"
+	default y
+	help
+	  If you say Y here the kernel will use a 4Kb stacksize for the
+	  kernel stack attached to each process/thread. This facilitates
+	  running more threads on a system and also reduces the pressure
+	  on the VM subsystem for higher order allocations.
+
+config HZ
+	int
+	default 1000 if CLEOPATRA
+	default 100
+
+comment "RAM configuration"
+
+config RAMBASE
+	hex "Address of the base of RAM"
+	default "0"
+	help
+	  Define the address that RAM starts at. On many platforms this is
+	  0, the base of the address space. And this is the default. Some
+	  platforms choose to setup their RAM at other addresses within the
+	  processor address space.
+
+config RAMSIZE
+	hex "Size of RAM (in bytes)"
+	default "0x400000"
+	help
+	  Define the size of the system RAM. If you select 0 then the
+	  kernel will try to probe the RAM size at runtime. This is not
+	  supported on all CPU types.
+
+config VECTORBASE
+	hex "Address of the base of system vectors"
+	default "0"
+	help
+	  Define the address of the system vectors. Commonly this is
+	  put at the start of RAM, but it doesn't have to be. On ColdFire
+	  platforms this address is programmed into the VBR register, thus
+	  actually setting the address to use.
+
+config KERNELBASE
+	hex "Address of the base of kernel code"
+	default "0x400"
+	help
+	  Typically on m68k systems the kernel will not start at the base
+	  of RAM, but usually some small offset from it. Define the start
+	  address of the kernel here. The most common setup will have the
+	  processor vectors at the base of RAM and then the start of the
+	  kernel. On some platforms some RAM is reserved for boot loaders
+	  and the kernel starts after that. The 0x400 default was based on
+	  a system with the RAM based at address 0, and leaving enough room
+	  for the theoretical maximum number of 256 vectors.
+
+choice
+	prompt "RAM bus width"
+	default RAMAUTOBIT
+
+config RAMAUTOBIT
+	bool "AUTO"
+	help
+	  Select the physical RAM data bus size. Not needed on most platforms,
+	  so you can generally choose AUTO.
+
+config RAM8BIT
+	bool "8bit"
+	help
+	  Configure RAM bus to be 8 bits wide.
+
+config RAM16BIT
+	bool "16bit"
+	help
+	  Configure RAM bus to be 16 bits wide.
+
+config RAM32BIT
+	bool "32bit"
+	help
+	  Configure RAM bus to be 32 bits wide.
+
+endchoice
+
+comment "ROM configuration"
+
+config ROM
+	bool "Specify ROM linker regions"
+	default n
+	help
+	  Define a ROM region for the linker script. This creates a kernel
+	  that can be stored in flash, with possibly the text, and data
+	  regions being copied out to RAM at startup.
+
+config ROMBASE
+	hex "Address of the base of ROM device"
+	default "0"
+	depends on ROM
+	help
+	  Define the address that the ROM region starts at. Some platforms
+	  use this to set their chip select region accordingly for the boot
+	  device.
+
+config ROMVEC
+	hex "Address of the base of the ROM vectors"
+	default "0"
+	depends on ROM
+	help
+	  This is almost always the same as the base of the ROM. Since on all
+	  68000 type variants the vectors are at the base of the boot device
+	  on system startup.
+
+config ROMVECSIZE
+	hex "Size of ROM vector region (in bytes)"
+	default "0x400"
+	depends on ROM
+	help
+	  Define the size of the vector region in ROM. For most 68000
+	  variants this would be 0x400 bytes in size. Set to 0 if you do
+	  not want a vector region at the start of the ROM.
+
+config ROMSTART
+	hex "Address of the base of system image in ROM"
+	default "0x400"
+	depends on ROM
+	help
+	  Define the start address of the system image in ROM. Commonly this
+	  is strait after the ROM vectors.
+
+config ROMSIZE
+	hex "Size of the ROM device"
+	default "0x100000"
+	depends on ROM
+	help
+	  Size of the ROM device. On some platforms this is used to setup
+	  the chip select that controls the boot ROM device.
+
+choice
+	prompt "Kernel executes from"
+	---help---
+	  Choose the memory type that the kernel will be running in.
+
+config RAMKERNEL
+	bool "RAM"
+	help
+	  The kernel will be resident in RAM when running.
+
+config ROMKERNEL
+	bool "ROM"
+	help
+	  The kernel will be resident in FLASH/ROM when running. This is
+	  often referred to as Execute-in-Place (XIP), since the kernel
+	  code executes from the position it is stored in the FLASH/ROM.
+
+endchoice
+
+if COLDFIRE
+source "kernel/Kconfig.preempt"
+endif
+
+source "kernel/time/Kconfig"
+
+endif

 source "mm/Kconfig"

 endmenu

+
+if ARCH = "m68knommu"
+
+config ISA_DMA_API
+	bool
+	depends on !M5272
+	default y
+
+source "drivers/pcmcia/Kconfig"
+endif
+
 menu "General setup"

 source "fs/Kconfig.binfmt"

+if ARCH != "m68knommu"
+
 config ZORRO
 	bool "Amiga Zorro (AutoConfig) bus support"
 	depends on AMIGA
@@ -458,12 +1167,29 @@ source "drivers/pci/Kconfig"

 source "drivers/zorro/Kconfig"

+endif
+
 endmenu

+if ARCH = "m68knommu"
+
+menu "Power management options"
+
+config PM
+	bool "Power Management support"
+	help
+	  Support processor power management modes
+
+endmenu
+
+endif
+
 source "net/Kconfig"

 source "drivers/Kconfig"

+if ARCH != "m68knommu"
+
 menu "Character devices"

 config ATARI_MFPSER
@@ -618,6 +1344,8 @@ config SERIAL_CONSOLE

 endmenu

+endif
+
 source "fs/Kconfig"

 source "arch/m68k/Kconfig.debug"
diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
index 570d85c..3910b46 100644
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -1,3 +1,5 @@
+ifeq ($(ARCH),m68k)
+
 #
 # m68k/Makefile
 #
@@ -120,3 +122,130 @@ archclean:

 install:
 	sh $(srctree)/arch/m68k/install.sh $(KERNELRELEASE) vmlinux.gz 
System.map "$(INSTALL_PATH)"
+
+else
+
+#
+# m68knommu Makefile
+#
+# This file is subject to the terms and conditions of the GNU General 
Public
+# License.  See the file "COPYING" in the main directory of this archive
+# for more details.
+#
+# (C) Copyright 2002, Greg Ungerer <gerg at snapgear.com>
+#
+
+KBUILD_DEFCONFIG := m5208evb_defconfig
+
+platform-$(CONFIG_M68328)	:= 68328
+platform-$(CONFIG_M68EZ328)	:= 68EZ328
+platform-$(CONFIG_M68VZ328)	:= 68VZ328
+platform-$(CONFIG_M68360)	:= 68360
+platform-$(CONFIG_M5206)	:= 5206
+platform-$(CONFIG_M5206e)	:= 5206e
+platform-$(CONFIG_M520x)	:= 520x
+platform-$(CONFIG_M523x)	:= 523x
+platform-$(CONFIG_M5249)	:= 5249
+platform-$(CONFIG_M527x)	:= 527x
+platform-$(CONFIG_M5272)	:= 5272
+platform-$(CONFIG_M528x)	:= 528x
+platform-$(CONFIG_M5307)	:= 5307
+platform-$(CONFIG_M532x)	:= 532x
+platform-$(CONFIG_M5407)	:= 5407
+PLATFORM := $(platform-y)
+
+board-$(CONFIG_PILOT)		:= pilot
+board-$(CONFIG_UC5272)          := UC5272
+board-$(CONFIG_UC5282)          := UC5282
+board-$(CONFIG_UCSIMM)		:= ucsimm
+board-$(CONFIG_UCDIMM)		:= ucdimm
+board-$(CONFIG_UCQUICC)		:= uCquicc
+board-$(CONFIG_DRAGEN2)		:= de2
+board-$(CONFIG_ARNEWSH)		:= ARNEWSH
+board-$(CONFIG_FREESCALE)	:= FREESCALE
+board-$(CONFIG_M5235EVB)	:= M5235EVB
+board-$(CONFIG_M5271EVB)	:= M5271EVB
+board-$(CONFIG_M5275EVB)	:= M5275EVB
+board-$(CONFIG_M5282EVB)	:= M5282EVB
+board-$(CONFIG_ELITE)		:= eLITE
+board-$(CONFIG_NETtel)		:= NETtel
+board-$(CONFIG_SECUREEDGEMP3)	:= MP3
+board-$(CONFIG_CLEOPATRA)	:= CLEOPATRA
+board-$(CONFIG_senTec)		:= senTec
+board-$(CONFIG_SNEHA) 	        := SNEHA
+board-$(CONFIG_M5208EVB)	:= M5208EVB
+board-$(CONFIG_MOD5272)		:= MOD5272
+board-$(CONFIG_AVNET)           := AVNET
+board-$(CONFIG_SAVANT)		:= SAVANT
+BOARD := $(board-y)
+
+model-$(CONFIG_RAMKERNEL)	:= ram
+model-$(CONFIG_ROMKERNEL)	:= rom
+MODEL := $(model-y)
+
+#
+# Some code support is grouped together for a common cpu-subclass (for
+# example all ColdFire cpu's are very similar). Determine the sub-class
+# for the selected cpu. ONLY need to define this for the non-base member
+# of the family.
+#
+cpuclass-$(CONFIG_M5206)	:= coldfire
+cpuclass-$(CONFIG_M5206e)	:= coldfire
+cpuclass-$(CONFIG_M520x)	:= coldfire
+cpuclass-$(CONFIG_M523x)	:= coldfire
+cpuclass-$(CONFIG_M5249)	:= coldfire
+cpuclass-$(CONFIG_M527x)	:= coldfire
+cpuclass-$(CONFIG_M5272)	:= coldfire
+cpuclass-$(CONFIG_M528x)	:= coldfire
+cpuclass-$(CONFIG_M5307)	:= coldfire
+cpuclass-$(CONFIG_M532x)	:= coldfire
+cpuclass-$(CONFIG_M5407)	:= coldfire
+cpuclass-$(CONFIG_M68328)	:= 68328
+cpuclass-$(CONFIG_M68EZ328)	:= 68328
+cpuclass-$(CONFIG_M68VZ328)	:= 68328
+cpuclass-$(CONFIG_M68360)	:= 68360
+CPUCLASS := $(cpuclass-y)
+
+ifneq ($(CPUCLASS),$(PLATFORM))
+CLASSDIR := arch/m68k/platform/$(cpuclass-y)/
+endif
+
+export PLATFORM BOARD MODEL CPUCLASS
+
+#
+# Some CFLAG additions based on specific CPU type.
+#
+cflags-$(CONFIG_M5206)		:= $(call cc-option,-mcpu=5206,-m5200)
+cflags-$(CONFIG_M5206e)		:= $(call cc-option,-m5206e,-m5200)
+cflags-$(CONFIG_M520x)		:= $(call cc-option,-mcpu=5208,-m5200)
+cflags-$(CONFIG_M523x)		:= $(call cc-option,-mcpu=523x,-m5307)
+cflags-$(CONFIG_M5249)		:= $(call cc-option,-mcpu=5249,-m5200)
+cflags-$(CONFIG_M5271)		:= $(call cc-option,-mcpu=5271,-m5307)
+cflags-$(CONFIG_M5272)		:= $(call cc-option,-mcpu=5271,-m5200)
+cflags-$(CONFIG_M5275)		:= $(call cc-option,-mcpu=5275,-m5307)
+cflags-$(CONFIG_M528x)		:= $(call cc-option,-m528x,-m5307)
+cflags-$(CONFIG_M5307)		:= $(call cc-option,-m5307,-m5200)
+cflags-$(CONFIG_M532x)		:= $(call cc-option,-mcpu=532x,-m5307)
+cflags-$(CONFIG_M5407)		:= $(call cc-option,-m5407,-m5200)
+cflags-$(CONFIG_M68328)		:= -m68000
+cflags-$(CONFIG_M68EZ328)	:= -m68000
+cflags-$(CONFIG_M68VZ328)	:= -m68000
+cflags-$(CONFIG_M68360)		:= -m68332
+
+KBUILD_AFLAGS += $(cflags-y)
+
+KBUILD_CFLAGS += $(cflags-y)
+KBUILD_CFLAGS += -D__linux__
+KBUILD_CFLAGS += -DUTS_SYSNAME=\"uClinux\"
+
+head-y := arch/m68k/platform/$(cpuclass-y)/head.o
+
+core-y	+= arch/m68k/kernel/ \
+	   arch/m68k/mm/ \
+	   $(CLASSDIR) \
+	   arch/m68k/platform/$(PLATFORM)/
+libs-y	+= arch/m68k/lib/
+
+archclean:
+
+endif

-- 
Steven King -- sfking at fdwdc dot com


From jamie at shareable.org  Sat Oct 17 23:22:11 2009
From: jamie at shareable.org (Jamie Lokier)
Date: Sun, 18 Oct 2009 04:22:11 +0100
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <200910140621.47564.vapier@gentoo.org>
References: <4AD1C54B.8070705@vmlinux.org> <4AD594F8.1030405@selta.it>
	<200910140621.47564.vapier@gentoo.org>
Message-ID: <20091018032211.GD15656@shareable.org>

Mike Frysinger wrote:
> On Wednesday 14 October 2009 05:08:08 Cappelletti Fabio wrote:
> > Hi all, I'm tying to  write a simple hush script , but I have a lot of
> > problem with two commands : expr and cat!
> > In particula my script is as follow:
> > #!/bin/hush
> > A= `cat /proc/driver/cardtype/BoardAddr`
> > B= `expr $A \* 2`
> > C= `expr $B -1`
> 
> you know you cant go sticking whitespace wherever you like, right ?  shell 
> scripts are not make files -- whitespace around the "=" matters.

That's right.  Remove the space after "=" and the script should work.

Still, it indicates a bug in hush, because A= `cat
/proc/driver/cardtype/BoardAddr` is a valid command, even though it's
not the command you thought.

-- Jamie


From vapier at gentoo.org  Sun Oct 18 00:29:43 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 18 Oct 2009 00:29:43 -0400
Subject: [uClinux-dev] Problem in hush scripts
In-Reply-To: <20091018032211.GD15656@shareable.org>
References: <4AD1C54B.8070705@vmlinux.org>
	<200910140621.47564.vapier@gentoo.org>
	<20091018032211.GD15656@shareable.org>
Message-ID: <200910180029.43990.vapier@gentoo.org>

On Saturday 17 October 2009 23:22:11 Jamie Lokier wrote:
> Mike Frysinger wrote:
> > On Wednesday 14 October 2009 05:08:08 Cappelletti Fabio wrote:
> > > Hi all, I'm tying to  write a simple hush script , but I have a lot of
> > > problem with two commands : expr and cat!
> > > In particula my script is as follow:
> > > #!/bin/hush
> > > A= `cat /proc/driver/cardtype/BoardAddr`
> > > B= `expr $A \* 2`
> > > C= `expr $B -1`
> >
> > you know you cant go sticking whitespace wherever you like, right ? 
> > shell scripts are not make files -- whitespace around the "=" matters.
> 
> That's right.  Remove the space after "=" and the script should work.
> 
> Still, it indicates a bug in hush, because A= `cat
> /proc/driver/cardtype/BoardAddr` is a valid command, even though it's
> not the command you thought.

the OP did not provide any info about what version of busybox he's using, and 
testing latest busybox shows correct behavior with the proposed code.
-mike


From sam at ravnborg.org  Sun Oct 18 03:47:45 2009
From: sam at ravnborg.org (Sam Ravnborg)
Date: Sun, 18 Oct 2009 09:47:45 +0200
Subject: [uClinux-dev] Re: [PATCH] Merge m68k and m68knommu
In-Reply-To: <200910171802.59072.sfking@fdwdc.com>
References: <200910171802.59072.sfking@fdwdc.com>
Message-ID: <20091018074745.GA13755@merkur.ravnborg.org>

On Sat, Oct 17, 2009 at 06:02:58PM -0700, Steven King wrote:
> This is a script and patch to merge the m68knommu arch into m68k.
> 
> The script was inspired by the script Sam Ravnborg used to merge the 
> includes from m68knommu. For those files common to both arches but 
> differing in content, the m68k version of the file is renamed to 
> <file>_mm.<ext> and the m68knommu version of the file is moved into the 
> corresponding m68k directory and renamed <file>_no.<ext> and a small 
> wrapper file <file>.<ext> is used to select between the two version. Files 
> that are common to both but don't differ are removed from the m68knommu 
> tree and files and directories that are unique to the m68knommu tree are 
> moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
> 
> To select between the the versions of the files, the wrapper uses
> 
> #ifdef CONFIG_MMU
> #include <file>_mm.<ext>
> #else
> #include <file>_no.<ext>
> #endif
> 
> The patch modifies the toplevel Makefile so that ARCH=m68knommu still works 
> (by setting SRCARCH=m68k) and adds the m68knommu Kconfig and Makefile 
> to the m68k Kconfig and Makefile, using the definition of ARCH to select 
> which values to use.
> 
> Thus when building for either a m68k or an m68knommu target, one still 
> specifies either ARCH=m68k or ARCH=m68knommu and everything should 
> build EXACTLY as it did pre-merge.  (I think).

Hi Steven.

This looks good!
The mechanical method you are using really makes it simple to do
the merge.
And it also nicely highlights which files that really differs.

There is obviously more that can be merged later
but this is the first and biggest step.

> 
> Signed-off-by: Steven King <sfking at fdwdc.com>
Acked-by: Sam Ravnborg <sam at ravnborg.org>

	Sam


From dhowells at redhat.com  Tue Oct 13 06:10:18 2009
From: dhowells at redhat.com (David Howells)
Date: Tue, 13 Oct 2009 11:10:18 +0100
Subject: [uClinux-dev] Re: [PATCH] NOMMU: fix malloc performance by adding
	uninitialized flag
In-Reply-To: <1255419845-30504-1-git-send-email-vapier@gentoo.org>
References: <1255419845-30504-1-git-send-email-vapier@gentoo.org>
	<12871.1175267477@redhat.com>
Message-ID: <32310.1255428618@redhat.com>


This seems reasonable.  MAP_UNINITIALIZE definitely needs adding to the
general list so that the MMU folks don't steal the bit.  I would also call it
MAP_UNINITIALIZED (well, actually, I'd call it MAP_UNINITIALISED:-), otherwise
it looks like you're asking mmap() to uninitialise the memory for you.
Similarly for CONFIG_MMAP_ALLOW_UNINITIALIZE - I'd add a terminal 'D'.

I've also re-written the documenation somewhat and expanded the patch
description to mention the changes to ELF-FDPIC.

David
---
From: Jie Zhang <jie.zhang at analog.com>
Subject: [PATCH] NOMMU: Fix malloc performance by adding uninitialized flag

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.zhang at analog.com>
Signed-off-by: Robin Getz <rgetz at analog.com>
Signed-off-by: Mike Frysinger <vapier at gentoo.org>
Signed-off-by: David Howells <dhowells at redhat.com>
---

 Documentation/nommu-mmap.txt      |   26 ++++++++++++++++++++++++++
 fs/binfmt_elf_fdpic.c             |    3 ++-
 include/asm-generic/mman-common.h |    5 +++++
 init/Kconfig                      |   22 ++++++++++++++++++++++
 mm/nommu.c                        |    8 +++++---
 5 files changed, 60 insertions(+), 4 deletions(-)


diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt
index b565e82..b216ced 100644
--- a/Documentation/nommu-mmap.txt
+++ b/Documentation/nommu-mmap.txt
@@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP
      granule but will only discard the excess if appropriately configured as
      this has an effect on fragmentation.
 
+ (*) The memory allocated by a request for an anonymous mapping will normally
+     be cleared by the kernel before being returned in accordance with the
+     Linux man pages (ver 2.22 or later)
+
+     In the MMU case this can be achieved with reasonable performance as
+     regions are backed by virtual pages, with the contents only being mapped
+     to cleared physical pages when a write happens on that specific page
+     (prior to which, the pages are effectively mapped to the global zero page
+     from which reads can take place).  This spreads out the time it takes to
+     initialize the contents of a page - depending on the write-usage of the
+     mapping.
+
+     In the no-MMU case, however, anonymous mappings are backed by physical
+     pages, and the entire map is cleared at allocation time.  This can cause
+     significant delays during a userspace malloc() as the C library does an
+     anonymous mapping and the kernel then does a memset for the entire map.
+
+     However, for memory that isn't required to be precleared - such as that
+     returned by malloc() - mmap() can take a MAP_UNINITIALIZE flag to indicate
+     to the kernel that it shouldn't bother clearing the memory before
+     returning it.  Note that CONFIG_MMAP_ALLOW_UNINITIALIZE must be enabled to
+     permit this, otherwise the flag will be ignored.
+
+     uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
+     to allocate the brk and stack region.
+
  (*) A list of all the private copy and anonymous mappings on the system is
      visible through /proc/maps in no-MMU mode.
 
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index e19b9bb..ab7e57b 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -380,7 +380,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
 	down_write(&current->mm->mmap_sem);
 	current->mm->start_brk = do_mmap(NULL, 0, stack_size,
 					 PROT_READ | PROT_WRITE | PROT_EXEC,
-					 MAP_PRIVATE | MAP_ANONYMOUS | MAP_GROWSDOWN,
+					 MAP_PRIVATE | MAP_ANONYMOUS |
+					 MAP_UNINITIALIZE | MAP_GROWSDOWN,
 					 0);
 
 	if (IS_ERR_VALUE(current->mm->start_brk)) {
diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h
index 5ee13b2..dddf626 100644
--- a/include/asm-generic/mman-common.h
+++ b/include/asm-generic/mman-common.h
@@ -19,6 +19,11 @@
 #define MAP_TYPE	0x0f		/* Mask for type of mapping */
 #define MAP_FIXED	0x10		/* Interpret addr exactly */
 #define MAP_ANONYMOUS	0x20		/* don't use a file */
+#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZE
+# define MAP_UNINITIALIZE 0x4000000	/* For anonymous mmap, memory could be uninitialized */
+#else
+# define MAP_UNINITIALIZE 0x0		/* Don't support this flag */
+#endif
 
 #define MS_ASYNC	1		/* sync memory asynchronously */
 #define MS_INVALIDATE	2		/* invalidate the caches */
diff --git a/init/Kconfig b/init/Kconfig
index 09c5c64..9c0ffd1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1069,6 +1069,28 @@ config SLOB
 
 endchoice
 
+config MMAP_ALLOW_UNINITIALIZE
+	bool "Allow mmapped anonymous memory to be un-initialized"
+	depends on EMBEDDED && !MMU
+	default n
+	help
+	   Normally, and according to the Linux spec, anonymous memory obtained
+	   from mmap() has it's contents cleared before it is passed to
+	   userspace.  Enabling this config option allows you to request that
+	   mmap() skip that if it is given an MAP_UNINITIALIZE flag, thus
+	   providing a huge performance boost.  If this option is not enabled,
+	   then the flag will be ignored.
+
+	   This is taken advantage of by uClibc's malloc(), and also by
+	   ELF-FDPIC binfmt's brk and stack allocator.
+
+	   Because of the obvious security issues, this option should only be
+	   enabled on embedded devices where you control what is run in
+	   userspace.  Since that isn't generally a problem on no-MMU systems,
+	   it is normally safe to say Y here.
+
+	   See Documentation/nommu-mmap.txt for more information.
+
 config PROFILING
 	bool "Profiling support (EXPERIMENTAL)"
 	help
diff --git a/mm/nommu.c b/mm/nommu.c
index eefce2d..688f6d0 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1143,9 +1143,6 @@ static int do_mmap_private(struct vm_area_struct *vma,
 		if (ret < rlen)
 			memset(base + ret, 0, rlen - ret);
 
-	} else {
-		/* if it's an anonymous mapping, then just clear it */
-		memset(base, 0, rlen);
 	}
 
 	return 0;
@@ -1343,6 +1340,11 @@ unsigned long do_mmap_pgoff(struct file *file,
 		goto error_just_free;
 	add_nommu_region(region);
 
+	/* clear anonymous mappings that don't ask for uninitialized data */
+	if (!vma->vm_file && !(flags & MAP_UNINITIALIZE))
+		memset((void *)region->vm_start, 0,
+		       region->vm_end - region->vm_start);
+
 	/* okay... we have a mapping; now we have to register it */
 	result = vma->vm_start;
 


From vapier at gentoo.org  Tue Oct 13 07:20:21 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 13 Oct 2009 07:20:21 -0400
Subject: [uClinux-dev] [PATCH v2] NOMMU: fix malloc performance by adding
	uninitialized flag
In-Reply-To: <32310.1255428618@redhat.com>
References: <32310.1255428618@redhat.com>
Message-ID: <1255432821-1104-1-git-send-email-vapier@gentoo.org>

From: Jie Zhang <jie.zhang at 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.zhang at analog.com>
Signed-off-by: Robin Getz <rgetz at analog.com>
Signed-off-by: Mike Frysinger <vapier at gentoo.org>
Signed-off-by: David Howells <dhowells at redhat.com>
---
v2
	- add a 'D' suffix in define names

David: i think i slurped all your changes into this and changed all the
	occurrences to have a D suffix ...

 Documentation/nommu-mmap.txt      |   26 ++++++++++++++++++++++++++
 fs/binfmt_elf_fdpic.c             |    3 ++-
 include/asm-generic/mman-common.h |    5 +++++
 init/Kconfig                      |   22 ++++++++++++++++++++++
 mm/nommu.c                        |    8 +++++---
 5 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt
index b565e82..8e1ddec 100644
--- a/Documentation/nommu-mmap.txt
+++ b/Documentation/nommu-mmap.txt
@@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP
      granule but will only discard the excess if appropriately configured as
      this has an effect on fragmentation.
 
+ (*) The memory allocated by a request for an anonymous mapping will normally
+     be cleared by the kernel before being returned in accordance with the
+     Linux man pages (ver 2.22 or later).
+
+     In the MMU case this can be achieved with reasonable performance as
+     regions are backed by virtual pages, with the contents only being mapped
+     to cleared physical pages when a write happens on that specific page
+     (prior to which, the pages are effectively mapped to the global zero page
+     from which reads can take place).  This spreads out the time it takes to
+     initialize the contents of a page - depending on the write-usage of the
+     mapping.
+
+     In the no-MMU case, however, anonymous mappings are backed by physical
+     pages, and the entire map is cleared at allocation time.  This can cause
+     significant delays during a userspace malloc() as the C library does an
+     anonymous mapping and the kernel then does a memset for the entire map.
+
+     However, for memory that isn't required to be precleared - such as that
+     returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
+     indicate to the kernel that it shouldn't bother clearing the memory before
+     returning it.  Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled
+     to permit this, otherwise the flag will be ignored.
+
+     uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
+     to allocate the brk and stack region.
+
  (*) A list of all the private copy and anonymous mappings on the system is
      visible through /proc/maps in no-MMU mode.
 
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 38502c6..79d2b1a 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -380,7 +380,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
 	down_write(&current->mm->mmap_sem);
 	current->mm->start_brk = do_mmap(NULL, 0, stack_size,
 					 PROT_READ | PROT_WRITE | PROT_EXEC,
-					 MAP_PRIVATE | MAP_ANONYMOUS | MAP_GROWSDOWN,
+					 MAP_PRIVATE | MAP_ANONYMOUS |
+					 MAP_UNINITIALIZED | MAP_GROWSDOWN,
 					 0);
 
 	if (IS_ERR_VALUE(current->mm->start_brk)) {
diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h
index 5ee13b2..2011126 100644
--- a/include/asm-generic/mman-common.h
+++ b/include/asm-generic/mman-common.h
@@ -19,6 +19,11 @@
 #define MAP_TYPE	0x0f		/* Mask for type of mapping */
 #define MAP_FIXED	0x10		/* Interpret addr exactly */
 #define MAP_ANONYMOUS	0x20		/* don't use a file */
+#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
+# define MAP_UNINITIALIZED 0x4000000	/* For anonymous mmap, memory could be uninitialized */
+#else
+# define MAP_UNINITIALIZED 0x0		/* Don't support this flag */
+#endif
 
 #define MS_ASYNC	1		/* sync memory asynchronously */
 #define MS_INVALIDATE	2		/* invalidate the caches */
diff --git a/init/Kconfig b/init/Kconfig
index 09c5c64..817aeca 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1069,6 +1069,28 @@ config SLOB
 
 endchoice
 
+config MMAP_ALLOW_UNINITIALIZED
+	bool "Allow mmaped anonymous memory to be un-initialized"
+	depends on EMBEDDED && !MMU
+	default n
+	help
+	  Normally, and according to the Linux spec, anonymous memory obtained
+	  from mmap() has it's contents cleared before it is passed to
+	  userspace.  Enabling this config option allows you to request that
+	  mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
+	  providing a huge performance boost.  If this option is not enabled,
+	  then the flag will be ignored.
+
+	  This is taken advantage of by uClibc's malloc(), and also by
+	  ELF-FDPIC binfmt's brk and stack allocator.
+
+	  Because of the obvious security issues, this option should only be
+	  enabled on embedded devices where you control what is run in
+	  userspace.  Since that isn't generally a problem on no-MMU systems,
+	  it is normally safe to say Y here.
+
+	  See Documentation/nommu-mmap.txt for more information.
+
 config PROFILING
 	bool "Profiling support (EXPERIMENTAL)"
 	help
diff --git a/mm/nommu.c b/mm/nommu.c
index 5189b5a..11e8231 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1143,9 +1143,6 @@ static int do_mmap_private(struct vm_area_struct *vma,
 		if (ret < rlen)
 			memset(base + ret, 0, rlen - ret);
 
-	} else {
-		/* if it's an anonymous mapping, then just clear it */
-		memset(base, 0, rlen);
 	}
 
 	return 0;
@@ -1343,6 +1340,11 @@ unsigned long do_mmap_pgoff(struct file *file,
 		goto error_just_free;
 	add_nommu_region(region);
 
+	/* clear anonymous mappings that don't ask for uninitialized data */
+	if (!vma->vm_file && !(flags & MAP_UNINITIALIZED))
+		memset((void *)region->vm_start, 0,
+		       region->vm_end - region->vm_start);
+
 	/* okay... we have a mapping; now we have to register it */
 	result = vma->vm_start;
 
-- 
1.6.5



From dhowells at redhat.com  Tue Oct 13 12:03:42 2009
From: dhowells at redhat.com (David Howells)
Date: Tue, 13 Oct 2009 17:03:42 +0100
Subject: [uClinux-dev] Re: [PATCH v2] NOMMU: fix malloc performance by
	adding uninitialized flag
In-Reply-To: <1255432821-1104-1-git-send-email-vapier@gentoo.org>
References: <1255432821-1104-1-git-send-email-vapier@gentoo.org>
	<32310.1255428618@redhat.com>
Message-ID: <3372.1255449822@redhat.com>

Mike Frysinger <vapier at gentoo.org> wrote:

> +	bool "Allow mmaped anonymous memory to be un-initialized"

Can you change that to be 'mmapped' and 'uninitialized'?

Other than that, it looks good.

David


From vapier at gentoo.org  Tue Oct 13 17:31:07 2009
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 13 Oct 2009 17:31:07 -0400
Subject: [uClinux-dev] [PATCH v3] NOMMU: fix malloc performance by adding
	uninitialized flag
In-Reply-To: <3372.1255449822@redhat.com>
References: <3372.1255449822@redhat.com>
Message-ID: <1255469467-17065-1-git-send-email-vapier@gentoo.org>

From: Jie Zhang <jie.zhang at 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.zhang at analog.com>
Signed-off-by: Robin Getz <robin.getz at analog.com>
Signed-off-by: Mike Frysinger <vapier at gentoo.org>
Signed-off-by: David Howells <dhowells at redhat.com>
Acked-by: Paul Mundt <lethal at linux-sh.org>
---
v3
	- tweak kconfig desc

 Documentation/nommu-mmap.txt      |   26 ++++++++++++++++++++++++++
 fs/binfmt_elf_fdpic.c             |    3 ++-
 include/asm-generic/mman-common.h |    5 +++++
 init/Kconfig                      |   22 ++++++++++++++++++++++
 mm/nommu.c                        |    8 +++++---
 5 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt
index b565e82..8e1ddec 100644
--- a/Documentation/nommu-mmap.txt
+++ b/Documentation/nommu-mmap.txt
@@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP
      granule but will only discard the excess if appropriately configured as
      this has an effect on fragmentation.
 
+ (*) The memory allocated by a request for an anonymous mapping will normally
+     be cleared by the kernel before being returned in accordance with the
+     Linux man pages (ver 2.22 or later).
+
+     In the MMU case this can be achieved with reasonable performance as
+     regions are backed by virtual pages, with the contents only being mapped
+     to cleared physical pages when a write happens on that specific page
+     (prior to which, the pages are effectively mapped to the global zero page
+     from which reads can take place).  This spreads out the time it takes to
+     initialize the contents of a page - depending on the write-usage of the
+     mapping.
+
+     In the no-MMU case, however, anonymous mappings are backed by physical
+     pages, and the entire map is cleared at allocation time.  This can cause
+     significant delays during a userspace malloc() as the C library does an
+     anonymous mapping and the kernel then does a memset for the entire map.
+
+     However, for memory that isn't required to be precleared - such as that
+     returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
+     indicate to the kernel that it shouldn't bother clearing the memory before
+     returning it.  Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled
+     to permit this, otherwise the flag will be ignored.
+
+     uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
+     to allocate the brk and stack region.
+
  (*) A list of all the private copy and anonymous mappings on the system is
      visible through /proc/maps in no-MMU mode.
 
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 38502c6..79d2b1a 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -380,7 +380,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
 	down_write(&current->mm->mmap_sem);
 	current->mm->start_brk = do_mmap(NULL, 0, stack_size,
 					 PROT_READ | PROT_WRITE | PROT_EXEC,
-					 MAP_PRIVATE | MAP_ANONYMOUS | MAP_GROWSDOWN,
+					 MAP_PRIVATE | MAP_ANONYMOUS |
+					 MAP_UNINITIALIZED | MAP_GROWSDOWN,
 					 0);
 
 	if (IS_ERR_VALUE(current->mm->start_brk)) {
diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h
index 5ee13b2..2011126 100644
--- a/include/asm-generic/mman-common.h
+++ b/include/asm-generic/mman-common.h
@@ -19,6 +19,11 @@
 #define MAP_TYPE	0x0f		/* Mask for type of mapping */
 #define MAP_FIXED	0x10		/* Interpret addr exactly */
 #define MAP_ANONYMOUS	0x20		/* don't use a file */
+#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
+# define MAP_UNINITIALIZED 0x4000000	/* For anonymous mmap, memory could be uninitialized */
+#else
+# define MAP_UNINITIALIZED 0x0		/* Don't support this flag */
+#endif
 
 #define MS_ASYNC	1		/* sync memory asynchronously */
 #define MS_INVALIDATE	2		/* invalidate the caches */
diff --git a/init/Kconfig b/init/Kconfig
index 09c5c64..309cd9a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1069,6 +1069,28 @@ config SLOB
 
 endchoice
 
+config MMAP_ALLOW_UNINITIALIZED
+	bool "Allow mmapped anonymous memory to be uninitialized"
+	depends on EMBEDDED && !MMU
+	default n
+	help
+	  Normally, and according to the Linux spec, anonymous memory obtained
+	  from mmap() has it's contents cleared before it is passed to
+	  userspace.  Enabling this config option allows you to request that
+	  mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
+	  providing a huge performance boost.  If this option is not enabled,
+	  then the flag will be ignored.
+
+	  This is taken advantage of by uClibc's malloc(), and also by
+	  ELF-FDPIC binfmt's brk and stack allocator.
+
+	  Because of the obvious security issues, this option should only be
+	  enabled on embedded devices where you control what is run in
+	  userspace.  Since that isn't generally a problem on no-MMU systems,
+	  it is normally safe to say Y here.
+
+	  See Documentation/nommu-mmap.txt for more information.
+
 config PROFILING
 	bool "Profiling support (EXPERIMENTAL)"
 	help
diff --git a/mm/nommu.c b/mm/nommu.c
index 5189b5a..11e8231 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1143,9 +1143,6 @@ static int do_mmap_private(struct vm_area_struct *vma,
 		if (ret < rlen)
 			memset(base + ret, 0, rlen - ret);
 
-	} else {
-		/* if it's an anonymous mapping, then just clear it */
-		memset(base, 0, rlen);
 	}
 
 	return 0;
@@ -1343,6 +1340,11 @@ unsigned long do_mmap_pgoff(struct file *file,
 		goto error_just_free;
 	add_nommu_region(region);
 
+	/* clear anonymous mappings that don't ask for uninitialized data */
+	if (!vma->vm_file && !(flags & MAP_UNINITIALIZED))
+		memset((void *)region->vm_start, 0,
+		       region->vm_end - region->vm_start);
+
 	/* okay... we have a mapping; now we have to register it */
 	result = vma->vm_start;
 
-- 
1.6.5



From gerg at snapgear.com  Tue Oct 13 20:25:59 2009
From: gerg at snapgear.com (Greg Ungerer)
Date: Wed, 14 Oct 2009 10:25:59 +1000
Subject: [uClinux-dev] Re: [PATCH v3] NOMMU: fix malloc performance by
 adding uninitialized flag
In-Reply-To: <1255469467-17065-1-git-send-email-vapier@gentoo.org>
References: <3372.1255449822@redhat.com>
	<1255469467-17065-1-git-send-email-vapier@gentoo.org>
Message-ID: <4AD51A97.6060204@snapgear.com>


Mike Frysinger wrote:
> From: Jie Zhang <jie.zhang at 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.zhang at analog.com>
> Signed-off-by: Robin Getz <robin.getz at analog.com>
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> Signed-off-by: David Howells <dhowells at redhat.com>
> Acked-by: Paul Mundt <lethal at linux-sh.org>

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


> ---
> v3
> 	- tweak kconfig desc
> 
>  Documentation/nommu-mmap.txt      |   26 ++++++++++++++++++++++++++
>  fs/binfmt_elf_fdpic.c             |    3 ++-
>  include/asm-generic/mman-common.h |    5 +++++
>  init/Kconfig                      |   22 ++++++++++++++++++++++
>  mm/nommu.c                        |    8 +++++---
>  5 files changed, 60 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt
> index b565e82..8e1ddec 100644
> --- a/Documentation/nommu-mmap.txt
> +++ b/Documentation/nommu-mmap.txt
> @@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP
>       granule but will only discard the excess if appropriately configured as
>       this has an effect on fragmentation.
>  
> + (*) The memory allocated by a request for an anonymous mapping will normally
> +     be cleared by the kernel before being returned in accordance with the
> +     Linux man pages (ver 2.22 or later).
> +
> +     In the MMU case this can be achieved with reasonable performance as
> +     regions are backed by virtual pages, with the contents only being mapped
> +     to cleared physical pages when a write happens on that specific page
> +     (prior to which, the pages are effectively mapped to the global zero page
> +     from which reads can take place).  This spreads out the time it takes to
> +     initialize the contents of a page - depending on the write-usage of the
> +     mapping.
> +
> +     In the no-MMU case, however, anonymous mappings are backed by physical
> +     pages, and the entire map is cleared at allocation time.  This can cause
> +     significant delays during a userspace malloc() as the C library does an
> +     anonymous mapping and the kernel then does a memset for the entire map.
> +
> +     However, for memory that isn't required to be precleared - such as that
> +     returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
> +     indicate to the kernel that it shouldn't bother clearing the memory before
> +     returning it.  Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled
> +     to permit this, otherwise the flag will be ignored.
> +
> +     uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
> +     to allocate the brk and stack region.
> +
>   (*) A list of all the private copy and anonymous mappings on the system is
>       visible through /proc/maps in no-MMU mode.
>  
> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
> index 38502c6..79d2b1a 100644
> --- a/fs/binfmt_elf_fdpic.c
> +++ b/fs/binfmt_elf_fdpic.c
> @@ -380,7 +380,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm,
>  	down_write(&current->mm->mmap_sem);
>  	current->mm->start_brk = do_mmap(NULL, 0, stack_size,
>  					 PROT_READ | PROT_WRITE | PROT_EXEC,
> -					 MAP_PRIVATE | MAP_ANONYMOUS | MAP_GROWSDOWN,
> +					 MAP_PRIVATE | MAP_ANONYMOUS |
> +					 MAP_UNINITIALIZED | MAP_GROWSDOWN,
>  					 0);
>  
>  	if (IS_ERR_VALUE(current->mm->start_brk)) {
> diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h
> index 5ee13b2..2011126 100644
> --- a/include/asm-generic/mman-common.h
> +++ b/include/asm-generic/mman-common.h
> @@ -19,6 +19,11 @@
>  #define MAP_TYPE	0x0f		/* Mask for type of mapping */
>  #define MAP_FIXED	0x10		/* Interpret addr exactly */
>  #define MAP_ANONYMOUS	0x20		/* don't use a file */
> +#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
> +# define MAP_UNINITIALIZED 0x4000000	/* For anonymous mmap, memory could be uninitialized */
> +#else
> +# define MAP_UNINITIALIZED 0x0		/* Don't support this flag */
> +#endif
>  
>  #define MS_ASYNC	1		/* sync memory asynchronously */
>  #define MS_INVALIDATE	2		/* invalidate the caches */
> diff --git a/init/Kconfig b/init/Kconfig
> index 09c5c64..309cd9a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1069,6 +1069,28 @@ config SLOB
>  
>  endchoice
>  
> +config MMAP_ALLOW_UNINITIALIZED
> +	bool "Allow mmapped anonymous memory to be uninitialized"
> +	depends on EMBEDDED && !MMU
> +	default n
> +	help
> +	  Normally, and according to the Linux spec, anonymous memory obtained
> +	  from mmap() has it's contents cleared before it is passed to
> +	  userspace.  Enabling this config option allows you to request that
> +	  mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
> +	  providing a huge performance boost.  If this option is not enabled,
> +	  then the flag will be ignored.
> +
> +	  This is taken advantage of by uClibc's malloc(), and also by
> +	  ELF-FDPIC binfmt's brk and stack allocator.
> +
> +	  Because of the obvious security issues, this option should only be
> +	  enabled on embedded devices where you control what is run in
> +	  userspace.  Since that isn't generally a problem on no-MMU systems,
> +	  it is normally safe to say Y here.
> +
> +	  See Documentation/nommu-mmap.txt for more information.
> +
>  config PROFILING
>  	bool "Profiling support (EXPERIMENTAL)"
>  	help
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 5189b5a..11e8231 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -1143,9 +1143,6 @@ static int do_mmap_private(struct vm_area_struct *vma,
>  		if (ret < rlen)
>  			memset(base + ret, 0, rlen - ret);
>  
> -	} else {
> -		/* if it's an anonymous mapping, then just clear it */
> -		memset(base, 0, rlen);
>  	}
>  
>  	return 0;
> @@ -1343,6 +1340,11 @@ unsigned long do_mmap_pgoff(struct file *file,
>  		goto error_just_free;
>  	add_nommu_region(region);
>  
> +	/* clear anonymous mappings that don't ask for uninitialized data */
> +	if (!vma->vm_file && !(flags & MAP_UNINITIALIZED))
> +		memset((void *)region->vm_start, 0,
> +		       region->vm_end - region->vm_start);
> +
>  	/* okay... we have a mapping; now we have to register it */
>  	result = vma->vm_start;
>  

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg at 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


From f.cappelletti at selta.it  Wed Oct 14 05:02:31 2009
From: f.cappelletti at selta.it (Cappelletti Fabio)
Date: Wed, 14 Oct 2009 11:02:31 +0200
Subject: [uClinux-dev] Prolem with hush scripts
In-Reply-To: <20091013230429.GA32164@securecomputing.com>
References: <3372.1255449822@redhat.com>	<1255469467-17065-1-git-send-email-vapier@gentoo.org>
	<20091013230429.GA32164@securecomputing.com>
Message-ID: <4AD593A7.5060408@selta.it>

Hi all, I'm trying to write a hush script with expr command and cat 
command but it doesn't work.
I posted my script:
#!/bin/hush
A= `cat /proc/driver/typeboard/BoardAddr`
C= expr $A \* 2
D= expr $B -1

this is the optput

hush: cannot exec '`cat': No such file or directory
expr: syntax error
expr: syntax error


Thanks!
Fabio



From ndprasad at gmail.com  Mon Oct 19 13:52:36 2009
From: ndprasad at gmail.com (Prasad)
Date: Mon, 19 Oct 2009 10:52:36 -0700
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <001e01ca4f7d$cf081480$6d183d80$@net>
References: <4AD1C54B.8070705@vmlinux.org>
	<200910140804.53751.vapier@gentoo.org>
	<84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>
	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>
	<84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>
	<005401ca4dc3$552044a0$ff60cde0$@net>
	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>
	<EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>
	<3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>
	<001e01ca4f7d$cf081480$6d183d80$@net>
Message-ID: <3351bfbe0910191052te733d63n18caddee6621e85f@mail.gmail.com>

I mean to ask, is there any advantage in using NOR-ECC flash agains
regular NOR flash. Does the linux mtd driver/jffs2 differentiate it?

On Sat, Oct 17, 2009 at 4:01 PM, Keith Mund (AZ) <keithmund at cox.net> wrote:
> On Friday, October 16, 2009 5:04 PM, Prasad wrote:
>>Got it. Is there any difference in the linux implementation if you use
>>NOR-ECC flash against NOR flash along with jffs2.
>
> I read the question in more than one way.
>
> Keith Mund
>
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>


From keithmund at cox.net  Mon Oct 19 15:49:05 2009
From: keithmund at cox.net (Keith Mund (AZ))
Date: Mon, 19 Oct 2009 12:49:05 -0700
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <3351bfbe0910191052te733d63n18caddee6621e85f@mail.gmail.com>
References: <4AD1C54B.8070705@vmlinux.org>	<200910140804.53751.vapier@gentoo.org>	<84974D4AE49DC04D97A1594F46EA0701010B702F@VGRFMAIL1.vitecnet.local>	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>	<84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>	<005401ca4dc3$552044a0$ff60cde0$@net>	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>	<EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>	<3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>	<001e01ca4f7d$cf081480$6d183d80$@net>
	<3351bfbe0910191052te733d63n18caddee6621e85f@mail.gmail.com>
Message-ID: <000301ca50f5$3731f170$a595d450$@net>

>from Prasad - Monday, October 19, 2009 10:53 AM:
>I mean to ask, is there any advantage in using NOR-ECC flash agains
>regular NOR flash. Does the linux mtd driver/jffs2 differentiate it?

The "advantage" part depends on the needs of each system. Some benefits of
ECC are that it helps overcome problems with occasional false flash reads,
and buffered writing can be faster. Direct write through with NOR
dramatically reduces the chances of corruption due to an interrupted write.

Linux does determine if you have NOR-ECC and enables buffering. Buffering is
a must because you can call the file write function numerous times, even to
write one byte at a time. NOR-ECC only allows one write per page before an
erase so the writes are buffered before they are committed.

Keith Mund




From ndprasad at gmail.com  Mon Oct 19 19:43:24 2009
From: ndprasad at gmail.com (Prasad)
Date: Mon, 19 Oct 2009 16:43:24 -0700
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <000301ca50f5$3731f170$a595d450$@net>
References: <4AD1C54B.8070705@vmlinux.org>
	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>
	<84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>
	<005401ca4dc3$552044a0$ff60cde0$@net>
	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>
	<EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>
	<3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>
	<001e01ca4f7d$cf081480$6d183d80$@net>
	<3351bfbe0910191052te733d63n18caddee6621e85f@mail.gmail.com>
	<000301ca50f5$3731f170$a595d450$@net>
Message-ID: <3351bfbe0910191643xc330277h4a64538f4e234108@mail.gmail.com>

Interesting..till now i was thinking there is still some kind of
buffering mechanism in case of NOR flash. So if there is a process
that opens a file writes one byte at a time (write() or fwrite() on
jffs2 partitioned file system), this will kind of wear out the flash
pretty right?. May be a stupid question, can we force the buffering
even for NOR flash for increasing the longevity of the flash ?

- Prasad

On Mon, Oct 19, 2009 at 12:49 PM, Keith Mund (AZ) <keithmund at cox.net> wrote:
>>from Prasad - Monday, October 19, 2009 10:53 AM:
>>I mean to ask, is there any advantage in using NOR-ECC flash agains
>>regular NOR flash. Does the linux mtd driver/jffs2 differentiate it?
>
> The "advantage" part depends on the needs of each system. Some benefits of
> ECC are that it helps overcome problems with occasional false flash reads,
> and buffered writing can be faster. Direct write through with NOR
> dramatically reduces the chances of corruption due to an interrupted write.
>
> Linux does determine if you have NOR-ECC and enables buffering. Buffering is
> a must because you can call the file write function numerous times, even to
> write one byte at a time. NOR-ECC only allows one write per page before an
> erase so the writes are buffered before they are committed.
>
> Keith Mund
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>


From eauth at softsys.co.at  Mon Oct 19 20:04:02 2009
From: eauth at softsys.co.at (Erwin Authried)
Date: Tue, 20 Oct 2009 02:04:02 +0200
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <3351bfbe0910191643xc330277h4a64538f4e234108@mail.gmail.com>
References: <4AD1C54B.8070705@vmlinux.org>
	<11497C2E-594E-4D98-9A58-425A85AAACDB@argonst.com>
	<84974D4AE49DC04D97A1594F46EA0701011184DB@VGRFMAIL1.vitecnet.local>
	<005401ca4dc3$552044a0$ff60cde0$@net>
	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>
	<EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>
	<3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>
	<001e01ca4f7d$cf081480$6d183d80$@net>
	<3351bfbe0910191052te733d63n18caddee6621e85f@mail.gmail.com>
	<000301ca50f5$3731f170$a595d450$@net>
	<3351bfbe0910191643xc330277h4a64538f4e234108@mail.gmail.com>
Message-ID: <1255997042.3696.3.camel@eeepc>

for NOR flash, the number of erase cycles on each sector is limited, not
the number of writes. For the flash lifetime, it doesn't make a
difference if you write one byte at a time or a complete sector at once.

-Erwin

Am Montag, den 19.10.2009, 16:43 -0700 schrieb Prasad:
> Interesting..till now i was thinking there is still some kind of
> buffering mechanism in case of NOR flash. So if there is a process
> that opens a file writes one byte at a time (write() or fwrite() on
> jffs2 partitioned file system), this will kind of wear out the flash
> pretty right?. May be a stupid question, can we force the buffering
> even for NOR flash for increasing the longevity of the flash ?
> 
> - Prasad
> 
> On Mon, Oct 19, 2009 at 12:49 PM, Keith Mund (AZ) <keithmund at cox.net> wrote:
> >>from Prasad - Monday, October 19, 2009 10:53 AM:
> >>I mean to ask, is there any advantage in using NOR-ECC flash agains
> >>regular NOR flash. Does the linux mtd driver/jffs2 differentiate it?
> >
> > The "advantage" part depends on the needs of each system. Some benefits of
> > ECC are that it helps overcome problems with occasional false flash reads,
> > and buffered writing can be faster. Direct write through with NOR
> > dramatically reduces the chances of corruption due to an interrupted write.
> >
> > Linux does determine if you have NOR-ECC and enables buffering. Buffering is
> > a must because you can call the file write function numerous times, even to
> > write one byte at a time. NOR-ECC only allows one write per page before an
> > erase so the writes are buffered before they are committed.
> >
> > Keith Mund
> >
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> > To unsubscribe see:
> > http://mailman.uclinux.org/mailman/options/uclinux-dev
> >
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev



From ndprasad at gmail.com  Mon Oct 19 20:28:42 2009
From: ndprasad at gmail.com (Prasad)
Date: Mon, 19 Oct 2009 17:28:42 -0700
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <1255997042.3696.3.camel@eeepc>
References: <4AD1C54B.8070705@vmlinux.org>
	<005401ca4dc3$552044a0$ff60cde0$@net>
	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>
	<EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>
	<3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>
	<001e01ca4f7d$cf081480$6d183d80$@net>
	<3351bfbe0910191052te733d63n18caddee6621e85f@mail.gmail.com>
	<000301ca50f5$3731f170$a595d450$@net>
	<3351bfbe0910191643xc330277h4a64538f4e234108@mail.gmail.com>
	<1255997042.3696.3.camel@eeepc>
Message-ID: <3351bfbe0910191728h7443d695t1fbee2a5ec7e673c@mail.gmail.com>

For the NOR flash, when the write( , , 1) routine is called, the file
system(jffs2 in this case) has to read back the whole sector, modify
that byte, erase the sector and then write back the whole sector (in
order to write a single byte). Is it not so..So it does affect the
flash-lifetime right?

- Prasad

On Mon, Oct 19, 2009 at 5:04 PM, Erwin Authried <eauth at softsys.co.at> wrote:
> for NOR flash, the number of erase cycles on each sector is limited, not
> the number of writes. For the flash lifetime, it doesn't make a
> difference if you write one byte at a time or a complete sector at once.
>
> -Erwin
>
> Am Montag, den 19.10.2009, 16:43 -0700 schrieb Prasad:
>> Interesting..till now i was thinking there is still some kind of
>> buffering mechanism in case of NOR flash. So if there is a process
>> that opens a file writes one byte at a time (write() or fwrite() on
>> jffs2 partitioned file system), this will kind of wear out the flash
>> pretty right?. May be a stupid question, can we force the buffering
>> even for NOR flash for increasing the longevity of the flash ?
>>
>> - Prasad
>>
>> On Mon, Oct 19, 2009 at 12:49 PM, Keith Mund (AZ) <keithmund at cox.net> wrote:
>> >>from Prasad - Monday, October 19, 2009 10:53 AM:
>> >>I mean to ask, is there any advantage in using NOR-ECC flash agains
>> >>regular NOR flash. Does the linux mtd driver/jffs2 differentiate it?
>> >
>> > The "advantage" part depends on the needs of each system. Some benefits of
>> > ECC are that it helps overcome problems with occasional false flash reads,
>> > and buffered writing can be faster. Direct write through with NOR
>> > dramatically reduces the chances of corruption due to an interrupted write.
>> >
>> > Linux does determine if you have NOR-ECC and enables buffering. Buffering is
>> > a must because you can call the file write function numerous times, even to
>> > write one byte at a time. NOR-ECC only allows one write per page before an
>> > erase so the writes are buffered before they are committed.
>> >
>> > Keith Mund
>> >
>> >
>> > _______________________________________________
>> > uClinux-dev mailing list
>> > uClinux-dev at uclinux.org
>> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> > This message was resent by uclinux-dev at uclinux.org
>> > To unsubscribe see:
>> > http://mailman.uclinux.org/mailman/options/uclinux-dev
>> >
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev at uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev at uclinux.org
>> To unsubscribe see:
>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>


From eauth at softsys.co.at  Mon Oct 19 20:46:41 2009
From: eauth at softsys.co.at (Erwin Authried)
Date: Tue, 20 Oct 2009 02:46:41 +0200
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <3351bfbe0910191728h7443d695t1fbee2a5ec7e673c@mail.gmail.com>
References: <4AD1C54B.8070705@vmlinux.org>
	<005401ca4dc3$552044a0$ff60cde0$@net>
	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>
	<EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>
	<3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>
	<001e01ca4f7d$cf081480$6d183d80$@net>
	<3351bfbe0910191052te733d63n18caddee6621e85f@mail.gmail.com>
	<000301ca50f5$3731f170$a595d450$@net>
	<3351bfbe0910191643xc330277h4a64538f4e234108@mail.gmail.com>
	<1255997042.3696.3.camel@eeepc>
	<3351bfbe0910191728h7443d695t1fbee2a5ec7e673c@mail.gmail.com>
Message-ID: <1255999601.3696.10.camel@eeepc>

I don't know about the jffs2 internals in detail, but I'm pretty sure
that it doesn't work in the way you described. That would be the worst
approach for a flash filesystem that one can think of.

-Erwin

Am Montag, den 19.10.2009, 17:28 -0700 schrieb Prasad:
> For the NOR flash, when the write( , , 1) routine is called, the file
> system(jffs2 in this case) has to read back the whole sector, modify
> that byte, erase the sector and then write back the whole sector (in
> order to write a single byte). Is it not so..So it does affect the
> flash-lifetime right?
> 
> - Prasad
> 
> On Mon, Oct 19, 2009 at 5:04 PM, Erwin Authried <eauth at softsys.co.at> wrote:
> > for NOR flash, the number of erase cycles on each sector is limited, not
> > the number of writes. For the flash lifetime, it doesn't make a
> > difference if you write one byte at a time or a complete sector at once.
> >
> > -Erwin
> >
> > Am Montag, den 19.10.2009, 16:43 -0700 schrieb Prasad:
> >> Interesting..till now i was thinking there is still some kind of
> >> buffering mechanism in case of NOR flash. So if there is a process
> >> that opens a file writes one byte at a time (write() or fwrite() on
> >> jffs2 partitioned file system), this will kind of wear out the flash
> >> pretty right?. May be a stupid question, can we force the buffering
> >> even for NOR flash for increasing the longevity of the flash ?
> >>
> >> - Prasad
> >>
> >> On Mon, Oct 19, 2009 at 12:49 PM, Keith Mund (AZ) <keithmund at cox.net> wrote:
> >> >>from Prasad - Monday, October 19, 2009 10:53 AM:
> >> >>I mean to ask, is there any advantage in using NOR-ECC flash agains
> >> >>regular NOR flash. Does the linux mtd driver/jffs2 differentiate it?
> >> >
> >> > The "advantage" part depends on the needs of each system. Some benefits of
> >> > ECC are that it helps overcome problems with occasional false flash reads,
> >> > and buffered writing can be faster. Direct write through with NOR
> >> > dramatically reduces the chances of corruption due to an interrupted write.
> >> >
> >> > Linux does determine if you have NOR-ECC and enables buffering. Buffering is
> >> > a must because you can call the file write function numerous times, even to
> >> > write one byte at a time. NOR-ECC only allows one write per page before an
> >> > erase so the writes are buffered before they are committed.
> >> >
> >> > Keith Mund
> >> >
> >> >
> >> > _______________________________________________
> >> > uClinux-dev mailing list
> >> > uClinux-dev at uclinux.org
> >> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >> > This message was resent by uclinux-dev at uclinux.org
> >> > To unsubscribe see:
> >> > http://mailman.uclinux.org/mailman/options/uclinux-dev
> >> >
> >> _______________________________________________
> >> uClinux-dev mailing list
> >> uClinux-dev at uclinux.org
> >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> >> This message was resent by uclinux-dev at uclinux.org
> >> To unsubscribe see:
> >> http://mailman.uclinux.org/mailman/options/uclinux-dev
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> > To unsubscribe see:
> > http://mailman.uclinux.org/mailman/options/uclinux-dev
> >
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev



From allon.stern at argonst.com  Mon Oct 19 21:44:27 2009
From: allon.stern at argonst.com (Allon Stern)
Date: Mon, 19 Oct 2009 21:44:27 -0400
Subject: [uClinux-dev] JFFS2 file corrupt at power down.
In-Reply-To: <3351bfbe0910191728h7443d695t1fbee2a5ec7e673c@mail.gmail.com>
References: <4AD1C54B.8070705@vmlinux.org>
	<005401ca4dc3$552044a0$ff60cde0$@net>
	<3351bfbe0910151647i42594d92yc46349769e2ce8de@mail.gmail.com>
	<EFC13AC2-E73A-4B42-9B44-235BA160E41A@argonst.com>
	<3351bfbe0910161703o37330794m23711b6de1818f4a@mail.gmail.com>
	<001e01ca4f7d$cf081480$6d183d80$@net>
	<3351bfbe0910191052te733d63n18caddee6621e85f@mail.gmail.com>
	<000301ca50f5$3731f170$a595d450$@net>
	<3351bfbe0910191643xc330277h4a64538f4e234108@mail.gmail.com>
	<1255997042.3696.3.camel@eeepc>
	<3351bfbe0910191728h7443d695t1fbee2a5ec7e673c@mail.gmail.com>
Message-ID: <40C31B17-ED63-4E44-8E34-11388A1B8D3F@argonst.com>


On Oct 19, 2009, at 8:28 PM, Prasad wrote:

> For the NOR flash, when the write( , , 1) routine is called, the file
> system(jffs2 in this case) has to read back the whole sector, modify
> that byte, erase the sector and then write back the whole sector (in
> order to write a single byte). Is it not so..So it does affect the
> flash-lifetime right?

While you have to erase a whole block of NOR flash at a time, you  
don't have to write a whole block.
In fact, you can program a single bit. As long as you're writing a 0.

That is, when you erase a block, you set every bit to a 1. When you  
program a flash, you clear the bits you want cleared. So you can write  
at the same byte address multiple times, as long as none of those  
writes set a 0 to a 1. If you want to set even a single bit from a 0  
to a 1, you have to erase the whole block.

Flash filesystems don't change the data in place to match some ideal -  
that would be silly. Instead, they invalidate the old data, and write  
a new copy. When they start running short of clean space, the file  
system consolidates the valid data, and garbage collects the  
invalidated data into clean space. This shuffling is why these file  
systems need some amount of headroom to reliably shuffle this data  
around. They have to plan for the operation to be interrupted at ANY  
time, and still maintain a recoverable state.

-
allon


From wellknown at gmx.net  Tue Oct 20 08:06:41 2009
From: wellknown at gmx.net (Tom Mayer)
Date: Tue, 20 Oct 2009 14:06:41 +0200
Subject: [uClinux-dev] Luminary lm3s9b92
Message-ID: <4ADDA7D1.5090308@gmx.net>


Hi everybody,

I am new to uClinux and have a few questions.

I plan to use the lm3s9b92 chip from luminary (already got 2 samples :)) 
with uClinux. I plan to design hardware with 16mb sdram and 4mb flash. 
 from my research that should be plenty of space for uClinux.

This is a cortex-m3 controller. I discovered some patches so it seems 
that it would be supported.


My fear is NIC/LAN driver. This chip is really perfect - including MAC 
and PHY on chip. Is there anyone who already made some steps in using 
this controller with uClinux?

Would be nice if  someone experienced could point out if this chip is 
usable with the uClinux project. Maybe there are circumstances that make 
the chip unusable?


Best Regards and many thanks,

Tom



From lsorense at csclub.uwaterloo.ca  Tue Oct 20 10:17:07 2009
From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen)
Date: Tue, 20 Oct 2009 10:17:07 -0400
Subject: [uClinux-dev] Luminary lm3s9b92
In-Reply-To: <4ADDA7D1.5090308@gmx.net>
References: <4ADDA7D1.5090308@gmx.net>
Message-ID: <20091020141707.GA5526@csclub.uwaterloo.ca>

On Tue, Oct 20, 2009 at 02:06:41PM +0200, Tom Mayer wrote:
> I am new to uClinux and have a few questions.
>
> I plan to use the lm3s9b92 chip from luminary (already got 2 samples :))  
> with uClinux. I plan to design hardware with 16mb sdram and 4mb flash.  
> from my research that should be plenty of space for uClinux.

That sounds reasonable to me at least.

> This is a cortex-m3 controller. I discovered some patches so it seems  
> that it would be supported.
>
> My fear is NIC/LAN driver. This chip is really perfect - including MAC  
> and PHY on chip. Is there anyone who already made some steps in using  
> this controller with uClinux?

No idea.  

> Would be nice if  someone experienced could point out if this chip is  
> usable with the uClinux project. Maybe there are circumstances that make  
> the chip unusable?

Well it appears to be an ARM Cortex M3 core, and there are patches
around to make that work with linux.  No idea about that specific chip,
but have a look here:
http://www.linux-arm.com/LinuxKernel/LinuxM3

This page has some links and info for Unison Ultra Tiny Embedded Linux
for that chip:
http://www.luminarymicro.com/products/ekc-lm3s9b92.html

So well no idea what getting drivers would be like.  It is TI so
the impression I have gotten over the years with TI is that they are
practically hostile to open source.  Perhaps that is only some divisions
of the company though.

-- 
Len Sorensen


From os at emlix.com  Tue Oct 20 10:20:58 2009
From: os at emlix.com (Oskar Schirmer)
Date: Tue, 20 Oct 2009 16:20:58 +0200
Subject: [uClinux-dev] Luminary lm3s9b92
In-Reply-To: <4ADDA7D1.5090308@gmx.net>
References: <4ADDA7D1.5090308@gmx.net>
Message-ID: <20091020142058.GA13272@emlix.com>

On Tue, Oct 20, 2009 at 14:06:41 +0200, Tom Mayer wrote:
> I plan to use the lm3s9b92 chip from luminary (already got 2 samples :)) 
> with uClinux. I plan to design hardware with 16mb sdram and 4mb flash. From 
> my research that should be plenty of space for uClinux.
>
> This is a cortex-m3 controller. I discovered some patches so it seems that 
> it would be supported.

do these patches add thumb-2 support to the arm assembly code
sections? if not so, you would probably have to add thumb-2 code
to support cortex-m3.

> My fear is NIC/LAN driver. This chip is really perfect - including MAC and 
> PHY on chip. Is there anyone who already made some steps in using this 
> controller with uClinux?

no. but according to the data sheet it looks quite straight
forward, so I doubt there are obstacles for writing it from
scratch.

> Would be nice if  someone experienced could point out if this chip is 
> usable with the uClinux project. Maybe there are circumstances that make 
> the chip unusable?

as of now, looks like someone would need to do the whole port.
adding driver support might be more work than the cortex-m3 stuff.
so no problem. theoretically...

  Oskar
-- 
oskar schirmer, emlix gmbh, http://www.emlix.com
fon +49 551 30664-0, fax -11, bahnhofsallee 1b, 37081 g?ttingen, germany
sitz der gesellschaft: g?ttingen, amtsgericht g?ttingen hr b 3160
gesch?ftsf?hrer: dr. uwe kracke, ust-idnr.: de 205 198 055

emlix - your embedded linux partner


From wolfgang at iksw-muees.de  Tue Oct 20 12:30:15 2009
From: wolfgang at iksw-muees.de (Wolfgang =?iso-8859-1?q?M=FCes?=)
Date: Tue, 20 Oct 2009 18:30:15 +0200
Subject: [uClinux-dev] Luminary lm3s9b92
In-Reply-To: <4ADDA7D1.5090308@gmx.net>
References: <4ADDA7D1.5090308@gmx.net>
Message-ID: <200910201830.16019.wolfgang@iksw-muees.de>

Hi Tom,

Am Dienstag, 20. Oktober 2009 14:06:41 schrieb Tom Mayer:
> I plan to use the lm3s9b92 chip from luminary (already got 2 samples :))
> with uClinux. I plan to design hardware with 16mb sdram and 4mb flash.
>  from my research that should be plenty of space for uClinux.

I have looked at this chip, too - and have decided against it.

This chip is NOT designed to execute code from external memory. It is 
possible, but without a data or instruction cache, the resulting speed will be 
so slow, that the usage is very limited.

Take a decent chip with a good community and plenty of computing power.
I can recommend the blackfin CPU.

regards

Wolfgang
-- 
Wahre Worte sind nicht sch?n. Sch?ne Worte sind nicht wahr.

(Laotse)


From lgowris at rediffmail.com  Tue Oct 20 12:51:02 2009
From: lgowris at rediffmail.com (gowri sankar loganathan)
Date: 20 Oct 2009 16:51:02 -0000
Subject: [uClinux-dev] support for kernal 2.6.XX compilation
Message-ID: <20091020165102.44670.qmail@f5mail-236-230.rediffmail.com>

Hello All,
         I trying to build kernal 2.6.XX for atmel AT91 processor, I am getting the following error, it would very help full if someone provides me some info regarding what is going wrong.   


/home/armtools/uClinux-dist# make ARCH=arm CROSS_COMPILE=/home/armtools/arm2007q1/bin/arm-none-linux-gnueabi-
make -C tools/ucfront
make[1]: Entering directory `/home/armtools/uClinux-dist/tools/ucfront'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/armtools/uClinux-dist/tools/ucfront'
ln -sf /home/armtools/uClinux-dist/tools/ucfront/ucfront tools/ucfront-gcc
ln -sf /home/armtools/uClinux-dist/tools/ucfront/ucfront tools/ucfront-g++
ln -sf /home/armtools/uClinux-dist/tools/ucfront/ucfront-ld tools/ucfront-ld
ln -sf /home/armtools/uClinux-dist/tools/ucfront/jlibtool tools/jlibtool
chmod +x tools/romfs-inst.sh tools/modules-alias.sh tools/build-udev-perms.sh
make -C config automake
make[1]: Entering directory `/home/armtools/uClinux-dist/config'
make[1]: Nothing to be done for `automake'.
make[1]: Leaving directory `/home/armtools/uClinux-dist/config'
. linux-2.6.x/.config; if [ "$CONFIG_INITRAMFS_SOURCE" != "" ]; then \
		mkdir -p `dirname $CONFIG_INITRAMFS_SOURCE`; \
		touch $CONFIG_INITRAMFS_SOURCE || exit 1; \
	fi
make ARCH=arm CROSS_COMPILE=/home/armtools/arm2007q1/bin/arm-none-linux-gnueabi- -j4 -C linux-2.6.x  || exit 1
make[1]: Entering directory `/home/armtools/uClinux-dist/linux-2.6.x'
  CHK     include/linux/version.h
make[2]: `include/asm-arm/mach-types.h' is up to date.
  CHK     include/linux/utsrelease.h
  CALL    scripts/checksyscalls.sh
:1097:2: warning: #warning syscall fadvise64 not implemented
:1265:2: warning: #warning syscall migrate_pages not implemented
:1321:2: warning: #warning syscall pselect6 not implemented
:1325:2: warning: #warning syscall ppoll not implemented
:1365:2: warning: #warning syscall epoll_pwait not implemented
  CHK     include/linux/compile.h
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
make[1]: Leaving directory `/home/armtools/uClinux-dist/linux-2.6.x'
if [ -f linux-2.6.x/vmlinux ]; then \
		ln -f linux-2.6.x/vmlinux linux-2.6.x/linux ; \
	fi
. linux-2.6.x/.config; if [ "$CONFIG_MODULES" = "y" ]; then \
		[ -d linux-2.6.x/modules ] || mkdir linux-2.6.x/modules; \
		make ARCH=arm CROSS_COMPILE=/home/armtools/arm2007q1/bin/arm-none-linux-gnueabi- -C linux-2.6.x modules; \
	fi
for dir in  include lib include user ; do [ ! -d $dir ] || make ARCH=arm -C $dir || exit 1 ; done
make[1]: Entering directory `/home/armtools/uClinux-dist/include'
find . -depth -type l -a ! -name Makefile | xargs rm > /dev/null 2>&1 || exit 0
find . -depth -type d | grep -v .svn | xargs rmdir > /dev/null 2>&1 || exit 0
Making symlinks in include/
ln: creating symbolic link `././linux': File exists
Making include/c++ symlink to compiler c++ includes
Checking for modern c++ bits, /home/armtools/arm2007q1/bin/../arm-none-linux-gnueabi/include/c++/Sourcery/arm-none-linux-gnueabi/./bits
make[1]: Leaving directory `/home/armtools/uClinux-dist/include'
make[1]: Entering directory `/home/armtools/uClinux-dist/lib'
make -j1 -C ../include                 || exit $?
make[2]: Entering directory `/home/armtools/uClinux-dist/include'
find . -depth -type l -a ! -name Makefile | xargs rm > /dev/null 2>&1 || exit 0
find . -depth -type d | grep -v .svn | xargs rmdir > /dev/null 2>&1 || exit 0
Making symlinks in include/
ln: creating symbolic link `././linux': File exists
Making include/c++ symlink to compiler c++ includes
Checking for modern c++ bits, /home/armtools/arm2007q1/bin/../arm-none-linux-gnueabi/include/c++/Sourcery/arm-none-linux-gnueabi/./bits
make[2]: Leaving directory `/home/armtools/uClinux-dist/include'
[ -z "uClibc" ] ||\
		make -j4 uClibc || exit $?
make[2]: Entering directory `/home/armtools/uClinux-dist/lib'
[ ! -d "uClibc" ] || ( touch uClibc/.sgbuilt_lib && make -j1 -C uClibc ) || exit $?
make[3]: Entering directory `/home/armtools/uClinux-dist/uClibc'
make[3]: warning: -jN forced in submake: disabling jobserver mode.
make[4]: `conf' is up to date.
  CC libcrypt/des.o
In file included from ./include/bits/posix1_lim.h:153,
                 from ./include/limits.h:144,
                 from libcrypt/des.c:33:
./include/bits/local_lim.h:36:26: error: linux/limits.h: No such file or directory
libcrypt/des.c:472: warning: function declaration isn't a prototype
libcrypt/des.c:985: warning: function declaration isn't a prototype
make[3]: *** [libcrypt/des.o] Error 1
make[3]: Leaving directory `/home/armtools/uClinux-dist/uClibc'
make[2]: *** [uClibc] Error 2
make[2]: Leaving directory `/home/armtools/uClinux-dist/lib'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/armtools/uClinux-dist/lib'
make: *** [subdirs] Error 1


with thanks & regards,
Gowrisankar Loganathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091020/b63b0479/attachment.html>

From christiangieseler at yahoo.de  Wed Oct 21 02:04:27 2009
From: christiangieseler at yahoo.de (Christian Gieseler)
Date: Tue, 20 Oct 2009 23:04:27 -0700 (PDT)
Subject: AW: [uClinux-dev] support for kernal 2.6.XX compilation
In-Reply-To: <20091020165102.44670.qmail@f5mail-236-230.rediffmail.com>
References: <20091020165102.44670.qmail@f5mail-236-230.rediffmail.com>
Message-ID: <523166.10000.qm@web23504.mail.ird.yahoo.com>

Hi,

have a look at this:
http://mailman.uclinux.org/pipermail/uclinux-dev/2009-May/000890.html. 
Maybe this solves your problem. 
There are more posts about limits.h in the archives.

HTH
Regards
Chrsitian


>
>Von: gowri sankar loganathan <lgowris at rediffmail.com>
>An: uclinux-dev at uclinux.org
>Gesendet: Dienstag, den 20. Oktober 2009, 18:51:02 Uhr
>Betreff: [uClinux-dev] support for kernal 2.6.XX compilation
>
>Hello All,
>>         I trying to build kernal 2.6.XX for atmel AT91 processor, I am getting the following error, it would very help full if someone provides me some info regarding what is going wrong. 
>
>
>>/home/armtools/uClinux-dist# make ARCH=arm CROSS_COMPILE=/home/armtools/arm2007q1/bin/arm-none-linux-gnueabi-
>>make -C tools/ucfront
>>make[1]: Entering directory `/home/armtools/uClinux-dist/tools/ucfront'
>>make[1]: Nothing to be done for `all'.
>>make[1]: Leaving directory `/home/armtools/uClinux-dist/tools/ucfront'
>>ln -sf /home/armtools/uClinux-dist/tools/ucfront/ucfront tools/ucfront-gcc
>>ln -sf /home/armtools/uClinux-dist/tools/ucfront/ucfront tools/ucfront-g++
>>ln -sf /home/armtools/uClinux-dist/tools/ucfront/ucfront-ld tools/ucfront-ld
>>ln -sf /home/armtools/uClinux-dist/tools/ucfront/jlibtool tools/jlibtool
>>chmod +x tools/romfs-inst.sh tools/modules-alias.sh tools/build-udev-perms.sh
>>make -C config automake
>>make[1]: Entering directory `/home/armtools/uClinux-dist/config'
>>make[1]: Nothing to be done for `automake'.
>>make[1]: Leaving directory `/home/armtools/uClinux-dist/config'
>>. linux-2.6.x/.config; if [ "$CONFIG_INITRAMFS_SOURCE" != "" ]; then 
>>		mkdir -p `dirname $CONFIG_INITRAMFS_SOURCE`; 
>>		touch $CONFIG_INITRAMFS_SOURCE || exit 1; 
>>	fi
>>make ARCH=arm CROSS_COMPILE=/home/armtools/arm2007q1/bin/arm-none-linux-gnueabi- -j4 -C linux-2.6.x  || exit 1
>>make[1]: Entering directory `/home/armtools/uClinux-dist/linux-2.6.x'
>>  CHK     include/linux/version.h
>>make[2]: `include/asm-arm/mach-types.h' is up to date.
>>  CHK     include/linux/utsrelease.h
>>  CALL    scripts/checksyscalls.sh
>> :1097:2: warning: #warning syscall fadvise64 not implemented
>> :1265:2: warning: #warning syscall migrate_pages not implemented
>> :1321:2: warning: #warning syscall pselect6 not implemented
>> :1325:2: warning: #warning syscall ppoll not implemented
>> :1365:2: warning: #warning syscall epoll_pwait not implemented
>>  CHK     include/linux/compile.h
>>  Kernel: arch/arm/boot/Image is ready
>>  Kernel: arch/arm/boot/zImage is ready
>>make[1]: Leaving directory `/home/armtools/uClinux-dist/linux-2.6.x'
>>if [ -f linux-2.6.x/vmlinux ]; then 
>>		ln -f linux-2.6.x/vmlinux linux-2.6.x/linux ; 
>>	fi
>>. linux-2.6.x/.config; if [ "$CONFIG_MODULES" = "y" ]; then 
>>		[ -d linux-2.6.x/modules ] || mkdir linux-2.6.x/modules; 
>>		make ARCH=arm CROSS_COMPILE=/home/armtools/arm2007q1/bin/arm-none-linux-gnueabi- -C linux-2.6.x modules; 
>>	fi
>>for dir in  include lib include user ; do [ ! -d $dir ] || make ARCH=arm -C $dir || exit 1 ; done
>>make[1]: Entering directory `/home/armtools/uClinux-dist/include'
>>find . -depth -type l -a ! -name Makefile | xargs rm > /dev/null 2>&1 || exit 0
>>find . -depth -type d | grep -v .svn | xargs rmdir > /dev/null 2>&1 || exit 0
>>Making symlinks in include/
>>ln: creating symbolic link `././linux': File exists
>>Making include/c++ symlink to compiler c++ includes
>>Checking for modern c++ bits, /home/armtools/arm2007q1/bin/../arm-none-linux-gnueabi/include/c++/Sourcery/arm-none-linux-gnueabi/./bits
>>make[1]: Leaving directory `/home/armtools/uClinux-dist/include'
>>make[1]: Entering directory `/home/armtools/uClinux-dist/lib'
>>make -j1 -C ../include                 || exit $?
>>make[2]: Entering directory `/home/armtools/uClinux-dist/include'
>>find . -depth -type l -a ! -name Makefile | xargs rm > /dev/null 2>&1 || exit 0
>>find . -depth -type d | grep -v .svn | xargs rmdir > /dev/null 2>&1 || exit 0
>>Making symlinks in include/
>>ln: creating symbolic link `././linux': File exists
>>Making include/c++ symlink to compiler c++ includes
>>Checking for modern c++ bits, /home/armtools/arm2007q1/bin/../arm-none-linux-gnueabi/include/c++/Sourcery/arm-none-linux-gnueabi/./bits
>>make[2]: Leaving directory `/home/armtools/uClinux-dist/include'
>>[ -z "uClibc" ] ||
>>		make -j4 uClibc || exit $?
>>make[2]: Entering directory `/home/armtools/uClinux-dist/lib'
>>[ ! -d "uClibc" ] || ( touch uClibc/.sgbuilt_lib && make -j1 -C uClibc ) || exit $?
>>make[3]: Entering directory `/home/armtools/uClinux-dist/uClibc'
>>make[3]: warning: -jN forced in submake: disabling jobserver mode.
>>make[4]: `conf' is up to date.
>>  CC libcrypt/des.o
>>In file included from ./include/bits/posix1_lim.h:153,
>>                 from ./include/limits.h:144,
>>                 from libcrypt/des.c:33:
>>./include/bits/local_lim.h:36:26: error: linux/limits.h: No such file or directory
>>libcrypt/des.c:472: warning: function declaration isn't a prototype
>>libcrypt/des.c:985: warning: function declaration isn't a prototype
>>make[3]: *** [libcrypt/des.o] Error 1
>>make[3]: Leaving directory `/home/armtools/uClinux-dist/uClibc'
>>make[2]: *** [uClibc] Error 2
>>make[2]: Leaving directory `/home/armtools/uClinux-dist/lib'
>>make[1]: *** [all] Error 2
>>make[1]: Leaving directory `/home/armtools/uClinux-dist/lib'
>>make: *** [subdirs] Error 1
>
>
>>with thanks & regards,
>>Gowrisankar Loganathan
>
>
>
>
> 

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091020/2cc98832/attachment.html>

From jsun at junsun.net  Wed Oct 21 19:10:53 2009
From: jsun at junsun.net (Jun Sun)
Date: Wed, 21 Oct 2009 16:10:53 -0700
Subject: [uClinux-dev] kernel compilation breaks with AEABI but no
	OABI_COMPAT
Message-ID: <20091021231053.GC753@Pogoplug>


We are compiling for 2.6.25 kernel last year's Aug 8th uclinux distro
for a no-mmu ARM7 board.  We have been using both options and kernel
compiles fine.

Today I tried to get rid of OABI_COMPAT option and got the following
errors:

  CC      kernel/time.o
kernel/time.c:53:2: error: #error ICSA specification requires the logging of time changes. This architecture will not log changes.

A quick search did not reveal any easy answers. Does anybody know 
the solution?

Cheers.

Jun


From sjt.kar at gmail.com  Thu Oct 22 01:50:07 2009
From: sjt.kar at gmail.com (Sujit K M)
Date: Thu, 22 Oct 2009 11:20:07 +0530
Subject: [uClinux-dev] kernel compilation breaks with AEABI but no 
	OABI_COMPAT
In-Reply-To: <20091021231053.GC753@Pogoplug>
References: <20091021231053.GC753@Pogoplug>
Message-ID: <921ca19c0910212250g7d7d0d9ev7095614e8b081390@mail.gmail.com>

Hi,

As per the source code.

#ifdef __ARCH_WANT_SYS_TIME
 52
 53 /*
 54  * sys_time() can be implemented in user-level using
 55  * sys_gettimeofday().  Is this for backwards compatibility?  If so,
 56  * why not move it into the appropriate arch directory (for those
 57  * architectures that need it).
 58  */


Does this help?

Thanks,

On Thu, Oct 22, 2009 at 4:40 AM, Jun Sun <jsun at junsun.net> wrote:
>
> We are compiling for 2.6.25 kernel last year's Aug 8th uclinux distro
> for a no-mmu ARM7 board. ?We have been using both options and kernel
> compiles fine.
>
> Today I tried to get rid of OABI_COMPAT option and got the following
> errors:
>
> ?CC ? ? ?kernel/time.o
> kernel/time.c:53:2: error: #error ICSA specification requires the logging of time changes. This architecture will not log changes.
>
> A quick search did not reveal any easy answers. Does anybody know
> the solution?
>
> Cheers.
>
> Jun
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>



-- 
-- Sujit K M

blog(http://kmsujit.blogspot.com/)


From fabio.giovagnini at aurion-tech.com  Sat Oct 24 09:27:34 2009
From: fabio.giovagnini at aurion-tech.com (Fabio Giovagnini)
Date: Sat, 24 Oct 2009 15:27:34 +0200
Subject: [uClinux-dev] Hi, all a question about RSK+ 7203 renesas board
Message-ID: <200910241527.34643.fabio.giovagnini@aurion-tech.com>

Hi All,
I'm designing a custom board assuming as start pont the eva board.
If  understand properly, the nor flash has the boot loader, allowing the board 
to start.
The softawre given by MCP Data is funny and very good configured. But I cannot 
see the source coed of the boot loader.
Does anyone of you know what boot loader it is and where can I find teh source 
code if any?

Thanks in advance

-- 
Fabio Giovagnini

Aurion s.r.l.
CF e P.IVA 00885711200
Tel. +39.335.8350919

www.aurion-tech.com

account telefono VoIP skype (www.skype.com):
aurion.giovagnini


From allon.stern at argonst.com  Sat Oct 24 10:33:28 2009
From: allon.stern at argonst.com (Allon Stern)
Date: Sat, 24 Oct 2009 10:33:28 -0400
Subject: [uClinux-dev] Hi, all a question about RSK+ 7203 renesas board
In-Reply-To: <200910241527.34643.fabio.giovagnini@aurion-tech.com>
References: <200910241527.34643.fabio.giovagnini@aurion-tech.com>
Message-ID: <9C9CF120-1A05-4B45-A967-00B5849F3ADE@argonst.com>



On Oct 24, 2009, at 9:27 AM, Fabio Giovagnini <fabio.giovagnini at aurion-tech.com 
 > wrote:

> The softawre given by MCP Data is funny and very good configured.  
> But I cannot see the source coed of the boot loader.
> Does anyone of you know what boot loader it is and where can I find  
> teh source code if any?

Does the boot loader identify itself?
What is the banner?
 from a cursory look, it appears that the u-boot bootloader from Denx,  
supports that board. I like u-boot. It is feature rich, easy to extend  
and easy to add support for new platforms

http://www.denx.de/wiki/U-Boot/WebHome
-
allon 


From fabio.giovagnini at aurion-tech.com  Sat Oct 24 10:37:40 2009
From: fabio.giovagnini at aurion-tech.com (Fabio Giovagnini)
Date: Sat, 24 Oct 2009 16:37:40 +0200
Subject: [uClinux-dev] Hi, all a question about RSK+ 7203 renesas board
In-Reply-To: <9C9CF120-1A05-4B45-A967-00B5849F3ADE@argonst.com>
References: <200910241527.34643.fabio.giovagnini@aurion-tech.com>
	<9C9CF120-1A05-4B45-A967-00B5849F3ADE@argonst.com>
Message-ID: <200910241637.40763.fabio.giovagnini@aurion-tech.com>

Thanks a lot Allon.
Can I write to you directly for an opinion exchange?

Fill free to answer also NO!!!!!

For now many many thanks.


Alle 16:33, sabato 24 ottobre 2009, Allon Stern ha scritto:
> On Oct 24, 2009, at 9:27 AM, Fabio Giovagnini
> <fabio.giovagnini at aurion-tech.com
>
>  > wrote:
> >
> > The softawre given by MCP Data is funny and very good configured.
> > But I cannot see the source coed of the boot loader.
> > Does anyone of you know what boot loader it is and where can I find
> > teh source code if any?
>
> Does the boot loader identify itself?
> What is the banner?
>  from a cursory look, it appears that the u-boot bootloader from Denx,
> supports that board. I like u-boot. It is feature rich, easy to extend
> and easy to add support for new platforms
>
> http://www.denx.de/wiki/U-Boot/WebHome
> -
> allon
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev

-- 
Fabio Giovagnini

Aurion s.r.l.
CF e P.IVA 00885711200
Tel. +39.335.8350919

www.aurion-tech.com

account telefono VoIP skype (www.skype.com):
aurion.giovagnini


From vinodnagare at yahoo.com  Sun Oct 25 03:05:34 2009
From: vinodnagare at yahoo.com (Vinod Nagare)
Date: Sun, 25 Oct 2009 00:05:34 -0700 (PDT)
Subject: [uClinux-dev] Problem:Spurious Interrupt on Coldfire................
Message-ID: <918801.13858.qm@web33504.mail.mud.yahoo.com>

Dear Friends,
?
I am using a custom build board using MCF5485 and uClinux 2.4.x ported on it. I am using General Purpose Timer (GPT), which is generating interrupts to CPU and an ISR is connected to this interrupt.
?
When the timer is configured to generate interrupt for period 100ms the ISR is invoked every 100ms and functions properly.
?
But when I configurs timer (GPT)?to generate interrupt every 10ms following message is printed on console (connected to minicom) and the system starves and ISR is?not invoked.
?
Spurious interrupt 4488788
Spurious interrupt 4289755
..........................................
and such messages are printed continously.....
?
?
Please help me to solve this problem as I need an ISR to be executed every 2ms.
?
Thank You and regards,
Vinod Nagare


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091025/ebb8e0e1/attachment.html>

From allon.stern at argonst.com  Sun Oct 25 07:20:21 2009
From: allon.stern at argonst.com (Allon Stern)
Date: Sun, 25 Oct 2009 07:20:21 -0400
Subject: [uClinux-dev] Problem:Spurious Interrupt on
	Coldfire................
In-Reply-To: <918801.13858.qm@web33504.mail.mud.yahoo.com>
References: <918801.13858.qm@web33504.mail.mud.yahoo.com>
Message-ID: <3FF5A6EB-31DD-4A2B-9E7A-B7CACB71B6F3@argonst.com>


On Oct 25, 2009, at 3:05 AM, Vinod Nagare <vinodnagare at yahoo.com> wrote:

> I am using a custom build board using MCF5485 and uClinux 2.4.x  
> ported on it. I am using General Purpose Timer (GPT), which is  
> generating interrupts to CPU and an ISR is connected to this  
> interrupt.
>
> When the timer is configured to generate interrupt for period 100ms  
> the ISR is invoked every 100ms and functions properly.
>
> But when I configurs timer (GPT) to generate interrupt every 10ms  
> following message is printed on console (connected to minicom) and  
> the system starves and ISR is not invoked.
>
> Spurious interrupt 4488788
> Spurious interrupt 4289755
> ..........................................
> and such messages are printed continously.....

What is the return value from your ISR?

Is the timer used for something else on the system, or is itnotherwise  
unused? Check the kernel code / drivers.

These are first guesses.
-
allon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091025/956b9380/attachment.html>

From vinodnagare at yahoo.com  Mon Oct 26 00:16:10 2009
From: vinodnagare at yahoo.com (Vinod Nagare)
Date: Sun, 25 Oct 2009 21:16:10 -0700 (PDT)
Subject: [uClinux-dev] Re: uClinux-dev Digest, Vol 78, Issue 16
In-Reply-To: <20091025170003.B8353435C9@uclinux.org>
Message-ID: <573781.68228.qm@web33504.mail.mud.yahoo.com>

Thank You Dear Allon,
?
I did not understan what is mean by return from ISR?
?
?
The timer is not used for any other purpose and if functions as expected when configured for higher timer value but generates spurious interrupts for lower values.
?
Still i am not able to solve this issue, please help me.
?
Regards,
Vinod 
?


--- On Sun, 10/25/09, uclinux-dev-request at uclinux.org <uclinux-dev-request at uclinux.org> wrote:


From: uclinux-dev-request at uclinux.org <uclinux-dev-request at uclinux.org>
Subject: uClinux-dev Digest, Vol 78, Issue 16
To: uclinux-dev at uclinux.org
Date: Sunday, October 25, 2009, 10:30 PM


Send uClinux-dev mailing list submissions to
??? uclinux-dev at uclinux.org

To subscribe or unsubscribe via the World Wide Web, visit
??? http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
or, via email, send a message with subject or body 'help' to
??? uclinux-dev-request at uclinux.org

You can reach the person managing the list at
??? uclinux-dev-owner at uclinux.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of uClinux-dev digest..."


Today's Topics:

???1. Problem:Spurious Interrupt on Coldfire................
? ? ? (Vinod Nagare)
???2. Re: Problem:Spurious Interrupt on??? Coldfire................
? ? ? (Allon Stern)


----------------------------------------------------------------------

Message: 1
Date: Sun, 25 Oct 2009 00:05:34 -0700 (PDT)
From: Vinod Nagare <vinodnagare at yahoo.com>
Subject: [uClinux-dev] Problem:Spurious Interrupt on
??? Coldfire................
To: uclinux-dev at uclinux.org
Message-ID: <918801.13858.qm at web33504.mail.mud.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"

Dear Friends,
?
I am using a custom build board using MCF5485 and uClinux 2.4.x ported on it. I am using General Purpose Timer (GPT), which is generating interrupts to CPU and an ISR is connected to this interrupt.
?
When the timer is configured to generate interrupt for period 100ms the ISR is invoked every 100ms and functions properly.
?
But when I configurs timer (GPT)?to generate interrupt every 10ms following message is printed on console (connected to minicom) and the system starves and ISR is?not invoked.
?
Spurious interrupt 4488788
Spurious interrupt 4289755
..........................................
and such messages are printed continously.....
?
?
Please help me to solve this problem as I need an ISR to be executed every 2ms.
?
Thank You and regards,
Vinod Nagare


? ? ? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091025/ebb8e0e1/attachment-0001.html

------------------------------

Message: 2
Date: Sun, 25 Oct 2009 07:20:21 -0400
From: Allon Stern <allon.stern at argonst.com>
Subject: Re: [uClinux-dev] Problem:Spurious Interrupt on
??? Coldfire................
To: uClinux development list <uclinux-dev at uclinux.org>
Cc: "uclinux-dev at uclinux.org" <uclinux-dev at uclinux.org>
Message-ID: <3FF5A6EB-31DD-4A2B-9E7A-B7CACB71B6F3 at argonst.com>
Content-Type: text/plain; charset="us-ascii"


On Oct 25, 2009, at 3:05 AM, Vinod Nagare <vinodnagare at yahoo.com> wrote:

> I am using a custom build board using MCF5485 and uClinux 2.4.x? 
> ported on it. I am using General Purpose Timer (GPT), which is? 
> generating interrupts to CPU and an ISR is connected to this? 
> interrupt.
>
> When the timer is configured to generate interrupt for period 100ms? 
> the ISR is invoked every 100ms and functions properly.
>
> But when I configurs timer (GPT) to generate interrupt every 10ms? 
> following message is printed on console (connected to minicom) and? 
> the system starves and ISR is not invoked.
>
> Spurious interrupt 4488788
> Spurious interrupt 4289755
> ..........................................
> and such messages are printed continously.....

What is the return value from your ISR?

Is the timer used for something else on the system, or is itnotherwise? 
unused? Check the kernel code / drivers.

These are first guesses.
-
allon
-------------- next part --------------
?

An HTML attachment was scrubbed...
URL: http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091025/956b9380/attachment-0001.html

------------------------------

_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

End of uClinux-dev Digest, Vol 78, Issue 16
*******************************************

?
?
?
?


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091025/bfb8a373/attachment.html>

From kieranbingham at gmail.com  Mon Oct 26 06:08:17 2009
From: kieranbingham at gmail.com (Kieran Bingham)
Date: Mon, 26 Oct 2009 10:08:17 +0000
Subject: [uClinux-dev] Hi, all a question about RSK+ 7203 renesas board
In-Reply-To: <200910241527.34643.fabio.giovagnini@aurion-tech.com>
References: <200910241527.34643.fabio.giovagnini@aurion-tech.com>
Message-ID: <4AE57511.1020104@gmail.com>

Fabio Giovagnini wrote:
> Hi All,
> I'm designing a custom board assuming as start pont the eva board.
> If  understand properly, the nor flash has the boot loader, allowing the board 
> to start.
> The softawre given by MCP Data is funny and very good configured. But I cannot 
> see the source coed of the boot loader.
> Does anyone of you know what boot loader it is and where can I find teh source 
> code if any?
>
> Thanks in advance
>
>   
Hi Fabio,

The RSK7203 is supported by U-Boot, and I believe the sources are in the 
mainline project of U-Boot.

Indeed the board support files are shown at the following GIT url.
http://git.denx.de/?p=u-boot.git;a=tree;f=board/renesas/rsk7203

You should be able to run the latest version of U-Boot quite successfully?

--
Regards
Kieran Bingham


From fabio.giovagnini at aurion-tech.com  Mon Oct 26 06:10:13 2009
From: fabio.giovagnini at aurion-tech.com (Fabio Giovagnini)
Date: Mon, 26 Oct 2009 11:10:13 +0100
Subject: [uClinux-dev] Hi, all a question about RSK+ 7203 renesas board
In-Reply-To: <4AE57511.1020104@gmail.com>
References: <200910241527.34643.fabio.giovagnini@aurion-tech.com>
	<4AE57511.1020104@gmail.com>
Message-ID: <200910261110.13991.fabio.giovagnini@aurion-tech.com>

Hi Keiran

Could you tell me why into the 2.0 version no g++ complier is yet enabled?

Thanks a lot


Alle 11:08, luned? 26 ottobre 2009, Kieran Bingham ha scritto:
> Fabio Giovagnini wrote:
> > Hi All,
> > I'm designing a custom board assuming as start pont the eva board.
> > If  understand properly, the nor flash has the boot loader, allowing the
> > board to start.
> > The softawre given by MCP Data is funny and very good configured. But I
> > cannot see the source coed of the boot loader.
> > Does anyone of you know what boot loader it is and where can I find teh
> > source code if any?
> >
> > Thanks in advance
>
> Hi Fabio,
>
> The RSK7203 is supported by U-Boot, and I believe the sources are in the
> mainline project of U-Boot.
>
> Indeed the board support files are shown at the following GIT url.
> http://git.denx.de/?p=u-boot.git;a=tree;f=board/renesas/rsk7203
>
> You should be able to run the latest version of U-Boot quite successfully?
>
> --
> Regards
> Kieran Bingham
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev

-- 
Fabio Giovagnini

Aurion s.r.l.
CF e P.IVA 00885711200
Tel. +39.335.8350919

www.aurion-tech.com

account telefono VoIP skype (www.skype.com):
aurion.giovagnini


From allon.stern at argonst.com  Mon Oct 26 12:17:53 2009
From: allon.stern at argonst.com (Allon Stern)
Date: Mon, 26 Oct 2009 12:17:53 -0400
Subject: [uClinux-dev] Re: uClinux-dev Digest, Vol 78, Issue 16
In-Reply-To: <573781.68228.qm@web33504.mail.mud.yahoo.com>
References: <573781.68228.qm@web33504.mail.mud.yahoo.com>
Message-ID: <E67FEB07-3C06-4A64-A90D-5ABF2EBFC180@argonst.com>


On Oct 26, 2009, at 12:16 AM, Vinod Nagare wrote:

> Thank You Dear Allon,
>
> I did not understan what is mean by return from ISR?
>

Your ISR is a function, invoked by the kernel.
What value does it return?
If you return anything other than IRQ_HANDLED, you might get a  
spurious interrupt message. If you fail to specify a return value, you  
might get weird results, maybe what you are seeing.
-
allon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091026/1a656898/attachment.html>

From jsun at junsun.net  Mon Oct 26 21:10:35 2009
From: jsun at junsun.net (Jun Sun)
Date: Mon, 26 Oct 2009 18:10:35 -0700
Subject: [uClinux-dev] kernel compilation breaks with AEABI but no
	OABI_COMPAT
In-Reply-To: <921ca19c0910212250g7d7d0d9ev7095614e8b081390@mail.gmail.com>
References: <20091021231053.GC753@Pogoplug>
	<921ca19c0910212250g7d7d0d9ev7095614e8b081390@mail.gmail.com>
Message-ID: <20091027011035.GA1767@Pogoplug>


Not really.  So we should just ignore that error message by removing
the #error pragma?

Cheers.

Jun


On Thu, Oct 22, 2009 at 11:20:07AM +0530, Sujit K M wrote:
> Hi,
> 
> As per the source code.
> 
> #ifdef __ARCH_WANT_SYS_TIME
>  52
>  53 /*
>  54  * sys_time() can be implemented in user-level using
>  55  * sys_gettimeofday().  Is this for backwards compatibility?  If so,
>  56  * why not move it into the appropriate arch directory (for those
>  57  * architectures that need it).
>  58  */
> 
> 
> Does this help?
> 
> Thanks,
> 
> On Thu, Oct 22, 2009 at 4:40 AM, Jun Sun <jsun at junsun.net> wrote:
> >
> > We are compiling for 2.6.25 kernel last year's Aug 8th uclinux distro
> > for a no-mmu ARM7 board. ?We have been using both options and kernel
> > compiles fine.
> >
> > Today I tried to get rid of OABI_COMPAT option and got the following
> > errors:
> >
> > ?CC ? ? ?kernel/time.o
> > kernel/time.c:53:2: error: #error ICSA specification requires the logging of time changes. This architecture will not log changes.
> >
> > A quick search did not reveal any easy answers. Does anybody know
> > the solution?
> >
> > Cheers.
> >
> > Jun
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> > To unsubscribe see:
> > http://mailman.uclinux.org/mailman/options/uclinux-dev
> >
> 
> 
> 
> -- 
> -- Sujit K M
> 
> blog(http://kmsujit.blogspot.com/)
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev


From sjt.kar at gmail.com  Tue Oct 27 04:06:09 2009
From: sjt.kar at gmail.com (Sujit K M)
Date: Tue, 27 Oct 2009 13:36:09 +0530
Subject: [uClinux-dev] kernel compilation breaks with AEABI but no 
	OABI_COMPAT
In-Reply-To: <20091027011035.GA1767@Pogoplug>
References: <20091021231053.GC753@Pogoplug>
	<921ca19c0910212250g7d7d0d9ev7095614e8b081390@mail.gmail.com>
	<20091027011035.GA1767@Pogoplug>
Message-ID: <921ca19c0910270106j772108abubd33d930da224f79@mail.gmail.com>

> Not really. ?So we should just ignore that error message by removing
> the #error pragma?

I think you will have to change the __ARCH_WANT_SYS_TIME. to n.

>
> Cheers.
>
> Jun
>
>
> On Thu, Oct 22, 2009 at 11:20:07AM +0530, Sujit K M wrote:
>> Hi,
>>
>> As per the source code.
>>
>> #ifdef __ARCH_WANT_SYS_TIME
>> ?52
>> ?53 /*
>> ?54 ?* sys_time() can be implemented in user-level using
>> ?55 ?* sys_gettimeofday(). ?Is this for backwards compatibility? ?If so,
>> ?56 ?* why not move it into the appropriate arch directory (for those
>> ?57 ?* architectures that need it).
>> ?58 ?*/
>>
>>
>> Does this help?
>>
>> Thanks,
>>
>> On Thu, Oct 22, 2009 at 4:40 AM, Jun Sun <jsun at junsun.net> wrote:
>> >
>> > We are compiling for 2.6.25 kernel last year's Aug 8th uclinux distro
>> > for a no-mmu ARM7 board. ?We have been using both options and kernel
>> > compiles fine.
>> >
>> > Today I tried to get rid of OABI_COMPAT option and got the following
>> > errors:
>> >
>> > ?CC ? ? ?kernel/time.o
>> > kernel/time.c:53:2: error: #error ICSA specification requires the logging of time changes. This architecture will not log changes.
>> >
>> > A quick search did not reveal any easy answers. Does anybody know
>> > the solution?
>> >
>> > Cheers.
>> >
>> > Jun
>> > _______________________________________________
>> > uClinux-dev mailing list
>> > uClinux-dev at uclinux.org
>> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> > This message was resent by uclinux-dev at uclinux.org
>> > To unsubscribe see:
>> > http://mailman.uclinux.org/mailman/options/uclinux-dev
>> >
>>
>>
>>
>> --
>> -- Sujit K M
>>
>> blog(http://kmsujit.blogspot.com/)
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev at uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev at uclinux.org
>> To unsubscribe see:
>> http://mailman.uclinux.org/mailman/options/uclinux-dev
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>



-- 
-- Sujit K M

blog(http://kmsujit.blogspot.com/)


From sjt.kar at gmail.com  Tue Oct 27 04:29:45 2009
From: sjt.kar at gmail.com (Sujit K M)
Date: Tue, 27 Oct 2009 13:59:45 +0530
Subject: [uClinux-dev] kernel compilation breaks with AEABI but no 
	OABI_COMPAT
In-Reply-To: <921ca19c0910270106j772108abubd33d930da224f79@mail.gmail.com>
References: <20091021231053.GC753@Pogoplug>
	<921ca19c0910212250g7d7d0d9ev7095614e8b081390@mail.gmail.com>
	<20091027011035.GA1767@Pogoplug>
	<921ca19c0910270106j772108abubd33d930da224f79@mail.gmail.com>
Message-ID: <921ca19c0910270129j529ff6e8q2f58c38f33fc163b@mail.gmail.com>

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/asm-arm/unistd.h#L425

Found the specifics.

On Tue, Oct 27, 2009 at 1:36 PM, Sujit K M <sjt.kar at gmail.com> wrote:
>> Not really. ?So we should just ignore that error message by removing
>> the #error pragma?
>
> I think you will have to change the __ARCH_WANT_SYS_TIME. to n.
>
>>
>> Cheers.
>>
>> Jun
>>
>>
>> On Thu, Oct 22, 2009 at 11:20:07AM +0530, Sujit K M wrote:
>>> Hi,
>>>
>>> As per the source code.
>>>
>>> #ifdef __ARCH_WANT_SYS_TIME
>>> ?52
>>> ?53 /*
>>> ?54 ?* sys_time() can be implemented in user-level using
>>> ?55 ?* sys_gettimeofday(). ?Is this for backwards compatibility? ?If so,
>>> ?56 ?* why not move it into the appropriate arch directory (for those
>>> ?57 ?* architectures that need it).
>>> ?58 ?*/
>>>
>>>
>>> Does this help?
>>>
>>> Thanks,
>>>
>>> On Thu, Oct 22, 2009 at 4:40 AM, Jun Sun <jsun at junsun.net> wrote:
>>> >
>>> > We are compiling for 2.6.25 kernel last year's Aug 8th uclinux distro
>>> > for a no-mmu ARM7 board. ?We have been using both options and kernel
>>> > compiles fine.
>>> >
>>> > Today I tried to get rid of OABI_COMPAT option and got the following
>>> > errors:
>>> >
>>> > ?CC ? ? ?kernel/time.o
>>> > kernel/time.c:53:2: error: #error ICSA specification requires the logging of time changes. This architecture will not log changes.
>>> >
>>> > A quick search did not reveal any easy answers. Does anybody know
>>> > the solution?
>>> >
>>> > Cheers.
>>> >
>>> > Jun
>>> > _______________________________________________
>>> > uClinux-dev mailing list
>>> > uClinux-dev at uclinux.org
>>> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>> > This message was resent by uclinux-dev at uclinux.org
>>> > To unsubscribe see:
>>> > http://mailman.uclinux.org/mailman/options/uclinux-dev
>>> >
>>>
>>>
>>>
>>> --
>>> -- Sujit K M
>>>
>>> blog(http://kmsujit.blogspot.com/)
>>> _______________________________________________
>>> uClinux-dev mailing list
>>> uClinux-dev at uclinux.org
>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>> This message was resent by uclinux-dev at uclinux.org
>>> To unsubscribe see:
>>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>> _______________________________________________
>> uClinux-dev mailing list
>> uClinux-dev at uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev at uclinux.org
>> To unsubscribe see:
>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>>
>
>
>
> --
> -- Sujit K M
>
> blog(http://kmsujit.blogspot.com/)
>



-- 
-- Sujit K M

blog(http://kmsujit.blogspot.com/)


From sjt.kar at gmail.com  Tue Oct 27 08:00:47 2009
From: sjt.kar at gmail.com (Sujit K M)
Date: Tue, 27 Oct 2009 17:30:47 +0530
Subject: [uClinux-dev] kernel compilation breaks with AEABI but no 
	OABI_COMPAT
In-Reply-To: <921ca19c0910270129j529ff6e8q2f58c38f33fc163b@mail.gmail.com>
References: <20091021231053.GC753@Pogoplug>
	<921ca19c0910212250g7d7d0d9ev7095614e8b081390@mail.gmail.com>
	<20091027011035.GA1767@Pogoplug>
	<921ca19c0910270106j772108abubd33d930da224f79@mail.gmail.com>
	<921ca19c0910270129j529ff6e8q2f58c38f33fc163b@mail.gmail.com>
Message-ID: <921ca19c0910270500u13d5fa6dqcbba75ec46724e0@mail.gmail.com>

http://lxr.linux.no/linux+v2.6.31/include/asm-generic/unistd.h#L738

There seems to be some generic code also that you need to check.

On Tue, Oct 27, 2009 at 1:59 PM, Sujit K M <sjt.kar at gmail.com> wrote:
> http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/asm-arm/unistd.h#L425
>
> Found the specifics.
>
> On Tue, Oct 27, 2009 at 1:36 PM, Sujit K M <sjt.kar at gmail.com> wrote:
>>> Not really. ?So we should just ignore that error message by removing
>>> the #error pragma?
>>
>> I think you will have to change the __ARCH_WANT_SYS_TIME. to n.
>>
>>>
>>> Cheers.
>>>
>>> Jun
>>>
>>>
>>> On Thu, Oct 22, 2009 at 11:20:07AM +0530, Sujit K M wrote:
>>>> Hi,
>>>>
>>>> As per the source code.
>>>>
>>>> #ifdef __ARCH_WANT_SYS_TIME
>>>> ?52
>>>> ?53 /*
>>>> ?54 ?* sys_time() can be implemented in user-level using
>>>> ?55 ?* sys_gettimeofday(). ?Is this for backwards compatibility? ?If so,
>>>> ?56 ?* why not move it into the appropriate arch directory (for those
>>>> ?57 ?* architectures that need it).
>>>> ?58 ?*/
>>>>
>>>>
>>>> Does this help?
>>>>
>>>> Thanks,
>>>>
>>>> On Thu, Oct 22, 2009 at 4:40 AM, Jun Sun <jsun at junsun.net> wrote:
>>>> >
>>>> > We are compiling for 2.6.25 kernel last year's Aug 8th uclinux distro
>>>> > for a no-mmu ARM7 board. ?We have been using both options and kernel
>>>> > compiles fine.
>>>> >
>>>> > Today I tried to get rid of OABI_COMPAT option and got the following
>>>> > errors:
>>>> >
>>>> > ?CC ? ? ?kernel/time.o
>>>> > kernel/time.c:53:2: error: #error ICSA specification requires the logging of time changes. This architecture will not log changes.
>>>> >
>>>> > A quick search did not reveal any easy answers. Does anybody know
>>>> > the solution?
>>>> >
>>>> > Cheers.
>>>> >
>>>> > Jun
>>>> > _______________________________________________
>>>> > uClinux-dev mailing list
>>>> > uClinux-dev at uclinux.org
>>>> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>> > This message was resent by uclinux-dev at uclinux.org
>>>> > To unsubscribe see:
>>>> > http://mailman.uclinux.org/mailman/options/uclinux-dev
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> -- Sujit K M
>>>>
>>>> blog(http://kmsujit.blogspot.com/)
>>>> _______________________________________________
>>>> uClinux-dev mailing list
>>>> uClinux-dev at uclinux.org
>>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>> This message was resent by uclinux-dev at uclinux.org
>>>> To unsubscribe see:
>>>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>>> _______________________________________________
>>> uClinux-dev mailing list
>>> uClinux-dev at uclinux.org
>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>> This message was resent by uclinux-dev at uclinux.org
>>> To unsubscribe see:
>>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>>>
>>
>>
>>
>> --
>> -- Sujit K M
>>
>> blog(http://kmsujit.blogspot.com/)
>>
>
>
>
> --
> -- Sujit K M
>
> blog(http://kmsujit.blogspot.com/)
>



-- 
-- Sujit K M

blog(http://kmsujit.blogspot.com/)


From Olov at gmx.de  Tue Oct 27 16:07:49 2009
From: Olov at gmx.de (Oliver Rod)
Date: Tue, 27 Oct 2009 21:07:49 +0100
Subject: [uClinux-dev] XUPV2 PetaLinux "mtd: partition "ROMfs" is out of
	reach"
Message-ID: <20091027200749.157640@gmx.net>

Hi,

I make my student research project my aim is running petalinux v0.40 on a microblaze XUPV2. My Hardware is running fine, but i have problems with my romfs.I start the board and push the image.elf in my ram and I get this KernelMessage:
Linux version 2.6.20-uc0 (tool at tool) (gcc version 3.4.1 ( PetaLinux 0.20 Build -rc1 050607 )) #8 Thu Oct 22 13:55:38 CEST 2009
setup_cpuinfo: initialising
setup_cpuinfo: No PVR support in CPU.  Using static compile-time info
set_cpuinfo_static: Using static CPU info.
setup_memory: max_mapnr: 0x9ffff
setup_memory: min_low_pfn: 0x90000
setup_memory: max_low_pfn: 0x10000
On node 0 totalpages: 65536
  DMA zone: 512 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 65024 pages, LIFO batch:15
  Normal zone: 0 pages used for memmap
Built 1 zonelists.  Total pages: 65024
Kernel command line: root=/dev/ram console=ttyUL0,38400
OPB INTC #0 at 0x81800000
PID hash table entries: 1024 (order: 10, 4096 bytes)
TIMER at 0x83C00000
disabling early console
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257920k/262144k available
Calibrating delay loop... 49.45 BogoMIPS (lpj=247296)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
uartlite.0: ttyUL0 at MMIO 0x84000000 (irq = 3) is a uartlite
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Microblaze FSL FIFO Driver. John Williams <jwilliams at itee.uq.edu.au>
FSL FIFO[0] initialised
eth0: using fifo mode.
eth0: No PHY detected.  Assuming a PHY at address 0.
eth0: Xilinx EMACLite #0 at 0x81000000 mapped to 0x81000000, irq=2
uclinux[mtd]: RAM probe address=0x901c6238 size=0x0
Creating 1 MTD partitions on "RAM":
0x00000000-0x00000000 : "ROMfs"
mtd: partition "ROMfs" is out of reach -- disabled
uclinux[mtd]: set ROMfs to be root filesystem index=0
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
No filesystem could mount root, tried:  ext3 ext2 cramfs msdos vfat romfs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
 <0>Rebooting in 120 seconds..

So I check if my romfs is in my image.elf

microblaze-uclinux-objcopy --add-section=.romfs=software/petalinux-dist/images/romfs.img --adjust-section-vma=.romfs=0x901ab000 --no-adjust-warnings --set-section-flags=.romfs=alloc,load,data software/petalinux-dist/linux-2.6.x/linux software/petalinux-dist/images/image.elf
BFD: software/petalinux-dist/images/image.elf: warning: allocated section `.romfs' not in segment

microblaze-uclinux-objdump -x software/petalinux-dist/images/image.elf |grep romfs
 32 .romfs        001e6c00  901ab000  901ab000  001a694d  2**0
00000000 l    d  .romfs    00000000
901656b4 l     O .text    00000004 __exitcall_exit_romfs_fs
901a7d34 l       .init.text    00000034 exit_romfs_fs
901a91d4 l     O .initcall.init    00000004 __initcall_init_romfs_fs6
901a2228 l       .init.text    00000084 init_romfs_fs
90188bf4 l     O .data    00000020 romfs_fs_type
900b3c78 l       .text    0000002c romfs_get_sb
90188c14 l     O .data    0000004c romfs_ops
900b3ba8 l       .text    00000038 romfs_alloc_inode
900b3be0 l       .text    00000030 romfs_destroy_inode
900b39a8 l       .text    00000200 romfs_read_inode
900b3008 l       .text    00000064 romfs_statfs
900b3c64 l       .text    00000014 romfs_remount
90177780 l     O .rodata    0000003c romfs_aops
900b37a4 l       .text    00000204 romfs_readpage
901777bc l     O .rodata    0000006c romfs_dir_operations
900b33c0 l       .text    000001d8 romfs_readdir
90188c60 l     O .data    00000054 romfs_dir_inode_operations
900b3598 l       .text    0000020c romfs_lookup
90188cb4 l     O .data    00000020 romfs_modemap
90188cd4 l     O .data    00000008 romfs_dtype_table
900b2e0c l       .text    000001fc romfs_fill_super
900b306c l       .text    000001a8 romfs_strnlen
900b3214 l       .text    000001ac romfs_copyfrom
901ba20c l     O .bss    00000004 romfs_inode_cachep
901ab000 l    d  .romfs    00000000
90000990 g       .text    000000a8 get_romfs_len
90000980 g       .text    00000010 get_romfs_base

Thank you for your help.

Greets,
Oliver
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser


From Dan.Snyder at trilliantinc.com  Tue Oct 27 16:22:10 2009
From: Dan.Snyder at trilliantinc.com (Dan  Snyder)
Date: Tue, 27 Oct 2009 13:22:10 -0700
Subject: [uClinux-dev] XUPV2 PetaLinux "mtd: partition "ROMfs" is out of
	reach"
In-Reply-To: <20091027200749.157640@gmx.net>
Message-ID: <8FBEB8ACDE3D6C4D80DD3E64A9712B4C0483ACD571@Mail1.trilliant.local>

Can you post your kernel .config?

 
-----Original Message-----
From: uclinux-dev-bounces at uclinux.org [mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Oliver Rod
Sent: Tuesday, October 27, 2009 2:08 PM
To: uclinux-dev at uclinux.org
Subject: [uClinux-dev] XUPV2 PetaLinux "mtd: partition "ROMfs" is out of reach"

Hi,

I make my student research project my aim is running petalinux v0.40 on a microblaze XUPV2. My Hardware is running fine, but i have problems with my romfs.I start the board and push the image.elf in my ram and I get this KernelMessage:
Linux version 2.6.20-uc0 (tool at tool) (gcc version 3.4.1 ( PetaLinux 0.20 Build -rc1 050607 )) #8 Thu Oct 22 13:55:38 CEST 2009
setup_cpuinfo: initialising
setup_cpuinfo: No PVR support in CPU.  Using static compile-time info
set_cpuinfo_static: Using static CPU info.
setup_memory: max_mapnr: 0x9ffff
setup_memory: min_low_pfn: 0x90000
setup_memory: max_low_pfn: 0x10000
On node 0 totalpages: 65536
  DMA zone: 512 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 65024 pages, LIFO batch:15
  Normal zone: 0 pages used for memmap
Built 1 zonelists.  Total pages: 65024
Kernel command line: root=/dev/ram console=ttyUL0,38400
OPB INTC #0 at 0x81800000
PID hash table entries: 1024 (order: 10, 4096 bytes)
TIMER at 0x83C00000
disabling early console
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257920k/262144k available
Calibrating delay loop... 49.45 BogoMIPS (lpj=247296)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
uartlite.0: ttyUL0 at MMIO 0x84000000 (irq = 3) is a uartlite
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Microblaze FSL FIFO Driver. John Williams <jwilliams at itee.uq.edu.au>
FSL FIFO[0] initialised
eth0: using fifo mode.
eth0: No PHY detected.  Assuming a PHY at address 0.
eth0: Xilinx EMACLite #0 at 0x81000000 mapped to 0x81000000, irq=2
uclinux[mtd]: RAM probe address=0x901c6238 size=0x0
Creating 1 MTD partitions on "RAM":
0x00000000-0x00000000 : "ROMfs"
mtd: partition "ROMfs" is out of reach -- disabled
uclinux[mtd]: set ROMfs to be root filesystem index=0
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
No filesystem could mount root, tried:  ext3 ext2 cramfs msdos vfat romfs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
 <0>Rebooting in 120 seconds..

So I check if my romfs is in my image.elf

microblaze-uclinux-objcopy --add-section=.romfs=software/petalinux-dist/images/romfs.img --adjust-section-vma=.romfs=0x901ab000 --no-adjust-warnings --set-section-flags=.romfs=alloc,load,data software/petalinux-dist/linux-2.6.x/linux software/petalinux-dist/images/image.elf
BFD: software/petalinux-dist/images/image.elf: warning: allocated section `.romfs' not in segment

microblaze-uclinux-objdump -x software/petalinux-dist/images/image.elf |grep romfs
 32 .romfs        001e6c00  901ab000  901ab000  001a694d  2**0
00000000 l    d  .romfs    00000000
901656b4 l     O .text    00000004 __exitcall_exit_romfs_fs
901a7d34 l       .init.text    00000034 exit_romfs_fs
901a91d4 l     O .initcall.init    00000004 __initcall_init_romfs_fs6
901a2228 l       .init.text    00000084 init_romfs_fs
90188bf4 l     O .data    00000020 romfs_fs_type
900b3c78 l       .text    0000002c romfs_get_sb
90188c14 l     O .data    0000004c romfs_ops
900b3ba8 l       .text    00000038 romfs_alloc_inode
900b3be0 l       .text    00000030 romfs_destroy_inode
900b39a8 l       .text    00000200 romfs_read_inode
900b3008 l       .text    00000064 romfs_statfs
900b3c64 l       .text    00000014 romfs_remount
90177780 l     O .rodata    0000003c romfs_aops
900b37a4 l       .text    00000204 romfs_readpage
901777bc l     O .rodata    0000006c romfs_dir_operations
900b33c0 l       .text    000001d8 romfs_readdir
90188c60 l     O .data    00000054 romfs_dir_inode_operations
900b3598 l       .text    0000020c romfs_lookup
90188cb4 l     O .data    00000020 romfs_modemap
90188cd4 l     O .data    00000008 romfs_dtype_table
900b2e0c l       .text    000001fc romfs_fill_super
900b306c l       .text    000001a8 romfs_strnlen
900b3214 l       .text    000001ac romfs_copyfrom
901ba20c l     O .bss    00000004 romfs_inode_cachep
901ab000 l    d  .romfs    00000000
90000990 g       .text    000000a8 get_romfs_len
90000980 g       .text    00000010 get_romfs_base

Thank you for your help.

Greets,
Oliver
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


From c.baumann at ppc-ag.de  Wed Oct 28 05:13:23 2009
From: c.baumann at ppc-ag.de (Christoph Baumann)
Date: Wed, 28 Oct 2009 10:13:23 +0100
Subject: [uClinux-dev] Problem with OpenSSH_5.2p1
Message-ID: <4AE80B33.4010500@ppc-ag.de>

Hello,

working on getting OpenSSH (5.2p1 + OpenSSL 0.9.8k with uClinux patch)
to run in a uClinux environment I ran into a problem.
The ssh client gets a SIGSEGV when it tries to access environment
variables. So I put a wrapper around getenv which checks the "extern
char **environ" pointer. It showed that it has the value 0x58585858
which is a rather improbable value. As a workaround I let the getenv
wrapper set up a default environment. This works until the ssh client
tries to exit gracefully. On exit it gets a SIGSEGV again.
To check if the environment is messed up in any case, I wrote a simple
program that only dumps the environment variables. This program works
fine. So the cause of the problem lies more in the ssh client.
Has anybody seen similar problems?

Regards
	Christoph Baumann


-- 

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax:   +49(621)40165-???
mailto://c.baumann at ppc-ag.de
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott


THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS
CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK
PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE
INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE
INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE,
DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS
STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL
TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE
ORIGINAL MESSAGE FROM YOUR DATABASE



From allon.stern at argonst.com  Wed Oct 28 09:39:08 2009
From: allon.stern at argonst.com (Allon Stern)
Date: Wed, 28 Oct 2009 09:39:08 -0400
Subject: [uClinux-dev] Problem with OpenSSH_5.2p1
In-Reply-To: <4AE80B33.4010500@ppc-ag.de>
References: <4AE80B33.4010500@ppc-ag.de>
Message-ID: <AC6C223F-5488-4F50-AA63-2F66BE3D9874@argonst.com>


On Oct 28, 2009, at 5:13 AM, Christoph Baumann wrote:

> To check if the environment is messed up in any case, I wrote a simple
> program that only dumps the environment variables. This program works
> fine. So the cause of the problem lies more in the ssh client.
> Has anybody seen similar problems?

What's the stack size of the SSH client?
Remember, the uclinux runtime does not have a dynamic stack size.

Run "<toolchain-prefix>flthdr" on your target FLAT executable to read  
the header.
flthdr -s lets you change the stack size. Try increasing the stack size.

Once you find an appropriate size, you can put it into the compile  
flags.


Your test program probably didn't need much stack, so it succeeded.  
Any time you see improbable values being returned, or crashes on  
exiting, or crashes which show the PC being a weird value, suspect  
stack corruption - remember, functions return values go on the stack,  
as does the return location for function calls. Stack corruption will  
often lead to, as we put it, "return to data".

-
allon


From c.baumann at ppc-ag.de  Wed Oct 28 10:01:11 2009
From: c.baumann at ppc-ag.de (Christoph Baumann)
Date: Wed, 28 Oct 2009 15:01:11 +0100
Subject: [uClinux-dev] Problem with OpenSSH_5.2p1
In-Reply-To: <AC6C223F-5488-4F50-AA63-2F66BE3D9874@argonst.com>
References: <4AE80B33.4010500@ppc-ag.de>
	<AC6C223F-5488-4F50-AA63-2F66BE3D9874@argonst.com>
Message-ID: <4AE84EA7.7080107@ppc-ag.de>

On 28.10.2009 14:39, Allon Stern wrote:
> What's the stack size of the SSH client?
> Remember, the uclinux runtime does not have a dynamic stack size.

currently it's 32k


> Run "<toolchain-prefix>flthdr" on your target FLAT executable to read
> the header.
> flthdr -s lets you change the stack size. Try increasing the stack size.
> 
> Once you find an appropriate size, you can put it into the compile flags.

Are there any "good" known values for ssh?


--
Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax:   +49(621)40165-???
mailto://c.baumann at ppc-ag.de
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott


THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS
CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK
PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE
INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE
INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE,
DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS
STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL
TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE
ORIGINAL MESSAGE FROM YOUR DATABASE



From allon.stern at argonst.com  Wed Oct 28 10:55:59 2009
From: allon.stern at argonst.com (Allon Stern)
Date: Wed, 28 Oct 2009 10:55:59 -0400
Subject: [uClinux-dev] Problem with OpenSSH_5.2p1
In-Reply-To: <4AE84EA7.7080107@ppc-ag.de>
References: <4AE80B33.4010500@ppc-ag.de>
	<AC6C223F-5488-4F50-AA63-2F66BE3D9874@argonst.com>
	<4AE84EA7.7080107@ppc-ag.de>
Message-ID: <F8754F38-719D-4F61-98AE-337663CE18DD@argonst.com>


On Oct 28, 2009, at 10:01 AM, Christoph Baumann wrote:

> On 28.10.2009 14:39, Allon Stern wrote:
>> What's the stack size of the SSH client?
>> Remember, the uclinux runtime does not have a dynamic stack size.
>
> currently it's 32k
>
>
>> Run "<toolchain-prefix>flthdr" on your target FLAT executable to read
>> the header.
>> flthdr -s lets you change the stack size. Try increasing the stack  
>> size.
>>
>> Once you find an appropriate size, you can put it into the compile  
>> flags.
>
> Are there any "good" known values for ssh?
>

Well, stack usage varies according to program structure, as well as  
call structure at runtime, so while static analysis can be a good  
starting point, if there is any recursion, it becomes non-deterministic.

For security critical functions, like OpenSSH, I'd question whether a  
non-mmu system is a good choice, especially without memory protection.

In any case, I'd recommend doubling the stack until you find a value  
that works, then back off by powers of two until it doesn't, then back  
up a couple of steps as a safety margin. Or, depending on how memory- 
rich you are, you can just leave it with a bunch of extra memory. So  
if 64K works, give it 128K of stack, for a good safety margin (which  
is still no guarantee you won't be vulnerable to a stack overflow).


-
allon


From c.baumann at ppc-ag.de  Wed Oct 28 11:15:51 2009
From: c.baumann at ppc-ag.de (Christoph Baumann)
Date: Wed, 28 Oct 2009 16:15:51 +0100
Subject: [uClinux-dev] Problem with OpenSSH_5.2p1
In-Reply-To: <F8754F38-719D-4F61-98AE-337663CE18DD@argonst.com>
References: <4AE80B33.4010500@ppc-ag.de>	<AC6C223F-5488-4F50-AA63-2F66BE3D9874@argonst.com>	<4AE84EA7.7080107@ppc-ag.de>
	<F8754F38-719D-4F61-98AE-337663CE18DD@argonst.com>
Message-ID: <4AE86027.8080306@ppc-ag.de>

On 28.10.2009 15:55, Allon Stern wrote:
> In any case, I'd recommend doubling the stack until you find a value
> that works, then back off by powers of two until it doesn't, then back
> up a couple of steps as a safety margin. Or, depending on how
> memory-rich you are, you can just leave it with a bunch of extra memory.
> So if 64K works, give it 128K of stack, for a good safety margin (which
> is still no guarantee you won't be vulnerable to a stack overflow).

Even with 1M it still shows this phenomenon. Surprisingly sshd works
fine. What makes me also wonder is the fact that the pointer "environ"
hasn't just some random value as I would expect it with a stack
overflow. It always "points" to 0x58585858.
Maybe there is something wrong with the exec() command of my platform
library?


Regards
	Christoph


-- 

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax:   +49(621)40165-???
mailto://c.baumann at ppc-ag.de
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott


THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS
CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK
PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE
INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE
INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE,
DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS
STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL
TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE
ORIGINAL MESSAGE FROM YOUR DATABASE



From JMoore at moreycorp.com  Wed Oct 28 16:13:38 2009
From: JMoore at moreycorp.com (John B Moore)
Date: Wed, 28 Oct 2009 15:13:38 -0500
Subject: [uClinux-dev] m68k g++: reloc outside program
In-Reply-To: <AC6C223F-5488-4F50-AA63-2F66BE3D9874@argonst.com>
Message-ID: <OFC73F3AAA.A8B87C2B-ON8625765D.006C6183-8625765D.006F49B7@moreycorp.com>

We currently have a platform which uses an M5233 nommu Coldfire with 
uClinux using a 2.6.17 kernel with uClibc 0.9.27, bFLT executables and no 
shared library support. The compiler set  we are using is the 4.1.1 
compiler set as distributed from the uclinux.org website and it works well 
for programming in C. Recently we have a need to program in C++ so I have 
been trying to get the g++ compiler to generate a valid executable. The 
compile works fine but when I run, I always get :

BINFMT_FLAT: reloc outside program 0xff9b0d01 (0 - 0x84f54/0x51060), 
killing helloworld!

and a SIGSEGV. The application is simply hello world as follows:

#include <iostream>

int main (int argc, char **argv)
{
    std::cout << "Hello World\n";
    return 0;
}

The compile and link step are as follows:

m68k-elf-g++ -m5307 -DCONFIG_COLDFIRE -I../../include  -g -O0 -pipe 
-fno-common -fno-builtin -Wall -Wno-strict-aliasing -DEMBED -msep-data 
-Dlinux -D__linux__ -Dunix -D__uClinux__    -c -o helloworld.o 
helloworld.C

m68k-elf-g++ -m5307 -DCONFIG_COLDFIRE -I../../include   -g -O0 -pipe 
-fno-common -fno-builtin -Wall -Wno-strict-aliasing -DEMBED -msep-data 
-Dlinux -D__linux__ -Dunix -D__uClinux__  -L../../lib/morey 
-Wl,--fatal-warnings -Wl,-elf2flt -Wl,-move-rodata -msep-data  -lstdc++ -o 
helloworld helloworld.o 
 
It seems that no matter what compile and link options I use the result is 
the same. I have also tried increasing the stack size to as large as 256K 
with no change . I searched around and found many methods  that people 
have used to solve this problem and have tried pretty much every one but 
nothing seems to change the result. Is there possibly an issue in the 
elf2flt conversion that is causing this issue? 

Any ideas on how to eliminate this issue would be appreciated.

John Moore
The Morey Corporation
100 Morey Drive
Woodridge, IL 60517-8135
Email: jmoore at moreycorp.com




This e-mail, including attachments, may contain information that is 
confidential and/or proprietary, and may only be used by the person to 
whom this email is addressed. If the recipient of this e-mail is not the 
intended recipient or an authorized agent, the reader is hereby notified 
that any dissemination, distribution, or copying of this e-mail is 
prohibited. If this e-mail has been delivered to you in error, please 
notify the sender by replying to this message and deleting this e-mail 
immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20091028/5042d8d2/attachment.html>

From wolfgang at iksw-muees.de  Wed Oct 28 17:52:06 2009
From: wolfgang at iksw-muees.de (Wolfgang =?iso-8859-15?q?M=FCes?=)
Date: Wed, 28 Oct 2009 22:52:06 +0100
Subject: [uClinux-dev] m68k g++: reloc outside program
In-Reply-To: <OFC73F3AAA.A8B87C2B-ON8625765D.006C6183-8625765D.006F49B7@moreycorp.com>
References: <OFC73F3AAA.A8B87C2B-ON8625765D.006C6183-8625765D.006F49B7@moreycorp.com>
Message-ID: <200910282252.06586.wolfgang@iksw-muees.de>

John,

Am Mittwoch, 28. Oktober 2009 21:13:38 schrieb John B Moore:
> We currently have a platform which uses an M5233 nommu Coldfire with
> uClinux using a 2.6.17 kernel with uClibc 0.9.27, bFLT executables and no
> shared library support. The compiler set  we are using is the 4.1.1
> compiler set as distributed from the uclinux.org website and it works well
> for programming in C. Recently we have a need to program in C++ so I have
> been trying to get the g++ compiler to generate a valid executable. The
> compile works fine but when I run, I always get :
> 
> BINFMT_FLAT: reloc outside program 0xff9b0d01 (0 - 0x84f54/0x51060),
> killing helloworld!
> 
> and a SIGSEGV. The application is simply hello world as follows:
> 
> #include <iostream>

Oh! iostream! So you need the global constructors to work!

Is your linker including the crtbegin and crtend libs as first and last 
objects in the list of linked files? Check in the ELF file!

regards

Wolfgang
-- 
Wahre Worte sind nicht sch?n. Sch?ne Worte sind nicht wahr.

(Laotse)


From gerg at snapgear.com  Wed Oct 28 20:01:34 2009
From: gerg at snapgear.com (Greg Ungerer)
Date: Thu, 29 Oct 2009 10:01:34 +1000
Subject: [uClinux-dev] m68k g++: reloc outside program
In-Reply-To: <OFC73F3AAA.A8B87C2B-ON8625765D.006C6183-8625765D.006F49B7@moreycorp.com>
References: <OFC73F3AAA.A8B87C2B-ON8625765D.006C6183-8625765D.006F49B7@moreycorp.com>
Message-ID: <4AE8DB5E.2010504@snapgear.com>

Hi John,

John B Moore wrote:
> We currently have a platform which uses an M5233 nommu Coldfire with 
> uClinux using a 2.6.17 kernel with uClibc 0.9.27, bFLT executables and 
> no shared library support. The compiler set  we are using is the 4.1.1 
> compiler set as distributed from the uclinux.org website and it works 
> well for programming in C. Recently we have a need to program in C++ so 
> I have been trying to get the g++ compiler to generate a valid 
> executable. The compile works fine but when I run, I always get :
> 
> BINFMT_FLAT: reloc outside program 0xff9b0d01 (0 - 0x84f54/0x51060), 
> killing helloworld!

I seem to recall a few problems with c++ code generation from that
gcc-4.1.1 based toolchain. I think the answer for most people was
to use the code sourcery toolchains, which seemed to get this right.

Regards
Greg


> and a SIGSEGV. The application is simply hello world as follows:
> 
> #include <iostream>
> 
> int main (int argc, char **argv)
> {
>     std::cout << "Hello World\n";
>     return 0;
> }
> 
> The compile and link step are as follows:
> 
> m68k-elf-g++ -m5307 -DCONFIG_COLDFIRE -I../../include  -g -O0 -pipe 
> -fno-common -fno-builtin -Wall -Wno-strict-aliasing -DEMBED -msep-data 
> -Dlinux -D__linux__ -Dunix -D__uClinux__    -c -o helloworld.o helloworld.C
> 
> m68k-elf-g++ -m5307 -DCONFIG_COLDFIRE -I../../include   -g -O0 -pipe 
> -fno-common -fno-builtin -Wall -Wno-strict-aliasing -DEMBED -msep-data 
> -Dlinux -D__linux__ -Dunix -D__uClinux__  -L../../lib/morey 
>  -Wl,--fatal-warnings -Wl,-elf2flt -Wl,-move-rodata -msep-data  -lstdc++ 
> -o helloworld helloworld.o
>  
> It seems that no matter what compile and link options I use the result 
> is the same. I have also tried increasing the stack size to as large as 
> 256K with no change . I searched around and found many methods  that 
> people have used to solve this problem and have tried pretty much every 
> one but nothing seems to change the result. Is there possibly an issue 
> in the elf2flt conversion that is causing this issue?
> 
> Any ideas on how to eliminate this issue would be appreciated.
> 
> John Moore
> The Morey Corporation
> 100 Morey Drive
> Woodridge, IL 60517-8135
> Email: jmoore at moreycorp.com
> 
> 
> 
> 
> This e-mail, including attachments, may contain information that is 
> confidential and/or proprietary, and may only be used by the person to 
> whom this email is addressed. If the recipient of this e-mail is not the 
> intended recipient or an authorized agent, the reader is hereby notified 
> that any dissemination, distribution, or copying of this e-mail is 
> prohibited. If this e-mail has been delivered to you in error, please 
> notify the sender by replying to this message and deleting this e-mail 
> immediately.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg at 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


From gerg at snapgear.com  Thu Oct 29 20:40:34 2009
From: gerg at snapgear.com (Greg Ungerer)
Date: Fri, 30 Oct 2009 10:40:34 +1000
Subject: [uClinux-dev] Re: [PATCH] Coldfire GPIO corrections
In-Reply-To: <200910151254.41599.sfking@fdwdc.com>
References: <200910151254.41599.sfking@fdwdc.com>
Message-ID: <4AEA3602.1060105@snapgear.com>

Hi Steven,

Steven King wrote:
> Pin 0 of the EPORT is not connected on the 523x, 5271, 5275 and 528x and the 
> TIMER on the 523x has 8 pins, not 4.

Thanks, I have pushed this into the for-linus branch of

  git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git

Thanks
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg at 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


From Olov at gmx.de  Fri Oct 30 07:31:35 2009
From: Olov at gmx.de (Oliver Rod)
Date: Fri, 30 Oct 2009 12:31:35 +0100
Subject: [uClinux-dev] XUPV2 PetaLinux "mtd: partition "ROMfs" is out
	of	reach"
In-Reply-To: <8FBEB8ACDE3D6C4D80DD3E64A9712B4C0483ACD571@Mail1.trilliant.local>
References: <8FBEB8ACDE3D6C4D80DD3E64A9712B4C0483ACD571@Mail1.trilliant.local>
Message-ID: <20091030113135.176550@gmx.net>


Of course, thanks for your help

Greets,
Oliver

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20-uc0
#
CONFIG_MICROBLAZE=y
# CONFIG_SWAP is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME is not set
CONFIG_UID16=y
CONFIG_DEFCONFIG_LIST="arch/$ARCH/defconfig"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_SYSCTL_SYSCALL=y
# CONFIG_KALLSYMS is not set
# CONFIG_HOTPLUG is not set
CONFIG_PRINTK=y
# CONFIG_BUG is not set
CONFIG_ELF_CORE=y
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
# CONFIG_EPOLL is not set
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_TINY_SHMEM=y
CONFIG_BASE_SMALL=1
# CONFIG_SLOB is not set

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Platform options
#
# CONFIG_PCI is not set
CONFIG_PLATFORM_XILINX_XILINX_XUP_V2PRO=y
# CONFIG_PLATFORM_MORPHOLOGIC_MPL3E_REVB_LITE_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_S3DSP1800A_REV1_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_S3DSP1800A_REV1_MMU_EDK111 is not set
# CONFIG_PLATFORM_XILINX_S3DSP1800A_REV1_EDK101 is not set
# CONFIG_PLATFORM_XILINX_S3DSP1800A_REV1_EDK111 is not set
# CONFIG_PLATFORM_XILINX_ML401_LL_TEMAC_SGDMA_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_ML401_LL_TEMAC_SGDMA_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_REVD_LITE_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_REVC_LITE_EDK101 is not set
# CONFIG_PLATFORM_XILINX_ML505_LL_TEMAC_SGDMA_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_REVA_LITE_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_REVA_LITE_EDK101 is not set
# CONFIG_PLATFORM_XILINX_ML505_LL_TEMAC_SGDMA_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_MMU is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_MMU is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_REVD is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_REVA_SGDMA is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_REVA is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_REVC is not set
# CONFIG_PLATFORM_MICROBLAZE_AUTO is not set
# CONFIG_ALLOW_EDIT_AUTO is not set
CONFIG_PROJECT_NAME="XUP-V2Pro"
CONFIG_UARTLITE=1
CONFIG_STDINOUT_BASEADDR=0x84000000
CONFIG_XILINX_ERAM_START=0x90000000
CONFIG_XILINX_ERAM_SIZE=0x10000000
CONFIG_XILINX_LMB_START=0x00000000
CONFIG_XILINX_LMB_SIZE=0x00002000
CONFIG_XILINX_CPU_CLOCK_FREQ=100000000
CONFIG_XILINX_MICROBLAZE0_INSTANCE="microblaze_0"
CONFIG_XILINX_MICROBLAZE0_SCO=0
CONFIG_XILINX_MICROBLAZE0_DATA_SIZE=32
CONFIG_XILINX_MICROBLAZE0_DYNAMIC_BUS_SIZING=1
CONFIG_XILINX_MICROBLAZE0_FAMILY="virtex2p"
CONFIG_XILINX_MICROBLAZE0_AREA_OPTIMIZED=0
CONFIG_XILINX_MICROBLAZE0_INTERCONNECT=1
CONFIG_XILINX_MICROBLAZE0_DPLB_DWIDTH=64
CONFIG_XILINX_MICROBLAZE0_DPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_MICROBLAZE0_DPLB_BURST_EN=0
CONFIG_XILINX_MICROBLAZE0_DPLB_P2P=0
CONFIG_XILINX_MICROBLAZE0_IPLB_DWIDTH=64
CONFIG_XILINX_MICROBLAZE0_IPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_MICROBLAZE0_IPLB_BURST_EN=0
CONFIG_XILINX_MICROBLAZE0_IPLB_P2P=0
CONFIG_XILINX_MICROBLAZE0_D_PLB=1
CONFIG_XILINX_MICROBLAZE0_D_OPB=0
CONFIG_XILINX_MICROBLAZE0_D_LMB=1
CONFIG_XILINX_MICROBLAZE0_I_PLB=1
CONFIG_XILINX_MICROBLAZE0_I_OPB=0
CONFIG_XILINX_MICROBLAZE0_I_LMB=1
CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_BARREL=0
CONFIG_XILINX_MICROBLAZE0_USE_DIV=0
CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL=1
CONFIG_XILINX_MICROBLAZE0_USE_FPU=0
CONFIG_XILINX_MICROBLAZE0_UNALIGNED_EXCEPTIONS=0
CONFIG_XILINX_MICROBLAZE0_ILL_OPCODE_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_IOPB_BUS_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_DOPB_BUS_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_IPLB_BUS_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_DPLB_BUS_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_DIV_ZERO_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_FPU_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_FSL_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_PVR=0
CONFIG_XILINX_MICROBLAZE0_PVR_USER1=0x00000000
CONFIG_XILINX_MICROBLAZE0_PVR_USER2=0x00000000
CONFIG_XILINX_MICROBLAZE0_DEBUG_ENABLED=1
CONFIG_XILINX_MICROBLAZE0_NUMBER_OF_PC_BRK=1
CONFIG_XILINX_MICROBLAZE0_NUMBER_OF_RD_ADDR_BRK=0
CONFIG_XILINX_MICROBLAZE0_NUMBER_OF_WR_ADDR_BRK=0
CONFIG_XILINX_MICROBLAZE0_INTERRUPT_IS_EDGE=0
CONFIG_XILINX_MICROBLAZE0_EDGE_IS_POSITIVE=1
CONFIG_XILINX_MICROBLAZE0_RESET_MSR=0x00000000
CONFIG_XILINX_MICROBLAZE0_OPCODE_0X0_ILLEGAL=0
CONFIG_XILINX_MICROBLAZE0_FSL_LINKS=1
CONFIG_XILINX_MICROBLAZE0_FSL_DATA_SIZE=32
CONFIG_XILINX_MICROBLAZE0_USE_EXTENDED_FSL_INSTR=0
CONFIG_XILINX_MICROBLAZE0_ICACHE_BASEADDR=0x90000000
CONFIG_XILINX_MICROBLAZE0_ICACHE_HIGHADDR=0x9FFFFFFF
CONFIG_XILINX_MICROBLAZE0_USE_ICACHE=1
CONFIG_XILINX_MICROBLAZE0_ALLOW_ICACHE_WR=1
CONFIG_XILINX_MICROBLAZE0_ADDR_TAG_BITS=15
CONFIG_XILINX_MICROBLAZE0_CACHE_BYTE_SIZE=8192
CONFIG_XILINX_MICROBLAZE0_ICACHE_USE_FSL=1
CONFIG_XILINX_MICROBLAZE0_ICACHE_LINE_LEN=4
CONFIG_XILINX_MICROBLAZE0_ICACHE_ALWAYS_USED=0
CONFIG_XILINX_MICROBLAZE0_DCACHE_BASEADDR=0x90000000
CONFIG_XILINX_MICROBLAZE0_DCACHE_HIGHADDR=0x9FFFFFFF
CONFIG_XILINX_MICROBLAZE0_USE_DCACHE=1
CONFIG_XILINX_MICROBLAZE0_ALLOW_DCACHE_WR=1
CONFIG_XILINX_MICROBLAZE0_DCACHE_ADDR_TAG=15
CONFIG_XILINX_MICROBLAZE0_DCACHE_BYTE_SIZE=8192
CONFIG_XILINX_MICROBLAZE0_DCACHE_USE_FSL=1
CONFIG_XILINX_MICROBLAZE0_DCACHE_LINE_LEN=4
CONFIG_XILINX_MICROBLAZE0_DCACHE_ALWAYS_USED=0
CONFIG_XILINX_MICROBLAZE0_USE_MMU=0
CONFIG_XILINX_MICROBLAZE0_MMU_DTLB_SIZE=4
CONFIG_XILINX_MICROBLAZE0_MMU_ITLB_SIZE=2
CONFIG_XILINX_MICROBLAZE0_MMU_TLB_ACCESS=3
CONFIG_XILINX_MICROBLAZE0_MMU_ZONES=16
CONFIG_XILINX_MICROBLAZE0_USE_INTERRUPT=1
CONFIG_XILINX_MICROBLAZE0_USE_EXT_BRK=1
CONFIG_XILINX_MICROBLAZE0_USE_EXT_NM_BRK=1
CONFIG_XILINX_MICROBLAZE0_HW_VER="7.10.d"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_INSTANCE="dlmb_cntlr"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_BASEADDR=0x00000000
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_HIGHADDR=0x00001FFF
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_MASK=0x80000000
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_LMB_AWIDTH=32
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_LMB_DWIDTH=32
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_HW_VER="2.10.a"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_INSTANCE="ilmb_cntlr"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_BASEADDR=0x00000000
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_HIGHADDR=0x00001FFF
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_MASK=0x80000000
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_LMB_AWIDTH=32
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_LMB_DWIDTH=32
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_HW_VER="2.10.a"
CONFIG_XILINX_UARTLITE_0_INSTANCE="RS232_Uart_1"
CONFIG_XILINX_UARTLITE_0_FAMILY="virtex2p"
CONFIG_XILINX_UARTLITE_0_SPLB_CLK_FREQ_HZ=100000000
CONFIG_XILINX_UARTLITE_0_BASEADDR=0x84000000
CONFIG_XILINX_UARTLITE_0_HIGHADDR=0x8400FFFF
CONFIG_XILINX_UARTLITE_0_SPLB_AWIDTH=32
CONFIG_XILINX_UARTLITE_0_SPLB_DWIDTH=64
CONFIG_XILINX_UARTLITE_0_SPLB_P2P=0
CONFIG_XILINX_UARTLITE_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_UARTLITE_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_UARTLITE_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_UARTLITE_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_UARTLITE_0_BAUDRATE=38400
CONFIG_XILINX_UARTLITE_0_DATA_BITS=8
CONFIG_XILINX_UARTLITE_0_USE_PARITY=0
CONFIG_XILINX_UARTLITE_0_ODD_PARITY=0
CONFIG_XILINX_UARTLITE_0_HW_VER="1.00.a"
CONFIG_XILINX_UARTLITE_0_IRQ=3
CONFIG_XILINX_MDM_0_INSTANCE="debug_module"
CONFIG_XILINX_MDM_0_FAMILY="virtex2p"
CONFIG_XILINX_MDM_0_JTAG_CHAIN=2
CONFIG_XILINX_MDM_0_INTERCONNECT=1
CONFIG_XILINX_MDM_0_BASEADDR=0x84400000
CONFIG_XILINX_MDM_0_HIGHADDR=0x8440FFFF
CONFIG_XILINX_MDM_0_SPLB_AWIDTH=32
CONFIG_XILINX_MDM_0_SPLB_DWIDTH=64
CONFIG_XILINX_MDM_0_SPLB_P2P=0
CONFIG_XILINX_MDM_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_MDM_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_MDM_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_MDM_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_MDM_0_OPB_DWIDTH=32
CONFIG_XILINX_MDM_0_OPB_AWIDTH=32
CONFIG_XILINX_MDM_0_MB_DBG_PORTS=1
CONFIG_XILINX_MDM_0_USE_UART=1
CONFIG_XILINX_MDM_0_UART_WIDTH=8
CONFIG_XILINX_MDM_0_WRITE_FSL_PORTS=0
CONFIG_XILINX_MDM_0_HW_VER="1.00.d"
CONFIG_XILINX_ETHERNETLITE_0_INSTANCE="Ethernet_MAC"
CONFIG_XILINX_ETHERNETLITE_0_FAMILY="virtex2p"
CONFIG_XILINX_ETHERNETLITE_0_BASEADDR=0x81000000
CONFIG_XILINX_ETHERNETLITE_0_HIGHADDR=0x8100FFFF
CONFIG_XILINX_ETHERNETLITE_0_SPLB_CLK_PERIOD_PS=10000
CONFIG_XILINX_ETHERNETLITE_0_SPLB_AWIDTH=32
CONFIG_XILINX_ETHERNETLITE_0_SPLB_DWIDTH=64
CONFIG_XILINX_ETHERNETLITE_0_SPLB_P2P=0
CONFIG_XILINX_ETHERNETLITE_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_ETHERNETLITE_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_ETHERNETLITE_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_ETHERNETLITE_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_ETHERNETLITE_0_DUPLEX=1
CONFIG_XILINX_ETHERNETLITE_0_TX_PING_PONG=1
CONFIG_XILINX_ETHERNETLITE_0_RX_PING_PONG=1
CONFIG_XILINX_ETHERNETLITE_0_HW_VER="2.00.b"
CONFIG_XILINX_ETHERNETLITE_0_IRQ=2
CONFIG_XILINX_TIMER_0_INSTANCE="xps_timer_1"
CONFIG_XILINX_TIMER_0_FAMILY="virtex2p"
CONFIG_XILINX_TIMER_0_COUNT_WIDTH=32
CONFIG_XILINX_TIMER_0_ONE_TIMER_ONLY=0
CONFIG_XILINX_TIMER_0_TRIG0_ASSERT=1
CONFIG_XILINX_TIMER_0_TRIG1_ASSERT=1
CONFIG_XILINX_TIMER_0_GEN0_ASSERT=1
CONFIG_XILINX_TIMER_0_GEN1_ASSERT=1
CONFIG_XILINX_TIMER_0_BASEADDR=0x83C00000
CONFIG_XILINX_TIMER_0_HIGHADDR=0x83C0FFFF
CONFIG_XILINX_TIMER_0_SPLB_AWIDTH=32
CONFIG_XILINX_TIMER_0_SPLB_DWIDTH=64
CONFIG_XILINX_TIMER_0_SPLB_P2P=0
CONFIG_XILINX_TIMER_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_TIMER_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_TIMER_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_TIMER_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_TIMER_0_HW_VER="1.00.a"
CONFIG_XILINX_TIMER_0_IRQ=0
CONFIG_XILINX_INTC_0_INSTANCE="xps_intc_0"
CONFIG_XILINX_INTC_0_FAMILY="virtex2p"
CONFIG_XILINX_INTC_0_BASEADDR=0x81800000
CONFIG_XILINX_INTC_0_HIGHADDR=0x8180FFFF
CONFIG_XILINX_INTC_0_SPLB_AWIDTH=32
CONFIG_XILINX_INTC_0_SPLB_DWIDTH=64
CONFIG_XILINX_INTC_0_SPLB_P2P=0
CONFIG_XILINX_INTC_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_INTC_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_INTC_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_INTC_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_INTC_0_NUM_INTR_INPUTS=4
CONFIG_XILINX_INTC_0_KIND_OF_INTR=0x0000000C
CONFIG_XILINX_INTC_0_KIND_OF_EDGE=0x0000000C
CONFIG_XILINX_INTC_0_KIND_OF_LVL=0x00000003
CONFIG_XILINX_INTC_0_HAS_IPR=1
CONFIG_XILINX_INTC_0_HAS_SIE=1
CONFIG_XILINX_INTC_0_HAS_CIE=1
CONFIG_XILINX_INTC_0_HAS_IVR=1
CONFIG_XILINX_INTC_0_IRQ_ACTIVE=1
CONFIG_XILINX_INTC_0_HW_VER="1.00.a"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_NUM_INSTANCES=2
CONFIG_XILINX_TIMER_NUM_INSTANCES=1
CONFIG_XILINX_MPMC_NUM_INSTANCES=1
CONFIG_XILINX_ETHERNETLITE_NUM_INSTANCES=1
CONFIG_XILINX_INTC_NUM_INSTANCES=1
CONFIG_XILINX_MDM_NUM_INSTANCES=1
CONFIG_XILINX_UARTLITE_NUM_INSTANCES=1

#
# Processor type and features
#
# CONFIG_MMU is not set
CONFIG_NO_MMU=y
# CONFIG_PREEMPT is not set
# CONFIG_XILINX_UNCACHED_SHADOW is not set
CONFIG_LARGE_ALLOCS=y
# CONFIG_USE_BRAM is not set
# CONFIG_OPT_LIB_FUNCTION is not set

#
# Boot options
#
CONFIG_CMDLINE="root=/dev/ram console=ttyUL0,38400"
CONFIG_CMDLINE_FORCE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set

#
# Exectuable file formats
#
CONFIG_BINFMT_FLAT=y
# CONFIG_BINFMT_ZFLAT is not set
# CONFIG_BINFMT_SHARED_FLAT is not set
# CONFIG_BINFMT_MISC is not set

#
# Advanced setup
#

#
# Default settings for advanced configuration options are used
#

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_IPSEC_NAT_TRAVERSAL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_EPCS is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0x0
CONFIG_MTD_PHYSMAP_LEN=0x0
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
# CONFIG_MTD_SNAPARM is not set
CONFIG_MTD_UCLINUX=y
CONFIG_MTD_UCLINUX_EBSS=y
# CONFIG_MTD_SNAPGEARuC is not set
# CONFIG_MTD_M520x is not set
# CONFIG_MTD_PLATRAM is not set
# CONFIG_MTD_AVNET5282 is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set

#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_XILINX_SYSACE=y

#
# Misc devices
#
# CONFIG_TIFM_CORE is not set
CONFIG_MICROBLAZE_FSLFIFO=y

#
# FSL Channel Selection
#
CONFIG_MICROBLAZE_FSLFIFO0=y
# CONFIG_MICROBLAZE_FSLFIFO1 is not set
# CONFIG_MICROBLAZE_FSLFIFO2 is not set
# CONFIG_MICROBLAZE_FSLFIFO3 is not set
# CONFIG_MICROBLAZE_FSLFIFO4 is not set
# CONFIG_MICROBLAZE_FSLFIFO5 is not set
# CONFIG_MICROBLAZE_FSLFIFO6 is not set
# CONFIG_MICROBLAZE_FSLFIFO7 is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_NETLINK is not set

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
# CONFIG_ATA is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# I2O device support
#

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# PHY device support
#

#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set
# CONFIG_OPEN_ETH is not set
# CONFIG_MTIP1000_ETH is not set
# CONFIG_NE2000 is not set
# CONFIG_XILINX_EMAC is not set
CONFIG_XILINX_EMACLITE=y

#
# Ethernet (1000 Mbit)
#
# CONFIG_XILINX_LLTEMAC is not set

#
# Ethernet (10000 Mbit)
#

#
# Token Ring devices
#

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
# CONFIG_INPUT is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_LEDMAN is not set
# CONFIG_SNAPDOG is not set
# CONFIG_FAST_TIMER is not set
# CONFIG_RESETSWITCH is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_UARTLITE=y
CONFIG_SERIAL_UARTLITE_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_XILINX_SPI is not set
CONFIG_XILINX_GPIO=y
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_M41T11M6 is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB_ARCH_HAS_HCD is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#

#
# Virtualization
#
CONFIG_XILINX_EDK=y

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_DNOTIFY is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_DIRECTIO=y

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Distributed Lock Manager
#
# CONFIG_DLM is not set

#
# Debug
#
# CONFIG_COREDUMP_PRINTK is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_UARTLITE_ADDRESS=0x00000000

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC32 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_IOMAP_COPY=y


-------- Original-Nachricht --------
> Datum: Tue, 27 Oct 2009 13:22:10 -0700
> Von: "Dan  Snyder" <Dan.Snyder at trilliantinc.com>
> An: uClinux development list <uclinux-dev at uclinux.org>
> Betreff: RE: [uClinux-dev] XUPV2 PetaLinux "mtd: partition "ROMfs" is out of	reach"

> Can you post your kernel .config?
> 
>  
> -----Original Message-----
> From: uclinux-dev-bounces at uclinux.org
> [mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Oliver Rod
> Sent: Tuesday, October 27, 2009 2:08 PM
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] XUPV2 PetaLinux "mtd: partition "ROMfs" is out of
> reach"
> 
> Hi,
> 
> I make my student research project my aim is running petalinux v0.40 on a
> microblaze XUPV2. My Hardware is running fine, but i have problems with my
> romfs.I start the board and push the image.elf in my ram and I get this
> KernelMessage:
> Linux version 2.6.20-uc0 (tool at tool) (gcc version 3.4.1 ( PetaLinux 0.20
> Build -rc1 050607 )) #8 Thu Oct 22 13:55:38 CEST 2009
> setup_cpuinfo: initialising
> setup_cpuinfo: No PVR support in CPU.  Using static compile-time info
> set_cpuinfo_static: Using static CPU info.
> setup_memory: max_mapnr: 0x9ffff
> setup_memory: min_low_pfn: 0x90000
> setup_memory: max_low_pfn: 0x10000
> On node 0 totalpages: 65536
>   DMA zone: 512 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 65024 pages, LIFO batch:15
>   Normal zone: 0 pages used for memmap
> Built 1 zonelists.  Total pages: 65024
> Kernel command line: root=/dev/ram console=ttyUL0,38400
> OPB INTC #0 at 0x81800000
> PID hash table entries: 1024 (order: 10, 4096 bytes)
> TIMER at 0x83C00000
> disabling early console
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 257920k/262144k available
> Calibrating delay loop... 49.45 BogoMIPS (lpj=247296)
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 8192 bind 4096)
> TCP reno registered
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> uartlite.0: ttyUL0 at MMIO 0x84000000 (irq = 3) is a uartlite
> RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
> Microblaze FSL FIFO Driver. John Williams <jwilliams at itee.uq.edu.au>
> FSL FIFO[0] initialised
> eth0: using fifo mode.
> eth0: No PHY detected.  Assuming a PHY at address 0.
> eth0: Xilinx EMACLite #0 at 0x81000000 mapped to 0x81000000, irq=2
> uclinux[mtd]: RAM probe address=0x901c6238 size=0x0
> Creating 1 MTD partitions on "RAM":
> 0x00000000-0x00000000 : "ROMfs"
> mtd: partition "ROMfs" is out of reach -- disabled
> uclinux[mtd]: set ROMfs to be root filesystem index=0
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> No filesystem could mount root, tried:  ext3 ext2 cramfs msdos vfat romfs
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(1,0)
>  <0>Rebooting in 120 seconds..
> 
> So I check if my romfs is in my image.elf
> 
> microblaze-uclinux-objcopy
> --add-section=.romfs=software/petalinux-dist/images/romfs.img --adjust-section-vma=.romfs=0x901ab000 --no-adjust-warnings
> --set-section-flags=.romfs=alloc,load,data
> software/petalinux-dist/linux-2.6.x/linux software/petalinux-dist/images/image.elf
> BFD: software/petalinux-dist/images/image.elf: warning: allocated section
> `.romfs' not in segment
> 
> microblaze-uclinux-objdump -x software/petalinux-dist/images/image.elf
> |grep romfs
>  32 .romfs        001e6c00  901ab000  901ab000  001a694d  2**0
> 00000000 l    d  .romfs    00000000
> 901656b4 l     O .text    00000004 __exitcall_exit_romfs_fs
> 901a7d34 l       .init.text    00000034 exit_romfs_fs
> 901a91d4 l     O .initcall.init    00000004 __initcall_init_romfs_fs6
> 901a2228 l       .init.text    00000084 init_romfs_fs
> 90188bf4 l     O .data    00000020 romfs_fs_type
> 900b3c78 l       .text    0000002c romfs_get_sb
> 90188c14 l     O .data    0000004c romfs_ops
> 900b3ba8 l       .text    00000038 romfs_alloc_inode
> 900b3be0 l       .text    00000030 romfs_destroy_inode
> 900b39a8 l       .text    00000200 romfs_read_inode
> 900b3008 l       .text    00000064 romfs_statfs
> 900b3c64 l       .text    00000014 romfs_remount
> 90177780 l     O .rodata    0000003c romfs_aops
> 900b37a4 l       .text    00000204 romfs_readpage
> 901777bc l     O .rodata    0000006c romfs_dir_operations
> 900b33c0 l       .text    000001d8 romfs_readdir
> 90188c60 l     O .data    00000054 romfs_dir_inode_operations
> 900b3598 l       .text    0000020c romfs_lookup
> 90188cb4 l     O .data    00000020 romfs_modemap
> 90188cd4 l     O .data    00000008 romfs_dtype_table
> 900b2e0c l       .text    000001fc romfs_fill_super
> 900b306c l       .text    000001a8 romfs_strnlen
> 900b3214 l       .text    000001ac romfs_copyfrom
> 901ba20c l     O .bss    00000004 romfs_inode_cachep
> 901ab000 l    d  .romfs    00000000
> 90000990 g       .text    000000a8 get_romfs_len
> 90000980 g       .text    00000010 get_romfs_base
> 
> Thank you for your help.
> 
> Greets,
> Oliver

> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser


From Olov at gmx.de  Fri Oct 30 07:31:35 2009
From: Olov at gmx.de (Oliver Rod)
Date: Fri, 30 Oct 2009 12:31:35 +0100
Subject: [uClinux-dev] XUPV2 PetaLinux "mtd: partition "ROMfs" is out
	of	reach"
In-Reply-To: <8FBEB8ACDE3D6C4D80DD3E64A9712B4C0483ACD571@Mail1.trilliant.local>
References: <8FBEB8ACDE3D6C4D80DD3E64A9712B4C0483ACD571@Mail1.trilliant.local>
Message-ID: <20091030113135.176550@gmx.net>


Of course, thanks for your help

Greets,
Oliver

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20-uc0
#
CONFIG_MICROBLAZE=y
# CONFIG_SWAP is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME is not set
CONFIG_UID16=y
CONFIG_DEFCONFIG_LIST="arch/$ARCH/defconfig"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_SYSCTL_SYSCALL=y
# CONFIG_KALLSYMS is not set
# CONFIG_HOTPLUG is not set
CONFIG_PRINTK=y
# CONFIG_BUG is not set
CONFIG_ELF_CORE=y
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
# CONFIG_EPOLL is not set
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_TINY_SHMEM=y
CONFIG_BASE_SMALL=1
# CONFIG_SLOB is not set

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Platform options
#
# CONFIG_PCI is not set
CONFIG_PLATFORM_XILINX_XILINX_XUP_V2PRO=y
# CONFIG_PLATFORM_MORPHOLOGIC_MPL3E_REVB_LITE_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_S3DSP1800A_REV1_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_S3DSP1800A_REV1_MMU_EDK111 is not set
# CONFIG_PLATFORM_XILINX_S3DSP1800A_REV1_EDK101 is not set
# CONFIG_PLATFORM_XILINX_S3DSP1800A_REV1_EDK111 is not set
# CONFIG_PLATFORM_XILINX_ML401_LL_TEMAC_SGDMA_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_ML401_LL_TEMAC_SGDMA_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_REVD_LITE_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_REVC_LITE_EDK101 is not set
# CONFIG_PLATFORM_XILINX_ML505_LL_TEMAC_SGDMA_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_REVA_LITE_MMU_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_REVA_LITE_EDK101 is not set
# CONFIG_PLATFORM_XILINX_ML505_LL_TEMAC_SGDMA_EDK101 is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_MMU is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_MMU is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_REVD is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_REVA_SGDMA is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E1600_REVA is not set
# CONFIG_PLATFORM_XILINX_SPARTAN3E500_REVC is not set
# CONFIG_PLATFORM_MICROBLAZE_AUTO is not set
# CONFIG_ALLOW_EDIT_AUTO is not set
CONFIG_PROJECT_NAME="XUP-V2Pro"
CONFIG_UARTLITE=1
CONFIG_STDINOUT_BASEADDR=0x84000000
CONFIG_XILINX_ERAM_START=0x90000000
CONFIG_XILINX_ERAM_SIZE=0x10000000
CONFIG_XILINX_LMB_START=0x00000000
CONFIG_XILINX_LMB_SIZE=0x00002000
CONFIG_XILINX_CPU_CLOCK_FREQ=100000000
CONFIG_XILINX_MICROBLAZE0_INSTANCE="microblaze_0"
CONFIG_XILINX_MICROBLAZE0_SCO=0
CONFIG_XILINX_MICROBLAZE0_DATA_SIZE=32
CONFIG_XILINX_MICROBLAZE0_DYNAMIC_BUS_SIZING=1
CONFIG_XILINX_MICROBLAZE0_FAMILY="virtex2p"
CONFIG_XILINX_MICROBLAZE0_AREA_OPTIMIZED=0
CONFIG_XILINX_MICROBLAZE0_INTERCONNECT=1
CONFIG_XILINX_MICROBLAZE0_DPLB_DWIDTH=64
CONFIG_XILINX_MICROBLAZE0_DPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_MICROBLAZE0_DPLB_BURST_EN=0
CONFIG_XILINX_MICROBLAZE0_DPLB_P2P=0
CONFIG_XILINX_MICROBLAZE0_IPLB_DWIDTH=64
CONFIG_XILINX_MICROBLAZE0_IPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_MICROBLAZE0_IPLB_BURST_EN=0
CONFIG_XILINX_MICROBLAZE0_IPLB_P2P=0
CONFIG_XILINX_MICROBLAZE0_D_PLB=1
CONFIG_XILINX_MICROBLAZE0_D_OPB=0
CONFIG_XILINX_MICROBLAZE0_D_LMB=1
CONFIG_XILINX_MICROBLAZE0_I_PLB=1
CONFIG_XILINX_MICROBLAZE0_I_OPB=0
CONFIG_XILINX_MICROBLAZE0_I_LMB=1
CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_BARREL=0
CONFIG_XILINX_MICROBLAZE0_USE_DIV=0
CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL=1
CONFIG_XILINX_MICROBLAZE0_USE_FPU=0
CONFIG_XILINX_MICROBLAZE0_UNALIGNED_EXCEPTIONS=0
CONFIG_XILINX_MICROBLAZE0_ILL_OPCODE_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_IOPB_BUS_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_DOPB_BUS_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_IPLB_BUS_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_DPLB_BUS_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_DIV_ZERO_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_FPU_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_FSL_EXCEPTION=0
CONFIG_XILINX_MICROBLAZE0_PVR=0
CONFIG_XILINX_MICROBLAZE0_PVR_USER1=0x00000000
CONFIG_XILINX_MICROBLAZE0_PVR_USER2=0x00000000
CONFIG_XILINX_MICROBLAZE0_DEBUG_ENABLED=1
CONFIG_XILINX_MICROBLAZE0_NUMBER_OF_PC_BRK=1
CONFIG_XILINX_MICROBLAZE0_NUMBER_OF_RD_ADDR_BRK=0
CONFIG_XILINX_MICROBLAZE0_NUMBER_OF_WR_ADDR_BRK=0
CONFIG_XILINX_MICROBLAZE0_INTERRUPT_IS_EDGE=0
CONFIG_XILINX_MICROBLAZE0_EDGE_IS_POSITIVE=1
CONFIG_XILINX_MICROBLAZE0_RESET_MSR=0x00000000
CONFIG_XILINX_MICROBLAZE0_OPCODE_0X0_ILLEGAL=0
CONFIG_XILINX_MICROBLAZE0_FSL_LINKS=1
CONFIG_XILINX_MICROBLAZE0_FSL_DATA_SIZE=32
CONFIG_XILINX_MICROBLAZE0_USE_EXTENDED_FSL_INSTR=0
CONFIG_XILINX_MICROBLAZE0_ICACHE_BASEADDR=0x90000000
CONFIG_XILINX_MICROBLAZE0_ICACHE_HIGHADDR=0x9FFFFFFF
CONFIG_XILINX_MICROBLAZE0_USE_ICACHE=1
CONFIG_XILINX_MICROBLAZE0_ALLOW_ICACHE_WR=1
CONFIG_XILINX_MICROBLAZE0_ADDR_TAG_BITS=15
CONFIG_XILINX_MICROBLAZE0_CACHE_BYTE_SIZE=8192
CONFIG_XILINX_MICROBLAZE0_ICACHE_USE_FSL=1
CONFIG_XILINX_MICROBLAZE0_ICACHE_LINE_LEN=4
CONFIG_XILINX_MICROBLAZE0_ICACHE_ALWAYS_USED=0
CONFIG_XILINX_MICROBLAZE0_DCACHE_BASEADDR=0x90000000
CONFIG_XILINX_MICROBLAZE0_DCACHE_HIGHADDR=0x9FFFFFFF
CONFIG_XILINX_MICROBLAZE0_USE_DCACHE=1
CONFIG_XILINX_MICROBLAZE0_ALLOW_DCACHE_WR=1
CONFIG_XILINX_MICROBLAZE0_DCACHE_ADDR_TAG=15
CONFIG_XILINX_MICROBLAZE0_DCACHE_BYTE_SIZE=8192
CONFIG_XILINX_MICROBLAZE0_DCACHE_USE_FSL=1
CONFIG_XILINX_MICROBLAZE0_DCACHE_LINE_LEN=4
CONFIG_XILINX_MICROBLAZE0_DCACHE_ALWAYS_USED=0
CONFIG_XILINX_MICROBLAZE0_USE_MMU=0
CONFIG_XILINX_MICROBLAZE0_MMU_DTLB_SIZE=4
CONFIG_XILINX_MICROBLAZE0_MMU_ITLB_SIZE=2
CONFIG_XILINX_MICROBLAZE0_MMU_TLB_ACCESS=3
CONFIG_XILINX_MICROBLAZE0_MMU_ZONES=16
CONFIG_XILINX_MICROBLAZE0_USE_INTERRUPT=1
CONFIG_XILINX_MICROBLAZE0_USE_EXT_BRK=1
CONFIG_XILINX_MICROBLAZE0_USE_EXT_NM_BRK=1
CONFIG_XILINX_MICROBLAZE0_HW_VER="7.10.d"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_INSTANCE="dlmb_cntlr"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_BASEADDR=0x00000000
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_HIGHADDR=0x00001FFF
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_MASK=0x80000000
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_LMB_AWIDTH=32
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_LMB_DWIDTH=32
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_0_HW_VER="2.10.a"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_INSTANCE="ilmb_cntlr"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_BASEADDR=0x00000000
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_HIGHADDR=0x00001FFF
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_MASK=0x80000000
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_LMB_AWIDTH=32
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_LMB_DWIDTH=32
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_1_HW_VER="2.10.a"
CONFIG_XILINX_UARTLITE_0_INSTANCE="RS232_Uart_1"
CONFIG_XILINX_UARTLITE_0_FAMILY="virtex2p"
CONFIG_XILINX_UARTLITE_0_SPLB_CLK_FREQ_HZ=100000000
CONFIG_XILINX_UARTLITE_0_BASEADDR=0x84000000
CONFIG_XILINX_UARTLITE_0_HIGHADDR=0x8400FFFF
CONFIG_XILINX_UARTLITE_0_SPLB_AWIDTH=32
CONFIG_XILINX_UARTLITE_0_SPLB_DWIDTH=64
CONFIG_XILINX_UARTLITE_0_SPLB_P2P=0
CONFIG_XILINX_UARTLITE_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_UARTLITE_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_UARTLITE_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_UARTLITE_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_UARTLITE_0_BAUDRATE=38400
CONFIG_XILINX_UARTLITE_0_DATA_BITS=8
CONFIG_XILINX_UARTLITE_0_USE_PARITY=0
CONFIG_XILINX_UARTLITE_0_ODD_PARITY=0
CONFIG_XILINX_UARTLITE_0_HW_VER="1.00.a"
CONFIG_XILINX_UARTLITE_0_IRQ=3
CONFIG_XILINX_MDM_0_INSTANCE="debug_module"
CONFIG_XILINX_MDM_0_FAMILY="virtex2p"
CONFIG_XILINX_MDM_0_JTAG_CHAIN=2
CONFIG_XILINX_MDM_0_INTERCONNECT=1
CONFIG_XILINX_MDM_0_BASEADDR=0x84400000
CONFIG_XILINX_MDM_0_HIGHADDR=0x8440FFFF
CONFIG_XILINX_MDM_0_SPLB_AWIDTH=32
CONFIG_XILINX_MDM_0_SPLB_DWIDTH=64
CONFIG_XILINX_MDM_0_SPLB_P2P=0
CONFIG_XILINX_MDM_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_MDM_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_MDM_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_MDM_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_MDM_0_OPB_DWIDTH=32
CONFIG_XILINX_MDM_0_OPB_AWIDTH=32
CONFIG_XILINX_MDM_0_MB_DBG_PORTS=1
CONFIG_XILINX_MDM_0_USE_UART=1
CONFIG_XILINX_MDM_0_UART_WIDTH=8
CONFIG_XILINX_MDM_0_WRITE_FSL_PORTS=0
CONFIG_XILINX_MDM_0_HW_VER="1.00.d"
CONFIG_XILINX_ETHERNETLITE_0_INSTANCE="Ethernet_MAC"
CONFIG_XILINX_ETHERNETLITE_0_FAMILY="virtex2p"
CONFIG_XILINX_ETHERNETLITE_0_BASEADDR=0x81000000
CONFIG_XILINX_ETHERNETLITE_0_HIGHADDR=0x8100FFFF
CONFIG_XILINX_ETHERNETLITE_0_SPLB_CLK_PERIOD_PS=10000
CONFIG_XILINX_ETHERNETLITE_0_SPLB_AWIDTH=32
CONFIG_XILINX_ETHERNETLITE_0_SPLB_DWIDTH=64
CONFIG_XILINX_ETHERNETLITE_0_SPLB_P2P=0
CONFIG_XILINX_ETHERNETLITE_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_ETHERNETLITE_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_ETHERNETLITE_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_ETHERNETLITE_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_ETHERNETLITE_0_DUPLEX=1
CONFIG_XILINX_ETHERNETLITE_0_TX_PING_PONG=1
CONFIG_XILINX_ETHERNETLITE_0_RX_PING_PONG=1
CONFIG_XILINX_ETHERNETLITE_0_HW_VER="2.00.b"
CONFIG_XILINX_ETHERNETLITE_0_IRQ=2
CONFIG_XILINX_TIMER_0_INSTANCE="xps_timer_1"
CONFIG_XILINX_TIMER_0_FAMILY="virtex2p"
CONFIG_XILINX_TIMER_0_COUNT_WIDTH=32
CONFIG_XILINX_TIMER_0_ONE_TIMER_ONLY=0
CONFIG_XILINX_TIMER_0_TRIG0_ASSERT=1
CONFIG_XILINX_TIMER_0_TRIG1_ASSERT=1
CONFIG_XILINX_TIMER_0_GEN0_ASSERT=1
CONFIG_XILINX_TIMER_0_GEN1_ASSERT=1
CONFIG_XILINX_TIMER_0_BASEADDR=0x83C00000
CONFIG_XILINX_TIMER_0_HIGHADDR=0x83C0FFFF
CONFIG_XILINX_TIMER_0_SPLB_AWIDTH=32
CONFIG_XILINX_TIMER_0_SPLB_DWIDTH=64
CONFIG_XILINX_TIMER_0_SPLB_P2P=0
CONFIG_XILINX_TIMER_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_TIMER_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_TIMER_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_TIMER_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_TIMER_0_HW_VER="1.00.a"
CONFIG_XILINX_TIMER_0_IRQ=0
CONFIG_XILINX_INTC_0_INSTANCE="xps_intc_0"
CONFIG_XILINX_INTC_0_FAMILY="virtex2p"
CONFIG_XILINX_INTC_0_BASEADDR=0x81800000
CONFIG_XILINX_INTC_0_HIGHADDR=0x8180FFFF
CONFIG_XILINX_INTC_0_SPLB_AWIDTH=32
CONFIG_XILINX_INTC_0_SPLB_DWIDTH=64
CONFIG_XILINX_INTC_0_SPLB_P2P=0
CONFIG_XILINX_INTC_0_SPLB_NUM_MASTERS=2
CONFIG_XILINX_INTC_0_SPLB_MID_WIDTH=1
CONFIG_XILINX_INTC_0_SPLB_NATIVE_DWIDTH=32
CONFIG_XILINX_INTC_0_SPLB_SUPPORT_BURSTS=0
CONFIG_XILINX_INTC_0_NUM_INTR_INPUTS=4
CONFIG_XILINX_INTC_0_KIND_OF_INTR=0x0000000C
CONFIG_XILINX_INTC_0_KIND_OF_EDGE=0x0000000C
CONFIG_XILINX_INTC_0_KIND_OF_LVL=0x00000003
CONFIG_XILINX_INTC_0_HAS_IPR=1
CONFIG_XILINX_INTC_0_HAS_SIE=1
CONFIG_XILINX_INTC_0_HAS_CIE=1
CONFIG_XILINX_INTC_0_HAS_IVR=1
CONFIG_XILINX_INTC_0_IRQ_ACTIVE=1
CONFIG_XILINX_INTC_0_HW_VER="1.00.a"
CONFIG_XILINX_LMB_BRAM_IF_CNTLR_NUM_INSTANCES=2
CONFIG_XILINX_TIMER_NUM_INSTANCES=1
CONFIG_XILINX_MPMC_NUM_INSTANCES=1
CONFIG_XILINX_ETHERNETLITE_NUM_INSTANCES=1
CONFIG_XILINX_INTC_NUM_INSTANCES=1
CONFIG_XILINX_MDM_NUM_INSTANCES=1
CONFIG_XILINX_UARTLITE_NUM_INSTANCES=1

#
# Processor type and features
#
# CONFIG_MMU is not set
CONFIG_NO_MMU=y
# CONFIG_PREEMPT is not set
# CONFIG_XILINX_UNCACHED_SHADOW is not set
CONFIG_LARGE_ALLOCS=y
# CONFIG_USE_BRAM is not set
# CONFIG_OPT_LIB_FUNCTION is not set

#
# Boot options
#
CONFIG_CMDLINE="root=/dev/ram console=ttyUL0,38400"
CONFIG_CMDLINE_FORCE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set

#
# Exectuable file formats
#
CONFIG_BINFMT_FLAT=y
# CONFIG_BINFMT_ZFLAT is not set
# CONFIG_BINFMT_SHARED_FLAT is not set
# CONFIG_BINFMT_MISC is not set

#
# Advanced setup
#

#
# Default settings for advanced configuration options are used
#

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_IPSEC_NAT_TRAVERSAL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_EPCS is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0x0
CONFIG_MTD_PHYSMAP_LEN=0x0
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
# CONFIG_MTD_SNAPARM is not set
CONFIG_MTD_UCLINUX=y
CONFIG_MTD_UCLINUX_EBSS=y
# CONFIG_MTD_SNAPGEARuC is not set
# CONFIG_MTD_M520x is not set
# CONFIG_MTD_PLATRAM is not set
# CONFIG_MTD_AVNET5282 is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set

#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_XILINX_SYSACE=y

#
# Misc devices
#
# CONFIG_TIFM_CORE is not set
CONFIG_MICROBLAZE_FSLFIFO=y

#
# FSL Channel Selection
#
CONFIG_MICROBLAZE_FSLFIFO0=y
# CONFIG_MICROBLAZE_FSLFIFO1 is not set
# CONFIG_MICROBLAZE_FSLFIFO2 is not set
# CONFIG_MICROBLAZE_FSLFIFO3 is not set
# CONFIG_MICROBLAZE_FSLFIFO4 is not set
# CONFIG_MICROBLAZE_FSLFIFO5 is not set
# CONFIG_MICROBLAZE_FSLFIFO6 is not set
# CONFIG_MICROBLAZE_FSLFIFO7 is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_NETLINK is not set

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
# CONFIG_ATA is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# I2O device support
#

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# PHY device support
#

#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set
# CONFIG_OPEN_ETH is not set
# CONFIG_MTIP1000_ETH is not set
# CONFIG_NE2000 is not set
# CONFIG_XILINX_EMAC is not set
CONFIG_XILINX_EMACLITE=y

#
# Ethernet (1000 Mbit)
#
# CONFIG_XILINX_LLTEMAC is not set

#
# Ethernet (10000 Mbit)
#

#
# Token Ring devices
#

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
# CONFIG_INPUT is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_LEDMAN is not set
# CONFIG_SNAPDOG is not set
# CONFIG_FAST_TIMER is not set
# CONFIG_RESETSWITCH is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_UARTLITE=y
CONFIG_SERIAL_UARTLITE_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_XILINX_SPI is not set
CONFIG_XILINX_GPIO=y
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_M41T11M6 is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB_ARCH_HAS_HCD is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#

#
# Virtualization
#
CONFIG_XILINX_EDK=y

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=y
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_DNOTIFY is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_DIRECTIO=y

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Distributed Lock Manager
#
# CONFIG_DLM is not set

#
# Debug
#
# CONFIG_COREDUMP_PRINTK is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_UARTLITE_ADDRESS=0x00000000

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC32 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_IOMAP_COPY=y


-------- Original-Nachricht --------
> Datum: Tue, 27 Oct 2009 13:22:10 -0700
> Von: "Dan  Snyder" <Dan.Snyder at trilliantinc.com>
> An: uClinux development list <uclinux-dev at uclinux.org>
> Betreff: RE: [uClinux-dev] XUPV2 PetaLinux "mtd: partition "ROMfs" is out of	reach"

> Can you post your kernel .config?
> 
>  
> -----Original Message-----
> From: uclinux-dev-bounces at uclinux.org
> [mailto:uclinux-dev-bounces at uclinux.org] On Behalf Of Oliver Rod
> Sent: Tuesday, October 27, 2009 2:08 PM
> To: uclinux-dev at uclinux.org
> Subject: [uClinux-dev] XUPV2 PetaLinux "mtd: partition "ROMfs" is out of
> reach"
> 
> Hi,
> 
> I make my student research project my aim is running petalinux v0.40 on a
> microblaze XUPV2. My Hardware is running fine, but i have problems with my
> romfs.I start the board and push the image.elf in my ram and I get this
> KernelMessage:
> Linux version 2.6.20-uc0 (tool at tool) (gcc version 3.4.1 ( PetaLinux 0.20
> Build -rc1 050607 )) #8 Thu Oct 22 13:55:38 CEST 2009
> setup_cpuinfo: initialising
> setup_cpuinfo: No PVR support in CPU.  Using static compile-time info
> set_cpuinfo_static: Using static CPU info.
> setup_memory: max_mapnr: 0x9ffff
> setup_memory: min_low_pfn: 0x90000
> setup_memory: max_low_pfn: 0x10000
> On node 0 totalpages: 65536
>   DMA zone: 512 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 65024 pages, LIFO batch:15
>   Normal zone: 0 pages used for memmap
> Built 1 zonelists.  Total pages: 65024
> Kernel command line: root=/dev/ram console=ttyUL0,38400
> OPB INTC #0 at 0x81800000
> PID hash table entries: 1024 (order: 10, 4096 bytes)
> TIMER at 0x83C00000
> disabling early console
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 257920k/262144k available
> Calibrating delay loop... 49.45 BogoMIPS (lpj=247296)
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 8192 bind 4096)
> TCP reno registered
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> uartlite.0: ttyUL0 at MMIO 0x84000000 (irq = 3) is a uartlite
> RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
> Microblaze FSL FIFO Driver. John Williams <jwilliams at itee.uq.edu.au>
> FSL FIFO[0] initialised
> eth0: using fifo mode.
> eth0: No PHY detected.  Assuming a PHY at address 0.
> eth0: Xilinx EMACLite #0 at 0x81000000 mapped to 0x81000000, irq=2
> uclinux[mtd]: RAM probe address=0x901c6238 size=0x0
> Creating 1 MTD partitions on "RAM":
> 0x00000000-0x00000000 : "ROMfs"
> mtd: partition "ROMfs" is out of reach -- disabled
> uclinux[mtd]: set ROMfs to be root filesystem index=0
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> No filesystem could mount root, tried:  ext3 ext2 cramfs msdos vfat romfs
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(1,0)
>  <0>Rebooting in 120 seconds..
> 
> So I check if my romfs is in my image.elf
> 
> microblaze-uclinux-objcopy
> --add-section=.romfs=software/petalinux-dist/images/romfs.img --adjust-section-vma=.romfs=0x901ab000 --no-adjust-warnings
> --set-section-flags=.romfs=alloc,load,data
> software/petalinux-dist/linux-2.6.x/linux software/petalinux-dist/images/image.elf
> BFD: software/petalinux-dist/images/image.elf: warning: allocated section
> `.romfs' not in segment
> 
> microblaze-uclinux-objdump -x software/petalinux-dist/images/image.elf
> |grep romfs
>  32 .romfs        001e6c00  901ab000  901ab000  001a694d  2**0
> 00000000 l    d  .romfs    00000000
> 901656b4 l     O .text    00000004 __exitcall_exit_romfs_fs
> 901a7d34 l       .init.text    00000034 exit_romfs_fs
> 901a91d4 l     O .initcall.init    00000004 __initcall_init_romfs_fs6
> 901a2228 l       .init.text    00000084 init_romfs_fs
> 90188bf4 l     O .data    00000020 romfs_fs_type
> 900b3c78 l       .text    0000002c romfs_get_sb
> 90188c14 l     O .data    0000004c romfs_ops
> 900b3ba8 l       .text    00000038 romfs_alloc_inode
> 900b3be0 l       .text    00000030 romfs_destroy_inode
> 900b39a8 l       .text    00000200 romfs_read_inode
> 900b3008 l       .text    00000064 romfs_statfs
> 900b3c64 l       .text    00000014 romfs_remount
> 90177780 l     O .rodata    0000003c romfs_aops
> 900b37a4 l       .text    00000204 romfs_readpage
> 901777bc l     O .rodata    0000006c romfs_dir_operations
> 900b33c0 l       .text    000001d8 romfs_readdir
> 90188c60 l     O .data    00000054 romfs_dir_inode_operations
> 900b3598 l       .text    0000020c romfs_lookup
> 90188cb4 l     O .data    00000020 romfs_modemap
> 90188cd4 l     O .data    00000008 romfs_dtype_table
> 900b2e0c l       .text    000001fc romfs_fill_super
> 900b306c l       .text    000001a8 romfs_strnlen
> 900b3214 l       .text    000001ac romfs_copyfrom
> 901ba20c l     O .bss    00000004 romfs_inode_cachep
> 901ab000 l    d  .romfs    00000000
> 90000990 g       .text    000000a8 get_romfs_len
> 90000980 g       .text    00000010 get_romfs_base
> 
> Thank you for your help.
> 
> Greets,
> Oliver

> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser


From c.baumann at ppc-ag.de  Fri Oct 30 10:13:18 2009
From: c.baumann at ppc-ag.de (Christoph Baumann)
Date: Fri, 30 Oct 2009 15:13:18 +0100
Subject: [uClinux-dev] Problem with OpenSSH_5.2p1
In-Reply-To: <F8754F38-719D-4F61-98AE-337663CE18DD@argonst.com>
References: <4AE80B33.4010500@ppc-ag.de>	<AC6C223F-5488-4F50-AA63-2F66BE3D9874@argonst.com>	<4AE84EA7.7080107@ppc-ag.de>
	<F8754F38-719D-4F61-98AE-337663CE18DD@argonst.com>
Message-ID: <4AEAF47E.3080805@ppc-ag.de>

Meanwhile I tracked the overwriting of the "environ" pointer to a memset
of a global data structure (initialize_options in readconf.c). My trace
output of the interesting addresses is this:

&environ: 0x70cfb69c
poptions: 0x70cfa218
&poptions->forward_agent: 0x70cfa218
&poptions->visual_host_key: 0x70cfb6c8
sizeof(Options): 5300

'forward_agent' is the first and 'visual_host_key' the last element of
the Options structure. As you can see the addresses overlap with 'environ'.

This looks like a compiler problem. Any hints to fix that?


Regards
	Christoph


-- 

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax:   +49(621)40165-???
mailto://c.baumann at ppc-ag.de
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott


THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS
CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK
PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE
INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE
INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE,
DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS
STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL
TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE
ORIGINAL MESSAGE FROM YOUR DATABASE