Why is camera needed?

ronaldlees

ronaldlees

I needed another uSD for an Odroid used in a case where I don't care about the speed of the disk. In a department store i noticed a new packaging style Sandisk for only $8. It was the older, slower device, making me figure that they were targeting another niche to use up the older stock. Don't know really - but I thought I'd give it a shot.

When I tried to "dd" the image over to the new device, it complained that the device was "out of space". I unplugged it, plugged it back into the board, and retried the copy. No dice. Did this a couple more times, thinking I had a bad device.

So, on a whim I put it into my camera and let the camera format the disk. Then, I put it back on my FreeBSD machine, and tried to "dd" the image over to it. At that point, success!
 
I can only guess without further information, but I suspect the device was probably pre-formatted in some way, probably containing some crappy OEM tools for Windows. Maybe you were writing to one of multiple partitions, one which was quite small? It would of been interesting to see what partitions/filesystems etc were visible on the card before wiping it in the camera.

I have no doubt that whatever was already on the card that was cleared by the camera, could of also been cleared in FreeBSD.
 
taken from the SanDisk SD Card Product Manual:

SanDisk SD Cards have an endurance specification for each sector of 100,000 writes typical (reading a logical sector is unlimited). This far exceeds what is typically required in nearly all applications of SD Cards. For example, even very heavy use of the SD Card in cellular phones, personal communicators, pagers and voice recorders will use only a fraction of the total endurance over the typical device’s lifetime. For instance, it would take over 10 years to wear out an area on the SD Card on which a file of any size (from 512 bytes to maximum capacity) was rewritten 3 times per hour, 8 hours a day, 365 days per year
Click to expand...
 
usdmatt said:
I can only guess without further information, but I suspect the device was probably pre-formatted in some way ...

I have no doubt that whatever was already on the card that was cleared by the camera, could of also been cleared in FreeBSD.
Click to expand...

Well, here's hoping :)

The card showed no partition table prior to first attempted write (/dev/da1 only). Really interesting, weird behavior.
 
ronaldlees said:
The card showed no partition table prior to first attempted write (/dev/da1 only). Really interesting, weird behavior.
Click to expand...
I have experience with wrong geometries on SD cards when FreeBSD kernel didn't create device nodes for such malformed partitions. Linux did though.
 
aragats said:
I have experience with wrong geometries on SD cards when FreeBSD kernel didn't create device nodes for such malformed partitions. Linux did though.
Click to expand...

Maybe you're onto something there. Didn't try Linux, but the (probably) simple code in the camera didn't have trouble ...

A little surprised that a Sandisk would be that way, unless a lemon disk.
 
One thing you could have tried was # gpart destroy ... followed by # gpart create ... that might have done the trick.
 
FreeBSD must be pickier about what it'll write to. I've never had an issue with using the dd command against a device (and FreeBSD was seeing the device) on any OS before this happened.

Also I wonder if the card was some kind of fluke, or if instead the cheaper cards are different for some reason (like they want to "encourage" use of them only in cameras). Maybe the firmware doesn't work correctly until it "sees" a camera - although I'm not sure how that'd work on a technical level. The OS calls for iteration of USB device caps, but does the device get info about the host at that point?

This seems to be inferred by the "out of space" response, which would not be OS initiated.
 
FWIW, most cameras (and other "non-computer" devices) using SDcards usually just uses an implementation of FAT (fat32 or something like it) for the filesystem on the cards.
Also FWIW, the F3 program for testing SDcards might compile and work under FreeBSD, I haven't tested it.
 
tingo said:
FWIW, most cameras (and other "non-computer" devices) using SDcards usually just uses an implementation of FAT (fat32 or something like it) for the filesystem on the cards.
Also FWIW, the F3 program for testing SDcards might compile and work under FreeBSD, I haven't tested it.
Click to expand...

Right. But I wonder if the card is not setting up properly before there's any look at a partition table or partition or device space, FAT or otherwise. Does the card detect that it's in a camera some way? Like during iteration of device caps? It could simply return an "out of space" message before any further processing of disk space requests.

The packaging did emphasize cameras, although it didn't say you couldn't use it as a boot disk uSD. Then again, they never do.
 
There is a little ARM core on the card for things like wear leveling. I have seen proof of concept cases where that firmware was made to react on access patterns (4*boot sector read in a row means windows f.e.) and then do things differently. They had a windows install image there which would be backdoored when booting from it and be clean when checked. Or deliver some random sectors when read linear, meaning something like a forensic backup. In court, your lawyer simply asks for the evidence to be rechecked. Different checksum, case closed. There is much fun to be had with such controllers. They are also on harddiscs, btw. And since abuse of them has been spotted in the wild, you don't need a tinfoil hat.
 
Spooky stuff - almost as scary as correlated photons. But I digress. I know that some of the micro SD vendors were actively discouraging the use of their products as boot disks and root file system space for operating systems. IIRC, the reason given was the excessive support calls, based on usage case that really isn't healthy for the device. Don't remember if it was SanDisk.

There could be a one-time set flag, based on where it decided it had been inserted being "OK". I guess I'd have to buy another one at this point, since maybe the flag is set already permanently, and trace the low level USB traffic. At least then I'd know for sure it's the device being belligerent.

Cypress used to sell a neat little dev kit, where you could write/modify your own firmware for the Cypress USB mass storage devices. IIRC it came with reference implementation, so wouldn't need to be total rocket scientist. Starting to sound like a good idea ... :)

Edit: lookup shows that Cypress has discontinued original kit, but can get overall kit that includes original caps for $ouch. Guess there's always Ebay ...
 
You must log in or register to reply here.
Back
Top