Compilation instructions?

[ParzivalWolfram]

I've been following progress on Linux 3DS since I dropped it, and I was wondering what your procedure for compiling is, as I'm willing to test commits on my N3DSXL.

[nickdesaulniers]

$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi make -j$(nproc) nintendo3ds_defconfig
$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi make -j$(nproc)
$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi make -j$(nproc) nintendo3ds_ctr.dtb

see also 1, 2, 3.

[Wolfvak]

We will eventually release a buildroot system to compile the kernel + a small initramfs but as of right now you can disable the hardcoded rootfs directory and use the cpio from the original release.
Keeping this open until that happens.

[nickdesaulniers]

https://gist.github.com/xerpi/3c720d345820691a2985502fcd80268f#gistcomment-3684668 has directions for a basic buildroot image that works. Just need to modify the dts file to tell it not to power down the machine immediately.

But it would be good to add a buildroot repo to this gh project.

[nickdesaulniers]

I plan to rewrite the readme for each project with build steps.

[ParzivalWolfram]

I wonder if I could retool my old buildroot project for this kernel fork... Actually, that was rather painless. Hopefully it builds a little faster than it did on that 600MHz laptop I used to use.

…

On Tue, Mar 30, 2021 at 6:14 PM Nick Desaulniers ***@***.***> wrote: I plan to rewrite the readme for each project with build steps. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHE6CQPQQE5RBU4I2AU7WKTTGJLNJANCNFSM42DE744Q> .

[nickdesaulniers]

I think it would be better to keep the kernel build out of buildroot. It's simpler the other way around IMO; build a buildroot image as an initrd, then place it in the kernel sources and leave it in the kernel tree as rootfs.cpio.gz. The kernel build will produce the zImage with the ramdisk bundled.

I would create a separate git repo under this org that has a script and uses git submodules to clone all relevant sources, and orchestrate the build via shell scripts. It would also be nice for us to provide prebuilt binaries, since most of the time during development not all pieces change and it's generally easier for users to test with those (though they can still use our build scripts if they want).

I think that's a better approach than including patch files for kernel sources in buildroot. That won't scale when we break up the currently single commit for upstreaming.

[nickdesaulniers]

Since we don't want to pollute the linux dir with documentation (at least at this point. We can add documentations to Documentation/ later) for how to build or simply how to run this, do folks have thoughts on either approaches/ideas:

1. enable the wiki for this repo? This makes it quicker to edit/add/change, no commits or git necessary.
2. create a docs repo. Can create a gh-pages branch to have github host a url for us.
3. collaborate with https://3ds.hacks.guide/, https://github.com/hacks-guide/Guide_3DS . Perhaps we should have something more polished first?

I think it would be good to have separate docs for fellow developers vs users that just want to run linux. I guess they don't need to be separate per se. Thoughts?

[ParzivalWolfram]

Honestly, i'd be in favor of using the repo wiki. Too many repos will have build instructions, downloads, etc. in a gist or on some other page, which feels somewhat jarring, personally.

[nickdesaulniers]

SGTM. Yes gists aren't editable from others IIRC, so let's avoid those for documentation. @Wolfvak can you please enable wikis on all repos? One issue is that we wont be able to host binaries on the wiki pages, I think.

[Wolfvak]

Done

[ParzivalWolfram]

I can get Buildroot to spit out a zImage when I fix the hardcoded path in the defconfig, but it doesn't contain a rootfs. I'm not sure how to fix that, as Buildroot won't spit out a rootfs until well after you pass that point.

[nickdesaulniers]

right, because the kernel will fail to build because the kernel config says "look for rootfs.cpio.gz in the current working directory and include it in the build of the kernel." When you build the kernel via buildroot, you're building these in the wrong order. You need to build the buildroot image without building the kernel at all. Then you take the resulting rootfs.cpio.gz and put that in the kernel sources. Then you build the kernel.

[ParzivalWolfram]

right, because the kernel will fail to build because the kernel config says "look for rootfs.cpio.gz in the current working directory and include it in the build of the kernel." When you build the kernel via buildroot, you're building these in the wrong order. You need to build the buildroot image without building the kernel at all. Then you take the resulting rootfs.cpio.gz and put that in the kernel sources. Then you build the kernel.

I tried that, since you stated to do it in the PR I made, but it still spits out a bad zImage.

[nickdesaulniers]

but it still spits out a bad zImage.

If the rootfs.cpio.gz was not in the kernel sources, the kernel build should fail.

If the rootfs.cpio.gz is invalid, non-decompressable, or init is not executable, you should see a kernel panic (that's relatively good, at least the kernel image isn't bad, just the ramdisk is).

===

I've now recompiled firm_linux_loader (instructions) and arm9linuxfw (instructions) and verified they work.

I haven't tried this fork of the kernel yet, maybe something is messed up there with that. Let me verify and see if that's possibly the issue @ParzivalWolfram is hitting.

Where/how should I post binaries of what I have?

[ParzivalWolfram]

If the rootfs.cpio.gz was not in the kernel sources, the kernel build should fail.

If the rootfs.cpio.gz is invalid, non-decompressable, or init is not executable, you should see a kernel panic (that's relatively good, at least the kernel image isn't bad, just the ramdisk is).

It's failing immediately on boot as it can't mount the rootfs. The rootfs i'm building is almost 23MB, the zImage that should contain it is just over 5MB.

[ParzivalWolfram]

This is my buildroot config. (For some reason, I have to hardcode the commit for the kernel header specifically, I can't just tell it to use the master branch like I can the kernel itself.)
config.zip

[nickdesaulniers]

Please see:

1. the Table of Contents linked from any project in this org's wikis.
2. the twitch stream I did this past weekend.

The directions will change more in the future, but we'll try to keep the wikis up to data. Might do more fomal HTML/MD pages. Might upload that twitch video to YT.