rajivr has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
orivej has joined #nixos-aarch64
tilpner has quit [Read error: Connection reset by peer]
tilpner has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
stiell has joined #nixos-aarch64
stiell has quit [Ping timeout: 246 seconds]
stiell has joined #nixos-aarch64
stiell has quit [Ping timeout: 258 seconds]
stiell has joined #nixos-aarch64
<colemickens> samueldr: I'm thinking about taking some time to contribute my u-boot changes so that using the pi4 normally works with the rpi-uboot bootloader, since we sorta just have the image working now. I'm thinking about also seeing if I can "move" the image to using the bootloader-generation process (de-dupe) and move it out-of-tree to nixos-hardware? We could remove what's there now, or deprecate it and point people to
<colemickens> nixos-hardware? wdyt?
<colemickens> it'd be cool to whip that into shape for potential raspbian refugees
<samueldr> the goal always has been to delete the raspberry pi 4 nix derivation
<colemickens> I know
<samueldr> (I'm agreeing I think)
<colemickens> Okay!
<samueldr> any effort towards ensuring sd_image works at the very least as an aarch64 stepping stone is welcome
<colemickens> okay, I think what I have in mind jives with everything I've heard you discuss, and/or fits with what I feel like a good split of nixpkgs/nixos-hardware could be
orivej has quit [Ping timeout: 240 seconds]
ashkitten has quit [Quit: WeeChat 3.0]
ashkitten has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
alpernebbi has joined #nixos-aarch64
zupo has joined #nixos-aarch64
bdju has joined #nixos-aarch64
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
dev_mohe has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
zupo has quit [Ping timeout: 272 seconds]
Darkmatter66 has joined #nixos-aarch64
cole-h has quit [Ping timeout: 240 seconds]
Darkmatter66 has quit [Quit: ZNC 1.8.2 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
orivej has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-aarch64
srk has quit [Ping timeout: 268 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
srk has joined #nixos-aarch64
orivej has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
Darkmatter66_ has quit [Ping timeout: 240 seconds]
alpernebbi has quit [Quit: alpernebbi]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
zupo_ has quit [Quit: Textual IRC Client: www.textualapp.com]
orivej has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
srk has quit [Ping timeout: 268 seconds]
srk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
Acou_Bass has joined #nixos-aarch64
<adisbladis> I thought we were supposed to build native armv7 on the community builder?
<adisbladis> What happened?
<sphalerite> adisbladis: what do you mean?
<sphalerite> as in what are you expecting concretely and how is that expectation not being fulfilled?
<adisbladis> sphalerite: I expected `nix-build '<nixpkgs>' -A foo --argstr system armv7l-linux` to work
<sphalerite> unfortunately no
<adisbladis> Actual result: a 'armv7l-linux' with features {} is required to build '/nix/store/d437id9dxb8x0d1r00chcicp1zc2adbi-bootstrap-stage0-stdenv-linux.drv', but I am a 'aarch64-linux' with features {benchmark, big-parallel, gccarch-armv8-a, kvm, nixos-test}
<adisbladis> Ugh... Idk what to do
<sphalerite> you could pass --extra-platforms armv7l-linux but that also wouldn't really help
<adisbladis> qemu-user is too slow to be a realistic option
<sphalerite> (that will make nix just think "ok I'm an armv7l-linux as well"
<sphalerite> That doesn't work however, because of tools using uname and thinking "oh I'm aarch64 ok"
<sphalerite> What you can do is make a hardware-accelerated VM that has aarch64 disabled
<adisbladis> If only we could have nice things...
<sphalerite> Not sure if there are any ready-made ones there, but there is some prior work on the topic https://github.com/grahamc/packet-nix-builder/pull/2
<{^_^}> grahamc/packet-nix-builder#2 (by thefloweringash, 1 year ago, open): armv7l-linux build vm for aarch64-linux machines
<adisbladis> Hm, I recall some discussion around faking platforms
<adisbladis> This would be a major change, but it's really quite appealing
<sphalerite> Yes, faking platforms is what extra-platforms implements basically
<adisbladis> sphalerite: I mean so uname would return the correct result
<sphalerite> I did that way back when we first got the community box
<sphalerite> oh right
<sphalerite> I mean you can try just patching nix to use the personality syscall to fake it, but I'm not sure how well it'll work
<sphalerite> #21471 would in principle be the right solution, but it's… nontrivial to actually do
<{^_^}> https://github.com/NixOS/nixpkgs/issues/21471 (by Ericson2314, 4 years ago, open): Always cross compile
<adisbladis> Yeah... I think I'd rather try to find some armv7 cloud vendor for now
<adisbladis> Is there one?
zupo has quit [Ping timeout: 256 seconds]
<sphalerite> don't know if scaleway still offer theirs
<sphalerite> I think the VM approach is more promising though
<sphalerite> based on my scaleway experience, you might as well just make your own little $SBC cluster
<adisbladis> sphalerite: I can't
<sphalerite> srk: what was your 32-bit ARM cluster made of again?
<adisbladis> I don't have a home :P
<adisbladis> Nowhere to put anything
<sphalerite> adisbladis: or ask srk if you can borrow his :ppp
<sphalerite> (I don't know if it still exists)
<adisbladis> Hm, now that r-ryantm is off the main nix-community build machine I might just enable qemu-user there for now
<adisbladis> We should have some spare capacity
<sphalerite> Why not use VMs on the nix-community machine?
<sphalerite> it'll be a lot faster.
<adisbladis> I lost all my energy to do anything remotely complicated atm
<gchristensen> the armv7 cloud vendors are miserable
<gchristensen> adisbladis: what are you trying to build?
<adisbladis> gchristensen: Things for my remarkable
<gchristensen> ah
<gchristensen> armv7 is completely exhausting to me
<adisbladis> Yeah :/
<adisbladis> Tbh every time I get into anything cross I want to flip a table
<adisbladis> There is always something broken
<adisbladis> But I completely understand their SoC choice
<adisbladis> There doesn't seem to be much in the way of aarch64 for the purpose
<gchristensen> even rpi is aarch64 now
<gchristensen> but that is probably a different enough target
<adisbladis> Remarkable has special considerations, like e-ink controllers
<adisbladis> I wish I had one of my old armv7 phones handy, but it's all in storage :/
<gchristensen> there are probably 1000+ developers who would pay for an armv7 "cloud" but my impression is anyone who knows anything about it doesn't want to get near supporting such a thing
<clever> i'm having trouble building anything for armv6l here
<adisbladis> Lol, it gets worse
<clever> cross compile fails with one error, native fails with another
<adisbladis> gchristensen: Oh yes, no one in their right mind would offer that as a commercial service :P
<clever> and i'm also having trouble finding an old nixpkgs that still works, because dezgeg deleted the bootstrap files
<gchristensen> $1,000,000/day
<sphalerite> clever: redo the bootstrap using debian tools or similar?
<sphalerite> or cross-compiled stuff
<sphalerite> or is it broken to the point that you can't build busybox?
<clever> sphalerite: one of the native faults, is that the linker during a gcc build just silently exits with code 1, and no error
<sphalerite> oh nice
<clever> the older nixpkgs fail, because it cant fetch the bootstrap tools+busybox from dezgeg's server (404)
<sphalerite> hmmm I might still have some of those ancient bootstrap tools lying around somewhere
<clever> i could maybe try a new bootstrap-tools with an old nixpkgs...
<sphalerite> or that
<sphalerite> funnily enough, the place that I might have these ancient bootstrap tools is on the storage I was considering wiping earlier.
<clever> in my case, the current goal is to get wpa_supplicant running on a pi0
<clever> currently i'm waiting on a native gcc build
<Ericson2314> sphalerite: i think we're getting closer
<Ericson2314> https://github.com/NixOS/nixpkgs/pull/110914 puts on the path to unifying darwin native and cross
<{^_^}> #110914 (by Ericson2314, 1 week ago, open): WIP: treewide: Improve pure darwin cross
<clever> oooo
<sphalerite> nice!
<Ericson2314> but then i got sidetracked with https://github.com/NixOS/nixpkgs/pull/111487
<{^_^}> #111487 (by Ericson2314, 3 days ago, open): Super WIP: llvmPackages: Clean up outputs, cross compile tools themselves
<clever> Ericson2314: is there anything else you can see wrong with my arm pr? other then it probably breaking x86 multilib?
<Ericson2314> and then https://reviews.llvm.org/D28234
<Ericson2314> clever: checking
monk has left #nixos-aarch64 ["Error from remote client"]
<gchristensen> A
<gchristensen> oops
monk has joined #nixos-aarch64
<Ericson2314> just one more thing
<clever> and *boom*
<clever> https://gist.github.com/cleverca22/fe64ae59747c97d1f6ddb859954ca0ba native armv6l build (ran on an aarch64 kernel) failed with no clear error
<clever> repeating with cores=1 doesnt help
<clever> linux-headers> bash: line 1: 3866 Segmentation fault scripts/basic/fixdep scripts/basic/.fixdep.d scripts/basic/fixdep 'gcc -Wp,-MMD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89 -o scripts/basic/fixdep scripts/basic/fixdep.c ' > scripts/basic/.fixdep.cmd
<clever> if i instead build with master, i get a segfault
cole-h has joined #nixos-aarch64
<{^_^}> #107386 (by Gaelan, 6 weeks ago, open): Can't build linux-headers on armv6l
<clever> sphalerite: any idea for the error in the above gist?
<sphalerite> no
<Ericson2314> clever: i once got a aarch64 that was actually failure to exec for some reason on a graviton
<Ericson2314> with bootstrap tools
<Ericson2314> and then i found a similar Nixpkgs issues for 32 bit arm
<Ericson2314> so i dunno
<sphalerite> graviton doesn't support 32-bit, does it?
<clever> i'm repeating the test on master, without the arm-copy patch from the above issue
<Ericson2314> sphalerite: don't think so, but I think that shouldn't get in the way of the 64 bit bootstrap tools?
<Ericson2314> `file` said they were 64-bit at least
<sphalerite> oh right. Then never mind me
orivej has joined #nixos-aarch64
<clever> gcc> collect2: error: ld returned 1 exit status
<clever> dang, gcc fails in the same way, with the arm-copy patch removed
<clever> armv6l-unknown-linux-gnueabihf-binutils> unpacking source archive /nix/store/n1pp66v5mya20j0rq5mbzkak0pf6sal0-binutils-2.31.1.tar.bz2
<clever> back to trying cross...
<clever> [3/11/128 built
<clever> armv6l-unknown-linux-gnueabihf-binutils> collect2: error: ld returned 1 exit status
<clever> and now the cross binutils fails too, with no error!!
<clever> might have been disk space related...
<samueldr> anyone comfortable with flakes wants to help review? https://github.com/NixOS/mobile-nixos/pull/294
<{^_^}> mobile-nixos#294 (by archseer, 12 hours ago, open): Flake compatibility
<samueldr> it looks simple enough
<clever> ack, guile is building once more!
Darkmatter66 has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
zupo has joined #nixos-aarch64
<craige[m]1> Thanks for the monthly report samueldr++ - great update!
<{^_^}> samueldr's karma got increased to 318
<samueldr> you're welcome
<samueldr> so many little things, some I worked not exclusively during that month, just fell together
<samueldr> I didn't even plan for the qcacld-2.0 stuff to be done :)
<samueldr> the solution just fell in my lap
* craige[m]1 needs to write a karma bot where "++" transfers some for of Crypto to to the recipient.
<samueldr> some good ol' AES-GCM
<samueldr> or the classic ROT13?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<flokli> so turns out, I finally managed to assemble the kobol64
<flokli> It's a neat device. A lot of blinking LEDs, and a pretty crazy baudrate :-D
<flokli> Armbian 20.11.6 Focal is a bit… eww
* samueldr looks at box
<flokli> "ohai, you seem to be running in .de, for sure you'll want either de_DE.UTF-8 or hsb_DE.UTF-8"
<samueldr> I didn't even start yet :/
<flokli> and I also configured Europe/Berlin for you as TZ
<flokli> Well, it boots, for much I can tell
<samueldr> maybe mine is DOA!
<flokli> make sure the landline power is connected
<flokli> mine was a bit grumpy, starting via battery
<flokli> I didn't realize it at first
monk has left #nixos-aarch64 ["Error from remote client"]
<flokli> w.r.t. getting NixOS there, I'm not wondering whether I should fix broken cross and assemble a separate sdcard with it, or just install nix on that Ubuntu, and build there :-D
<samueldr> angerman has something IIRC
<samueldr> though, I sure would say "fix cross"
<samueldr> or at the very least, start with a cross from early january
monk has joined #nixos-aarch64
<flokli> samueldr: define that something that angerman has
<samueldr> anger, man
<flokli> oooh
<samueldr> something for the helios64
<samueldr> like I said, *I* still haven't taken the time to do anything with it :|
<samueldr> I'm taking the rest of the week off of Mobile NixOS, but I already decided to work on a small fun project not involving ARM
<flokli> and closes it again
<clever> firmware for /nix/store/mjcj4l6hilp6ffbx06nhqmnk7f6v88n5-modules/lib/modules/5.4.72-v7l+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko: brcm/brcmfmac43012-sdio.bin
<clever> sphalerite: have you seen this error?
<samueldr> flokli: armbian is the official location of vendor patches for mainline IIRC
<samueldr> which, if I get right, means they're not really "shipping vendor kernels" or anything BSP
<samueldr> better than many RK3399 boards
<flokli> true
<samueldr> but yeah, a lot of patches around
<samueldr> IIRC for u-boot too
<flokli> 100
<samueldr> u-boot IIRC manages the delayed start of the disks
<samueldr> since otherwise the current spike will be too high
* flokli looks at the single ssd currently plugged in
<samueldr> TOO HIGH I said
<flokli> all the way up to the moon :-)
<samueldr> but yeah, I figure you understand it would be about 5 3.5" hungry hungry hippos^W HDDs
<flokli> ack
<flokli> "hey, let's start spinning some rust. all of it"
<samueldr> tbf, I did do some RK3399 work recently that would allow using the Helios64 as a mass storage device via USB
<samueldr> or any other fun things you can think of via usb
<sphalerite> flokli: oh yeah, assembly is a bit of a pain. angerman's thing worked fine for me, though I ended up nixifying the kernel config a bit more.
<sphalerite> I should probably publish what I did
<sphalerite> flokli: what I did includes a btrfs-based image that you can just plonk on the eMMC, ISTR you like btrfs ;)
<flokli> sweet
<sphalerite> flokli: https://git.sr.ht/~linuxhackerman/bold/tree it has some weirdness, but maybe you can tolerate it :p
<sphalerite> it's largely based on angerman's work but adapted to my taste
<sphalerite> the weirdest bit is probably my rust fan control program because I didn't want to use fancontrol the shell script x)
<samueldr> if you're changing the kernel's baudrate, you probably want to change ATF and u-boot's to
<samueldr> too*
<samueldr> oh
<samueldr> and ATF's
<samueldr> as u-boot's been taken care of
<samueldr> though I don't think ATF is too verbose
<sphalerite> yeah I think angerman had that but it got lost along the way to my repo
<flokli> sphalerite: do I want to know what https://git.sr.ht/~linuxhackerman/bold/tree/master/item/helios64.nix#L23 does?
<flokli> as for the custom unit invoking ethtool, that could probably just be a TransmitChecksumOffload=false in a .link file matching the interface name/driver/whatever
<samueldr> oh
<samueldr> mainline linux *may* have an issue with its MMC driver
Darkmatter66 has quit [Ping timeout: 276 seconds]
<samueldr> I've hit it on different platforms
<samueldr> it seems to happen on x86_64 too
<samueldr> but it is extremely inconsistent
<samueldr> what this does is until the block device is shown, it turns it off and on again
<samueldr> (hi, I'm not sphalerite)
<flokli> heh
<samueldr> had to do the same for asus-dumo
<samueldr> my gut feeling is that it's highly dependent on the exact mmc chip
<samueldr> that some are more marginal than others
<samueldr> and that *something* in the driver exacerbates the issue
<sphalerite> yeah. I initially discovered this "fix" on my chromebook, where it can take >5 minutes of attempts for the emmc to appear… thankfully it's nowhere near that bad with the helios64 and often just works without that script needing to do any work at all
<samueldr> first time I saw that issue was on the pinebook (A64) (not pro), with one specific MMC chip
<samueldr> but at the time I just assumed the chip wasn't supposed to work in it
<sphalerite> flokli: oh yeah the link file is a good idea, I think I noticed that udev could take care of it at some point and then forgot again.
<flokli> hmm, the RK3399 can't do kvm, right?
<samueldr> it can
<samueldr> note that you may have to tell qemu to stick to either the two fast, or the four small cores
<samueldr> not sure anything changed, but qemu couldn't deal with all of them at once at some point
<flokli> I think I first need to tell armbian/Ubuntuarmbian to build a kernel with support compiled in
<flokli> sigh
<samueldr> taskset -c 0-3 or 4-5 IIRC
<sphalerite> why do kvm on ubuntu when you could install nix and get your nixos image done as quickly as possible? ;)
<andi-> flokli likes to take detours and waste time on yet another SBC that ends up collecting dust :P
<samueldr> ugh
<flokli> I installed nix on it
<samueldr> store them in boxes
<samueldr> no dust
<flokli> But I need qemu to build the disk image
<flokli> Or to run a VM test
<andi-> I think I built my image with binfmt
<flokli> I might just abuse some other aarch64 box or binfmt with that
<samueldr> or cross-compile from ~january 5th nixpkgs
<andi-> https://github.com/andir/infra/blob/master/bootstrap/rockpi.nix is how I build the initial image for my rockpi
<sphalerite> flokli: ooooh I see.
<sphalerite> build just the kernel, boot ubuntu with that kernel? :D
<sphalerite> andi-: I think the helios64 has a lot more potential for production use than many other SBCs :)
<samueldr> almost sounds like you're looking for doing it in the most annoying way :)
tilpner has quit [Ping timeout: 272 seconds]
<samueldr> I think so too, especially the upcoming one with ECC RAM