SD card low level read

[MarkMLl]

Perhaps after initializing the SD card is stuck in SPI mode and can't be brought back into SD mode (though judging from the SD card spec the card should allow this with each power up sequence).

...

Again, it does not matter if the SD card is formatted with FAT or not. If the whole disk is not available in disk management then something else went wrong.

I've not seen a device get "stuck" like that, but there's always the possibility that it could be forced if the embedded RISCOS wrote something to one of the engineering/configuration pages.

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.

** 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.).

MarkMLl

[geraldholdsworth]

Does the /device/ appear as e.g. /dev/sdb when plugged in? Note that I'm not talking about the /filesystem/ here, or about individual /files/ on the filesystem.

Sorry, been busy for a few days with work.

I'm not using Linux, but I need to support it. I've only heard rumours that there is a RISC OS driver for Linux (or, more specifically, ADFS).

Under macOS, a RPi bootable RPi card (and disc image) has a FAT16 partition which macOS can mount. But, the RISC OS partition appears red and unmountable. Looking at the hex dump of the image I can see the RISC OS partition, as expected (in fact, it appears to be interleaved with the FAT16 partition). So I just need to be able to access an SD card in the same way as an image file.

I'm going to fire up my RPi next, booting into RISC OS, and format an SD card as ADFS, then see what macOS makes of it.

Note that the OP, although it sounds like he has the same issue as myself, is not trying to access a RISC OS partition.

[geraldholdsworth]

Just did a quick Internet search for "ADFS driver for Linux" and found that you can, or at least you could, read ADFS (RISC OS) images under Linux natively, but only as read-only. However, I don't know Linux well and only have it installed inside a VirtualBox for compiling Lazarus projects (which I can now do in macOS without bothering to fire up Linux).

[MarkMLl]

Assume that the number of people who know RISCOS here is minimal, and that it is at best only peripherally relevant since you're not being asked to produce a program to run on it.

Get yourself a spare PC, stick e.g. Ubuntu on it- NOT in a VM- and then by and large we'll be able to talk you through enough to work out roughly what's going on.

MarkMLl

[geraldholdsworth]

I've had another look at found this, which should do the job for what I'm after:
https://forum.lazarus.freepascal.org/index.php?topic=27769.0
But only appears to be for Windows. I also need to work out how to get a list of all devices and partitions. Again, there is a post that shows that, but, again, only for Windows (32 bit), although there is talk of using Linux - guess I could do trial and error and enumerate the disc number and partition number until it errors out.

[dseligo]

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).

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

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]

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.

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).

** 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.).

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).

Only if I had more time...

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]

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).

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.

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.

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]

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).

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.

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.

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.

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.

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