<mDuff> What does it take to get g_ether working on a Pi 4b on NixOS? I see CONFIG_USB_DWC2_DUAL_ROLE=y, but loading g_ether, it warns "udc-core: couldn't find an available UDC"
<samueldr> I guess the question is "what does it take on other distros"
<samueldr> it should be the same afterward
<mDuff> It looks like Raspian ships a device tree overlay that does some necessary initialization-time setup.
<mDuff> ...I *suspect* that getting the appropriate bits into `config.hardware.deviceTree` might be appropriate, but ofc, need to figure out what aforementioned "appropriate bits" are first.
<samueldr> gchristensen (not time sensitive) as the qemu settings have not been fiddled with, and it works on my pinebook pro, and on the community builder, I guess it's likely to work on that c2.large, since the same qemu settings worked for thefl*weringash earlier
<gchristensen> great. I'm just getting to another active part of making dinner, let's create a c2.large.arm in a couple hours?
<samueldr> we could yeah
<gchristensen> coor
<gchristensen> cool. I took a nap from like 4:??-6, and am probably up for it then :)
<mDuff> ...hmm, looks like the existing raspberrypi-firmware-1.20190925 (pkgs.raspberrypifw) contains a dwc2.dtbo that might be what's missing...
<mDuff> ...yup, that did the trick.
<clever> mDuff: by default, the rpi4 usb-c is in device mode
<clever> there are dtbo flags to force it into host mode, but you probably dont want that
<mDuff> *nod* -- I'm trying to convince my Pi to play ethernet-dongle. After telling the bootloader to install the dwc2 overlay (and loading g_ether), it's doing that properly.
<mDuff> ...so the next step is to make the sd_image build set it up that way out-of-the-box. :)
Irenes[m] has quit [Ping timeout: 252 seconds]
lovesegfault has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 2.7]
h0m1 has joined #nixos-aarch64
<samueldr> pushed a change to use s2idle for suspend in the pinebook pro config, that's opinionated, but a much better thing to do rather than accidentally activating suspend and needing to force shutdown
<clever> samueldr: that reminds me, ive got crazy ideas to make suspend to ram work on an rpi, lol
<gchristensen> hi samueldr
<samueldr> hi gchristensen
<samueldr> once suspend is fixed on the kernel (or u-boot, or trustzone?) that'll go away from that generic config
lovesegfault has quit [Ping timeout: 272 seconds]
<thefloweringash> hi everyone
<samueldr> 'morning!
<samueldr> (assuming)
mDuff has quit [Ping timeout: 268 seconds]
<gchristensen> mksquashfs :(
<samueldr> ah, taking a while to make your system image to deploy&
<samueldr> ?*
<gchristensen> yea
ryantrinkle has joined #nixos-aarch64
<gchristensen> "but it parallelizes well" evidently not b/c it still takes ages to finish a 500mb squash with 96 cores
<samueldr> why can't I hold all these cores? http://i.imgur.com/PB9d7.jpg
<gchristensen> put a `mksquashfs` over the faceand it is right on the money
* t184256 just understood that he can run QEMU VMs inside Nix-on-Droid
<samueldr> can you?
<samueldr> is /dev/kvm there?
<samueldr> and accessible
<t184256> No, but tcg works
<thefloweringash> (reading scrollback) cross compiling that vm was on my todo list. I bootstrapped with an old sdimage and never got around to switching. The module I use does technically support cross buliding with nixpkgs.crossSystem
<samueldr> thefloweringash: you saw the gist?
<samueldr> oh, and a complication, I initially tried (part for fun) to cross-compile the qemu "harness" from x86_64-linux to aarch64-linux, and the system from x86_64-linux to armv7-llinux
<samueldr> qemu won't cross-compile due to python3 deps not cross-compiling right now
<samueldr> when I reduced the jenga^W complexity stack, it went easier :)
<thefloweringash> the build-vm-script is ok for testing, but the overlayfs of 9p + tmpfs is probably too slow, and overlayfs breaks the go tests for large files. for productionising I think I'd recommend some simple filesystem like ext4
<samueldr> I see
<thefloweringash> oh, no, didn't see the gist
<samueldr> ah, basically what was needed for it to cross-compile, got rid of `system` and used my usual cross-compilation fixes
<thefloweringash> for reference, my "production" config: https://bitbucket.org/thefloweringash/alex-config/src/master/build-vm.nix -- hopefully a good starting point, and if we come up with something nicer I'd like to take the changes :)
<samueldr> ooh, that's great
<thefloweringash> it passes a /nix/store as a squash, and on boot copies it to /
<samueldr> <3 thefloweringash
<{^_^}> thefloweringash's karma got increased to 6
<samueldr> I do wonder if it is worth it to keep the aarch64 cross-compilation of the armv7l system part of the "critical" chain with the armv7l builders
<samueldr> maybe with an hydra build
<samueldr> I don't know how else they can be managed by the aarch64 system without relying on *another* armv7l builder
<samueldr> maybe I'm missing something obvious?
h0m1 has quit [Ping timeout: 260 seconds]
<gchristensen> seems like a good idea
h0m1 has joined #nixos-aarch64
lovesegfault has joined #nixos-aarch64
<lovesegfault> gchristensen: Any idea why ghc doesn't build in parallel on the aarch64 box?
<gchristensen> ghc can't handle more than 4 cores
<gchristensen> or 10 maybe
* lovesegfault is horrified
<lovesegfault> ofc my gentoo buddies are there to complain :P
nbp has quit [Ping timeout: 250 seconds]
nbp has joined #nixos-aarch64
dongcarl has quit [Quit: The Lounge - https://thelounge.chat]
andi- has quit [Ping timeout: 252 seconds]
dongcarl has joined #nixos-aarch64
<gchristensen> this is no fun
<lovesegfault> gchristensen: What is?
<gchristensen> 20 minute iteration times to find my mistake was a typo, 5 times in a row
<lovesegfault> D:
<lovesegfault> That is horrible
<gchristensen> I really need to do more with the VM tests, instead of needing to test on real hw
<gchristensen> DRAM Initialization: [ 80%] [ =================> ]
andi- has joined #nixos-aarch64
dongcarl has quit [Quit: The Lounge - https://thelounge.chat]
<DigitalKiwi> obviously the solution is just to compile more haskell programs at once
<DigitalKiwi> conclusion: rewrite everything in haskell
<lovesegfault> DigitalKiwi: I'm compilin GHC
<DigitalKiwi> all versions at once
<gchristensen> samueldr: favorite SSH key?
<samueldr> I don't remember which one you used last time
<gchristensen> also, consider replacing your rsa keys with ed25519, much shorter and nicer to read ina nix expr :P
<samueldr> that would mean actively _doing something_, I hate that ;)
<gchristensen> :P
<lovesegfault> gchristensen: That's a blessed opinion
<lovesegfault> Nix made me rotate all my ssh keys to ed25519
<lovesegfault> Also: What determines whether or not a pkg is built by hydra (AArch64)
<thefloweringash> the dropbear used in initrd ssh doesn't support them
<lovesegfault> in particulat: ghc is not, apparently
<samueldr> lovesegfault: probably hydraPlatforms somewhere in ghc
<lovesegfault> thefloweringash: Doesn't surprise me, unfortunately
<samueldr> otherwise it should be everything, just like in x86_64
<samueldr> I do wonder which one you used last time
<lovesegfault> samueldr: grepping for hydra in .../compilers/ghc shows nothing
<gchristensen> does it matter?
<samueldr> no :)
<samueldr> but you did ask
<samueldr> and I wanted to just give whichever you used last time
<samueldr> I don't know what it was
<gchristensen> well, send me one. I'm going do one deploy right after this command finishes and I'm going to bed :)
<DigitalKiwi> see if you had a favorite one you'd know
<samueldr> should be the one from the aarch64 community machine
<gchristensen> thefloweringash: want to play too?
<thefloweringash> in general, yeah, slightly busy just now, but if you add my key I can join in later
<lovesegfault> What are y'all doing?
<gchristensen> thefloweringash: send me a key
Vikingman has joined #nixos-aarch64
<thefloweringash> gchristensen: sent
<samueldr> probably figuring out a good way to get a 32 bit ARM infra for hydra builds
<samueldr> though nothing binding for now, hopefully it'll work and be acceptable and accepted
<lovesegfault> Oh, that would be awesome :)
<samueldr> I don't know what will be the next step
<gchristensen> all I know is the first step is being able to do it, and we've been trying for that for at least a year
<samueldr> I'm thinking it may be a subset at first
<samueldr> that's for sure
<gchristensen> building the docs.
<gchristensen> I just want to go to bed :x
<gchristensen> Emily is about to rescue me from this apparent nightmare
<samueldr> no worries if you finish up tomorrow morning
<samueldr> in fact, unless it's *really* about to finish, finish up whenever :)
<DigitalKiwi> gchristensen: if you get it working i'll send you desk pictures
<gchristensen> g'night!
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
h0m1 has quit [Quit: WeeChat 2.7]
h0m1 has joined #nixos-aarch64
kai_w_ has joined #nixos-aarch64
jackdk has quit [*.net *.split]
kai_w has quit [*.net *.split]
DigitalKiwi has quit [*.net *.split]
clever has quit [*.net *.split]
craige has quit [*.net *.split]
sigtrm has quit [*.net *.split]
sigtrm has joined #nixos-aarch64
craige has joined #nixos-aarch64
DigitalKiwi has joined #nixos-aarch64
clever has joined #nixos-aarch64
jackdk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
kai_w_ has quit [Quit: Konversation terminated!]
orivej has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 240 seconds]
wavirc22 has joined #nixos-aarch64
wavirc22 has quit [Ping timeout: 258 seconds]
wavirc22 has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 258 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ryantrinkle has joined #nixos-aarch64
lovesegfault has quit [Ping timeout: 272 seconds]
<samueldr> got a tip on my pinebook pro repository, updated ATF to the latest tip and reboot now works just fine on the pinebook pro
<Smith[m]> samueldr: Nice! git checkout and nixos-rebuild switch will fix it ?
<samueldr> nope
<samueldr> updating u-boot automatically is "rude" and dangerous
<samueldr> just like if we updated your bios firmware on update!
<samueldr> git pull and those instructions
<Smith[m]> It's from u-boot so i have to rewrite it ?
<samueldr> not sure I understand the question
<samueldr> I'll try to answer anyway: u-boot has to be updated on the eMMC (assuming you're booting off the eMMC)
<Smith[m]> Yeah just saw the commit :D
<Smith[m]> Yes I mean i have to do a dd again with the new u-boot
<samueldr> and if for some awful reason it failed to update, you wouldn't be able to boot :)
<samueldr> yeah
<samueldr> though I did add that oneliner
<samueldr> with the by-path device it's sure to be the eMMC
<Smith[m]> I'm using a sd-card , Do I have to change the uboot on the eMMC ?
<samueldr> it would have been nice if it fixed suspend though :)
<samueldr> it depends on your exact setup
<samueldr> if there is a u-boot on the eMMC, it's that one that the pinebook pro will be using
<samueldr> otherwise it defers to the SD card
<samueldr> if you erased the start of the eMMC to use the SD card, you may want to burn that u-boot to the SD card
<Smith[m]> Oh right, I see.
<samueldr> (there is no absolute right answer to that question :))
hexa- has quit [Quit: WeeChat 2.7]
lovesegfault has joined #nixos-aarch64
hexa- has joined #nixos-aarch64
lovesegfault has quit [Ping timeout: 268 seconds]
lovesegfault has joined #nixos-aarch64
<lovesegfault> Eh, I keep getting no space left of device; annoying
zupo has joined #nixos-aarch64
mDuff has joined #nixos-aarch64
zupo has quit [Ping timeout: 268 seconds]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
dongcarl has joined #nixos-aarch64
<lovesegfault> clever, samueldr Have any of you encountered a rebel RPi3?
<lovesegfault> uboot just boots the same entry
<lovesegfault> ignores extlinux.conf
<clever> lovesegfault: any chance you have multiple boot partitions?
<clever> lovesegfault: are you sure its even running uboot?
<lovesegfault> clever: I am not sure
<lovesegfault> I could have two boots?
<lovesegfault> it all started when I tried resizing my boot
<clever> lovesegfault: definitely, check `fdisk -l` on the device
<lovesegfault> because nixos-rebuild would fail with out of disk
<clever> only see one boot partition
<clever> is it actually mounted?
<lovesegfault> it mounts both on boot
<lovesegfault> how do I set sdc1 as boot?
<clever> lovesegfault: fileSystems."/boot"
<clever> same as normal nixos
<lovesegfault> I mean, mark the FS partition as boot
<lovesegfault> fdisk reports sdc2 as boot
<clever> the rpi firmware ignores that boot flag
<clever> it just looks for a fat32 with the boot files
<lovesegfault> :(
<lovesegfault> then why on earth is it reading some rogue extlinux :P
<clever> lovesegfault: if you `umount /boot` then `ls /boot` is there a second extlinux.conf?
<lovesegfault> clever: :O yes
<clever> lovesegfault: thats why
<clever> lovesegfault: delete the interloper!
* lovesegfault nukes it
<lovesegfault> And it broke :P
<clever> lovesegfault: i think the nixos setup assumes that the fat32 is NOT at /boot
<clever> lovesegfault: and extlinux.conf should be in the /boot directory of the ext4 at /
<clever> copy it over, and then fix your fileSystems. ?
<lovesegfault> So this is wrong?
<clever> maybe
<clever> i cant find a source, but i remember the fat32 belonging at /boot/firmware
<clever> /home/clever/apps/nixpkgs-hasura/nixos/modules/installer/cd-dvd/sd-image.nix: "/boot/firmware" = {
<clever> yeah, there it is
<clever> /home/clever/apps/nixpkgs-hasura/nixos/modules/installer/cd-dvd/sd-image.nix: Volume ID for the /boot/firmware partition on the SD card. This value
<clever> /home/clever/apps/nixpkgs-hasura/nixos/modules/installer/cd-dvd/sd-image.nix: Size of the /boot/firmware partition, in megabytes.
<clever> basically, uboot and the rpi firmware goes into the fat32, at /boot/firmware
<clever> extlinux.conf and the linux kernels, go into /boot, a directory on the ext3/4
<lovesegfault> Aha!
<lovesegfault> :)
<samueldr> clever++
<{^_^}> clever's karma got increased to 306
<lovesegfault> clever++
<{^_^}> clever's karma got increased to 307
<lovesegfault> Thanks all :D
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> notes about the latest update https://github.com/samueldr/wip-pinebook-pro#u-boot
<samueldr> u-boot now lights the LED up instantly thanks to external patches
<samueldr> but more useful for some, I added an alternative attribute that will use an alternate boot order
<samueldr> the default is that u-boot will look for the eMMC, then SD; the alternate order is that u-boot will look in SD, USB, then eMMC
v0|d has joined #nixos-aarch64
<clever> samueldr: lights up which led? on which models? thats something ive been researching
<samueldr> pinebook pro
<samueldr> on the pinebook pro
<clever> ah
<samueldr> :D
<clever> on older rpi models, the status led was plain gpio
<clever> on the 3 and 4, its on a barely documented i2c gpio expander
<clever> and your required to talk to the firmware to twiddle it
<clever> things break down, when you are the firmware :P