Yeah, I understood about the on-SD controller. There is typically some kind of ARM-based microcontroller that does all the block-device to NAND translation. It is doing something wrong and clearly dysfunctional now, though. I am sure that I did successful block operations on the same microSD previously.
On Tue, Mar 6, 2018 at 5:31 PM, Tomas Kuchta <[email protected]> wrote: > When I said card controller, I meant the card controller on/in the actual > SD card. Not the piece of HW attached to your computer. > > My conclusion at the time I was trying to understand the same behavior was > that the in-card controller must be doing file transactions of some kind. > Not behaving quite like basic block device. > > I recall even trying to actively corrupt the card's content, no success. > Still, all worked fine when installing Linux on said cards. > > Hope it helps you avoiding wasting whole day or three on this, like I did. > > Tomas > > On Mar 7, 2018 9:23 AM, [email protected] wrote: > >> I do not believe that SD cards respond to pure raw block writes from dd. >> Not unless the stream looks like files. >> >> I run into the same discovery some time ago. If I remember correctly, dd >> didn't overwrite the content even with random data. It could behave >> different for different firmware, but I tried a few with the same result. >> >> Tomas >> >> On Mar 7, 2018 9:13 AM, "wes" <[email protected]> wrote: >> >> that's only if you want to generate a certain size. otherwise it just keeps >> going until it runs out of blocks to fill. >> >> -wes >> >> On Tue, Mar 6, 2018 at 5:08 PM, Tim Garton <[email protected]> wrote: >> >> > Don't you need a "count=#" option to dd as well? Not at a computer right >> > now otherwise I'd be able to check if that's the case... >> > >> > On Mar 6, 2018 5:02 PM, "Richard England" <[email protected]> >> wrote: >> > >> > > On 03/06/2018 04:20 PM, Tomas Kuchta wrote: >> > > >> > >> Try to delete the original files first. Then create empty file using >> > >> /dev/zero and copy it to the card. I bet that it will be there on the >> > card >> > >> and some of your original data will disappear as result. >> > >> >> > >> My guess is that the card controller is deduplicating your /dev/zero >> > >> blocks >> > >> trying to protect the card from writes. >> > >> >> > >> Tomas >> > >> >> > >> On Mar 6, 2018 7:09 PM, "Russell Senior" <[email protected]> >> > >> wrote: >> > >> >> > >> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior >> > >>> <[email protected]> wrote: >> > >>> >> > >>>> On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock <[email protected]> >> > >>>> wrote: >> > >>>> >> > >>>>> My initial attempt to google this was unsuccessful (most people >> point >> > >>>>>> out the write protect tab, not my problem). >> > >>>>>> >> > >>>>> >> > >>>>> Bad switch on the write protect tab? (The tab operates a tiny >> > switch.) >> > >>>>> >> > >>>> Nope. >> > >>>> >> > >>>> I can turn the switch to lock and it mounts the device read only >> very >> > >>>> clearly. The behavior I observe is that it happily writes /dev/zero >> > >>>> over the block device, but then when I read again, the old data is >> > >>>> still present. >> > >>>> >> > >>> For example, if I flip the tab to write protect tab to "Lock", I get >> > >>> this: >> > >>> >> > >>> # dd if=/dev/zero of=/dev/sdc status=progress bs=1M >> > >>> dd: failed to open '/dev/sdc': Read-only file system >> > >>> _______________________________________________ >> > >>> PLUG mailing list >> > >>> [email protected] >> > >>> http://lists.pdxlinux.org/mailman/listinfo/plug >> > >>> >> > >>> _______________________________________________ >> > >> PLUG mailing list >> > >> [email protected] >> > >> http://lists.pdxlinux.org/mailman/listinfo/plug >> > >> >> > > >> > > |Perhaps using dd if=/dev/urandom |of=/dev/sdc status=progress bs=1M >> > > ...just a thought. >> > > >> > > _______________________________________________ >> > > PLUG mailing list >> > > [email protected] >> > > http://lists.pdxlinux.org/mailman/listinfo/plug >> > > >> > _______________________________________________ >> > PLUG mailing list >> > [email protected] >> > http://lists.pdxlinux.org/mailman/listinfo/plug >> > >> _______________________________________________ >> PLUG mailing list >> [email protected] >> http://lists.pdxlinux.org/mailman/listinfo/plug >> >> >> > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
