zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has joined #nixos-aarch64
zarel has quit [Ping timeout: 264 seconds]
zarel has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-aarch64
quinn has joined #nixos-aarch64
cript0nauta has quit [Remote host closed the connection]
<cole-h>
At some point in the near future I was thinking of setting up my Rock64 with NixOS. Does anybody have or know of any relevant configuration I could peek at?
<samueldr>
lopsided//98 edited it recently enough with AFAIK all good and recent information
<cole-h>
Thanks, I remember finding that page previously, but forgot about it...
<samueldr>
might also be another github user to look for configs, dunno if it's public
<thefloweringash>
Hmm. I don’t think that repo is really relevant any more. nixpkgs has uboot now, mainline kernel mostly works, just need to set up a generic image
<samueldr>
nice to have confirmation, I thought mainline must have been good
<samueldr>
thefloweringash: do you know if there is a u-boot for the SPI flash that is useful?
<thefloweringash>
I didn’t look much past microSD booting.
<samueldr>
cole-h: the "quick" setup guide is that you'll need to install u-boot on the generic sd image, and then that generic sd image should be able to boot
<samueldr>
you install "in-place"
<samueldr>
so rather than booting from usb and installing to /mnt, you "just" change the /etc/configuration.nix (that you'll have to create
<thefloweringash>
I think USB3 on mainline only required a dtb patch as of about 5.0. Though it stopped working recently and I haven’t found the time to debug it yet.
<samueldr>
if another kernel is needed, it's likely possible to cross-compile
<samueldr>
(since you don't want to build on the community machine for your trustable infra :))
<cole-h>
samueldr: Sorry, not grokking that installation stuff... I wouldn't be using nixos-install from a `nix-build -A .....sdImage -I nixos-config=iso.nix`, where iso.nix has the rock64Uboot stuff setup?
<samueldr>
oh, does the device have an eMMC?
<samueldr>
in that case yes, you could also nixos-install to the eMMC
<samueldr>
but generally, the sd image has been built with the expectation that you rebuild ontop of the first generation
<cole-h>
I wonder if I could install from SD or USB, but boot from an external USB drive... since SD's have such low durability
<thefloweringash>
I just put uboot on a microSD and everything else on usb3
<samueldr>
cole-h: do you have an idea of how the RK3399 boot flow works?
<samueldr>
or, RKwhatever
<cole-h>
Nope :^)
<thefloweringash>
But it’s not super interesting. u-boot goes on the card by itself and does magic extlinux stuff.
<cole-h>
I had originally gotten it with the plan to set it up as a nextcloud device
<samueldr>
the SoC (the CPU) has a small program built-in that will look for some "storage" devices, the SPI Flash, the eMMC, and SD card in order
<samueldr>
it will look for a bootable program that it can recognize
orivej_ has quit [Ping timeout: 246 seconds]
<thefloweringash>
I think the u-boot setup is so external to my config it won’t even be in that repo
<samueldr>
the SoC will boot the first program it finds
orivej has joined #nixos-aarch64
<samueldr>
for block devices (SD, eMMC), it looks at a particular disk offset, here it's sector 64 (512*64 bytes)
<samueldr>
this, in most cases, and in the case we're talking about, ends up booting u-boot
<samueldr>
u-boot, itself, is a confusing piece of tech :)
<samueldr>
it's playing the roles of both a firmware (like a BIOS or UEFI) and a bootloader (grub, systemd-boot, syslinux)
<samueldr>
u-boot will initialize some (most?) hardware, and then you're mostly done with Rockchip specific things
<samueldr>
some defaults may end up different on a rockchip-based platform, e.g. the u-boot search order, but it's configurable
<cole-h>
So I would first image the SD with ubootRock64 as described on that wiki page. If I plug in a USB that's been imaged with a custom NixOS installer, will that be automagically booted? Or am I misunderstanding?
<thefloweringash>
That should work
<cole-h>
I wonder if I could enable the write-lock on my SD after imaging it with the uboot...
<thefloweringash>
Or do what I did and get an arm board with a miswired microSD slot that is always read only ;-)
<cole-h>
Hehehe
<cole-h>
Well, it's small enough that I'll have a chance to use my 2GB SD card :P
<cole-h>
I wonder if I have anything smaller
orivej has quit [Quit: No Ping reply in 180 seconds.]
<samueldr>
sorry, had to attend to something
<samueldr>
u-boot, in its own boot order, searches for a couple strategies
<samueldr>
but for our images, it searches for a partition flagged bootable, with a boot/extlinux.conf (or simply extlinux.conf file at the root)
orivej has joined #nixos-aarch64
<samueldr>
another strategy it can use is search for a EFI program on an ESP, but that can get confusing fast, and there are some issues related to loading the right device FDT (.dtb)
alp has quit [Ping timeout: 272 seconds]
<cole-h>
samueldr: OK, I'm about to write the stuff to my SD -- when you say to remove all the partitions, can I just do `dd if=... of=/dev/sdf ...`, or do I actually need to ensure I remove the partitions using some tool?
<samueldr>
so in a week or two I'll be able to know what I did wrong, if it's even my fault
<samueldr>
cole-h: you don't technically have to remove the partitions, but if you don't it can get confusing fast :)
<cole-h>
Would that `dd` invocation not remove/corrupt the partition table?
<samueldr>
the ones on the wiki page (idbloader/u-boot) won't touch the partition table
<cole-h>
I see.
<samueldr>
if you dd if=/dev/zero bs=1M count=8 of=/dev/... it should wipe it clean enough
<samueldr>
(I don't remember how long a GPT is
<cole-h>
I could also just zero the entire thing, I guess :P
<samueldr>
that would also work
<samueldr>
the main reason I said to remove partitions is to ensure they don't end up getting mounted and corrupting the "firmware" that is installed at an arbitrary offset
<cole-h>
Ah, I see.
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
<cole-h>
Oh wait I think this 2GB one was the dead one from my pihole... lol.
<samueldr>
haha
<samueldr>
keep it
<samueldr>
it could be useful if e.g. the first few dozen MB are good
<samueldr>
you could use it to host a mostly-read-only uefi implementation https://rpi4-uefi.dev/
<samueldr>
that's what I'm using on a rpi3 setup, a "dead" µsd that still has enough working space for this
<samueldr>
in turn, that makes the raspberry pi behave like a completely coherent and modern piece of computing
<samueldr>
I can just put a usb drive with the aarch64 uefi iso
<samueldr>
and install using grub
<samueldr>
(on another usb device)
<cole-h>
I had a spare SD that I switched it to instead :P (The SD card death happened months ago now)
<samueldr>
it's, sadly, not yet 100% working on the rpi4 :(
<samueldr>
though if it's dead enough, bin it in the e-waste
<cole-h>
Well, badblocks doesn't say anything bad about the SD
<cole-h>
I can certainly read and write
<cole-h>
Guess it just got corrupted somehow, then.
<samueldr>
ah, so it might simply have been filesystem corruption
<cole-h>
Yep
<samueldr>
which is not an SD thing, but a raspberry pi thing AFAIUI
<cole-h>
Very cool...
<samueldr>
allegedly its power issues can make it unreliable with sd cards, too
<clever>
samueldr: nice!
<samueldr>
(which is how the meme of sd cards being fiddly was born)
orivej has quit [Ping timeout: 264 seconds]
<clever>
samueldr: i'm currently looking into how DPI and the pixel valves work...