cole-h has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 258 seconds]
rajivr has joined #nixos-aarch64
h0m2 has quit [Ping timeout: 244 seconds]
h0m2 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-aarch64
cole-h has quit [Ping timeout: 272 seconds]
hmpffff has joined #nixos-aarch64
ib07_ has joined #nixos-aarch64
ib07 has quit [Ping timeout: 240 seconds]
alpernebbi has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 260 seconds]
alp has joined #nixos-aarch64
ib07_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
ib07 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ky0ko has quit [Remote host closed the connection]
ky0ko has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
<patagonicus> misuzu++ Managed to build my system at the commit you gave me. Had to try a few times (mostly unrelated things, but bash-completion's tests still seem to be flaky).
<{^_^}> misuzu's karma got increased to 5
ib07 has quit [Ping timeout: 260 seconds]
alp has joined #nixos-aarch64
__red__ has quit [Remote host closed the connection]
zupo has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 246 seconds]
<patagonicus> Oh, fun. Now the other machines give me "Unexpected EOF" on nixos-rebuild boot. Haven't seen that one before.
<patagonicus> Ah. Probably because they are still trying to use one machine as a remote builder that's offline. But that wouldn't be a great error message.
<patagonicus> Hmm, no. Weird.
ib07 has joined #nixos-aarch64
alpernebbi has quit [Remote host closed the connection]
adisbladis has joined #nixos-aarch64
das_j has quit [Quit: killed]
ajs124 has joined #nixos-aarch64
das_j has joined #nixos-aarch64
ib07 has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
ib07 has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
ib07 has quit [Ping timeout: 272 seconds]
deadk has joined #nixos-aarch64
<das_j> clever: Does the raspi foundation print the serial onto the board?
<das_j> Probably no, right?
ib07 has joined #nixos-aarch64
ib07 has quit [Max SendQ exceeded]
ib07 has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
<clever> das_j: nope
<clever> das_j: the serial# is randomly generated by the firmware, when it boots a special programming SD card
<das_j> heck
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
ib07 has quit [Ping timeout: 240 seconds]
<das_j> heck
heywoodlh has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
cole-h has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
hmpffff has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gchristensen> anyone done anything with armv7l on AWS' graviton2's?
<gchristensen> it doesn't seem to support /dev/kvm
<clever> gchristensen: do you know if it has a GIC?
<clever> kvm without a GIC is extremely complicated
<gchristensen> cpuinfo doesn't mention a GIC
<DigitalKiwi> what's a GIC
<gchristensen> but dmesg does:
<clever> [ 0.000000] Boot CPU: AArch64 Processor [413fd0c1]
<clever> [ 0.000000] cma: Reserved 64 MiB at 0x0000000075000000
<clever> it booted in 64bit mode
<clever> and it definitely has a GIC
<clever> [ 0.136997] kvm [1]: HYP mode not available
<clever> gchristensen: and kvm cant find hypervisor mode, so its disabled
<gchristensen> yeah
<clever> i suspect your already inside a virtual machine
<clever> and they didnt enable nested virtualization
<gchristensen> yeah... maybe if I get one of those AWS Bare Metal machines
* gchristensen lights a bucket of money on fire
<DigitalKiwi> that bucket had children!
zupo has joined #nixos-aarch64
<gchristensen> I couldn't do it, anyway ... aws account limits.
alp has joined #nixos-aarch64
hmpffff has joined #nixos-aarch64
<gchristensen> armv7l continues to be such a thorn
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
<samueldr> I don't recall, are those graviton even able to armv7l?
<samueldr> well, to 32-bit armv8
<gchristensen> don't even know
<samueldr> (I want someone to tell me "armv8 is 64 bit" so badly)
<gchristensen> https://about.gitlab.com/blog/2020/05/15/gitlab-arm-aws-graviton2-solution/ is interesting, and I tried to figure out what that meant exactly but I think they just use binfmt?
<samueldr> IIRC, you could just pick a busybox static binary for 32 bit ARM and try to run it to know if it works or not
<samueldr> I'm not 100% confident of that assertion though
<samueldr> I don't know what gitlab does for 32-bit runners...
<samueldr> nothing in that page says anything about a specific scheme
<gchristensen> lol
<gchristensen> web design is their passion
<samueldr> all of that because I didn't enable fetching for 15 abitrary 3rd party domains
<samueldr> hmm, this doesn't seem to conclusively point towards qemu through binfmt for the AWS runners though
<samueldr> to me that says they do for development purposes
<gchristensen> I agree
<samueldr> but yeah, it could be
<samueldr> it could also be the 64 bit runners "just" running 32 bit software within a 64 bit kernel
<samueldr> though that would be really spooky with the personality bits of the kernel being so lacking for 32 bit mode on ARM
h0m2 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
<sphalerite> samueldr: or say aarch32
<sphalerite> I think everyone will hate that.
<samueldr> bit it _is_ the proper term!
<samueldr> if you are talking in a generic manner
<samueldr> since 32 bit armv8 is not armv7l, though it is compatible
<sphalerite> I know, it's still a terrible name
<sphalerite> ARM may be great at naming things ARM, but it's terrible at actually naming things in general
<sphalerite> IMHO
<samueldr> yeah
<samueldr> arm9
* gchristensen cries
<samueldr> which is armv4 and armv5
<samueldr> or ARM7
<sphalerite> what about ARM7TDMI
* gchristensen steps out the window
<samueldr> at least the TDMI helps convey the message
<samueldr> whilst the armv3 ARM7 core could be confused with armv7!
<sphalerite> true
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<clever> samueldr: arm has too many arms, and the documentation is spread over a dozen pdf files
monk has left #nixos-aarch64 ["Error from remote client"]
zupo has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
monk has joined #nixos-aarch64
<gchristensen> woohoo I get /dev/kvm now on amazon
<clever> baremetal?
<gchristensen> yea
<clever> [ 0.035799] CPU: All CPU(s) started at EL2
<clever> yep, i can confirm you booted in arm64 hypervisor mode this time
<clever> where did i put that image...
<clever> gchristensen: https://imgur.com/a/SiXlSaA
<gchristensen> I hmm
<clever> under normal conditions, going to a higher level (EL0->EL1) can only be done during an "exception" (syscall, hw irq, segfault)
<clever> going to a lower level (EL1->EL0) is done with the "exception return" opcode (eret)
<clever> when you go to a lower level, the bit-width can remain the same, or go smaller, but never bigger
<clever> so a 32bit kernel cant run a 64bit userland
<clever> the only way to go from 32bit->64bit, is to poke a higher power (EL2 or EL3), that is already in 64bit mode, and ask it to run something in 64bit for you
<gchristensen> nice
<clever> EL3 typically runs the firmware related to key management and DRM
<clever> EL2 is the hypervisor, and it can add a 2nd level of paging tables, so EL1's "physical address" goes thru the MMU a second time
<clever> EL1 is normal kernel space
<clever> and EL0 is userland
<samueldr> EL-1 is the javascript runtime
<samueldr> (joking)
<clever> samueldr: there is a dedicated opcode just for converting javascript floats back into 32bit ints, i'm not joking
<samueldr> I know
<samueldr> it matters because it needs to do the conversion "just like javascript does as implemented on x86_64"
<samueldr> which is 1~4% improvement IIRC compared to the slow path
<clever> gchristensen: in the case of something like an rpi, its possible to start EL3 in 32bit mode, there is no "higher power" to poke, so you are then permanently stuck in 32bit mode
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<clever> gchristensen: but to remain compatible with arm32 core's, from before EL's existed, you get the mess in the 1st image
<gchristensen> make -j64 is nice.
<samueldr> is this NixOS on armv7l again or something else?
<gchristensen> yeah, nixos on armv7l
<samueldr> nice
<gchristensen> I need to be able to build for arm7l ( :( ) and so trying to resurrect it
<samueldr> I feel that once we can get things evaluating / building, if we can make sure we have a machine that stays up to work through a limited subset of Nixpkgs the community can make it better
<samueldr> the hardest part currently is probably build firepower
<samueldr> having to build the world to fix one program isn't that nice :)
<gchristensen> yeah
<gchristensen> yeah.
<samueldr> like, I think anyone could realistically run armv7l on their e.g. raspberry pi to fix _one_ thing... but getting to "running aarch32 NixOS on my pi" is not the easiest
<gchristensen> +1
<gchristensen> I'm starting with the armv7l expression in the packet-nix-builders repo
<srk> I do run a bunch of armv7l rpis and one laptop. takes like a week to build from scratch (from cross compiled iso)
<samueldr> yeah :) I don't have that patience
<samueldr> if we get multiple contributors working on it, might it be relevant to make an armv7l branch on Nixpkgs that we can "stage" changes into a branch that changes less regularly? something that we could rebase / merge into master, etc?
<srk> it went pretty well last time, only like one test failure
<gchristensen> ideally we'd have a reliable arm7l builder for hydra too
<samueldr> yeah
<samueldr> I was assuming with such a builder
<samueldr> not sure if there is any worth in what I was asking though
<samueldr> maybe if things were woefully broken
<samueldr> but srk seems to say it's not
<samueldr> (and I didn't think it really was broken beyond belief)
<srk> pi4 compute module cluster could work :D
<samueldr> now that AArch32-capable big servers are identified, it might be less of an issue
<srk> ah, true
<gchristensen> I really, really, really don't want to be anywhere nearby to any quantity of rpis :P
<clever> gchristensen: i'll make sure to bring 5 of em to the next nixcon :P
<gchristensen> qemu-system-aarch64: can't apply global host-arm-cpu.aarch64=off: 'aarch64' feature cannot be disabled unless KVM is enabled and 32-bit EL1 is supported
<gchristensen> seems like I get the system at EL2
<gchristensen> so maybe that is saying the host just doesn't support 32bit EL1?
<gchristensen> but [ 0.030443] CPU features: detected: 32-bit EL0 Support
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<clever> gchristensen: some arm chips have support for a 32bit userland, but no 32bit kernel
<clever> so you must run a 64bit kernel with a 32bit userland
<gchristensen> ah ha! I just found that on the opensuse docs
<gchristensen> https://en.opensuse.org/ARM_architecture_support#Some_Armv8.x_SoCs_support_32-bit_only_in_userspace
<clever> it lets them ditch a large amount of the complex logic for 32bit kernel mode, that was in the image i linked above
<clever> 32bit EL0 is relatively simple, compare to kernel
<gchristensen> how can I tell the system to put me in to a 32bit-only userspace?
<gchristensen> beyond just running a 32bit program :)
<samueldr> you can't really
<samueldr> IIRC you'll always have environmental leakage
<gchristensen> that is how I thought it was... I was hoping for something better since I last looked with anger
<samueldr> though they seem to say they're using a chroot
<samueldr> maybe it's enough?
<samueldr> but IIRC last time we tried running aarch32 builds on aarch64 within the nix sandbox things were having issues, no?
<gchristensen> yeah I think so
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
<clever> there is a 32bit personality thing, that nix can set for 32bit on x86
<clever> but no such flag exists for arm32
<gchristensen> wow thankfully we don't have to deal with arm26
<samueldr> with what now?
<samueldr> ah
<samueldr> early ARM
<samueldr> it's not really 26 bit; it's mostly cheating some bits out of the address space AFAIUI
Mic92 has quit [Quit: WeeChat 2.9]
<DigitalKiwi> is armv26l what we'll get in ~18 generations
orivej has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 256 seconds]
zupo has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
kahiru has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<colemickens> I was just wondering about 2020.10 on pinebook, but I guess not good things.
<samueldr> u-boot?
<samueldr> what not good things?
<samueldr> there is one not-good-thing I have in mind: it default to enabling loading the environment from SPI flash
<samueldr> which means it can cause surprises for end-users that did nothin to the SPI flash
<samueldr> since IIRC the blobby vendor u-boot wrote to it
<colemickens> idk, a lot of this is still over my head, but this reply made it seem like maybe 2020.10 was perfectly configured for the rockchip chip in the PBP: https://github.com/samueldr/wip-pinebook-pro/pull/13#issuecomment-713712717
<colemickens> wasn't*
<samueldr> it wasn't for any of my builds according to what it said here AFAIK
<samueldr> I intended to look into it at some point
<samueldr> but ugh, time
<samueldr> I don't even think I looked into 5.9 properly
* colemickens is excited for 5.10-rc1, hoping to test mainline+uboot+drm rpi4
hmpffff has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
das_j has quit [Quit: killed]
ajs124 has quit [Quit: killed]
ajs124 has joined #nixos-aarch64
das_j has joined #nixos-aarch64
deadk has quit [Quit: edk]