Closed iAmInActions closed 3 years ago
try mounting /dev/vda2 into some directory and running switch_root
or pivot_root
? I've only tried doing stuff with chroot, but afaict those should work too.
if you really want to boot straight from /dev/vda2, you'll need to add the parameter here https://github.com/linux-3ds/linux/blob/master/arch/arm/boot/dts/nintendo3ds_ctr.dts#L40 (or here https://github.com/linux-3ds/linux/blob/master/arch/arm/boot/dts/nintendo3ds_ktr.dts#L52 if you're running a new3DS)
I think most initial ramdisks have a script that runs on boot and looks through all the available block devices, then boot from it (with UUID matching or something), so if there's a way to do that with buildroot I'd love to know about it
I just tried modding my kernel and it ended in a kernel panic. Your post saved me. I will try that now.
ok, good news and bad news: the bad news: x server still doesn't work. the good news: by modding the /init script to mount vda2 to mnt and running some other stuff afterwards, I was able to switch the root directory.
Once I manage to get it working with xorg and twm desktop, i will open up my own small repo containing the custom kernel and buildroot code and a pre-build disk image of debian for the 3ds.
awesome! please let us know through this issue when that happens
Ok, I found this issue, tried it myself and well, let me introduce you to raspbian on a 3ds running nano editor. rootfs is only readable for some weird reason but still. Pretty cool.
you can try doing mount -o remount,rw /
, or adding rw
to the kernel parameters from before
I made my own initramfs that sets it all up and it works. It boots into any raspberry pi image. BUT there is a big problem: I have my initramfs set to mount the partition (its an ext4 partition on /dev/vda2) as read/write but no matter what I try, it will always show up as read-only. The SD card is writeable on my pc and in the original nintendo 3ds operating system but not under raspbian, buildroot or ubuntu ports. Do you have any idea why that might be the case?
yeah, right now there's no write support on the SD card, sorry I forgot to mention that bit
it should be easy to add but I'm a bit terrified of messing up something in the code and losing data on my SD
eventually it'll be added, but honestly there's so much left to do in the 3DS that it's not a priority
eventually it'll be added, but honestly there's so much left to do in the 3DS that it's not a priority
I think getting the file system support fully working should be a big priority. I mean, once the card can be written on, it should be pretty easy to use gcc or make on the 3ds itself. that would speed up testing and development by quite a bit.
If you don't plan on adding it in the near future, I would like to add it on my own version myself. could you tell me where your current code for reading the sd card is?
Edit: found it in drivers/platform/nintendo3ds/ctr_sdhc.c
Another edit: I don't understand anything of that code. There are a total of 5 comments in 594 lines of code and I suck at c so yeah, not gonna be able to make writing work myself.
that driver is only for the wifi sdio controller
if you wanna look at SD, check here https://github.com/linux-3ds/arm9linuxfw/blob/master/source/vdev/sdcard.c
I'll also open a discussion in that repo regarding SD/eMMC support (https://github.com/linux-3ds/arm9linuxfw/discussions/19)
Write support would be great for my doom port and using the 3ds with a desktop environment.
Hello, I was making my own rootfs with a small x server included and it was getting to a size of around 50 mb. I thought that that is a bit much to build into a kernel and also its a bit annoying to rebuild the kernel for every small change I did to my x configuration. At first, I tried to find a way to pass a kernel argument (root=/dev/vda2) but I could not find one. Then, I had the idea to use a chroot to test it but that did not work as planned because it had problems accessing the frame buffer and therefore was not a viable testing solution. Thats why I want to ask, if there is any way to pass a kernel argument with the root fs or mod the launcher or kernel to use /dev/vda2 as default. Or in the worst case, make the chroot access the frame buffer if none of the above can be implemented easly.