Re: [uClinux-dev] [PATCH] iptables: use _exit instead of exit if execv fails

[David McCullough]

Jivin Rainer Keller lays it down ...
> Hi All,
> 
> We experienced mysterious memory corruptions in our router product
> configurations of uClinux. We tracked it down to iptables being the
> common element in those scenarios and were able to get a certain
> corruption to happen consistently at a fixed address (lucky) and were
> able to trap it with a register in our processor that traps on write to
> get a backtrace which pointed to this.
> 
> When using iptables xtables_insmod is called to load the iptables module
> using /sbin/modprobe. Neither the module nor modprobe are currently
> installed on our configuration (iptables support is compiled into the
> kernel and we use plain insmod currently). So the execv fails:
> 
> By using the real `exit' after the failed execv iptables modified memory
> (in fact unmapped all the heap) that was still shared between child and
> parent. When the child was done the parent continued and tried to free a
> pointer from its heap whose backing memory did not exist anymore. So it
> clobbered random memory and caused all kinds of havoc.

Applied :-)

Thanks,
Davidm


> diff --git a/iptables/xtables.c b/iptables/xtables.c
> index a309954..92314bc 100644
> --- a/iptables/xtables.c
> +++ b/iptables/xtables.c
> @@ -134,7 +134,11 @@ int xtables_insmod(const char *modname, const char
> *modprob
> case 0:
> execv(argv[0], argv);
> /* not usually reached */
> +#ifdef __uClinux__
> +   _exit(1);
> +#else
> exit(1);
> +#endif
> case -1:
> return -1;
> 
> This is mine and Ubicom's first patch to uClinux. I hope you find it
> useful.
> 
> Thank you for creating uClinux!
> Best Regards,
> - Rainer
> 
> 
> 
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
> 

-- 
David McCullough,  david_mccullo...@securecomputing.com,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.comhttp://www.uCdot.org
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] [PATCH] iptables: use _exit instead of exit if execv fails

[Rainer Keller]

Hi All,

We experienced mysterious memory corruptions in our router product
configurations of uClinux. We tracked it down to iptables being the
common element in those scenarios and were able to get a certain
corruption to happen consistently at a fixed address (lucky) and were
able to trap it with a register in our processor that traps on write to
get a backtrace which pointed to this.

When using iptables xtables_insmod is called to load the iptables module
using /sbin/modprobe. Neither the module nor modprobe are currently
installed on our configuration (iptables support is compiled into the
kernel and we use plain insmod currently). So the execv fails:

By using the real `exit' after the failed execv iptables modified memory
(in fact unmapped all the heap) that was still shared between child and
parent. When the child was done the parent continued and tried to free a
pointer from its heap whose backing memory did not exist anymore. So it
clobbered random memory and caused all kinds of havoc.

diff --git a/iptables/xtables.c b/iptables/xtables.c
index a309954..92314bc 100644
--- a/iptables/xtables.c
+++ b/iptables/xtables.c
@@ -134,7 +134,11 @@ int xtables_insmod(const char *modname, const char
*modprob
case 0:
execv(argv[0], argv);
/* not usually reached */
+#ifdef __uClinux__
+   _exit(1);
+#else
exit(1);
+#endif
case -1:
return -1;

This is mine and Ubicom's first patch to uClinux. I hope you find it
useful.

Thank you for creating uClinux!
Best Regards,
- Rainer



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

Re: [uClinux-dev] question about uclibc version

[Jun Sun]

On Mon, Mar 02, 2009 at 04:31:52PM -0500, Jate Sujjavanich wrote:
> The uClibc that comes with uClinux-dist is rather old.
> 
> I upgraded my local copy of uClinux-dist with the uClibc source from the
> Codesourcery toolchain for Coldfire. This fixed some strange timing bugs
> I found after activating CPU cache.
> 
> I think that uClinux-dist still contains an old uClibc because there
> hasn't been enough testing for newer versions.
> 

Just curious - how did upgrade the uClibc in the distro? Just dump
the source tree in the distro? What about the config for uclibc?

Also, do you use codesourcery toolchain then? They seem to have 
built-in uclibc. I wonder if we need to use that one or we should
upgrade the one inside the distro.

Cheers.

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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Jim Donelson]

Agreed. But from the external view, all you see are sectors that you can
read and write.


