pine64-rock64: init #1280
pine64-rock64: init #1280
Conversation
| "pcie_rockchip_host" | ||
| "phy_rockchip_pcie" | ||
| "sdhci_pci" |
There was a problem hiding this comment.
Is this not detected by nixos-generate-config?
There was a problem hiding this comment.
Mhm. but I guess our installer wouldn't boot, so the normal install workflow wouldn't boot.
There was a problem hiding this comment.
nixos-hardware/pine64/rockpro64/default.nix
Lines 3 to 8 in b12e314
my local config (and, in turn, what was done in this PR) is inspired by how the RockPro64 is configured
There was a problem hiding this comment.
I'm currently using a half-functional build of u-boot/tow-boot, generated from this draft PR Tow-Boot/Tow-Boot#322, so I don't really know how the usual NixOS install process would go
There was a problem hiding this comment.
We can leave those modules in here if you also add a README how to bootstrap the rest of the configuration i.e. instructions to build a installer image.
Without this context it would have little value to have this module in nixos-hardware.
There was a problem hiding this comment.
it's just the generic aarch64 uefi installer iso
I guess it'd be more common to go the u-boot+sd-card image route, like it says on the wiki
which is unlike what I have -- tow-boot+normal EFI installer
I wouldn't really recommend people use a draft PR for their own stuff though
| "phy_rockchip_pcie" | ||
| "sdhci_pci" | ||
| ]; | ||
| kernelModules = [ |
There was a problem hiding this comment.
Why is any of this needed? I don't remember needing to specify this.
There was a problem hiding this comment.
I remember some of them not being detected automatically, but I can remove that boot.kernelModules list entirely if it's out-of-scope for nixos-hardware
There was a problem hiding this comment.
I just copied it from my local config
There was a problem hiding this comment.
So it won't show any graphics if you attach a monitor, or what does this fix? Usually the kernel will match pci/usb vendor ids with drivers and load them as needed.
There was a problem hiding this comment.
I am fine with adding modules if they are actually not recognize by the hardware or if there is a good reason to add them to early boot
There was a problem hiding this comment.
makes sense, then I'll boot once without this list, and I'll compare which modules are loaded
might take a bit, I won't have access to the SBC for a few days
There was a problem hiding this comment.
using this after booting with all modules listed
$ ssh rock64.lan -- lsmod | cut -d' ' -f1 | sort -u > before.txtand this after removing them
$ ssh rock64.lan -- lsmod | cut -d' ' -f1 | sort -u > after.txtI can get a diff
$ diff before.txt after.txtthat shows that these are the modules that are not normally loaded, unless added there by force
panfrost
pcie_rockchip_host
phy_rockchip_pcie
rk3399_dmc
rockchip_dfi
rockchip_isp1
rockchip_rga
rockchip_saradc
sdhci_pci
v4l2_async
v4l2_fwnode
videobuf2_dma_sg
videobuf2_vmalloc
that being said, it still boots and I still get HDMI video out
There was a problem hiding this comment.
panfrost definitely shouldn't be there, lima is the correct driver for the rock64's rk3328 Mali-450 "Utgard" (and it's automatically loaded)
https://wiki.debian.org/PanfrostLima
https://docs.mesa3d.org/drivers/lima.html
There was a problem hiding this comment.
in conclusion: my machine boots without anything specified in boot.initrd.kernelModules and boot.kernelModules
|
@Mic92 since it looks like the rock64 works without any of the changes here, I'm open to simply closing this |
Description of changes
Added
pine64-rock64Things done
nixos-hardwareandimporting it via
<nixos-hardware>or Flake input