the new build was delayed due to other unforeseen bugs needing squished. Sorry for the late update!
is the github you build this in public? I would like to see commits and when there done and what not
@Wolfvak's repo was posted here, and that's the repo with the keyb/mouse code. I'm planning on hosting my modified buildroot repo once I feel it's working well enough without relying on my system's setup specifically (absolute paths and whatnot)
Busybox is a helper utility, not a shell. Several Linux commands are being handled by Busybox to save space.
so far...
I'm hoping to see the IR sensor get support eventually (that's on @Wolfvak's side though) as you could technically use that for file transfer, simple communication or, hell, just as an excuse to use your 3DS as a TV remote. If we figure out the Wi-Fi chip's workings and write/adapt a driver for it, we'd immediately broaden the scope of things doable with Linux 3DS IMMENSELY.
EDIT: found... *some* documentation on the Wi-Fi registers. That's a start, at least.
https://www.3dbrew.org/wiki/WIFI_Registers
Last edited by ParzivalWolfram,
IR support sounds pretty useless because nobody really does have an IR receiver, and most modern TVs just use other protocols (I've mostly seen BLE recently). As for WiFi, the chip in the 3DS has already been identified (by the 3dbrew people) as an AR6014 that communicates through SDIO, but I haven't really confirmed this hardware, nor really managed to test it (whenever I added the chip to the device tree it just would pretend it wasn't there, and yes the driver was compiled into the kernel).
Really, right now I'm focusing more on SD performance and protocol improvements. I'm debating as to whether arm9linuxfw should just expose a dumb block device you can read/write from, or a full MMC interface to send commands to.
Block device pros:
- Simpler to implement in the ARM9 side
- Already well tested and known to work
- It can use DMA in the future to process requests asynchronously
Block device cons:
- It is it's own non-standard device (currently /dev/ctr_mmc_{a,b} for NAND and SD)
- It won't cache the data that was read for some reason (it used to do so in 4.20)
- Harder to implement and test in the ARM11 side
- Extremely hard to implement card hotplugging
MMC pros:
- Uses a standard device interface (/dev/mmcblk)
- Linux already has a ton of code to handle MMC cards, including proper timeouts
- Has the best SD card configuration possible
- Can easily detect card removal and insertion
- Can dump CSD/CID, could even be used to unlock password locked NANDs (GW bricked consoles) in place, using nothing more than an ntrboot card
MMC cons:
- Complex to implement in the ARM9 side, it would need a passthrough for every single functionality the MMC controller provides
- Every single command Linux wants to send to the card involves a PXI transaction (this could be mitigated a bit with some tricks)
- I'm not sure how well it would handle a single controller that handles both an eMMC chip and an SD card
- There isn't a single example / skeleton driver for MMC hosts, so I'd have to understand an existing driver (and the hardware it works with), and modify it to fit with the 3DS' chip (there is an existing TMIO driver, which is very close to the chip the 3DS uses, but Linux can't directly access it because it's gated by the ARM9)
Similar threads
- No one is chatting at the moment.
-
-
@
Psionic Roshambo:
I remember one time I downloaded like a 500MB ISO file on 56K and that literally took like 2 days -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
