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
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.
<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.
<{^_^}>
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:
<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>
(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.
<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>
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
<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