<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>
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>
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
<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
<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?
<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
<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>
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