On Wed, Mar 25, 2009 at 1:53 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Wed, Mar 25, 2009 at 11:47:07AM -0400, Jim Donelson wrote:
> > .
> > As far as the card is concerned, it just has sectors you can read and
> write.
> > Where are these "lists" kept? The spec never address this.
>
> The spec covers the external interface.  The internal implementation
> details is not a concern for the spec.
>
> So you can make a card that simply gives you a fixed mapping.  Filesystems
> like FAT would kill that rather quickly.
>
> You can make one that does full lovely wear leveling and it would last
> much longer.
>
> Other than one dying sooner than the other, there is no difference that
> the user can see from the outside.  Both would provide a certain number
> of sectors that you can access.  How those sectors map to the flash
> chips internally is really none of the users business.
>
> --
> Len Sorensen
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Lennart Sorensen]

On Wed, Mar 25, 2009 at 11:47:07AM -0400, Jim Donelson wrote:
> .
> As far as the card is concerned, it just has sectors you can read and write.
> Where are these "lists" kept? The spec never address this.

The spec covers the external interface.  The internal implementation
details is not a concern for the spec.

So you can make a card that simply gives you a fixed mapping.  Filesystems
like FAT would kill that rather quickly.

You can make one that does full lovely wear leveling and it would last
much longer.

Other than one dying sooner than the other, there is no difference that
the user can see from the outside.  Both would provide a certain number
of sectors that you can access.  How those sectors map to the flash
chips internally is really none of the users business.

-- 
Len Sorensen
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] kernel error

[Ghanem Lafi]

Hi all Experts,

I build my image by using uClinux-dist-20080808.

When i debug linux.bin, ifound that it starts by *
arch/arm/kernel/head-nommu.S* and not by *arch/arm/mach-lpc22xx/head.S.

*Which modifications should i do ?

Regards,
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] netflash Documentation

[Glenn Henshaw]

  It appears that the latest version of netflash has the ability to  
sign loads cryptographically. Is the process to generale the load  
documented anywhere?


   ... Glenn

--
Glenn Henshaw Logical Outcome Ltd.
e: li...@logicaloutcome.ca w: www.logicaloutcome.ca



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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Jim Donelson]

.
As far as the card is concerned, it just has sectors you can read and write.
Where are these "lists" kept? The spec never address this.


On Wed, Mar 25, 2009 at 11:18 AM, Michael Schnell wrote:

>
>
>> -As for "low level formatting", huh? ...
>>
>
> The "low level formating" initializes the lists used for wear leveling :)
>
> -Michael
>
>
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Jim Donelson]

Regular means those built to the spec I referenced, not SDHC.
Wrong about what?


On Wed, Mar 25, 2009 at 11:10 AM, Michael Schnell wrote:

> Jim Donelson wrote:
>
>> -If we are talking about regular SD cards, there is no internal wear
>> leveling.
>>
> What do you think  are "regular SD cards" ?
>
> I suppose those that can be used with FAT file system in Digital cameras
> and can be connected to a PC (which does not have a special driver to do the
> wear leveling but recognizes them as memory a device as with a CF-card) need
> to have internal wear leveling. Otherwise they would not be usable.
>
> If I'm wrong please show some pointers on that.
>
> -Michael
>
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] Re: [PATCH 0/2] Make the Unevictable LRU available on NOMMU

[David Howells]

Anne Fomin  wrote:

>   I am working with the LPC2468  board and i will like to find out from you if
> you have any idea how to read the ADC value and set PWM in C code not on the
> command line.
> For the ADc read i have this piece of code which i am not sure it will work.
> # define adadc 0XE0034004

Can I suggest you repost this with a more appropriate subject line, and that
you also don't post it as part of the email thread to do with unevictable
LRUs?

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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Michael Schnell]

Certainly CF cards do have to do any wear leveling in the card since
they present IDE to the host system.
  
... as do SD-cards.via USB and other interfaces they are just "memory 
devices".


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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Michael Schnell]

Perhaps the usb adapter does it.
  

I very seriously doubt that.

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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Michael Schnell]

-As for "low level formatting", huh? ...


The "low level formating" initializes the lists used for wear leveling :)

-Michael

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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Michael Schnell]

Jim Donelson wrote:
I didn't say the driver HAD to do wear leveling, but if wear level is 
to be done, the driver must do it, as SD cards don't do it themselves.

Quoting from the SanDisk Spec:

"The SD Card’s Wear Level command is supported as a NOP operation to 
maintain backward compatibility with existing software utilities."


According the them, you don't need no stink'in wear leveling.

