-
-
Notifications
You must be signed in to change notification settings - Fork 13.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uboot: add ubootNanoPCT4 for NanoPC-T4 #111034
Conversation
I have marked the previous discussion resolved. Here are the conclusions:
|
Just wanted to say thank you very much @tmountain for this. I was doing some research into running NixOS on my NanoPC T4 but as these kind of devices with uboot are not my area I was mostly just flailing around. Much appreciated, especially with the wiki page instructions. Thanks! |
I'm happy to hear that you have found some benefit in this work. If this pull request gets merged, the next step is to integrate the NanoPC-T4 with this image builder. That should make the process of installing Nix painless for everyone. I will continue refining the guide as we make progress. Thank you for the positive feedback. |
I can confirm this works btw. I got NixOS running on my NanoPC-T4 yesterday using the uboot images provided by @tmountain which I assume were build using this derivation. The NVMe drive is not detected, but that appears to be a kernel driver issue and is separate from uboot. |
Not sure if it is helpful, but I'm using KingSpec 256GB PCIe NVMe (NE-256 2280), and it works out of the box. |
I have a Samsung EVO 960 250GB and it only appears with Friendly Core:
Both Armbian and NixOS don't show anything. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/how-to-provide-missing-headers-to-a-kernel-build/11422/1 |
Hi @samueldr. Just making sure you aren't waiting on anything my side to merge this. I'm contributing to another project, and waiting on this PR to merge before I submit my changes over there. Not trying to bug you--just making sure that there's nothing left on my side. Thanks. |
@GrahamcOfBorg build ubootNanoPCT4 |
Looking forward to have support in https://github.com/Mic92/nixos-aarch64-images |
This was a regression introduced sometime in Linux 5.9.x; the fix wasn't merged until 5.10.17: I confirmed that cherry-picking that one commit and rebuilding the DTB (no need to rebuild the kernel) makes the NVME reappear:
Sorry for posting here; I typed in a response to the same question on Armbian's forum but then it started making me jump through a bunch of hoops, captcha's, and click-the-email nonsense and I just gave up. |
I'm not sure if I was having the same issue, possible. But thanks for bringing this to our attention @a-m-joseph. My fix was to modify NixOS configuration to build some drivers directly into the kernel: {
# Fix for not detecting the NVMe SSD
boot.kernelPackages = pkgs.linuxPackages_5_10;
boot.kernelPatches = [{
name = "pcie-rockchip-config.patch";
patch = null;
extraConfig = ''
NVME_CORE y
BLK_DEV_NVME y
NVME_MULTIPATH y
PCIE_ROCKCHIP y
PCIE_ROCKCHIP_EP y
PCIE_ROCKCHIP_HOST y
PHY_ROCKCHIP_DP y
PHY_ROCKCHIP_PCIE y
PHY_ROCKCHIP_USB y
'';
}];
} https://github.com/jakubgs/nixos-nanopc-t4#nixos-config I will try to use |
We could have those in nixos-hardware as well. |
Sure. Why not, I can make a PR. Although compiling the kernel on the NanoPC-T4 is not the most pleasant experience, especially on a hot day. The poor thing is struggling. And not everyone does use the M.2 slot. One of these days I need to figure out if there's a way to offload some of the compilation to my |
Maybe we can enable the required kernel modules in our stock kernel? |
That would be amazing. |
@a-m-joseph I have tried using Linux kernel
So it appears booting from the M.2 NVMe does indeed require some modules baked into the kernel. |
Correct; you need both:
and
Or you can just put the kernel module in your initrd if you don't want to recompile the kernel. This true with all boot devices (including emmc, sd card, usb, etc)... the block device driver for your root filesystem always needs to be either compiled-in or else have its module included in the initrd. |
@a-m-joseph I have tried your suggestion and added:
But it was not enough to make the system detect the NVMe at boot time. I think more might be needed. |
I've also tested this:
And it also didn't work, so I'm not sure what else I can add. |
@tmountain, thanks again for all the time you put into this. I've been poking at this issue some more, because I have a pile of NanoPC-T4s and I really like them. I've been able to get the NanoPC to pull a second-stage bootloader off of an SPI chip by wiring it to the 40-pin header on the board (my use case needs to keep the firmware in SPI rather than eMMC for security reasons). It definitely loads, initializes the DRAM, prints useful stuff to the serial console, and starts copying the third-stage bootloader to the DRAM, but then things go all haywire. Have you considered the possibility that mainline u-boot simply does not have working DDR3 training for RK3399? As far as I can tell all the rk3399 boards with known-working, blobless mainline u-boot support use DDR4 memory (LPDDR4). For example, RockPro64 and Rock Pi4. The only blobless-boot RK3399 device I know of that uses DDR3 memory is the Samsung gru-kevin -- but that uses coreboot, not u-boot. And I know for a fact that mainline u-boot on gru-kevin does not work (or did not work as of February; there seem to have been a few more commits in March). I'm starting to suspect that the u-boot folks have never actually tested their RK3399 DDR3 training routines. They seem to have checked in defconfigs for a huge pile of rk3399 boards without testing many of them... basically TODO/FIXME placeholders. At least that's what I suspect. Let me know if this sounds plausible. FWIW my interest here is not specifically Nix-related, although I am learning nixpkgs (outside of NixOS). |
Motivation for this change
This adds support for the NanoPC-T4 to u-boot. The NanoPC-T4 does not work with upstream u-boot out of the box , so I created a custom repo and applied the necessary changes, which I extracted from the Armbian builder project.
The repo referenced in my PR is the result of applying this patch to the v2020.10 u-boot release.
The NanoPC-T4 will not boot if you build u-boot against a bl31.elf file. It only works if you produce a standalone trust.bin via the rkbin trust_merger utility. I have not been able to determine why this is, but Armbian ships with a custom trust.ini file with the following section which may play a role:
The trust_merger utility does not work with Nix out of the box, so I created a separate derivation to wrap it and make it run successfully. This resulted in the need to add a reference to callPackage to the uboot derivation.
If you'd prefer that I reformulate the PR to do the actual patching during the build, I can try to accommodate that request with some basic guidance.
Things done
./result/bin/
)