sdcErase() in HAL 3.0

[barthess]

Hi ulikoehler
Thanks for exhaustive answer. Reverting erase() function is not a big problem but later maintain is.
Could you write some erase tests for SDIO haltest application?

About renaming sdcErase() to sdcSecureErase(). I disagree. We can not name function "secure"
if we are not 100% sure in its security. Main problem is lack of full documentation in free access.
I hate all that proprietary crap.

As a result:
1) I will revert deleted sdcErase() function.
2) You will provide patch for testhal application.
3) Benchmarks would be very good too.

[barthess]

sdcErase() reintroduced

[ulikoehler]

Just saw that it was introduced in SVN. Thanks Giovanni and Barthess

@barthess: OK, I'll try to write a testhal test for it.

I see your point about not renaming. I agree.

Best regards,
Uli

[colin]

Actually it seems like the hypothetical sdcErase() and sdcSecureErase() have contrary characteristics.

Suppose, as is generally the case, I don't need secure erase.

Then I want to help the SD card controller do wear-leveling and optimize performance by marking unused regions of the flash as erased (like the SSD TRIM command). This generally will not immediately erase all the flash cells in that block.

On the other hand, the key characteristic of a secure erase command is that it does modify the state of every memory cell in the addressed region.

So I think you definitely would want separate "TRIM erase" and "secure erase" commands, if the SD card spec has these options. Sorry, I don't know the SD standard myself so I am ignorant of these details. But I wanted to bring up the significant difference in nature of the secure erase from the usual erase.

[ulikoehler]

@colin: As far as I know there are simply no different commands. There is CMD38 ("Erase") which is AFAIK mandatory. CMD32/CMD33 are only used to set the block range for CMD38.
See table 4-26 in https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf. CMD39/CMD41 are reserved, i.e. in the future they could hypothetically be used to implement different types of erase.

Note that I only suppose that secure erase (as advertised by some vendors) is implemented via CMD38. It's just a theory (I'd probably implement it that way) and I have not yet received an answer from ATP. The SD card physical layer simplified spec doesn't AFAIK mention CMD38 to be a secure erase. I only found that in a patent (see my previous post for details)

Conceptually I agree with you. Separate commands would be nice. However, the quality of most SD cards is quite dubious (many are just cheap chinese ones, fake SanDisk ones etc.) and therefore it would probably be dubious if they just ignore the TRIM command or do not erase securely in a secure erase operation.

@barthess: I have finished writing the SD erase test. It succeeds for two of my spare SD cards (cheap to medium-priced chinese ones) that appear to have no errors while it fails for some other chinese ones that do not even pass the (already-existing) read/write tests (my computer shows lot of errors when I try to read them using dd).

I'll get my hands on some fairly expensive Panasonic industrial microSDs in the next few days. I will re-test it with those, too.

http://pastebin.com/ukvqfhDM

@Giovanni: The forum does not allow .patch files to be attached - what is the preferred extension to use for patches (or shall I submit them somewhere else)?

Best regards, Uli

[Giovanni]

Hi,

Zipping files always work.

Giovanni

[barthess]

@ulikoehler
Thanks for your work. Code merged in trunk.