http://www.cs.ucr.edu/~amitra/sdcard/ProdManualSDCardv1.9.pdf 




They are plain wrong.

With 100.000 times write with a FAT file system (as usually used with 
cameras) the first sectors containing the FAT and the root directory 
will be dead after 100.000 files written. This is easily done with a 
camera.


-Michael


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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Michael Schnell]

Jim Donelson wrote:
-If we are talking about regular SD cards, there is no internal wear 
leveling.

What do you think  are "regular SD cards" ?

I suppose those that can be used with FAT file system in Digital cameras 
and can be connected to a PC (which does not have a special driver to do 
the wear leveling but recognizes them as memory a device as with a 
CF-card) need to have internal wear leveling. Otherwise they would not 
be usable.


If I'm wrong please show some pointers on that.

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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Jim Donelson]

Ok, here is what an SD card has - it has a RAM buffer that is the size of a
block, where a block is the smallest erasable chunk. That is what "Erase
Pooling" is vaguely referring to. If you are going to write sectors in the
same block, you should do that, send all the sectors in that block then
issue the write command.

If you write individual sectors, the card will do an erase/rewrite for each
sector on the entire block, and it will be very slow.

As to who does this, it depends, but it is harder that it may sound, because
now you have to track things based on the "geometry" of the card and know
when to do the write. The code is much simpler if you just write each sector
as it comes up. Most SBC cards just use an SPI to talk to the card.

But that is all the card does for you.




> Well it's up to the controller to do that perhaps.  Given that most people
> seem t use usb adapters for SD cards, the OS simply sees a USB storage
> device and runs FAT or some other filesystem on it.  Certainly no wear
> leveling done in software.  Perhaps the usb adapter does it.
>
> > -It take can take up to something like 40ms to write a single sector, as
> an
> > entire block must be erased and re-written.For a given card, it is indeed
> > specified. Cards have different speeds, but that that is available from
> the
> > internal config data of the card and the mfg specs - which are published.
> > The card indicated via status when it is done (of course only the driver
> is
> > going to see that)
> >
> > -As for "low level formatting", huh? Unlike a hard drive, a sector is a
> > sector. While writing a stand alone driver, I scrambled the data plenty
> of
> > times, and reformatting with windows "format" never failed to work. You
> > might be assuming it is like CF, which does emulate a hard drive.
>
> Certainly CF cards do have to do any wear leveling in the card since
> they present IDE to the host system.
>
> > You should get the spec from the SD people for 1.1 and read (parts of)
> it. I
> > think your issues are with the the OS/Driver and the way you are doing
> > things. Used correctly, SD cards will work fine.
> > Unless you have many files open, it should complete quickly.
>
> Well there might be some really bad SD cards out there too.
>
> --
> Len Sorensen
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Lennart Sorensen]

On Wed, Mar 25, 2009 at 08:09:02AM -0400, Jim Donelson wrote:
> -If we are talking about regular SD cards, there is no internal wear
> leveling.
> It is up to the driver to do that.

Well it's up to the controller to do that perhaps.  Given that most people
seem t use usb adapters for SD cards, the OS simply sees a USB storage
device and runs FAT or some other filesystem on it.  Certainly no wear
leveling done in software.  Perhaps the usb adapter does it.

> -It take can take up to something like 40ms to write a single sector, as an
> entire block must be erased and re-written.For a given card, it is indeed
> specified. Cards have different speeds, but that that is available from the
> internal config data of the card and the mfg specs - which are published.
> The card indicated via status when it is done (of course only the driver is
> going to see that)
> 
> -As for "low level formatting", huh? Unlike a hard drive, a sector is a
> sector. While writing a stand alone driver, I scrambled the data plenty of
> times, and reformatting with windows "format" never failed to work. You
> might be assuming it is like CF, which does emulate a hard drive.

Certainly CF cards do have to do any wear leveling in the card since
they present IDE to the host system.

> You should get the spec from the SD people for 1.1 and read (parts of) it. I
> think your issues are with the the OS/Driver and the way you are doing
> things. Used correctly, SD cards will work fine.
> Unless you have many files open, it should complete quickly.

Well there might be some really bad SD cards out there too.

-- 
Len Sorensen
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Erwin Authried]

