orivej has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
toon has quit [Ping timeout: 240 seconds]
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
<samueldr> colemickens: if you want to run the built-in OS, sure
<samueldr> colemickens: but the verizon Pixel 3 can't be unlocked
<samueldr> colemickens: because telcos are terrible
<colemickens> no way
<samueldr> yes way
<samueldr> IIRC same issue with pixel 2
<samueldr> so it was a minefield navigating through the cheaper options
<colemickens> thanks for lmk, that's ridiculous, but at the same time I'm not surprised? I guess I've recovered from past VZW trauma
<samueldr> unless someone leaks the qualcomm programmers, *and* somehow produces a valid bootloader image which allows unlocking, and system image (maybe) I don't think it'll happen
<samueldr> there may be a temporary root option from what I've read
<samueldr> but that's like 0.001% of the way there
<samueldr> you won't be booting Mobile NixOS with that
<colemickens> Yeah. So you know how you told me about the debug cables and I drug my feet? I told myself I wouldn't do that today.
<samueldr> haha
<colemickens> I might have a paperweight on the way if I can't cancel. lol, it is what is. except maybe that phrase is poisoned now.
<samueldr> it is of utmost importance, with any phone purchase, to check beforehand if it is (1) unlockable and (2) sources are available
<samueldr> and for (1), make sure that the _variant_ you buy has been confirmed!
<colemickens> Depending on how bad the screen is, I might just switch devices. Use it as my daily, use my current as a dev device.
<colemickens> (idk how nice big ebay sellers are about cancellations.)
<samueldr> dunno
<colemickens> so strange. it seems like they gave up on carrier locking it... so why bother keeping the bootloader locked?
<samueldr> can it be used outside of verizon?
<colemickens> I guess you comments imply it would take engineering work ($$$) for them to open it up
<samueldr> nah, probably no engineering work, only undoing the additional work or configuration they asked the OEM to do
cript0nauta has quit [Remote host closed the connection]
cript0nauta has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
cript0nauta has quit [Remote host closed the connection]
cript0nauta has joined #nixos-aarch64
<samueldr> ugh, I can't stand software that is inscrutable during runtime
<samueldr> udevadm returns "1"
<samueldr> --debug added gives no logging
<samueldr> udevadm settle*
<samueldr> looking at the source, sure enough, there is literally no useful debug log added around where error conditions can happen to return something
<samueldr> so one of the `return r` returns 1, and I need to figure out which
<samueldr> is it really that costly to not add a clear error message everywhere an error happens?
cript0nauta has quit [Remote host closed the connection]
cript0nauta has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 256 seconds]
h0m1 has joined #nixos-aarch64
<samueldr> welp, whatever causes the issue also affects eudev
<samueldr> so I guess it's a kernel-side regression
* samueldr actually tests the same nixpkgs revision with
<samueldr> 5.7*
<samueldr> welp, I guess I'll end up bisecting
rajivr has joined #nixos-aarch64
patagonicus9 has joined #nixos-aarch64
patagonicus has quit [Ping timeout: 256 seconds]
patagonicus9 is now known as patagonicus
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
kyren2 has joined #nixos-aarch64
<kyren2> maybe this is a more appropriate place to ask than #nixos, is it currently possible to cross compile nixos using nixos-rebuild from x86_64 to aarch64?
<kyren2> I'm trying to do this using the nixos nixpkgs.crossSystem configuration and it is failing, and I'm not even sure it's something that is supposed to work right now
<samueldr> with caveats, and limited
<samueldr> so, the easy answer is: not quite yet for a basic limited system
<samueldr> and probably not for a while for a complex system with lots of deps, especially X11 things
<samueldr> not that it's infeasible, but things weren't built with that in mind at first
<kyren2> okay, that would explain why there was documentation suggesting it would work and that it appeared to partially work, then fail partway through with a confusing error
<kyren2> oof, I don't have the error anymore but it was something like "I need x86_64-linux to build /nix/store/xxx-binutils-something but I am aarch64-linux"
<kyren2> but I was building ON x86_64-linux, it was very confusing
<kyren2> but thanks for the heads up!
<samueldr> that might be a different-but-related issue
<samueldr> what I'm talking about is that _at build time_ things end up failing
<samueldr> though yours was AFAICT at eval time
<samueldr> (or before building)
<kyren2> hmm, okay
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
kyren2 has quit [Remote host closed the connection]
<samueldr> :| I may need the gru-peeps to assemble, and test 5.8 with their gru-variants and suzyqable to see if it only affects dumo (or scarlet), or all grus
<samueldr> (I guess I could look at the device trees and see if there's any difference in the battery gauge side of things)
<DigitalKiwi> are you using real words
<samueldr> gru is the family of rk3399 chromeos devices
<samueldr> so, hopefully I'm using real worlds
<DigitalKiwi> what's suzyqable
<DigitalKiwi> and dumo
<samueldr> dumo is a gru
<samueldr> as scarlet, bob and kevin are
<DigitalKiwi> now you're just messing with me
<samueldr> I know it sounds wild
<samueldr> but it's all true
<DigitalKiwi> is there a stuart and a herb
<samueldr> now you're messing with me
<DigitalKiwi> :D
<DigitalKiwi> i guess they're trying to keep some plausible deniability to not get sued
<sphalerite> samueldr: wait, is this the issue that https://github.com/NixOS/nixpkgs/pull/94699 was done for?
<{^_^}> #94699 (by Mic92, 5 days ago, merged): Revert "linux: Init 5.8"
<samueldr> absolutely not
<sphalerite> ok
<samueldr> but at first I was suspecting it might be related
<sphalerite> in that case yeah I'll happily test it on my bob :)
<samueldr> 5.8 on bob spews stuff related to the battery on one of the serial ports
<samueldr> Unhandled VB reg %s
<samueldr> uh
<samueldr> %x
<samueldr> I tracked this to a series of update with the battery stuff in the kernel
<samueldr> and I haven't tracked it yet, but there's one update that also hangs udevadm settle, making it exit with status 1
<sphalerite> hm but 5.8 isn't back in nixpkgs yet
<samueldr> nope
<sphalerite> I'll wait for that if you don't mind :p
<samueldr> mobile nixos work :|
<samueldr> (which is EXTREMELY frustrating as there is absolutely no explanation why it exits with a failure code!)
<samueldr> eudev also does the same
<samueldr> so *something* somehow hangs settle, and no one tries to explain itself
<samueldr> I guess it must be that something with the EC is unhappy making things hang
<samueldr> because of that spew
<samueldr> if it's dumo/scarlet specific, it's going to be harder to get eyes on it I figure, it almost seems no one has one except me
<samueldr> even more confirmation, the battery is sbs-9-000b and the subsystem that is causing issues is sbs-battery
<samueldr> ah, part of arch/arm/boot/dts/cros-ec-sbs.dtsi so I guess it's likely to be quite universal as an issue
alp has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sphalerite> /build/source/build/../drivers/media/platform/msm/camera_v2/sensor/msm_sensor_driver.c:1033: undefined reference to `hq_regiser_hw_info'
<sphalerite> why must the typo have perpetuated itself like this
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kyren2 has joined #nixos-aarch64
<kyren2> hey, so I have a "successful" 20.03 install on a raspberry pi 3B+, is audio supposed to work or is there some other magic I have to do, I've really tried to figure this out myself but I'm in way overy my head I think
<clever> kyren2: analog audio or hdmi audio?
<kyren2> analog audio
<kyren2> the only output I seem to have is "dummy output"?
<clever> i think it should just work, what do you see in `cat /proc/asound/cards` ?
<kyren2> I will check that in just a bit
orivej has quit [Ping timeout: 240 seconds]
<kyren2> hmmm, okay so it looks like the hdmi is working maybe, I see:
<kyren2> 0 [vc4hdmi ]: vc4-hdmi - vc4-hdmi vc4-hdmi
<kyren2> but if I run 'pulsemixer' the only output I see is "Dummy Output", and I'm not sure what that means
<kyren2> maybe it's supposed to work and something else is going on
orivej has joined #nixos-aarch64
<clever> kyren2: sounds like the driver to do the pwm audio over vchiq isnt enabled
<kyren2> is that like a kernel module that I need to explicitly load, or is it part of the uhhh.. device tree stuff that I completely don't understand
<clever> pretty sure the device-tree enables it by default on the pi3
<clever> but the uboot layer in the middle might break it
<kyren2> okay got it, I removed everything I'd tried to "fix it" in config.txt and also upgraded to the 5.4 kernel that comes with 20.03 instead of using linuxPackages_4_19
<kyren2> this breaks HDMI
<kyren2> HOWEVER, either because of the upgrade or possibly because it breaks HDMI, it makes the other sound device work
<kyren2> I noticed that uboot seems to get in the way of configuring things in config.txt
<clever> config.txt will both enable certain things in hw/firmware, and also patch the device-tree to tell linux its safe to use the given hw
<clever> u-boot then throws the device-tree out, and loads its own device-tree from the SD card
<kyren2> oh I see
<kyren2> well that makes sense then
<clever> yeah, that complicates doing things the "right" way
<kyren2> I've reverted config.txt to what was in the 20.03 image and I won't touch it again then
<clever> for the fake analog audio, its a complicated dance between 3 main components
<clever> first, you have linux, generating audio samples somehow, and sending them to the firmware over vhciq
<clever> then the firmware on the VPU will accept those samples, use some fft wizardry to upsample it to ~400khz, and put samples into ram
<clever> the firmware then configures the dma peripheral, to copy them into the pwm peripheral, at a given rate
<clever> the pwm hw then generates PWM, and an external low-pass filter turns it into analog levels
<kyren2> is it possibly important that the pi was connected to a monitor over hdmi with no speakers, I was getting an error in dmesg that seemed to be about that
<kyren2> wow that's a lot of steps
<clever> the analog audio and hdmi audio should appear as completely seperate alsa devices
<clever> and then you just pick the right one in software
<clever> and thats what /proc/asound/cards is listing
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
<kyren2> I see
<clever> drivers/staging/vc04_services/interface/vchi/TODO:able to use bcm2835-audio without having /dev/vchiq created. One could argue
<clever> drivers/staging/vc04_services/bcm2835-audio/bcm2835.c: { .compatible = "brcm,bcm2835-audio",},
<clever> drivers/staging/vc04_services/Makefile:obj-$(CONFIG_SND_BCM2835) += bcm2835-audio/
<clever> kyren2: do you have CONFIG_SND_BCM2835 set?
<kyren2> I do now, as a module, but like I said sound is working in kernel 5.4.57
<kyren2> I'll check whether that was enabled in kernel 4.19
<kyren2> but I didn't change any kernel options from their default
<clever> this is the source for the arm side of the driver
<kyren2> I haven't checked on the 4_19 kernel to see if it was just not enabling the SND_BCM2835 module, it's not a big deal to me because I actually don't even want HDMI output
<kyren2> now I have a worse problem though with a terrible solution
<kyren2> the pi doesn't seem to boot without a monitor attached, I must be able to control that somehow via config.txt, my terrible solution is that I have one of those null hdmi dongles
<kyren2> ah, I think hdmi_force_hotplug=1 does the trick
<clever> there is a config.txt thing to ignore hdmi hotplug
<clever> yeah, thats it
<kyren2> clever++
<{^_^}> clever's karma got increased to 493
<kyren2> I now (maybe) have a working mopidy audio player on my raspberry pi that connects to my NAS
<kyren2> it at least works a little!
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
kyren2 has quit [Remote host closed the connection]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
samrose_ has quit [Ping timeout: 260 seconds]
samrose_ has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
LnL- is now known as LnL
zupo has joined #nixos-aarch64
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
<Thra11> Has anyone managed to do a significant amount of building using qemu on an aarch64 host to target armv7l? It appears to work ok at first, but whenever I try to build something it eventually gets stuck and ends up spinning at 100% CPU for hours.
cole-h has joined #nixos-aarch64
<samueldr> AFAIK yes
<samueldr> theflowering//ash is, and using an aarch64 server with serious firepower this eval (apparently?) built a whole boatload https://hydra.nixos.org/eval/1583749
alp has quit [Ping timeout: 246 seconds]
<samueldr> though it generally is stuck lately (off even?) and no one AFAIK looked into the issues https://hydra.nixos.org/jobset/nixpkgs/nixpkgs-unstable-armv7l
<Thra11> samueldr: I thought that was an armv7l kernel on an aarch64 CPU?
<samueldr> oh, you meant qemu-user?
<samueldr> because, you see, this is qemu (kvm)
<samueldr> :)
<Thra11> Yes, I do. (Sorry, should have said)
<samueldr> no worries, I *know* it's already extremely confusing and easy to make mistakes
<samueldr> I guess it's more about "is qemu-user working as well on aarch64 than on x86_64" at this point :/
<samueldr> I wouldn't think there is anything intrinsic to Nix, Nixpkgs or NixOS that makes this fail more
<samueldr> but I could be wrong
<Thra11> I guess if qemu-user doesn't work, but qemu does, I could create a qemu vm with NixOS as the guest and use that as my build server instead.
<samueldr> that's basically the only known workable solution for native builds, but might still need some work to get what you want
<Thra11> Hopefully theflowering//ash's cache will get me past the bit where I have to build the armv7l system to run inside the VM, without a working armv7l builder.
<samueldr> using 20.03 it's definitely possible to kickstart your own trustable system
<samueldr> through cross-compilation from x86_64
<samueldr> (that's how the chicken-and-egg scenario was solved here)
<samueldr> should still be possible... except that I haven't actually tested since a good while to see if there are regressions affecting armv7l
<Thra11> Do you know which "flavour" of qemu I want? (e.g. normal/kvm/xen/) Looks like both XEN and KVM are enabled in the kernel config.
<samueldr> kvm
<samueldr> at least that's what we have used
<samueldr> qemu-kvm, the package, is basically just a wrapper to qemu with the right option turned on IIRC
rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-aarch64
<Thra11> I don't seem to have a qemu-system-arm, only qemu-system-aarch64?
<samueldr> IIRC it's what you want anyway
* samueldr digs for details
alp has joined #nixos-aarch64
<Thra11> I'm sort of following https://nixos.wiki/wiki/NixOS_on_ARM/QEMU
<samueldr> it might not help that much
<thefloweringash> for reference that builder is currently on recent 20.03 (nixos-version says: 20.03.2762.e9bd19d4d35 (Markhor)), and cross compiles the base system
<thefloweringash> it uses the regular config option `nixpkgs.crossSystem.system`, see https://bitbucket.org/thefloweringash/alex-config/src/a1e9426d8388a55589a2fa21591cae113da280ab/configuration.nix#lines-132:146
<samueldr> aarch64→armv7l right?
<thefloweringash> yep
<samueldr> how's extra-platforms = armv5tel-linux armv6l-linux treating you?
<samueldr> do you get accidental armv7l in armv6l builds?
<thefloweringash> I haven't tried that in a while. I had to check what my last build configuration was for that host even
<samueldr> hah
<samueldr> so I'll assume it's undetermined
alp has quit [Ping timeout: 246 seconds]
quinn has joined #nixos-aarch64
pinkieval has quit [Killed (Sigyn (Stay safe off irc))]
pinkieval has joined #nixos-aarch64
<samueldr> sphalerite: about the issue I talked about... ~10-12 hours ago
<samueldr> pretty sure all rk3399 chromebooks will exhibit the issue
<samueldr> but no way to confirm
<sphalerite> I'll have lots of time (he said…) starting Friday, when I stop working for a while :)
<samueldr> but considering the print in the cros-ec comes from "virtual_battery", and *that* defines the battery protocol
<samueldr> and the registers added during 5.8 are not in there
<samueldr> the bug IMO is that the cros-ec prints logging for those
<samueldr> (oh, there's two issues btw)
<samueldr> which printing those is costly as it ends up losing logs, and also just plain ugly
<samueldr> and then there's another issue I need to figure out, but *something* isn't implemented right and it hangs for udevadm settle
<samueldr> and, again considering we can see the EC's source, basically it means I now have to jump into a LKML thread and argue :(
<sphalerite> exciting
<sphalerite> so am I understanding this right — the EC driver is breaking udev?
<samueldr> the battery driver, which is a generic protocol, which the cros-ec implements, is breaking udev
<samueldr> AFAIUI the EC driver from the kernel is not part of this
<samueldr> the EC exposes the "sbs" battery protocol in a generic manner over, uh, I²C IIRC (or another such protocol)
<samueldr> I²C yes
<samueldr> I'm about to check, but I believe it hangs udevadm settle because it would simply hang reading /sys/ fs paths
<samueldr> though I'm unsure about that assertion
<sphalerite> aaah
<samueldr> and then there's the other issue where it implements registers that the cros-ec virtual battery doesn't
<samueldr> in itself it probably would be fine, except that the virtual battery logs every bad access :/
<samueldr> so the EC log (ttyUSB2 for me) is basically useless
<samueldr> "This patchset improves support for SBS compliant batteries"
<samueldr> would it be rude to reply
<samueldr> "what about uncompliant batteries?"
<samueldr> or uh, non-compliant
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> right, if udevadm settle hangs, it's because it's waiting on things in a queue, use `--debug` on `udevd` to get actual useful info
{`-`} has joined #nixos-aarch64
<samueldr> ooh, I think the udevadm hang might be some bad behaviour when too many registers are being queried
<samueldr> or something along the line
<samueldr> because, carefully re-doing the history, I end up with it hanging for a while, but *not* (apparently?) timing out
<samueldr> I see nothing in there that is much different than the other commits
<samueldr> and udev didn't exit in a failure mode
andi- has quit [Ping timeout: 260 seconds]
<samueldr> my intuition seems to be valid; adding the following commit indeed now makes udevadm settle exit with status 1, which I interpret as probably some kind of timeout
<samueldr> it only adds more access to data
<samueldr> haha! I think I have found part of the problem, though I fear it might require another arduous bisect session
<samueldr> some change seems to be coaxing the sbs-battery driver into hammering the I²C endpoint with dozens, if not more, of queries per second
<samueldr> while on 5.7 it doesn't seem to
andi- has joined #nixos-aarch64
<samueldr> I feel the way I run an update on that chromeos tablet is weirdly neat
<samueldr> < result/kpart ssh nixos@snowball-two 'sudo dd of=/dev/mmcblk1p1 bs=8M status=progress && sudo reboot'
<samueldr> whew! it seems that at the start of that patch set it acts the same as with 5.7 proper, so the new misbehaviour is part of the same patchset
<noneucat> ran into a nasty bug involving driver probe order today :( apparently if you build all your modules into the kernel some drivers might just fail to probe due to an unlucky order
<samueldr> yeah
<samueldr> that's a thing that can happen
<samueldr> and it sucks
<samueldr> I've seen that for other things than the pinephone before
<noneucat> just curious: is there a reason why we do not use modules for the pinephone kernel in mobile-nixos?
<samueldr> not really
<samueldr> the main reason is that at one point there was absolutely no support for modules in Mobile NixOS
<noneucat> ahhhh
<noneucat> that makes sense
<samueldr> the real reason is that right now the stage-1 and stage-2 images are so disconnected that you might end up trying to load modules for the wrong kernel
<samueldr> e.g. if you update the kernel in your config, but not for the stage-1 boot
<samueldr> that's something that's in the "open ended questions" I have
<samueldr> I don't know yet how to solve it, so I ignore the problem until it's needed :
<samueldr> :)*
<noneucat> i see :) haha
<samueldr> it's possible to use a modules-based kernel with modules in stage-1
<samueldr> and have no modules within stage-2 at all
<samueldr> so that's a midway point
<samueldr> but it's where confusion may happen
<noneucat> yeah that's the direction i was thinking in too
<samueldr> like, that already works
<samueldr> qemu does that
<samueldr> you'll find most design decisions are often pragmatically driven
<samueldr> something like "it needed to be that way to work for one thing at one point in time"
<noneucat> just as a consequence of history i suppose
<samueldr> yeah
<danielrf[m]> So I just got adb/fastboot to build and run successfully with the nixpkgs clang toolchain on `aarch64-linux`: https://github.com/danielfullmer/soongnix/commit/e705c624b88ad55f59f05828c32a9cb2f01381ef
<danielrf[m]> I was able to flash an android image to my phone from my pinebook pro :)
<danielrf[m]> As far as I'm aware, Google doesn't distribute any platform-tools binaries for aarch64, including fastboot / adb