On Wed, 08 Apr 2015 10:34:20 +0000, Andrew Gabriel wrote:

In article
-
september.org,
Tim+ writes:
The Other Mike wrote:
On Wed, 8 Apr 2015 08:20:13 +0000 (UTC), Tim+
wrote:

We've got an 8gB SD card that has lost its "write-protect" switch
which has unfortunately converted it to read-only.

A quick shufti inside doesn't reveal any obvious switch connections
so I'm guessing the switch jumpers a couple of legs on the memory
chip.

https://www.dropbox.com/s/j3fi8icqqx...-04-2015%2018%
2057%2040.jpg?dl=0

If there anyway of rescuing the card? It's not really about the
money, just the challenge. ;-)

There are no switch contacts in there, the switch is in the socket.

Just use a bit of thin tape/epoxy/bodyfiller.

Doh! Should have realised.

Not all sockets even bother connecting up the switch contacts.
In any case, it's up to the OS if it takes any notice of write protect
on SD cards - it's not implemented in hardware.

As far as I know that's true[1]. It's not like it was with floppy disk
drives where the write protect disabled the write amp circuit in the
drive itself as well as setting a flag to the OS.

However, there still remains a possibility for the controller chip in
the card reader to implement exactly the same mechanism for write
protection as was standard with floppy disk drives so you can't totally
rule this out (but manufacturers being what they are, this does seem
unlikely).

[1] It's certainly true of the SD card slot in Canon P&S and 'Bridge'
cameras otherwise the CHDK wouldn't be able to use the write protect as
an indicator to autoload itself and allow the camera to *still* write to
the card.

--
Johnny B Good

On Wed, 08 Apr 2015 15:33:26 GMT, Johnny B Good
wrote:

On Wed, 08 Apr 2015 10:34:20 +0000, Andrew Gabriel wrote:

In article
-
september.org,
Tim+ writes:
The Other Mike wrote:
On Wed, 8 Apr 2015 08:20:13 +0000 (UTC), Tim+
wrote:

We've got an 8gB SD card that has lost its "write-protect" switch
which has unfortunately converted it to read-only.

A quick shufti inside doesn't reveal any obvious switch connections
so I'm guessing the switch jumpers a couple of legs on the memory
chip.

https://www.dropbox.com/s/j3fi8icqqx...-04-2015%2018%
2057%2040.jpg?dl=0

If there anyway of rescuing the card? It's not really about the
money, just the challenge. ;-)

There are no switch contacts in there, the switch is in the socket.

Just use a bit of thin tape/epoxy/bodyfiller.

Doh! Should have realised.

Not all sockets even bother connecting up the switch contacts.
In any case, it's up to the OS if it takes any notice of write protect
on SD cards - it's not implemented in hardware.

As far as I know that's true[1]. It's not like it was with floppy disk
drives where the write protect disabled the write amp circuit in the
drive itself as well as setting a flag to the OS.

However, there still remains a possibility for the controller chip in
the card reader to implement exactly the same mechanism for write
protection as was standard with floppy disk drives so you can't totally
rule this out (but manufacturers being what they are, this does seem
unlikely).

[1] It's certainly true of the SD card slot in Canon P&S and 'Bridge'
cameras otherwise the CHDK wouldn't be able to use the write protect as
an indicator to autoload itself and allow the camera to *still* write to
the card.


Some VHS machines will happily record index pulses on the control
track irrespective of the anti erasure tab.

I don't know what the tape rental industry thought about it, but the
added information should have been invisible to a machine without the
feature.



--

Graham.

%Profound_observation%

Johnny B Good wrote:
However, there still remains a possibility for the controller chip in
the card reader to implement exactly the same mechanism for write
protection as was standard with floppy disk drives so you can't totally
rule this out (but manufacturers being what they are, this does seem
unlikely).

There are two kinds of card reader:

The kind that has an SDIO controller directly on the SoC - this is common in
phones, tablets, cameras and some laptops. On this, the tab-detect switch
is a GPIO to the SoC and software can do whatever it wants. On Linux this
form shows up as /dev/mmcblk.

Or there's the kind where the card reader is connected by USB. In that case
it presents as a block device to the PC (/dev/sdX on Linux), and there's no
standardised means to indicate the write protect tab to the OS. This is
likely to implement the write protect feature in the firmware of the USB
card reader, so you can't un-protect from the OS.

Theo

In article , Theo Markettos
writes
Johnny B Good wrote:
However, there still remains a possibility for the controller chip in
the card reader to implement exactly the same mechanism for write
protection as was standard with floppy disk drives so you can't totally
rule this out (but manufacturers being what they are, this does seem
unlikely).

There are two kinds of card reader:

The kind that has an SDIO controller directly on the SoC - this is common in
phones, tablets, cameras and some laptops. On this, the tab-detect switch
is a GPIO to the SoC and software can do whatever it wants. On Linux this
form shows up as /dev/mmcblk.

Or there's the kind where the card reader is connected by USB. In that case
it presents as a block device to the PC (/dev/sdX on Linux), and there's no
standardised means to indicate the write protect tab to the OS. This is
likely to implement the write protect feature in the firmware of the USB
card reader, so you can't un-protect from the OS.