Am Mittwoch, den 25.03.2009, 08:38 -0400 schrieb Jim Donelson:
> I didn't say the driver HAD to do wear leveling, but if wear level is
> to be done, the driver must do it, as SD cards don't do it
> themselves. 
> Quoting from the SanDisk Spec:
> 
> "The SD Card’s Wear Level command is supported as a NOP operation to
> maintain backward compatibility with existing software utilities."
this just says that there isn't an explicit command for wear leveling,
but it doesn't say that the card doesn't do internal wear leveling.

the sentence just before that:

"Wear-leveling is an intrinsic part of the Erase Pooling functionality
of SD using NAND memory."

It doesn't specify HOW it is done, however. If there would be no wear
leveling at all, that would mean that the card would die pretty fast
with filesystems like FAT where the first sectors are written
frequently.

-Erwin


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

Re: [uClinux-dev] Re: [PATCH 0/2] Make the Unevictable LRU available on NOMMU

[Anne Fomin]

Hi There ,
  I am working with the LPC2468  board and i will like to find out from you
if you have any idea how to read the ADC value and set PWM in C code not on
the command line.
For the ADc read i have this piece of code which i am not sure it will work.
# define adadc 0XE0034004
int ADC_read()
{
  int val;
   val = adadc;
 return va;
}
Please do you know if this piece of Code will return me the value of at the
output of the adc.
Thanks alot for your help if you can

On Fri, Mar 20, 2009 at 5:24 PM, David Howells  wrote:

> Lee Schermerhorn  wrote:
>
> > I just want to point out [again :)] that removing the ramfs pages from
> > the lru will prevent them from being migrated
>
> This is less of an issue for NOMMU kernels, since you can't migrate pages
> that
> are mapped.
>
> David
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] remap_pfn_range

[Anne Fomin]

Hi There ,
  I am working with the LPC2468  board and i will like to find out from you
if you have any idea how to read the ADC value and set PWM in C code not on
the command line.
For the ADc read i have this piece of code which i am not sure it will work.
# define adadc 0XE0034004
int ADC_read()
{
  int val;
   val = adadc;
 return va;
}
Please do you know if this piece of Code will return me the value of at the
output of the adc.
Thanks alot for your help if you can
Anne


On Mon, Mar 23, 2009 at 5:38 PM, Daniel Glöckner  wrote:

> Hi,
> I'm a little confused as to how to write drivers that require
> remap_pfn_range on mmu Linux to function on nommu as well.
>
> The current nommu implementation looks like this:
>
> int remap_pfn_range(struct vm_area_struct *vma, unsigned long from,
>unsigned long to, unsigned long size, pgprot_t prot)
> {
>vma->vm_start = vma->vm_pgoff << PAGE_SHIFT;
>return 0;
> }
>
> It's strange to see vm_pgoff being used to define the start of the area.
> IMHO this should only be used for /dev/mem. In all other cases this is
> not related to the absolute address. And not changing vm_end will
> effectively change the size of the area.
>
> But is remap_pfn_range supposed to change vm_start at all?
> Shouldn't this, on nommu, consist only of checks if the size bytes starting
> at "from" and "to << PAGE_SHIFT" are inside vma?
> vm_start and vm_end are already at their designated value after mmap has
> called get_unmapped_area..
>
>  Daniel
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Jim Donelson]

I didn't say the driver HAD to do wear leveling, but if wear level is to be
done, the driver must do it, as SD cards don't do it themselves.
Quoting from the SanDisk Spec:

"The SD Card’s Wear Level command is supported as a NOP operation to
maintain backward compatibility with existing software utilities."

According the them, you don't need no stink'in wear leveling.

http://www.cs.ucr.edu/~amitra/sdcard/ProdManualSDCardv1.9.pdf



On Wed, Mar 25, 2009 at 8:21 AM, Erwin Authried  wrote:

> Am Mittwoch, den 25.03.2009, 08:09 -0400 schrieb Jim Donelson:
> > -If we are talking about regular SD cards, there is no internal wear
> > leveling.
> > It is up to the driver to do that.
> I think you are wrong here. There's no wear leveling in the driver.
>
> -Erwin
>
>
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Erwin Authried]

Am Mittwoch, den 25.03.2009, 08:09 -0400 schrieb Jim Donelson:
> -If we are talking about regular SD cards, there is no internal wear
> leveling.
> It is up to the driver to do that.
I think you are wrong here. There's no wear leveling in the driver. 

-Erwin


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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Jim Donelson]

-If we are talking about regular SD cards, there is no internal wear
leveling.
It is up to the driver to do that.

