aleph- has joined #nixos-aarch64
aleph- has quit [Client Quit]
aleph- has joined #nixos-aarch64
luxemboye has quit [Ping timeout: 240 seconds]
luxemboye has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 258 seconds]
h0m1 has joined #nixos-aarch64
patagonicus1 has joined #nixos-aarch64
apache8080 has joined #nixos-aarch64
patagonicus has quit [Ping timeout: 265 seconds]
patagonicus1 has quit [Quit: Ping timeout (120 seconds)]
patagonicus1 has joined #nixos-aarch64
sigtrm has quit [Ping timeout: 246 seconds]
sigtrm has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 268 seconds]
heywoodlh has quit [Quit: ZNC 1.8.2 - https://znc.in]
heywoodlh has joined #nixos-aarch64
apache8080 has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 268 seconds]
<Ke> normally one might be inclined to increase the voltage to reduce charging current etc.
<Ke> but not sure, what sort of tradeoffs there are, since that needs to be brought back to lower voltages to be actually used in most places
<Ke> definitely the norm in the industry is that tens of watts are normally transferred with higher voltages
bpye has joined #nixos-aarch64
srk has joined #nixos-aarch64
luxemboye has quit [Ping timeout: 240 seconds]
luxemboye has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 252 seconds]
zupo has quit [Ping timeout: 240 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #nixos-aarch64
<sphalerite> samueldr: do you have displayport working with your pinephone?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sphalerite> or rather: does anyone, and are there any tricks to it?
<sphalerite> I've tried connecting mine to my USB-C monitor, and the USB works fine (mouse and keyboard which are attached to the monitor control the pinephone just fine), but I'm not getting any additional outputs in xrandr
Irenes has quit [Ping timeout: 260 seconds]
<craige[m]> I've not had it working under any distro yet, sphalerite
<Ke> did you try reversing the connector orientation
<Ke> for some pine devices it made a difference, can't remember, which ones
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
Irenes has joined #nixos-aarch64
<sphalerite> craige[m]: hm the description of https://github.com/NixOS/mobile-nixos/pull/340 suggests that it does work
<{^_^}> mobile-nixos#340 (by samueldr, 3 weeks ago, open): pine64-pinephone: Fixes for gadget mode
<craige[m]> Excellent - that's sphalerite - I'll make sure to keep plugging away on the in future.
<craige[m]> * Excellent - thanks sphalerite - I'll make sure to keep plugging away on the in future.
h0m1 has quit [Ping timeout: 260 seconds]
<sphalerite> hm, but the power delivery from my monitor isn't working either, it doesn't charge while connected…
<sphalerite> Will try reversing the connector
<sphalerite> I can absolutely plug (no pun intended) the monitor that I have though, the Dell P2720DC, it works a charm with my laptop and it's great to have a dock-but-it's-inside-the-monitor-so-it-doesn't-take-up-any-desk-space
<sphalerite> The U2721DE is also nice, it's similar but with a slimmer bezel and ethernet. I have that one at work.
<sphalerite> Oh and displayport daisy-chaining so I can attach both of my external monitors with the one cable.
h0m1 has joined #nixos-aarch64
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
orivej has joined #nixos-aarch64
<sphalerite> OK, this seems to be independent of connector orientation.
<sphalerite> all it recognises is USB, no DP and no PD
<sphalerite> journal only shows USB things happening
alpernebbi has joined #nixos-aarch64
srk has quit [Quit: ZNC 1.8.2 - https://znc.in]
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
zupo has joined #nixos-aarch64
nicoo has quit [Remote host closed the connection]
nicoo has joined #nixos-aarch64
nicoo has quit [Ping timeout: 240 seconds]
nicoo has joined #nixos-aarch64
Raito_Bezarius has quit [Ping timeout: 260 seconds]
Raito_Bezarius has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Andoriyu has quit [Ping timeout: 245 seconds]
Irenes has quit [Ping timeout: 258 seconds]
Andoriyu has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
Irenes has joined #nixos-aarch64
<samueldr> I had eDP verified working with X11 on the demo image on my Pinephone
<samueldr> craige[m]/sphalerite: but note that earlier devices have a hardware issue, not sure if yours is one of them
<samueldr> documentation about this issue is terribly hard to understand correctly
<samueldr> there are no clear indications, only vague hints
<samueldr> >> HW on Pinephone 1.0 and 1.2 is broken, see above. With HW fix and USB-C HDMI dock/cable, HDMI out works.
<samueldr> except that's not entirely truthful
<samueldr> because newer 1.2 revisions have been fixed
<samueldr> there is also a firmware to flash to the ANX7688
<samueldr> which muddies up the water
<samueldr> I haven't worked on it on Mobile NixOS as a regression in mainline Linux made it impossible to flash at the time I was looking into it
<samueldr> more details about hardware bugs also on this page https://xnux.eu/devices/feature/anx7688.html
<samueldr> also note that strictly "power delivery" chargers may or may not work
<samueldr> I haven't been able to get any kind of answer about it
<samueldr> and haven't tried back now that I have a device with actually working USB
<samueldr> ah, this last page has more information about PD
<samueldr> the ANX7688 has to be configured properly, for this the firmware has to be flashed, and a software component has to have the firmware be loaded into the ANX7688
<samueldr> then it's able to do PD AFAIUI
<samueldr> but PD will be limited to 3A 5V, which is fine
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
rajivr has quit [Quit: Connection closed for inactivity]
justan0theruser has quit [Quit: WeeChat 2.9]
zhaofeng1 has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
<sphalerite> samueldr: wait, eDP or DP?
<samueldr> well, Type-C alternate mode
<samueldr> DP I guess
justanotheruser has quit [Ping timeout: 258 seconds]
<samueldr> yeah, eDP is just another DP, so it was wrong, but I also see why I was thinking the alt mode was called eDP
<samueldr> I guess we should always say "DisplayPort Alternate Mode on USB Type-C Connector"
<samueldr> as per the standard name
<edrex> i've finally gotten back around to installing on my two odroid hc1s. patagonicus any words of warning with current unstable?
justanotheruser has joined #nixos-aarch64
<samueldr> edrex: arapov (not present on irc at the moment) seemed to imply the HC1 used the same U-Boot builds as the C4
<edrex> i was reading that PR.. so does that mean I should use the PR as my nixpkgs?
<samueldr> it depends on what you're doing exactly
<samueldr> if you're building something that produces a full image with U-Boot built into it, I guess so
<samueldr> if you're burning U-Boot to the SD or image after the fact, no need to
<edrex> not sure yet. At some point I succeeded with a stock install image. Yeah I think just imaging SD card. Wait, U-Boot is in firmware right?
<samueldr> "in firmware" is not a thing really, U-Boot is stored somewhere (no don't think about that meme)
<samueldr> do you know if the HC1 have an SPI Flash?
* samueldr looks it up
<edrex> lol, i mean in flash
<samueldr> at first glance, it looks like there is no dedicated storage for the initial boot firmware
<samueldr> (U-Boot is the initial boot firmware here)
<samueldr> but their product pages are lacking
<edrex> Yes, my recollection is the sd image has to contain hardkernel's u-boot
<samueldr> right, no eMMC either?
<edrex> not on my board, there is an option iirc
<samueldr> wait, HC1 ??
<edrex> ya
<samueldr> Exynos5422?
<edrex> it's same as xu4
<edrex> armv7
<samueldr> then that's definitely not the same U-Boot as the C4
<samueldr> oh, disregard this PR!
<samueldr> I guess I got mixed up with the HC4
<edrex> it's built from the same repo iirc
<samueldr> in a totally unrelated way
<samueldr> each SoC may have a totally different way to build the firmware "correctly"
zupo has joined #nixos-aarch64
<samueldr> and most likely the exynos here does compared to an amlogic chip :)
<edrex> got it
<samueldr> I'm sorry I don't have experience with that platform to say anything
<edrex> i got confused by the hc4 model name too, it's an amalgam of hc1 and xu4 in my brain
<samueldr> what that PR was doing, initially, from the vendor's repository was only picking the binary blobs for the initial boot firmware
<samueldr> it was relying on the mainline U-Boot tree afterward
<edrex> so the stuff that's NDA/not available as source
<edrex> yeah, makes sense
<samueldr> yeah
<samueldr> but more importantly, AFAIUI it's signed and the amlogic SoC validates it
<samueldr> doc/README.odroid in mainline U-Boot quotes the HC1 as supported
<edrex> trying to get my brain back in the odroid groove
<samueldr> and it uses a similar scheme where binary blobs are used to start U-Boot
<edrex> iirc there is nix code somewhere to do the same for xu4/hc1
* edrex starts reading own notes from last december
<samueldr> XU3
<samueldr> though it only builds the U-Boot binaries, does not assemble any other blobs
<samueldr> not really an issue, but something to be aware of
<samueldr> CONFIG_IDENT_STRING=" for ODROID-XU3/XU4/HC1/HC2"
<samueldr> so it's a unified build
<edrex> any docs on building armv7 on an aarch64 host?
<samueldr> pkgsCross.armv7l-hf-multiplatform.ubootWhatever should get U-Boot going on x86_64
<samueldr> I know it's not what you asked for
<samueldr> about building armv7 on aarch64, the only safe way to do it is through a qemu-kvm virtualized (with kvm) vm
<samueldr> if the hardware supports it
<samueldr> it being running in 32 bit mode
<edrex> qemu-kvm runs ~ native speed?
<edrex> thanks, yeah I'm also wanting to enable ssh and install a host key. i know I went through this process at some point
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> qemu-kvm indeed runs at ~native speeds
<samueldr> a few years back I successfully built a "trustable" armv7l image with that method, and another user did too in parallel
<samueldr> (trustable meaning it was built without relying on artifacts from community users)
<samueldr> only third party artifacts were from cache.nixos.org
<colemickens> edrex: thefloweringash has a VM service nixos def that runs an arm7l vm
<colemickens> This is my take on it, it has a link to the original: https://github.com/colemickens/nixcfg/blob/main/modules/other-arch-vm.nix
<edrex> colemickens: i'm finding that very initimidating rn :) maybe once I level up a bit
<edrex> thanks though, filed away i my notes
alpernebbi has quit [Quit: alpernebbi]
<edrex> oh, I think this is what I did last time: https://github.com/NixOS/nixpkgs/pull/96991
<{^_^}> #96991 (by Mic92, 32 weeks ago, merged): nixos/installer: enable sshd by default
<edrex> hmm, I am not finding a link to the arm7l multiplatform sd image anywhere.. I think such is built on hydra, no? https://nixos.wiki/wiki/NixOS_on_ARM#Getting_the_installer
<samueldr> we don't have native armv7l builders
<samueldr> so there's no official images
<samueldr> it really makes getting started harder :(
<clever> arm32 native is also broken on master
<samueldr> it it still or a new breakage?
<clever> last i checked, the linker patch was still breaking linux headers
<samueldr> ah, not totally broken
<samueldr> just enough to cause an issue with a lot of things :)
<clever> the linuxHeaders used by the bootstrap stdenv
<clever> so the stdenv fails
<edrex> clever: is there an issue for it? i think that's the thing patagonicus1 mentioned a couple of months ago
<clever> edrex: yeah
<clever> *digs*
<edrex> thx
<clever> [clever@amd-nixos:~/apps/rpi/nixpkgs-test]$ nix build -f . hello --argstr system armv7l-linux
<clever> on a recent checkout of master
<{^_^}> #107386 (by Gaelan, 16 weeks ago, open): Can't build linux-headers on armv6l
<edrex> colemickens your qemu vm is looking more attractive :) what's the advantage over using binfmt-misc per-executable as in https://nixos.wiki/wiki/NixOS_on_ARM#Compiling_through_QEMU ?
<samueldr> it uses a real ARM cpu instead of an emulated one
<samueldr> which may or may not be problematic for some builds
<samueldr> binfmt-misc also has the issue of having an ambiant impurity that it runs on a foreign architecture, and *could* run those foreign architecture binaries
<edrex> oh, i thought the thing cole linked was for running on an amd64 host
<samueldr> though not really an issue in the end
<samueldr> nope, that VM runs on an aarch64 system :)
<patagonicus1> For the linked issue reverting the linked commit worked for me. Unfortunately armv7 is usually so broken that I have to have two or three local changes on nixpkgs to make it build
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
zupo has joined #nixos-aarch64
<edrex> patagonicus1: want to push a branch up somewhere with your local changes?
orivej has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 258 seconds]
<clever> [1/0/83 built, 32 copied (79.9 MiB)] building binutils-2.35.1 on ssh://pi@pi400 (round 1/2): checking whether build environment is sane... yes
justanotheruser has joined #nixos-aarch64
quinn has joined #nixos-aarch64
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 252 seconds]
heywoodlh has quit [Quit: ZNC 1.8.2 - https://znc.in]
heywoodlh has joined #nixos-aarch64
Andoriyu has quit [Quit: ZNC - https://znc.in]
<edrex> It sounds like what is holding things back is lack of official arm7l build hosts to keep builds from drifting
<edrex> but maybe there's too little interest because armv7 is less popular at least in devices with screens?
<edrex> (new devices)
<samueldr> mainly build infra issues
<samueldr> most servers you can get can't do 32 bit arm
<samueldr> and the one or two known hardware that can are extremely limited in numbers
<edrex> oh, i was wondering about that. so the hetzer arm servers are a no go
<samueldr> in addition to lacking the people-hours to actively work on slapping things into shape
<samueldr> not sure
<samueldr> depends on what they are
<samueldr> didn't know hetzner had ARM servers
<edrex> oh i think they EOL'd them awhile back..
<samueldr> so yeah, many of the ARM server options are no-go for 32 bit arm
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever> build of '/nix/store/zhklllfjp50zdyjrpfvqw5w304gmlr3k-linux-headers-5.11.drv' on 'ssh://pi@pi400' failed: builder for '/nix/store/zhklllfjp50zdyjrpfvqw5w304gmlr3k-linux-headers-5.11.drv' failed with exit code 2
<clever> samueldr: yep, still busted
<samueldr> aww
<clever> from todays master
<clever> samueldr: undoing the patch linked in the ticket does fix it (i believe), but that patch was to fix a ghc issue
<samueldr> can we conditionally apply the patch on not armv7?
<samueldr> sure, ghc won't build (maybe) on armv7l if that was the intent
<samueldr> but if it unblocks most everything else it would be better
<{^_^}> #103183 (by expipiplus1, 22 weeks ago, merged): Fix GHC bootstrap in pkgsMusl and include patch for binutils/16177
<clever> > This allows one to cross compile statically linked Haskell programs for armv7
<{^_^}> undefined variable 'This' at (string):494:1
<clever> samueldr: the whole point of the patch, was to fix ghc on arm
<clever> so excluding it only on arm, makes the patch pointless
<clever> oh
<clever> but its for CROSS compiling to arm
<clever> so the patch fixes cross-arm-ghc, but breaks native-arm-stdenv
<clever> so we want to make the patch only apply to cross, targeting arm
<samueldr> clever: please be more precise :) arm 32 bit or armv7l
<samueldr> otherwise it could get confusing
<clever> it breaks both v6 and v7
<samueldr> so arm 32 bit I guess
<clever> yeah
<samueldr> and yeah, in that case yeah, when cross-compiling only would I guess help?
<clever> yeah
<clever> [mainnet@mainnet-deployer:~/mainnet]$ nixops info --no-eval --plain | grep ec2 | grep rel | grep -v stopped | cut -f1 | sort -R | head
<clever> oops
<clever> wrong channel