ryantrinkle has joined #nixos-aarch64
orivej has quit [Ping timeout: 276 seconds]
<samueldr> the NixOS on ARM section of the Wiki really needs a rework
<samueldr> well, the main page, mainly
<gchristensen> the ZFS article does too
<samueldr> the difference is I don't have the domain knowledge for ZFS :)
<gchristensen> :P
<samueldr> if you haven't seen, gchristensen, #75069 actually packages neatly the ODROID-C2 u-boot build
<{^_^}> https://github.com/NixOS/nixpkgs/pull/75069 (by lopsided98, 4 hours ago, open): uboot: add support for the ODROID-C2
h0m1 has quit [Ping timeout: 252 seconds]
<simpson> Exciting.
h0m1 has joined #nixos-aarch64
<samueldr> oops, all mobile-nixos devices have the serial number 012345789 as a placeholder in adb
<samueldr> not useful for debugging another device
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-aarch64
<samueldr> lopsided98++
<{^_^}> lopsided98's karma got increased to 11
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vika_nezrimaya has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Aleksejs is now known as kurogizesa
sphalerite_ is now known as sphalerite
vika_nezrimaya has quit [Ping timeout: 250 seconds]
FRidh2 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
kurogizesa is now known as Aleksejs
Aleksejs is now known as kurogizesa
<gchristensen> nice!
kurogizesa is now known as Aleksejs
zupo has joined #nixos-aarch64
FRidh2 has quit [Ping timeout: 240 seconds]
FRidh2 has joined #nixos-aarch64
vika_nezrimaya has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
vika_nezrimaya has quit [Ping timeout: 265 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
chris| has quit [Ping timeout: 245 seconds]
chris| has joined #nixos-aarch64
zupo has quit [Ping timeout: 250 seconds]
zupo has joined #nixos-aarch64
<flokli> anybody importing nixos/modules/installer/cd-dvd/sd-image.nix from their nixos config and running into infinite recustion issues?
FRidh2 has quit [Ping timeout: 265 seconds]
FRidh2 has joined #nixos-aarch64
<flokli> hmm, turned out, I'm not supposed to use pkgs.path from INSIDE my configuration. At least not while importing other stuff.
<gchristensen> samueldr: export NIX_PATH="nixpkgs=$PWD/../nixpkgs" ?
ryantrinkle has quit [Ping timeout: 276 seconds]
ehmry is now known as ehmry_
ehmry_ has left #nixos-aarch64 [#nixos-aarch64]
<tilpner> flokli: Possible workaround: modulesPath
<tilpner> flokli: { modulesPath, ... }: { imports = [ "${modulesPath}/installer/cd-dvd/sd-image.nix" ]; }
<flokli> gchristensen: NIX_PATH is empty, all is pinned and self-contained
<gchristensen> except $PWD/../nixpkgs is outside of the repository and unspecified :)
<flokli> ah wait, gchristensen's reply wasn't related to my question
<flokli> tilpner: sweet, will give it a try, too :-)
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ryantrinkle has joined #nixos-aarch64
<gchristensen> dang
<flokli> hmm, in fact, I probably shouldn't import the module from the generic config, but only load it if I want to produce an SD card…
<gchristensen> it took about 1.5h but I was able to almost cross compile this nixos system to armvg0
<gchristensen> armv7l*
<gchristensen> it failed on a few and then I realized I was on 19.03
<flokli> lol
<flokli> gchristensen: I'm also almost done. It's now failing with fc-cache, even though https://github.com/NixOS/nixpkgs/pull/73344 claims it should work
<{^_^}> #73344 (by ebkalderon, 3 weeks ago, merged): makeFontsCache: Fix cross-compilation, use nativeBuildInputs
<gchristensen> nice!
<flokli> well, even more nice if it'd work
<gchristensen> :)
<gchristensen> reposting an idea from -dev, we should make all of stdenv's bootstrapping big-parallel
FRidh2 has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 268 seconds]
<flokli> we should probably shape up cross, and cross-build the minimal installers for aarch64 and armv7l ;-)
<gchristensen> it would be nice for nix-build to support some features
<gchristensen> like reserve 25 cores for big-parallel jobs, and run one big-parallel job at a time. and then for all the others, run 5 jobs at a time with 5 cores each
kai_w has quit [Quit: Konversation terminated!]
vika_nezrimaya has joined #nixos-aarch64
mcfrank has left #nixos-aarch64 ["WeeChat 1.9.1"]
<gchristensen> good grief samueldr it worked
<gchristensen> I have a armv7l image
orivej has joined #nixos-aarch64
<samueldr> what worked?
<samueldr> the cross-system build?
<samueldr> and duh, yeah, that's not exactly friendly to do it outside of the repo
<samueldr> especially without docs
<gchristensen> yeah cross-system build worked
<gchristensen> pointing at regular 19.09
<tilpner> Has anyone seen a make error 2 while cross-compiling linux to aarch64? Full log: https://tx0.co/aZ7
<tilpner> I updated my pinned sources, and forgot this would take another 6 hours if compiled with qemu :/
<samueldr> <3>/build/ccLmconz.s:50: Error: selected processor does not support `aese v7.16b,v1.16b'
<tilpner> Huh
<samueldr> with a kernel build, search error: to find the actual error
<samueldr> it's highly parallel
<samueldr> I got the error, too
<tilpner> That makes sense, thank you :)
<{^_^}> #74744 (by alexvorobiev, 5 days ago, open): Updating Raspberry Pi 3 on unstable channel fails with assembler errors trying to compile the kernel (aarch64)
<samueldr> it might have a similar fix to https://github.com/NixOS/nixpkgs/issues/64916
<{^_^}> #64916 (by thefloweringash, 20 weeks ago, open): Linux kernel versions 4.4 and 4.10 don't build on nixos-unstable Aarch64
<tilpner> Are the *.s names at all relevant? They differ, but I can't tell if they're random
<samueldr> not sure
<samueldr> <3>make[2]: *** [../scripts/Makefile.build:266: crypto/aegis128-neon-inner.o] Error 1
<samueldr> but this tells me that it's the same part
<samueldr> so I assume random
<tilpner> I'll just try disabling this for now
<tilpner> What could possibly go wrong
* tilpner CRYPTO_AEGIS128 n, CRYPTO_AEGIS128_SIMD n
<samueldr> if I remember right, you only need to disable the SIMD option
ryantrinkle has quit [Ping timeout: 265 seconds]
ryantrinkle has joined #nixos-aarch64
* tilpner spent an hour waiting on hydra to finish before realising it was still a qemu build :(
<tilpner> The new one seems to build though, with just _SIMD off :)
<samueldr> it built for me on my pinebook a64
<samueldr> for my*
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
<flokli> tilpner: running into this while cross-compiling too?
<tilpner> flokli: Yes, this was cross-compiled
<flokli> tilpner: so do you have some binfmt hackery, or a nixpkgs checkout where it doesn't break that way?
<flokli> The log clearly reads like it tries to execute a armv7l fc-cache binary…
<tilpner> My log or your log?
<samueldr> how are you testing?
<samueldr> (I don't know what to build)
<tilpner> Oh, I'm not cross-compiling everything
<tilpner> Just the kernel and a few select packages
<tilpner> That way, I get cache.n.o for most things, and only have to build the things I care about
<tilpner> When I try to cross-compile the whole thing, it starts building a lot more dependencies
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<flokli> tilpner: I'm trying to build a full sd card image for some armv7l box
<flokli> and I do a nix-build -A hosts.pynq.config.system.build.sdImage
* samueldr checks the state of cross-compiling stock sd-card on current nixos-unstable
<flokli> hosts/pynq.nix is just a regular nixos conf, like you'd use for nixos-rebuild switch -I config=… I disabled grub, enabled extlinux, configured the fstab, hostname and kernel
<samueldr> not sure all my PRs were merged
<samueldr> in fact I see they are not
<flokli> samueldr: I stole some of the workarounds from https://github.com/samueldr/cross-system/blob/master/configuration.nix
<{^_^}> #73088 (by samueldr, 3 weeks ago, open): groff: Fix cross-compilation
<{^_^}> #73606 (by samueldr, 2 weeks ago, open): valgrind: Add perl as a native build input
<samueldr> I've been leaving this to the staging peeps to merge
<flokli> ah, ran into the groff issue too
<flokli> but I don't really understand the fc-cache one
<samueldr> :)
<flokli> the PR looks fine, it says it fixes it, and I'm inclined to believe it does.
<flokli> But it still doesn't work afterwards
<flokli> and my nixpkgs surely contains the fix :-)
<flokli> samueldr: can confirm groff is fixed
<samueldr> hm? fixed without or with the PR?
<flokli> with the PR
* tilpner >.>
<flokli> I'm inclined to press that green button… it's staging, right?
<samueldr> right, staging
<flokli> so what's the new process of waiting for sb to merge things into staging?
<flokli> I assumed it's fine to merge to staging
<flokli> sometimes, magic happens, and things are in staging-next
<flokli> and then in master
<samueldr> I don't know anything about the process for staging so I was leaving this all in the hand of anyone-by-me
<samueldr> but-me*
<flokli> haha
<flokli> I pressed the button.
<samueldr> though yeah, I assume in staging it's going to be fine, since it's stabilizing at some point in staging-next
<flokli> and as for valgrind, Ericson approved. So this should really be fine :-)
<flokli> Merged, too
<samueldr> thanks
<samueldr> with those in staging, cross-system should be back to "good enough" soon
<flokli> what's with udisks, gpgme and friends?
<flokli> any idea why those are broken?
<samueldr> hm?
<samueldr> well, if nothing broke since last time I ran it
<samueldr> right
<samueldr> that's what I mean
<samueldr> with the cross-system workarounds it's going to be enough :D
<samueldr> still needs to all be actually fixed
<samueldr> IIRC gojbect-introspection has a meson-side issue with needing two pythons, host and build one
<flokli> I really think we should aim to build armv7l and aarch64 "minimal sd card installers"
<flokli> this will uncover these cross issues much quicker
<samueldr> yes
<samueldr> I think there was some talks about maybe doing this at some point, in a less-often scheduled jobset
<flokli> yeah, it obviously shouldn't block a channel. At least not in the near future
<flokli> but it should be exercised often enough so breakages are easily spotted
<flokli> we're not yet lineageos and build firmware for hundreds of devices every night :-)
<samueldr> yet
<gchristensen> we could
<flokli> we should
<flokli> we will
<gchristensen> holy hell
<flokli> oh yes :-)
<gchristensen> hydra's nixpkgs:trunk jobset is up to 80,000 jobs
<gchristensen> and only 4,000 fail :o
<gchristensen> this is amazing
<samueldr> it's not over 9000
<flokli> it goes up to eleven
<samueldr> armv[67]l and aarch64 cross of sd_image, and uefi iso, what's missing to get this in hydra?
<samueldr> I mean, we could also dump the whole nixpkgs release in there and build all, but I figure that's less useful?
<flokli> samueldr: It'll be too much I think
<gchristensen> I never could get that thing to boot :(
<flokli> but sd_image should be a target
<samueldr> yeah flokli, that's what I was thinking too
<samueldr> sd_image _and_ uefi iso
<samueldr> (except for armv6, for uefi iso)
<gchristensen> scaleway is writing to a "local SSD" at 7MiB/s
<samueldr> local on a network storage
<flokli> the cloud native experience
<gchristensen> correct, it is networked storage :(
<gchristensen> "/dev/nbd1" "not big data"
<flokli> I can't blame them. Nobody wants have disks connected to individual boards as a SPOF.
<gchristensen> I do
<gchristensen> then again they still haven't managed to shut that server down
zupo has joined #nixos-aarch64
<gchristensen> come ON scaleway
<gchristensen> shut the dang thing DOWN.
zupo has quit [Client Quit]
<gchristensen> scaleway is just a UI over openstack right?
<gchristensen> obviously, right?
<flokli> gchristensen: you could call them and ask if you should pull the cable yourself
Thra11 has joined #nixos-aarch64
<flokli> they say they have custom hardware
<samueldr> I don't know that they are
<flokli> or at least had
<gchristensen> oh yikes
<gchristensen> can't boot a C1 from a snapshot
<gchristensen> okay I guess this just won't work
<flokli> gchristensen: no pxe?
<gchristensen> lol
<gchristensen> no
<gchristensen> nor kexec
<samueldr> my current cross-compile did start from an awfully cold cache
<gchristensen> I _think_ I want to take the cross-system stuff and merge it with a netboot like system description
<gchristensen> > C1 instances are unfortunately pretty old instances, and are based on a old architecture. As such, those servers do not support local boot, and only boot through "bootscripts", via PXE.It should be possible to hijack the PXE process at boot time using the web console, but that would be extremely inconvenient as it would have to be done at every reboot.
<{^_^}> error: syntax error, unexpected ',', expecting ')', at (string):271:52
<clever> gchristensen: in the past, i have mentioned doing that on purpose, and using a ipxe script to configure pxe to try the local hdd next
<gchristensen> fancy
<clever> gchristensen: oh, is packet.net pxe purely "enter a url" based, or can you give them a 10-line script, and they host it at a url for you?
<gchristensen> I *think* there is a secret way to do the second
<gchristensen> but usually just "enter a URL"
<gchristensen> but this is for Scaleway
ryantrinkle has quit [Ping timeout: 240 seconds]
<gchristensen> oops
<gchristensen> kexec worked
<gchristensen> but no ssh :)
<clever> gchristensen: ip or auth?
<gchristensen> hm?
<clever> gchristensen: is it not answering at the ip, or the auth not letting you in?
<gchristensen> ssh isn't enabled on the kexec image
<clever> ah
<flokli> gchristensen: build your own! :-)
<gchristensen> I did
<gchristensen> and still managed to not enable ssh
<clever> my kexec image has ssh, and will reboot itself if you lack a management console
<ornxka> hello, so, i think ive managed to compile uboot (u-boot-sunxi-with-spl.bin) + a nixos sd image (nixos-sd-image-20.03pre-git-armv7l-linux.img.bz2) for my system, my question is, how do i write these two files to an sd card?
<ornxka> or does the .img file have the uboot code already in it?
<ornxka> ahhh
<ornxka> i write the img, then the bootloader code, i think
<clever> ornxka: i think for sunxi, the uboot has to be at a certain offset within the sd image
<clever> which can either be automated by nix (and already in the sdimage) or manually done afterwards
<clever> also, is the SD card using mbr or gpt?
<ornxka> was i supposed to partition it o_o;
<clever> the .img file already contains a partition table
<ornxka> ahh
<clever> gpt has a harder time with uboot at seek=8
<ornxka> its mbr, according to file
<clever> should be fine then
<ornxka> whoa hot damn it actually booted
<ornxka> <<< Welcome to NixOS 20.03pre-git (armv7l) - ttyS0 >>>
<gchristensen> woo!
<ornxka> that was a lot easier than i was expecting it to be
<samueldr> ornxka: yeah, the general order in sunxi images is "dd the image, then dd the bootloader at the right location"
<samueldr> which is what uboot-with-spl is
<clever> in theory, you could have a nix derivation that does the 2nd step
<samueldr> yeah
<samueldr> in practice that'd make n amount of images to generate
<samueldr> what could be more useful is a derivation that takes the sd image in input, and the board name, and generates a "burn-me.sh"
<clever> they could all reuse a uboot-less base image
<samueldr> clever: yes they could
<samueldr> but it still makes n images
<clever> yeah, the final image could be outside of hydra
<samueldr> :)
<clever> and the user generates it locally
<clever> ornxka: this also exists, to allow uboot on gpt
<samueldr> to allow some setups of secondary bootloaders on the main storage to use gpt
<samueldr> amlogic won't play nice with this
<samueldr> unverified still on rockchip
<ornxka> ah thats interesting, i was just reading earlier about boot processes, for something totally unrelated
<clever> the custom rpi firmware ive been working on would also open up the option of gpt on rpi
<samueldr> gpt already works on rpi3
<samueldr> iirc
<samueldr> not 100% sure though
<samueldr> though imo, the real solution is to treat the sd card on rpi as an opaque blob and just put tianocore on it
<samueldr> then boot from usb (or network I suppose)
<samueldr> much less painful in my experience
<clever> samueldr: the spi flash of the rpi4 basically takes that place
<samueldr> as long as tianocore can't fit in there, the sd card has to be a useless blob to me :)
<clever> yeah
<samueldr> (u-boot would be sufficient)
<clever> ive also got some dt issues i been to iron out
<clever> i can get linux to "boot" on my rpi3, but it fails in 3 ways
<clever> 1: some of the page table stuff isnt generating right, ive commented out a check to make it ignore the problem
<clever> 2: the bug detection code doesnt detect the bug properly and hard-hangs
<clever> 3: irq's are 100% non-functional, so it hangs when figuring out the clock speeds
<clever> 4: attempting to fix irq's has caused it to just fail with an error i cant solve