Forum > Windows

SD card low level read

<< < (5/5)

dseligo:

--- Quote from: MarkMLl on June 21, 2022, 11:06:48 am ---
--- Quote from: dseligo on June 20, 2022, 07:08:05 pm ---No. I have these devices which initialize SD card and after that cards aren't recognized in Windows or Linux at all. Cards work just fine in the device (device writes data to it and it can read data from card).

--- End quote ---

What do you mean? Do you mean that it isn't auto-mounted, or do you mean that it doesn't appear as e.g. /dev/sdb?

If it doesn't appear as /dev/sdb then what does the kernel log tell you?

In any case, what sort of device are you using between the card and the PC?

MarkMLl

--- End quote ---

I think it doesn't appear as a device, but I'm not sure. I work mostly under Windows (and I'm sure it doesn't appear as a drive there).
I'll test it in a couple of days and report it.

Only if I had more time...

PascalDragon:

--- Quote from: MarkMLl on June 22, 2022, 02:51:41 pm ---Noting https://www.riscosopen.org/forum/forums/11/topics/2244 I think the most likely thing is that RISCOS has wiped the partition and initialised a single (SDFS?) filesystem, in which case there's a real possibility that either an external (USB-connected?) interface box refuses to recognise it ** or that the OS (or more specifically, a desktop environment) won't attempt to auto-mount it without manual intervention. In any event, if OP isn't going to tell us what he's doing then he's the one that's stuck.
--- End quote ---

As dseligo wrote they can't access it using PhysicalDriveXXX on Windows which means that Windows (and the connected card reader) weren't able to initialize the SD card correctly. If it's only partitioned differently it won't matter, cause as long as the SD card can be initialized correctly it can be accessed (minus bad sectors obviously).


--- Quote from: MarkMLl on June 22, 2022, 02:51:41 pm ---** That might sound improbable, but SD-Cards are now a subsystem in their own right with their own engineering tradition: e.g. preferred partitioning and filesystem layout to put the FAT onto more-robust storage than is used for the data area. Taking that sort of thing into account, even though I've not seen an interface box present a card as other than a linear sector image (at least to the standard storage APIs, it's entirely reasonable that something of comparatively recent manufacture could get confused if its attempt at clever device management were stymied by a non-standard layout (i.e. no partition table etc.).
--- End quote ---

SD cards don't provide such mechanisms to the outside world. eMMC devices however do. Just look at the SD specification for the former.

Speaking of which: what might be possible is that the card is locked. I don't know if any ordinary USB reader correctly converts this state to the suitable SCSI commands used by the Mass Storage Protocol, but at least with an integrated, non-USB reader it should be possible to unlock the card if that is the case, though I don't know if Windows provides any mechanism for that. For Linux see here (though you need a SD card reader that displays the card as /dev/mmcXXX instead of /dev/sdXXX).


--- Quote from: dseligo on June 22, 2022, 10:03:26 pm ---Only if I had more time...

--- End quote ---

Do you by any chance know how these SD cards were initialized and in what environment they're used? Maybe some of use could try to reproduce this then.

MarkMLl:

--- Quote from: PascalDragon on June 23, 2022, 09:24:18 am ---As dseligo wrote they can't access it using PhysicalDriveXXX on Windows which means that Windows (and the connected card reader) weren't able to initialize the SD card correctly. If it's only partitioned differently it won't matter, cause as long as the SD card can be initialized correctly it can be accessed (minus bad sectors obviously).

--- End quote ---

Yes, /provided/ that the reader device doesn't crash because irrespective of the interface it exposes over USB it gets confused by a (partition table or) filesystem type it's not expecting.


--- Quote ---Do you by any chance know how these SD cards were initialized and in what environment they're used? Maybe some of use could try to reproduce this then.

--- End quote ---

I think he's already said that they were ordinary cards which became unmountable (to a PC) after an embedded system had put RISCOS on them.

I bet that embedded system was written by a Cambridge graduate. I have seen such things before (and not via Pace).

MarkMLl

PascalDragon:

--- Quote from: MarkMLl on June 23, 2022, 11:11:41 am ---
--- Quote from: PascalDragon on June 23, 2022, 09:24:18 am ---As dseligo wrote they can't access it using PhysicalDriveXXX on Windows which means that Windows (and the connected card reader) weren't able to initialize the SD card correctly. If it's only partitioned differently it won't matter, cause as long as the SD card can be initialized correctly it can be accessed (minus bad sectors obviously).

--- End quote ---

Yes, /provided/ that the reader device doesn't crash because irrespective of the interface it exposes over USB it gets confused by a (partition table or) filesystem type it's not expecting.
--- End quote ---

That would only be a case for some kind of smart reader that allows e.g. to copy files from one card to another with the press of a button on the reader or something. For anything else a reader doesn't need to access the partition table or the file system and considering that the manufacturers want to go as cheaply as possible they won't include such expensive functionality if they don't have to.


--- Quote from: MarkMLl on June 23, 2022, 11:11:41 am ---
--- Quote ---Do you by any chance know how these SD cards were initialized and in what environment they're used? Maybe some of use could try to reproduce this then.

--- End quote ---

I think he's already said that they were ordinary cards which became unmountable (to a PC) after an embedded system had put RISCOS on them.

--- End quote ---

The question is whether this process is reproducible, especially by someone else than dseligo.

Navigation

[0] Message Index

[*] Previous page

Go to full version