Worth mentioning too that there are non-volatile write protect register
bits on the SD card too which cameras frequently use to make everyone's
life more difficult when managing card contents through external
readers.

The setting of the write protect tab has no influence on these register
settings.

On that subject, I don't suppose you've come across any utilities to
manipulate SD card control registers via generic readers have you? I
have an annoying camera that insists on setting the write protect bit
every time it saves an image and it really gets on my tits. Sometimes
you can persuade it to remove the write protection by powering it up
straight into picture preview mode but it is by no means a reliable
solution.

--
fred
it's a ba-na-na . . . .

fred wrote:
On that subject, I don't suppose you've come across any utilities to
manipulate SD card control registers via generic readers have you? I
have an annoying camera that insists on setting the write protect bit
every time it saves an image and it really gets on my tits. Sometimes
you can persuade it to remove the write protection by powering it up
straight into picture preview mode but it is by no means a reliable
solution.

If you plug the card direct into an SDIO controller (/dev/mmcblk...) then
you (or at least your OS) can send it the SD protocol CMDxx commands (eg
CMD41). If you plug it into a USB reader I don't think there's a way to do
that - it just claims to be a block device and there's no standard way to
tell the computer it's an SD card, let alone send SD commands.

I haven't seen nonvolatile write protect commands in my reading of the SD
and SDHCI specs, but SD has support for DRM so maybe they're in there
somewhere. The specs are pretty complicated.

Unless you mean it's a filesystem write protect - permissions set to be
r--r--r-- or equivalent?

Theo

In article , Theo Markettos
writes
fred wrote:
On that subject, I don't suppose you've come across any utilities to
manipulate SD card control registers via generic readers have you? I
have an annoying camera that insists on setting the write protect bit
every time it saves an image and it really gets on my tits. Sometimes
you can persuade it to remove the write protection by powering it up
straight into picture preview mode but it is by no means a reliable
solution.

If you plug the card direct into an SDIO controller (/dev/mmcblk...) then
you (or at least your OS) can send it the SD protocol CMDxx commands (eg
CMD41). If you plug it into a USB reader I don't think there's a way to do
that - it just claims to be a block device and there's no standard way to
tell the computer it's an SD card, let alone send SD commands.

That's useful thanks, I use a USB access device so would need to find a
direct one.

I haven't seen nonvolatile write protect commands in my reading of the SD
and SDHCI specs, but SD has support for DRM so maybe they're in there
somewhere. The specs are pretty complicated.

It's not well known about and it's pretty pointless asking questions on
general forums about them as the uninitiated can't understand you're not
talking about the WP tab.

In the end I found the details by looking at a manufacturer's SD card
data eg Sandisk (1.1MB, 113 page pdf):

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

They're bits within the Card Specific Data (CSD) register (bits 12 &
13), PERM_WRITE_PROTECT, TMP_WRITE_PROTECT.

If you fancy a read, see section 3.5.3, page 3.13 & 3.14 plus other refs
section 1.5.9.10 and 1.5.9.12 on page 1.10.

In the end it went too deep for me to spend time on.

Unless you mean it's a filesystem write protect - permissions set to be
r--r--r-- or equivalent?

No, physical layer stuff, see above.

--
fred
it's a ba-na-na . . . .

fred wrote:
It's not well known about and it's pretty pointless asking questions on
general forums about them as the uninitiated can't understand you're not
talking about the WP tab.

In the end I found the details by looking at a manufacturer's SD card
data eg Sandisk (1.1MB, 113 page pdf):

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

They're bits within the Card Specific Data (CSD) register (bits 12 &
13), PERM_WRITE_PROTECT, TMP_WRITE_PROTECT.

If you fancy a read, see section 3.5.3, page 3.13 & 3.14 plus other refs
section 1.5.9.10 and 1.5.9.12 on page 1.10.

In the end it went too deep for me to spend time on.

Ah, right. There's lots of stuff buried in there.

I'd be tempted to get a Raspberry Pi or similar and hack the kernel to clear
the TMP_WRITE_PROTECT bit - though you have a bit of chicken-and-egg in
booting the Pi. Maybe there's a board that will boot off something that
isn't SD so you have the SD slot clear.

Alternatively, it seems someone has programmed an ATmega to do it:
http://www.seanet.com/~karllunt/sdlocker.html

Theo

In article , Theo Markettos
writes

Ah, right. There's lots of stuff buried in there.

I'd be tempted to get a Raspberry Pi or similar and hack the kernel to clear
the TMP_WRITE_PROTECT bit - though you have a bit of chicken-and-egg in
booting the Pi. Maybe there's a board that will boot off something that
isn't SD so you have the SD slot clear.

My ideal of course would be a utility I could run on the PC before
manage the images there.

Alternatively, it seems someone has programmed an ATmega to do it:
http://www.seanet.com/~karllunt/sdlocker.html

Well found, a truly dinky embedded solution, easy to pop in the slot to
unlock and than pass to the PC based reader.

I see he has made some enhancements, SDlocker 2 now has a passwording
option:

http://www.seanet.com/~karllunt/sdlocker2.html

and someone else has gone smaller, albeit needing a power feed so not
standalone:

https://github.com/Nephiel/sdlocker-tiny

I think I will still try to see if something can be done via an SDIO
controller it would be so much neater.

--
fred
it's a ba-na-na . . . .