-It take can take up to something like 40ms to write a single sector, as an
entire block must be erased and re-written.For a given card, it is indeed
specified. Cards have different speeds, but that that is available from the
internal config data of the card and the mfg specs - which are published.
The card indicated via status when it is done (of course only the driver is
going to see that)

-As for "low level formatting", huh? Unlike a hard drive, a sector is a
sector. While writing a stand alone driver, I scrambled the data plenty of
times, and reformatting with windows "format" never failed to work. You
might be assuming it is like CF, which does emulate a hard drive.

You should get the spec from the SD people for 1.1 and read (parts of) it. I
think your issues are with the the OS/Driver and the way you are doing
things. Used correctly, SD cards will work fine.
Unless you have many files open, it should complete quickly.


On Wed, Mar 25, 2009 at 7:06 AM, Erwin Authried  wrote:

> Am Mittwoch, den 25.03.2009, 11:30 +0100 schrieb Michael Schnell:
> > > My SD card is getting corrupted after issuing the reboot command and
> > > de-powering the board.
> > Are you sure it was unmount before shutting down the system ?
> >
> > BTW.:
> > Even if you do unmount it you are not safe. An SD-Card (like all similar
> > flash media) does an internal wear leveling. This can take an
> > unspecified amount of time after any write request. If you de-power the
> > SD-Card before this timespan is over it might be corrupted. Not only the
> > newly written data might be corrupt but any data on the card. I ever
> > read reports claiming that it can get so seriously corrupted that it
> > could not be formatted any more and a low-level formatting with a
> > special tool was necessary.
> >
> > -Michael
>
> Hi Michael,
>
> that sounds like SD cards cannot be used for anythiing serious. I'd like
> to know if this applies to industrial SD cards as well. What is the
> source of the information that you have? I'd really like to see that!!
>
> -Erwin
>
>
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Michael Schnell]

that sounds like SD cards cannot be used for anythiing serious. 
Yep ;) I suppose leaving the card powered up for some 10 seconds after 
unmounting it will be quite save, but as there are no specs from the 
card manufacture on the maximum necessary activity time after write you 
never can be absolutely sure.



I'd like
to know if this applies to industrial SD cards as well. 
I once read about "industrial" CF-Cards that come with better specs some 
time ago. Maybe these manufacturers do offer appropriate SD-Cards, as well.

What is the
source of the information that you have? I'd really like to see that!!
  
There already were several discussions on that in the public 
linux.embedded newsgroup. But in fact the problem is that you don't get 
informations :). You would need to try to get the max time spec from the 
card manufacturers, but I bet they will ignore you.


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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Erwin Authried]

Am Mittwoch, den 25.03.2009, 11:30 +0100 schrieb Michael Schnell:
> > My SD card is getting corrupted after issuing the reboot command and 
> > de-powering the board. 
> Are you sure it was unmount before shutting down the system ?
> 
> BTW.:
> Even if you do unmount it you are not safe. An SD-Card (like all similar 
> flash media) does an internal wear leveling. This can take an 
> unspecified amount of time after any write request. If you de-power the 
> SD-Card before this timespan is over it might be corrupted. Not only the 
> newly written data might be corrupt but any data on the card. I ever 
> read reports claiming that it can get so seriously corrupted that it 
> could not be formatted any more and a low-level formatting with a 
> special tool was necessary.
> 
> -Michael

Hi Michael,

that sounds like SD cards cannot be used for anythiing serious. I'd like
to know if this applies to industrial SD cards as well. What is the
source of the information that you have? I'd really like to see that!!

-Erwin


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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Michael Schnell]

Maybe there's some issue with the unmount?
Unmount needs some time to do it's work. Before it's ready the power 
should not be removed. I suppose there are ways to find out when it's ready.


Moreover the card needs some time to do it's work on the data written by 
unmount. I don't suppose there are ways to find out when it's ready.


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

Re: [uClinux-dev] SD card corruption upon reboot and de-power

[Michael Schnell]

My SD card is getting corrupted after issuing the reboot command and 
de-powering the board. 

Are you sure it was unmount before shutting down the system ?

BTW.:
Even if you do unmount it you are not safe. An SD-Card (like all similar 
flash media) does an internal wear leveling. This can take an 
unspecified amount of time after any write request. If you de-power the 
SD-Card before this timespan is over it might be corrupted. Not only the 
newly written data might be corrupt but any data on the card. I ever 
read reports claiming that it can get so seriously corrupted that it 
could not be formatted any more and a low-level formatting with a 
special tool was necessary.


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