orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
h0m1 has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-aarch64
h0m1 has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<colemickens> cool, my pi is now only net booting?
<colemickens> I know I didn't set that as the configuraiton for the eeprom I flashed.
* colemickens set BOOT_ORDER wrong
<clever> colemickens: with the most recent firmware, you can pop a pieeprom.upd and pieeprom.sig onto your tftp server, and the firmware will reflash itself
<clever> the .sig is just the bare sha256 hash of the .upd file
<colemickens> It turns out I just had the order wrong, so it fell back to sdcard after netboot timed out
<clever> but if you do "brick" things, you need recovery.bin to unbrick
<colemickens> But that's excellent to know
<clever> ah
<clever> and recovery.bin only works from SD
<colemickens> makes sense
<clever> if pieeprom.upd is found, the firmware will ALWAYS download it, and do a full diff against itself
<clever> if any changes are found, reflash & reboot
<clever> if no changes are found, continue the boot as normal
<colemickens> clever: to be clear, the peeprom.upd is just a regular pi eeprom.bin ?
<clever> colemickens: yep
<clever> let me grab a pastebin...
<colemickens> this seems great though, I can copy the /boot files and copy the latest firmware to pieeprom.upd and hash it, serve it all up over tftp and never really have to think about it
<colemickens> in fact, my netboot'd pi will stay more auto-updated than the mother-pi :P
<clever> colemickens: gistfile1.txt is using an x86 nixos machine to generate pieeprom.upd (rpi-eeprom-config has since been packaged by somebody else)
<clever> colemickens: gistfile2.txt is the serial output (because i had turned on BOOT_UART=1) as the pi4 boots
<clever> 47 is when it gave up sd booting (because my order says sd, then net)
<clever> ~71 is when it begins network boot
<clever> 131 is the diff of the .upd and eeprom, so it trigger a flashing
<colemickens> lol, my... purchase-eager self bought a cheap hdmi capture card instead of uart cable. feeling a bit silly.
<clever> and 135 onward, is the pi4 booting again
<colemickens> oh wow, yeah you captured the whole process
<clever> then i realized i did something wrong in the cfg (forget what) so i did it again
<clever> gistfile5.txt shows it booting when i dont delete the file, it found 0 bytes different, and continued the boot
<colemickens> does it still double-reboot though?
<clever> nope
<colemickens> It seems like it checks the eeprom twice in gist5 still
<clever> because i made a change to the .upd file
<colemickens> all inside gist5?
<colemickens> lines 17, and 29
<colemickens> Oh
<colemickens> gist5 IS you doing the new flash
<colemickens> and then the second, all-same boot, got it
<clever> yeah, line 1 is changing the version of the eeprom, 14 is the diff, and then 29 is when it rebooted and found no changes
<clever> gistfile1.txt is using the 2020-06-12 version, but it didnt do what i wanted, so i switched to 2020-06-15
<clever> i believe each + or . is a 4kb chunk of the eeprom, the erase block size
<clever> so the 25 +'s are 100kb on the dot
<clever> which is the bootcode.bin held in the eeprom
<clever> it has the same job and format as the old bootcode.bin from past models
noonien has quit [Ping timeout: 260 seconds]
<clever> also of note,
<clever> EEPROMs updated. R
<clever> PM_RSTS: 0x00001020
<clever> [clever@amd-nixos:~/apps/bcompiler]$ strings ~/apps/rpi/rpi-eeprom/firmware/critical/pieeprom-2020-04-16.bin | grep 'EEPROMs'
<clever> EEPROMs updated. Rebooting
<clever> colemickens: this printf got cut off, because it triggered a reboot without waiting for the uart tx to flush
<clever> > "ebooting".length
<clever> 8
<{^_^}> value is a string while a set was expected, at (string):318:1
noonien has joined #nixos-aarch64
<clever> 8 bytes missing
alunduil has joined #nixos-aarch64
noonien has quit [Quit: Connection closed for inactivity]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
cole-h has quit [Quit: Goodbye]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
<wavirc22> angerman: I have an emmc but could not get it to boot. uboot wouldn't pick up the partitions. Someone else reportedly made it work somehow. I ended up using an nvme drive over USB.
<angerman> wavirc22: as reported on the repo, I have it working on a eMMC. On the odroid forum someone reported having a bad eMMC. Does yours alllow you booting other images?
<angerman> wavirc22: I should have reversed enough of the aml encrypt tool to not need that idiocity anymore. Trying to fix the efuse/mac address right now.
<wavirc22> angerman: Yes. Armbian works ok. So I'm unclear on what I was doing wrong. This was my first, dive into uboot / nix and arm.
<angerman> wavirc22: I’ll probably open a few more PRs.
<wavirc22> angerman: I can add you as a collaborator if that's convenient for you.
<angerman> It’s ok as it is. I have a mildly different setup anyway that’s primarily focused on nixops setups. But I think it will be beneficial for others who end up finding your repo :-)
<wavirc22> angerman: Cool. I'll take what you have then.
v0|d has quit [Ping timeout: 240 seconds]
Thra11 has joined #nixos-aarch64
LnL has joined #nixos-aarch64
LnL is now known as Guest83099
Guest83099 has quit [Client Quit]
LnL- has joined #nixos-aarch64
LnL- has joined #nixos-aarch64
LnL- has quit [Changing host]
LnL- has quit [Client Quit]
LnL- has joined #nixos-aarch64
LnL- has quit [Client Quit]
LnL- has joined #nixos-aarch64
LnL- has quit [Client Quit]
LnL- has joined #nixos-aarch64
LnL- has quit [Client Quit]
LnL- has joined #nixos-aarch64
<angerman> wavirc22: alrigth, so this should fix the ethaddr: https://github.com/wav/nix-odroid-n2/pull/6
<{^_^}> wav/nix-odroid-n2#6 (by angerman, 19 seconds ago, open): WIP: fix ethaddr
<angerman> it's not fully polished yet... I'll also need to rework the packaging logic. But that might have to wait until next week.
<angerman> something I really don't understand is why the kernel doesn't print to the uart properly. It has ttyS0 set, but no log message show up.
<angerman> just the boot loader stages.
<Thra11> Does anyone know if any of the armv7l binary caches listed on https://nixos.wiki/wiki/NixOS_on_ARM#armv6l_and_armv7l are still active?
<Thra11> and if so, how to find a channel/commit for which they actually have a decent amount of stuff cached.
<angerman> I think clever still has his. Not sure which revision though.
<Thra11> angerman: clever's appears to have moved/disappeared completely rather than just not being up-to-date.
<thefloweringash> Thra11: my one should be active, results on cachix (https://app.cachix.org/cache/thefloweringash-armv7) hydra for status (https://hydra.cons.org.nz/project/thefloweringash-armv7)
<thefloweringash> I haven't added it to the wiki because I keep thinking I'm going to get around to making the official builds work
<Thra11> thefloweringash: Cool. I'll give it a go.
<Thra11> thefloweringash: Hooray! Finally something that works.
<Thra11> my qemu armv7l builds kept hanging at a the same point in the gettext build.
<Thra11> thefloweringash: What's going on here: https://hydra.cons.org.nz/build/9169 ?
<thefloweringash> yeah, I noticed that after linking it you... I have no idea
<thefloweringash> error message seems like the hydra-queue-runner isn't trusted, but it's there in nix.conf
orivej has joined #nixos-aarch64
<thefloweringash> there was a recent hydra bump on 20.03 (#93945), could be related
<{^_^}> https://github.com/NixOS/nixpkgs/pull/93945 (by ivan, 6 days ago, merged): hydra-unstable: 2020-06-23 -> 2020-07-28
cole-h has joined #nixos-aarch64
Thra11_ has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 246 seconds]
<hsngrmpf[m]> <thefloweringash "Thra11: my one should be active,"> 😍😍😍 Searching for this since yesterday. This needs to go to the wiki. Can I add it there?
zupo has joined #nixos-aarch64
<hsngrmpf[m]> my local qemu powered build of glibc is stuck at the same `cc1` process since 7 hours. Is this normal? Would it ever finish or is it just broken?
<Thra11_> hsngrmpf[m]: I had a qemu build of gettext get stuck on one command for something like 14 hours before I killed it. I can't imagine anything is so slow that it is actually doing stuff for that long.
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<hsngrmpf[m]> I wonder why there is so little support for nix on armv7l. Shouldn't there be a relatively big group of people who want to install nix on their rpi? Without using nixos.
<simpson> There's a lot of folks like myself who are merely lacking in round tuits, and ARM's a difficult family of architectures to support.
<thefloweringash> hsngrmpf: sure, might as well add a link to the config repo too: https://github.com/thefloweringash/thefloweringash-armv7
<hsngrmpf[m]> Could you guys give me a hint on how to install the nix package manager on a raspbian? Nothing i found so far has really worked.
<thefloweringash> at a guess, the regular linux binary installer should work, but there's nothing pre-built for armv7?
<hsngrmpf[m]> ACtually I;m not even sure where to look for it. It doesn't show anything here: https://releases.nixos.org/?prefix=nix/nix-2.3/
<hsngrmpf[m]> and an outdated nix-expression: https://nixos.wiki/wiki/Nix_on_ARM
<hsngrmpf[m]> Then a PR from last year: https://github.com/NixOS/nix/pull/2667
<{^_^}> nix#2667 (by matthewbauer, 1 year ago, open): Add armv6l-linux & armv7l-linux as cross jobs
<hsngrmpf[m]> THis one looks the most promising of everything i found. I've never messen with any hydra stuff. How to build this `job` myself?
<hsngrmpf[m]> * THis one looks the most promising of everything i found. I've never messed with any hydra stuff. How to build this `job` myself?
h0m1 has quit [Quit: WeeChat 2.9]
<thefloweringash> check out the branch and run `nix-build release.nix -A binaryTarball.armv7l-linux`
h0m1 has joined #nixos-aarch64
h0m1 has quit [Client Quit]
h0m1 has joined #nixos-aarch64
<hsngrmpf[m]> thefloweringash: What hardware are you using to maintain this armv7l cache
<thefloweringash> it's a honeycomb lx2k running an armv7l virtual machine (ie, `-cpu=host,aarch64=off`)
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
<hsngrmpf[m]> <thefloweringash "check out the branch and run `ni"> Sadly the resulting tarball contains x86-64 binaries. During the isntallation teh raspberry complains:
WRMilling has joined #nixos-aarch64
<samueldr> for either 19.09 or 20.03, not sure if it was _verified_, it was possible to build a working cross-compiled nixos system which AFAIK didn't have that bash issue
<samueldr> but since you only want nix
<samueldr> you might be better served with https://nixos.org/nix/manual/#sec-building-source
<samueldr> (sorry, I didn't go through all the logs to see what was tried)
AmandaC_ has joined #nixos-aarch64
AmandaC_ has quit [Remote host closed the connection]
<hsngrmpf[m]> A bit devastating that i didn't think of this myself ;) Thanks so much!
<samueldr> I mean, the other option of using the tarball release is technically better because, for supported non-nixos platforms, this is the supported option to install
<samueldr> so the "best" option would be to first get a throw-away armv7l OS, build nix, generate a native tarball, throw the system away, and use that tarball
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
<hsngrmpf[m]> If i ever get that tarball i will sell it for 10000$ :D
<hsngrmpf[m]> Currently being stuck in debian dependency hell to build nix. Are there some instructions around for debian?
<samueldr> hmm
<samueldr> there *is* a package either ready or upcoming
<samueldr> I don't know how you get from there to a .deb package
superherointj has joined #nixos-aarch64
<samueldr> and it might be somewhat specific to bullseye and sid
<samueldr> >> NOTE: This package only provides the nix binaries. One still needs to setup directories, environments variables and configuration files to use nix as described in the nix manual. The package nix-setup-systemd provides such a setup using systemd mechanisms, also see /usr/share/doc/nix-bin/README.Debian.
<samueldr> I guess this note is also important :)
<hsngrmpf[m]> Thanks. I'm slowly progressing in getting the build dependencies solved for building from git. I will try that first.
<hsngrmpf[m]> Not sure if i will break my raspbian by adding the sid unstable sources. Have made very bad experience with such things in the past ;) No rollback possible
<WRMilling> I was considering putting together my own build server for aarrch64, using qemu/kvm to run it. I can't seem to find an aarch64 image for this purpose. Whats the best path to setting up an aarch64 build server running nixos (or something else if better)
<samueldr> actual aarch64 hardware
<samueldr> qemu kvm, as in a full blown emulated system is... s l o w
<samueldr> sorry, qemu
<samueldr> though now I realize that you said kvm
<samueldr> so I guess you meant on kvm
<samueldr> in that case, uh, you would produce a vm image like you would on x86_64 :/
<samueldr> I think?
<WRMilling> I don't see an ISO to spin up an aarch64 box
<samueldr> though the answer still is that we generally end up running on baremetal
<hsngrmpf[m]> It is super damn slow. I wasted the last 24h waiting. It is not only slow. it is actually broken. Quemu just gets stuck completely for some packages. In my case is was with armv7l, but i assume it is the same for aarch64
<samueldr> it's not published along the other artifacts
<samueldr> give me a few minutes to fish the link in hydra
<WRMilling> I am just thinking 12-18 virtual cores is going to be faster than the PBP or other sbc, even if virtualized
<samueldr> hsngrmpf[m]: running qemu-user is different than a full blown qemu system, just in case
<samueldr> virtualized: fine; emulated: no
<WRMilling> Noted on the difference.
AmandaC has quit [Quit: Toodles]
<samueldr> and qemu-user is... workable for some, but I pretend it doesn't exist as it's bound to fail in weird ways :(
AmandaC has joined #nixos-aarch64
<hsngrmpf[m]> What is the difference between `full blown` and qemu-user? Is there any resource on that? I might try the `full blown` setup ;)
<samueldr> full blown is just running a qemu emulated machine, I don't have any docs on that
<samueldr> the Links tab has two links
<samueldr> you probably want "Latest successful build from a finished evaluation"
<samueldr> which means that it gives you a links for an iso from a generation where all builds were attempted to build
<samueldr> so the best possible coverage
<hsngrmpf[m]> Ah so `full blown` means running a VM instead of this binfmt stuff? I read somewhere that the VM is limited to 2GB RAM which renders it unusable for building
<samueldr> hsngrmpf[m]: I mourn the fact that "VM" has lost its meaning
<samueldr> hsngrmpf[m]: "VM" meant "virtual machine" as in "hardware-assisted virtualization" at some point in the past
<samueldr> but yeah, basically, you have a fully emulated machine, limited to whatever PAE allows though
<hsngrmpf[m]> ok 😉
<samueldr> the current EXTREMELY experimental try at native armv7l builds uses a qemu *vm* (hardware accelerated) that runs the armv7l kernel with something like 16GiB
<samueldr> WRMilling: just checking, you're cbebop (probably butchered the spelling) on the pine irc, or another user that started at around the same time doing about the same things?
quinn has joined #nixos-aarch64
<hsngrmpf[m]> What is the main reason armv7l binaries not being built/published on the official hydra/cache
<hsngrmpf[m]> WRMilling: I followed this to setup a qemu user build machine: https://github.com/t184256/nix-on-droid/issues/62
<hsngrmpf[m]> With the help of the binary cache my build now got past the point where it got stuck earlier.
<{^_^}> t184256/nix-on-droid#62 (by bbigras, 14 weeks ago, closed): remote builder (using qemu for aarch64)?
<WRMilling> Going to have to pick this one up later, duties call.
<samueldr> hsngrmpf[m]: the main reason is that getting powerful build machines that can do armv7l is basically out of reach for the nixos foundation right now
<samueldr> there is the cheaty way of armv8-that-can-do-armv7l, but that's not a given
superherointj has quit [Quit: Leaving]
orivej has quit [Ping timeout: 260 seconds]
WRMilling has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej_ has quit [Ping timeout: 272 seconds]
<hexa-> what'd I use for i2c via python on an rpi4 on nixos?
<hexa-> looks like python-smbus is packaged
<clever> hexa-: if you enable i2c in config.txt (and uboot doesnt get in the way), then it will show up as /dev/i2c-? and the standard ApI's will work
<hexa-> ah, so it's a config.txt thing :)
<clever> hexa-: i think you would pick one of the i2c overlays from /boot/overlays and then add dtoverlay=i2c1 for ex
<clever> i2c-mux looks interesting, but ive not looked at what the official one does
<hexa-> huh /boot/overlays?
<hexa-> that doesn't exist on my pi
<clever> it may be on the firmware partition
<clever> nixos does things a bit different from the norm, as usual
<hexa-> i have my firmware part mounted at /boot
<hexa-> has no overlays
<hexa-> but it should just be dtparam=i2c1=on apparently
<clever> ah, then youll want to copy the overlays from the official firmware repo
<clever> here is the i2c mux that i setup under my custom firmware
<clever> basically, lines 380-395 create 3 virtual i2c busses
<clever> and when you try to access any of them, the kernel will change the pin muxing automatically
<clever> but under normal conditions, you shouldnt touch the cam or smps bus
<hexa-> :D
<clever> on a pi3, its only of use when you dont use the official firmware
<hexa-> ah, there is pkgs.device-tree_rpi.overlays