<NickHu>
samueldr: I saw in a GitHub issue that you at some point were using a megous kernel in nixos - I'm having some issues with NixOS on my Orange Pi PC2 - it seems to lock up whenever I'm doing something heavy (e.g. compiling kernels) on the mainline kernel, and I have a sneaking suspicion that if I were able to use the megous kernel this problem might go away
<NickHu>
I saw that there are prebuilt versions, and I wondered if you had experimented with that because with many of these boards it takes like a day or more to compile linux
<NickHu>
Also is it possible to build a closure/derivation via qemu from my desktop? Has anyone tried that kind of thing?
<samueldr>
never used the prebuilt versions
<samueldr>
I'm not even sure I used the "proper" branches of their kernel
<samueldr>
search for binfmt qemu compilation, I think it'll turn up some results
<samueldr>
some users do
<samueldr>
I really don't :)
<NickHu>
I'm not a kernel expert, but could I temporarily just copy the prebuilt binaries to my /boot directory and point u-boot towards them, just enough to get my nixos-rebuild going without freezing?
<samueldr>
it could
<samueldr>
it all depends on what's built-in and what's built as modules
<samueldr>
another option is to go with cross-compilation, rather than emulating aarch64 on your desktop
<samueldr>
not sure how you'd do it _just_ for the kernel
<samueldr>
I'm sure there are fancy tricks to achieve that
<NickHu>
Oh I didn't realise you could cross-compile a kernel
<NickHu>
(without days of pain)
<samueldr>
it sure works fine with NixOS (thankfully)
<samueldr>
not everything in NixOS cross-compiles fine though
<samueldr>
and cross-compilation output is a different output than the native outputs
<samueldr>
useful for devices where the mainline kernel really doesn't work
<NickHu>
By the way, I see lots of stuff like "error 9 failed to decompress xz data", "g++: internal compiler error: Segmentation fault", and stuff like that when just building random packages on my board
<samueldr>
sounds like things are generally bad
<NickHu>
Is this just fairly common with nixos on arm or is it indicative of mainline not playing nice on my board?
<samueldr>
might be memory exhaustion?
<samueldr>
do you have swap?
<samueldr>
allwinner board I don't expect more than 2GB of RAM
<NickHu>
Yeah, and it's not all being utilised
<NickHu>
1GB RAM + 1GB swap
<samueldr>
hard to know exactly
<samueldr>
(I haven't booted an allwinner board with stock NixOS in a good while)
<NickHu>
Are allwinners generally bad news?
<samueldr>
no
h0m1 has quit [Quit: WeeChat 3.0]
<samueldr>
YMMV news maybe
h0m1 has joined #nixos-aarch64
<samueldr>
and not necessarily because of the CPU itself
<samueldr>
but because of the general design of limited RAM and how Nix and Nixpkgs doesn't optimize towards low RAM usage during builds
<samueldr>
that could cause YMMV
<samueldr>
there's also the nagging issue of storage on such typical designs, where it's often a dastardly SD card
<NickHu>
I see; could I eek out a little more "please don't die" by setting --jobs 1?
<sphalerite>
ha, it actually doesn't even _exist_ anymore by the looks of it. Domain expired.
<sphalerite>
sds2: depending on how you're going to use the boards, it might make more sense to cross-build your nixos for them
orivej has quit [Ping timeout: 256 seconds]
<patagonicus>
NickHu: My experience with cross-compilation has usually been that the linux kernel is one of the things that has the least problems building for other archs. :)
<patagonicus>
Yay, Pine64 has shipped my Pinephone … case. Weirdly I got two emails with the tracking info for the accessories I bought, which had to be a separate order from the phone itself (something, something, batteries).
<sds2>
sphalerite: The sd card is completely new and was never used before. Maybe the card was not big enough, 32gb?
FRidh has joined #nixos-aarch64
<sds2>
What is the proposed way to do it nowadays when dezgeg's cache isn't be there anymore? I took the command from the Wiki but it seems not to be up to date then... I already build an NixOS image for ARM on my laptop. I probably don't need it to build again...
<patagonicus>
Yeah, I just have my machines build everything, I don't want to use a community cache. But it's slow (and I got reasonably beefy machines for armv7 and multiple of them).
<patagonicus>
32GB is certainly enough, I've been running my systems on them. I don want to upgrade to 64GB cards so I don't have to collect garbage as often.
<Ke>
sphalerite: I'd guess the point for the discount is to do it in bigger batches
alp has joined #nixos-aarch64
<sds2>
clever: Did I use it incorrectly then? I actually don't understand why I have to do the whole image build again on the arm device? I cross build an image for the ARM device on my computer and booted the Cubietruck with this image. What is this purpose of this step?
<clever>
sds2: it looks like thats not the right url for the cache
<clever>
sds2: nix is also not able to mix cross and native builds, if you say to do a native build, it will never pull in cross built deps
<Ke>
as long as your stuff mostly hits caches, I would not even look at cross compile
<sds2>
Ke: Okay, good to know. I think I needed to get this route to get an image for armv7 architecture. As far as I understand, for aarch-64 it's not needed because there are already pre-build images for these devices...
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Ke>
no idea about armv7 anyway
<sds2>
I did this now (sudo -i nixos-rebuild switch --fast --option binary-caches https://arm.cachix.org --option binary-cache-public-keys thefloweringash-armv7.cachix.org-1:v+5yzBD2odFKeXbmC+OPWVqx4WVoIVO6UXgnSAWFtso=%) and it works but I guess this will run for a while...
<red[evilred]>
Well, in the meantime I'm trying to get this Pi4 up and running in aarch64
alp has joined #nixos-aarch64
<red[evilred]>
got some source issues
<red[evilred]>
sys/rpicamsrc/meson.build:30:4: ERROR: Problem encountered: Could not find bcm_host.h. Please pass the location of this header via -Drpi-header-dir=/path
<red[evilred]>
but I'll confess - compile is significantly faster than I thought it would be
<srk>
oO cross compiling image?
<red[evilred]>
nope - native
<red[evilred]>
it's hhitting the cache for 95% of stuff
<red[evilred]>
so it's surprisingly fast
<srk>
yeah, that's pretty cool on aarch64
<srk>
it took me few hours to get it to boot from USB
<srk>
wanted to add some notes to wiki
<red[evilred]>
oh - I just booted it off SD
<srk>
if I can remember what it was..
<srk>
firmware update
<red[evilred]>
ahhh
<red[evilred]>
that doesn't seem to be a requirement anymore - but being able to do so would be useful if I wanted to use a cluster of them to replace my gluster cluster
<srk>
rpi-eeprom-update -d -a
<srk>
and a fix for kernel spamming logs when SD card is not present
<NickHu>
sphalerite: thanks, I'll give it a go - the existence of the expression and my vague memory suggests that these uboot binaries are actually built on hydra; am I mistaken? How can I find them?
<sphalerite>
NickHu: if not, boot.binfmt.emulatedSystems = ["aarch64-linux"]; and it will use qemu-user to run aarch64 code on the amd64 machine
<sphalerite>
NickHu: in that case, you can try `nix build nixpkgs.ubootPinebookPro --argstr system aarch64-linux`
<sphalerite>
NickHu: it'll complain that it's not an aarch64 system if anything needs to be built, but substitute from the cache where possible.
<NickHu>
I was able to build it with your first command!
sorki has quit [Remote host closed the connection]
<NickHu>
It's given me an idbloader.img and a u-boot.itb file; I'm not terribly familiar with this - with the pinebook pro I know there's something funky like a version of uboot on emmc and also on the SD card. Assuming I just want nixos on the emmc (no SD card), what should I do?
sorki has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64
cole-h has quit [Ping timeout: 256 seconds]
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
FRidh has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<NickHu>
Hmm, I wrote the uboot I built with `nix build nixpkgs.pkgsCross.aarch64-multiplatform.ubootPinebookPro` to my pinebook pro and it doesn't seem to be able to boot emmc now
zupo has joined #nixos-aarch64
<NickHu>
I guess I'm not supposed to flash the default aarch64 image from hydra onto the PBP; I'll try samueldr's build
alp has joined #nixos-aarch64
<NickHu>
Hmm, it failed with /build/.attr-0: line 13: /nix/store/lflh4jl2w5zmdydpv03ljd74bzybi3rx-desktop-file-utils-0.24-aarch64-unknown-linux-gnu/bin/desktop-file-validate: cannot execute binary file: Exec format error - the repo instructions suggest that it should be able to cross compile
sds2 has quit [Quit: sds2]
taylskid has quit [Remote host closed the connection]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
monk has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
alp__ has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
alp has quit [Ping timeout: 260 seconds]
sorki has quit [Remote host closed the connection]
sorki has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp__ has quit [Ping timeout: 272 seconds]
<samueldr>
regressions and/or changes in Nixpkgs upstream could have broken the build
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
veleiro2 has joined #nixos-aarch64
<veleiro2>
has someone seen this one before? '[ 68.581606] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] *ERROR* Timed out trying to load firmware'
<samueldr>
you may need `rockchip/dptx.bin` from firmwareLinuxNonfree to be available
<samueldr>
it might be fine even if you have an earlier failure, as it may be able to load it from the stage-2 system afterward
<veleiro2>
well, even older generations dont boot now, with the previous kernels
<samueldr>
that's odd
<samueldr>
and unlikely
<samueldr>
unless you changed the installed u-boot
<samueldr>
note that this being the last error message you see is not necessarily the actual error message
<veleiro2>
well im using feature/u-boot-gfx
<samueldr>
ah
<samueldr>
did you read the entire thread?
<samueldr>
the kernel needs/needed fixes to work around an issue
<veleiro2>
well i have before but i'll do it again lol
zupo has joined #nixos-aarch64
<samueldr>
so if you're not using a kernel with such fixes, it will freeze for a range of kernels
<samueldr>
I think 5.5+
<veleiro2>
ohhhh, that makes sense
<veleiro2>
i build the kernel not from that branch, i believe
<samueldr>
then what you're seeing seems like is expected
<veleiro2>
i keep confusing this with the display init bug
<samueldr>
hopefully your u-boot is not installed to SPI
<veleiro2>
eeeeeeem
<samueldr>
(so you can gain access to the system by installing a non-gfx u-boot)
<samueldr>
or well, you could also cross-build the sd image fresh so you can fix the system with it :)
Acou_Bass has quit [Ping timeout: 256 seconds]
<veleiro2>
yeah this is strange though, I select the previous gen with 5.7 on boot but i'm pretty sure its not booting that one
<veleiro2>
because the last kernel would not init anything to the display and freeze, 9/10 times
Acou_Bass has joined #nixos-aarch64
<veleiro2>
but now choosing that old gen with the kernel that was built with the patches has the same missing firmware every time, and display always inits
<veleiro2>
i should go back to main u-boot branch, i was really only looking for being able to choose generations anyways
<veleiro2>
i cant remember why i wanted 5.7+
zupo has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
<samueldr>
yeah, the missing firmware is not an issue
<samueldr>
that firmware IIRC is only involved with external displays
<veleiro2>
ok thanks, makes sense
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<samueldr>
the issue where it freezes with pre-inited display shows absolutely no console output
<samueldr>
so it's not identifiable only from the output
<veleiro2>
ah ha! i suppose i was picking the wrong older gen. it boots them still
<veleiro2>
well i'll check out that thread again
<samueldr>
I haven't had the time to handle anything about the pinebook pro since a good while
<samueldr>
(and haven't used it still, due to this whole not having to be at some other place thingy)
<veleiro2>
are you still funded to do mobile-nixos or whatever?
<samueldr>
yes
<veleiro2>
awesome
<veleiro2>
i have been using it constantly, but i fight too many battles on multiple fronts with technology and was stuck on getting it to build a new derivation
<veleiro2>
i'm still fairly new to nix, one year going on now and the arm64 stuff is all new and niche
<veleiro2>
besides not being able to shut the lid or let it suspend, its great!
<veleiro2>
hehe
<samueldr>
shutting the lid should work fine
<samueldr>
as long as it's not configured to (really) suspend
<veleiro2>
must be another issue then
<veleiro2>
actually i couldnt use the PBP for the longest time because the case fully structurally failed
<veleiro2>
tried to repair it and it was never the same. so i got a new chassis from their store. i think its v2 now, works much better
<samueldr>
how did it fail?
<samueldr>
was it one of the square washer thingies?
<veleiro2>
the hinges are secured in place with plastic structure with metal nuts embedded, the walls of the plastic just fall apart
<veleiro2>
so when i received this chassis i also made sure to reinforce them with jbweld
alp__ has joined #nixos-aarch64
<samueldr>
I see
<colemickens>
weird, mine seems rather sturdy there
<colemickens>
or I wouldn't have guessed it was potentially going to fail anyway
<samueldr>
in mine one of the square plastic washers split in two, but still works fine for its job AFAICT
orivej has joined #nixos-aarch64
adamz has joined #nixos-aarch64
adamz has quit [Remote host closed the connection]
veleiro2 has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 265 seconds]
<NickHu>
Can you chainload uboot to get around the kernel 5.5+ error?
<samueldr>
not in a useful manner
<samueldr>
the issue is that the panel is already initialized
<samueldr>
so loading another u-boot wouldn't help
<samueldr>
and... I'm not entirely sure, but I think that's not even really a thing that can be done
<samueldr>
because u-boot handles BIOS-like tasks of hardware initialization
<NickHu>
I see
<NickHu>
I'm building the kernel off the graphics branch for the third time now because 1. not enough space in /tmp and 2. SD card failures
<NickHu>
ARM is so much fun
<samueldr>
tbf, nothing about that really is ARM specific
<NickHu>
True..
<samueldr>
(not that it helps)
<NickHu>
Don't suppose you know what size the Linux build gets to? I'm using du in the build directory as a crappy progress meter
<NickHu>
Currently at 2.0G
<samueldr>
I don't know, sorry
<NickHu>
Thanks anyway
<NickHu>
By the way, I saw some stuff in the kernel patch in the graphics branch about suspending - does this branch already incorporate that other PR about fixing suspend?
<samueldr>
I don't remember
<samueldr>
maybe the stuff that requires the non-free blob
<NickHu>
At a glance all #7 does is update the kernel sources and set ROCKCHIP-{SIP,SUSPEND_MODE} to yes, and the latter is also done in the graphics branch
justanotheruser has quit [Ping timeout: 265 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
veleiro2 has joined #nixos-aarch64
veleiro2 has quit [Remote host closed the connection]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner_ has joined #nixos-aarch64
veleiro2 has joined #nixos-aarch64
tilpner_ has quit [Remote host closed the connection]