Add write support for source/vdev/sdcard.c

[iAmInActions]

This topic was talked about before but noone actually ever finished it. I tried doing it myself but I suck at C so the only thing I actually did was causing a kernel panic whenever a write event got started. Would be nice if someone that actually knows how to work with C would add this functionality.

[Wolfvak]

I just pushed my current progress with it @ https://github.com/linux-3ds/arm9linuxfw/tree/sd-write-support, for some reason arm9linuxfw never gets the write cmd (at least not how I expect it)

last time I worked on it was maybe a week or two ago, because real life™️ got in the way, but I just wanna put this out there to let other people know I at least tried

if anyone has more info on this whole thing please make a PR to the branch? currently writes seem to be discarded (if you write to a mount and sync the filesystems, it's as if the write never happened, and if I put a debug abort in the code that writes to SD it's never triggered)

[FreddyFeuerstein]

I think I at least somewhat understand the cause:

DECLARE_VIRTDEV(
	vdev_sdcard, NULL,
	VDEV_T_BLOCK, VIRTIO_BLK_F_BLK_SIZE, 1,
	sdmc_hard_reset,
	sdmc_cfg_read, vdev_cfg_write_stub, <=== Here
	sdmc_process_vqueue
);

Its declared as a read-only device.

[Wolfvak]

nope... that's for the configuration space

much like PCI, some devices might have internal configuration bytes you can read/write to, in fact part of it is the block size (always hardcoded to 512 bytes) and the device total size in sectors

it makes sense to read from it, but at no point anything needs to be written to it (at least from what I can glance in the official spec), so the write operation is just stubbed

previously it was actually marked as a read-only device with VIRTIO_BLK_F_RO

you can see more information here https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-2390002

[FreddyFeuerstein]

That makes sence.

[FreddyFeuerstein]

Any chance that there might be write support soon?
@Wolfvak

[Wolfvak]

check the main repo, there's an experimental branch where SD card read and write work pretty well, you need the custom arm9linuxfw too

[FreddyFeuerstein]

[...] you need the custom arm9linuxfw too

The simple or the sd write support one?

[Wolfvak]

simple

[FreddyFeuerstein]

nice. thnx

[iAmInActions]

Great, I can finally run DOOM on my 3DS now! Still need to try it though.

[iAmInActions]

@Wolfvak One question: what /dev device is the SD card on now? It isn't at /dev/vda anymore.

[Wolfvak]

/dev/mmcblk0 for the SD card as a whole, /dev/mmcblk0p1 for the first partition

[iAmInActions]

@Wolfvak
no such file or directory. im using the simple branch of arm8linuxfw and the new pxi branch of the kernel.

[iAmInActions]

Is that the wrong constellation of versions or why isn't it working?

[iAmInActions]

I found out what the issue was:
I forgot to copy the .dtb files.

[iAmInActions]

@Wolfvak the new kernel seems to have a different architecture because my rootfs gives a lot of illegal instruction and segmentation faults. uname -a is reporting armv6l as usual but the pi zero build of debian errors out a ton and none of my apps work.

[Wolfvak]

the pi zero is probably built for softfp and not hardfp

this is also way off-topic for this issue

[iAmInActions]

ik. its just the rootfs i still had for testing. btw, the sd card driver works without problems. only issue is the rootfs that worked with the old kernel doesnt work anymore.

[spike11302000]

im currently having a issue with the branch that enables read/write support for sd cards.
when ever i try executing something on the sd card it will randomly segfault or illegal instruction. but when the binary is built in the initrd it works just fine.

i checked the checksum of the files to see if the file got changed some how

i do noticed after i executed the file and try again it will sometimes executes but most of the time it causes a soft kernel panic

[  535.068000] 8<--- cut here ---
[  535.076000] Unhandled fault: page domain fault (0x81b) at 0xb6d60000
[  535.092000] pgd = cbda9092
[  535.104000] [b6d60000] *pgd=27ab3831, *pte=222d955f, *ppte=222d9c7e
[  535.124000] Internal error: : 81b [#1] SMP ARM
[  535.132000] CPU: 1 PID: 252 Comm: grep Not tainted 5.11.0-rc1-g601f87f61c77-dirty #11
[  535.152000] Hardware name: Nintendo 3DS/CTR (Device Tree)
[  535.172000] PC is at v6_coherent_kern_range+0x4/0x2c
[  535.192000] LR is at arm_syscall+0x160/0x2f0
[  535.200000] pc : [<c0113bf0>]    lr : [<c010a774>]    psr: 40000013
[  535.224000] sp : c7adff90  ip : 00c5787d  fp : 00000000
[  535.244000] r10: 00000000  r9 : c7ade000  r8 : c0100244
[  535.264000] r7 : c7ade000  r6 : b6d60134  r5 : b6d60134  r4 : 00000002
[  535.284000] r3 : 00000000  r2 : c11345c0  r1 : b6d60134  r0 : b6d60000
[  535.308000] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  535.328000] Control: 00c5787d  Table: 27a6800a  DAC: 00000051
[  535.348000] Process grep (pid: 252, stack limit = 0x6d49077e)
[  535.372000] Stack: (0xc7adff90 to 0xc7ae0000)
[  535.380000] ff80:                                     b6d60008 ea000000 b6d60134 000f0002
[  535.404000] ffa0: c0100244 c0100060 b6d60008 ea000000 b6d60008 b6d60134 00000000 0000012c
[  535.424000] ffc0: b6d60008 ea000000 b6d60134 000f0002 0167e098 be971350 00000000 00000000
[  535.444000] ffe0: 000003ff be97131c b6f361dc b6f5ea0c 60000010 b6d60008 00000000 00000000
[  535.468000] [<c0113bf0>] (v6_coherent_kern_range) from [<c010a774>] (arm_syscall+0x160/0x2f0)
[  535.488000] [<c010a774>] (arm_syscall) from [<c0100060>] (ret_fast_syscall+0x0/0x58)
[  535.508000] Exception stack(0xc7adffa8 to 0xc7adfff0)
[  535.532000] ffa0:                   b6d60008 ea000000 b6d60008 b6d60134 00000000 0000012c
[  535.552000] ffc0: b6d60008 ea000000 b6d60134 000f0002 0167e098 be971350 00000000 00000000
[  535.576000] ffe0: 000003ff be97131c b6f361dc b6f5ea0c
[  535.596000] Code: ee070f15 e12fff1e e12fff1e e3c0001f (ee070f3a) 
[  535.616000] ---[ end trace d309443f54c30c13 ]---

i have tried multiple different filesystems and formatting without change.
i switched back to the master branch of the linux and arm9linuxfw and i had no issues executing the file but didnt have write support

[iAmInActions]

I had the same issue. building the initrd with multiarch and mounting the main partition and then an ext4 image on it fixed it for me. not the most elegant workaround but it works and i can play doom.

[spike11302000]

that works but i did it a bit differently. instead of having a ext4 image file on a partition i just looped the partition with losetup and mounted the loopback device. i would like a proper fix at some point for this but this works for now

[Wolfvak]

@spike11302000 this is more of a buildroot/kernel issue, can you open a new one there and describe this problem? it's not really related to the SD card support afaik