ubootNanoPCT4: Init at 2021.01

[samueldr]

Motivation for this change

For @tmountain, do not merge without their approval of the PR.

Assuming this board doesn't do anything extremely weird, it should work just like every other RK3399 board with mainline u-boot.

To test:

 $ nix-build -A pkgsCross.aarch64-multiplatform.ubootNanoPCT4
[...]
  CFGCHK  u-boot.cfg
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/fpryf9d42kayllzwv619rzmsjlgdclvw-uboot-nanopc-t4-rk3399_defconfig-2021.01-aarch64-unknown-linux-gnu
patching script interpreter paths in /nix/store/fpryf9d42kayllzwv619rzmsjlgdclvw-uboot-nanopc-t4-rk3399_defconfig-2021.01-aarch64-unknown-linux-gnu
checking for references to /build/ in /nix/store/fpryf9d42kayllzwv619rzmsjlgdclvw-uboot-nanopc-t4-rk3399_defconfig-2021.01-aarch64-unknown-linux-gnu...
/nix/store/fpryf9d42kayllzwv619rzmsjlgdclvw-uboot-nanopc-t4-rk3399_defconfig-2021.01-aarch64-unknown-linux-gnu

 $ dd if=result/idbloader.img of=/dev/mmcblkX conv=fsync,notrunc bs=512 seek=64

 $ dd if=result/u-boot.itb of=/dev/mmcblkX conv=fsync,notrunc bs=512 seek=16384

It is unknown to me if the HDMI output during u-boot should or should not be working.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/) Lacking hardware!
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[samueldr]

Converted to draft until @tmountain verifies it works.

[tmountain]

I tried building as instructed, and I ran into the following issue.

$ git clone https://github.com/samueldr/nixpkgs.git
$ git checkout feature/u-boot-nanopc-t4-rk3399
$ nix-build -j6 -A pkgsCross.aarch64-multiplatform.ubootNanoPCT4

make: *** [Makefile:940: all] Error 2
builder for '/nix/store/fffgk84q7b22qxlzxaxk19ihya32kdm0-aarch64-unknown-linux-gnu-stage-static-gcc-debug-10.2.0.drv' failed with exit code 2
cannot build derivation '/nix/store/lh4fnlvzigz78j5kc89w3xg42jx4hzfh-aarch64-unknown-linux-gnu-stage-static-gcc-debug-wrapper-10.2.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/v5blkadz217pm41dq0dvr1xw3w97808d-stdenv-linux.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/ym4vc0269ipxkdwzgdd41wl34cx3y8ks-glibc-2.32-24-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/9ps20aawh3l5rxsz2z7v0h1mysapvcya-aarch64-unknown-linux-gnu-stage-final-gcc-debug-wrapper-9.3.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/k6zm5n5bh369i23ssqmcmjbixnfq65xx-perl-5.32.0-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/nxb398h5fvw8cfspgdb1vy0z7gz6ixip-openssl-1.1.1i-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/svmjdfdadrd75cvwg9ad9k11kh04w9s2-stdenv-linux.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/43bmlkajn1jxqzc6nxprn5pbnbxlbnj7-uboot-nanopc-t4-rk3399_defconfig-2021.01-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
error: build of '/nix/store/43bmlkajn1jxqzc6nxprn5pbnbxlbnj7-uboot-nanopc-t4-rk3399_defconfig-2021.01-aarch64-unknown-linux-gnu.drv' failed

New to Nix, so please let me know if I'm doing something wrong.

[samueldr]

Was this done on the device itself? The exact instructions I shared were to cross-compile from an x86_64 system.

To do it on the AArch64 system:

 $ nix-build -A ubootNanoPCT4

[tmountain]

Got it to build just fine after switching away from the cross-compile version. I installed the image, and it tries to boot, but it gets stuck in a Getty loop (loading the info below repeatedly, see the screenshot).

https://imgur.com/a/Ryrh90t

Re-flashing with the pre-built u-boot images that I took from Armbian u-boot resolves the issue, and I can boot the Nix installer successfully.

[tmountain]

Doing some digging is leading me to wonder if this is related to CPU frequency. This issue showed the same symptom (Getty restarting), and the discussion pointed towards CPU frequency. In previous u-boot builds for the NanoPC-T4, I have seen images incorporated with a specific frequency:

  # taken from https://github.com/archlinuxarm/PKGBUILDs/pull/1728/files
  tools/mkimage -n rk3399 -T rksd -d ../rkbin/bin/rk33/rk3399_ddr_933MHz_v1.23.bin "${pkgdir}/boot/idbloader.img"
  cat ../rkbin/bin/rk33/rk3399_miniloader_v1.19.bin >> "${pkgdir}/boot/idbloader.img"

Not sure if it is related, but throwing out a suggestion in case it is helpful. I'm available to continue testing if needed.

[lopsided98]

I'm not familiar with this specific problem, but I think that frequency refers to the DRAM frequency. That file is the first stage bootloader (TPL) that does DRAM initialization.

With the Rock64 (RK3328), the U-Boot TPL doesn't work right and the kernel would usually crash before finishing booting, presumably due to memory corruption. I had to use the Rockchip provided binary blob instead. With the RockPro64 (RK3399), the U-Boot TPL works, but maybe it doesn't for the NanoPC-T4.

[tmountain]

I got a USB-to-TTL serial cable and used it to capture the boot messages via UART. Here's the full boot log for the image resulting from:

 $ nix-build -A ubootNanoPCT4

https://gist.github.com/tmountain/f3fd939dece80aaeb069c28db7d54e3d

And... here's what a successful boot looks like in case that is helpful (using the pre-built u-boot images from Armbian).

https://gist.github.com/tmountain/6b35dc5890ee15eae3c7ad15752f11c5

[tmountain]

@samueldr

After spending a ton of time on this, I can confidently say that the NanoPC-T4 does not work with the upstream u-boot. The only u-boot that I have been able to get to work reliably is the u-boot provided with Armbian (heavily patched), and after a lot of digging, I have extrapolated the appropriate patches and set up my own custom u-boot repo, which consists of the u-boot v2020.10 release with the appropriate Armbian patches applied.

My repo and relevant build instructions are available here:

https://github.com/tmountain/u-boot-nanopct4

I believe this repo provides a solid basis for a Nix derivation as it applies to u-boot and the NanoPC-T4; however, I'm uncertain what the Nix policy is regarding unofficial repos, etc. That said, you can view the patch itself here.

I'd be happy to take a stab at creating a new PR built around this work if it makes sense. If not, well... I'll keep the repo around for folks that want to build their own u-boot images for the nano.

Lastly, I tried reporting the NanoPC-T4 issues to the u-boot mailing list, but I did not receive a response.

[tmountain]

Based on all my findings above, I have submitted a new PR here:

#111034