ninjin has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 264 seconds]
ninjin has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
pbb has quit [Remote host closed the connection]
pbb has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
cole-h has quit [Quit: Goodbye]
<samueldr>
oh... hum... I'll continue looking tomorrow, but mediatek may be distributing a binary with GPL licensed source... and if so, we probably need planet computers to beat some sense into mediatek
<samueldr>
I don't think xiaomi would care :)
<samueldr>
though it could be surprising
<Ke>
lol, you accidentally used sense and mediatek in same expression
<jwaksbaum[m]>
samueldr: I remember you mentioned that you thought that supporting the rpi4 was too much work. What's specific about it that makes it harder to maintain? Will that change of uboot worked on it? And would that mean we flash uboot to the eeprom instead of the regular raspberry firmware? Also, would that mean we don't need `config.txt` anymore, or is that required by the earlier GPU stage of the boot process?
<jwaksbaum[m]>
I've been learning more about rpi4 boot recently and it's left me with some questions.
<jwaksbaum[m]>
* samueldr: I remember you mentioned that you thought that supporting the rpi4 was too much work. What's specific about it that makes it harder to maintain? Will that change if uboot worked on it? And would that mean we flash uboot to the eeprom instead of the regular raspberry firmware? Also, would that mean we don't need `config.txt` anymore, or is that required by the earlier GPU stage of the boot process?
<samueldr>
Ke: in an euphemistic manner, note!
<samueldr>
beating some sense implies there is none! :D
<samueldr>
whew, that's a bunch of questions jwaksbaum[m] :)
<samueldr>
what makes it harder to maintain? main reason is that it's a boot process specific to that family of devices, and unique to it
<samueldr>
unasked question: what makes the boot process annoying to use? no way to select a boot generation during boot
<samueldr>
will that change if u-boot works? yes. it's a question of when, not if :)
<samueldr>
will u-boot be flashed to the eeprom? no, sadly it's a teeny-tiny eeprom and there's not enough space for their bootloader + all the firmware files + u-boot
<samueldr>
the eeprom is only to allow them to then load the different files from the FAT32 partition, which in turn uses config.txt to boot *a kernel*
<samueldr>
u-boot, as with the raspberry pi 3, 2, 1, 0, is "a kernel" in that situation
<samueldr>
so config.txt is configured to load the u-boot binary, so in a sense yes, config.txt is needed... but no, because u-boot ends up doing the same job, but better
<samueldr>
hopefully that answers the questions?
<jwaksbaum[m]>
Yes this makes so much sense.
<jwaksbaum[m]>
So the config.txt would be like managed by uboot to convince the eeprom firmware to load uboot, and you wouldn't have to touch it.
<samueldr>
but in reality that's only half of the problem with maintaining
<samueldr>
there is also the current issue of the pi4 not being supported by the mainline kernel
<samueldr>
which is just a bit more tiring :)
<jwaksbaum[m]>
Mm that makes sense.
<samueldr>
when it will be, the same image will boot on the 3B, 3B+, 3A (is there a +?), and 4B!
<samueldr>
(and the pinebook pro, and the pine a64-lts, and MANY MORE devices!!)
<samueldr>
that's officially the only supported kind of image
<jwaksbaum[m]>
<samueldr "that's officially the only suppo"> One that boots on all arm boards?
<samueldr>
that contains a system with a "defconfig" build of the mainline kernel
<samueldr>
so boards that are supported by the defconfig of the mainline kernel are the target
<jwaksbaum[m]>
Gotcha
<samueldr>
the config.txt is not "managed" by u-boot, u-boot doesn't care about it, what we do is, in the config.txt, point it to u-boot
<samueldr>
while more often than not it boots a linux kernel, it can boot any ARM program/operating system!
<samueldr>
see, plan 9, risc OS, netBSD, FreeBSD (I guess?), and other non-Linuces!
<samueldr>
or some that are not OS per se, like u-boot or tianocore!
<samueldr>
tianocore being the reference implementation of UEFI
<samueldr>
once mainline works on the pi4, it should be possible to install via the UEFI .iso too using that tianocore setup
<jwaksbaum[m]>
<samueldr "tianocore being the reference im"> I was about to ask :)
<samueldr>
I have such a setup on a raspberry pi 3B
<samueldr>
technically, once tianocore is started, it's booting just like your computer (assuming UEFI) does
<samueldr>
another fun tidbit: u-boot has a minimal UEFI implementation too!
<samueldr>
so if you have u-boot going, it, too, can boot the UEFI iso for aarch64!
<samueldr>
my pine a64-lts has u-boot flashed to its SPI flash, so it's just like it has a bios/uefi installed
<samueldr>
I don't have to put in an SD card or an eMMC thingy, it can boot from usb
<samueldr>
(from u-boot)
<samueldr>
and the pinebook pro, once we have display init, and better mainline support, too
<jwaksbaum[m]>
Right right, we just can't do that because uboot can't use the display
<samueldr>
(mainline is supposedly just about ready with 5.8, haven't taken a look yet)
<jwaksbaum[m]>
So I've used uefi, but I'm not quite sure how it relates to uboot. Uefi is like a specification for booting a kernel?
<samueldr>
well, we can, but you need serial :)
<samueldr>
uefi is a specification to boot a computer
<jwaksbaum[m]>
<samueldr "well, we can, but you need seria"> Meaning you have to talk to uboot over serial bc it can't display
<samueldr>
serial "is" its display in that case, yeah
<samueldr>
(I did have grub from the UEFI iso started on its serial output when testing usb boot early on, so it's already proven working)
<jwaksbaum[m]>
Uboot is a program that can figure out how to boot in a variety of ways: uefi (I guess), but also extlinux?
<samueldr>
(and I know it works because my pinebook a64 uses u-boot's UEFI to boot grub to just continue booting)
<samueldr>
yeah
<jwaksbaum[m]>
Like I'm trying to understand the relationship between uboot and uefi
<samueldr>
u-boot blurs the line between a firmware (bios) and a bootloader (grub)
<samueldr>
basically, u-boot has a ton of features
<jwaksbaum[m]>
And uefi is a specification for a bootloader? But also I thought it's like an alternative to bios?
<samueldr>
uefi is a specification about how a computer boots and hands-off to an operating system
FRidh has joined #nixos-aarch64
<samueldr>
ouch, just taken the time to check, and it looks like there is proof enough that they (mediatek, and then the OEMs) are shipping a GPL binary without the sources here
<jwaksbaum[m]>
And uefi is often implemented by firmware located like "on the motherboard" of computers
<jwaksbaum[m]>
Yes that's not rude I really appreciate your answers, I will check that out!
<samueldr>
and the relationship between u-boot and uefi, basically is that u-boot has a command that is the most minimally useful UEFI implementation to continue booting
<samueldr>
u-boot implements only a tiny sliver, but probably the most important sliver
<Ke>
samueldr: would you happen to know, whether the keyboard fw is polling or event based
<Ke>
on pbp
<Ke>
if it's polling you could detect ghosting properly, when you have a 3 key combo with the 4.th key being not connected
<jwaksbaum[m]>
Feel free to not answer: what's the advantage of uboot over an implementation of uefi like tianocore?
<samueldr>
Ke: absolutely don't know
<samueldr>
jwaksbaum[m]: I don't know for sure, but I guess is that u-boot has much more bells and whistles included for many families of hardware
<samueldr>
it's likely u-boot already boots on your machine
<samueldr>
and you can make it boot different things
<samueldr>
if you want a system that boots to a GUI in 3s, it can do it
<samueldr>
(supposedly)
<samueldr>
well, it can be a part of it
<samueldr>
you can make it boot an android boot image too
<samueldr>
it can pxe boot
<samueldr>
it does sooooooooooooooooo much
<srk>
it can UEFI.. :D
<samueldr>
srk: you're many lines late :D
<srk>
hehe, just woke up :D
<samueldr>
in reality I guess it's not about what u-boot does, but what the other options can do and what they are
<samueldr>
u-boot is probably the default option in a large segment
<samueldr>
though it's probably a case where the default option is quite good
<srk>
+1
alp has joined #nixos-aarch64
<sphalerite>
samueldr: ooooh thanks for the hint!
<sphalerite>
hm it's only SPI boot related
<sphalerite>
I guess that makes it usable without coreboot?
<patagonicus>
Huh. Now my RPi is building aws-sdk-cpp. I wonder what's pulling that in.
<ar>
iirc nix
<samueldr>
sphalerite: note sure, but I think that may be what it means
<samueldr>
sphalerite: I only spotted this while poring over for something else
<samueldr>
maybe there are other changes either in or soon in that are relevant for u-boot-only booting
<ar>
patagonicus: nix uses aws-sdk-cpp for s3 support
<srk>
you can disable with nix override and withAWS = false
<sphalerite>
^ can recommend, saves a lot of build time and space if you're building everything from scratch
<patagonicus>
ar: Ah, that makes sense. Thanks.
<patagonicus>
It also looks like nix is the last package to be built. So less than 24h for the first rebuild on a RPi3. That's a bit surprising, actually, I thought the kernel alone would be >12h.
<patagonicus>
Or is it rebuilding nix first before then rebuilding the rest of the system with the new nix?
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-aarch64
<srk>
yes :)
<srk>
its always the first step for nixos-rebuild to ensure forward compatibility
orivej has joined #nixos-aarch64
Ashy has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<patagonicus>
Huh. I ran some errands and now I cannot connect to the Pi via SSH anymore. I'm pretty sure I did nixos-rebuild build, not switch.
<patagonicus>
Uhoh. There's a stack trace from the kernel on screen and it mentions swap and the scheduler. I wonder if the 5GB swap ran full. But even then it should have just OOM killed something. Bad SD card? But it's new …
<patagonicus>
"sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware interrupt." Hmm
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<patagonicus>
Oof. It looks like it's starting from scratch.
<betaboon>
are there any plans to have hydra build armv7l packages at some point ?
<srk>
yes, it's a bit complicated
<srk>
patagonicus: make sure it has enough cooling as well
<patagonicus>
srk: cooling seems unlikely since it crashed at around ~10AM. Yesterdey evening the room was definitely warmer and it was running at near full load the whole time.
<patagonicus>
But I got the tracking number for my replacement HC2, so by Tuesday or hopefully sooner I can try to get NixOS booted on that and then I don't need the RPi anymore. :)
<patagonicus>
Thinking about it, it might not start fresh. I didn't look at all the packages that it's building, but it doesn't seem to start with the bootstrap packages, so hopefully it's just the packages it didn't need to build nix.
<patagonicus>
Hmm, maybe, although I don't really want to use unofficial caches. :) I mostly trying to experiment with armv7l NixOS on a RPi because I eventually want to run it on a few Odroid HC2 (but booting them is different, unfortunately).
<patagonicus>
thefloweringash: Maybe you'd want to add a link to that to the NixOS wiki. The caches mentioned there don't exist anymore or are outdated.
<patagonicus>
I'll also try to get the cross compiling instructions added to the wiki, because the Qemu/binfmt instructions there didn't work for me.
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
<thefloweringash>
yeah, I was really hoping to skip straight to having an official upstream cache, but complications
<patagonicus>
Software's never easy. I still haven't learned to give even vaguely accurate estimates for my work projects.
alp has joined #nixos-aarch64
<thefloweringash>
what kind of problems did you get with the qemu/binfmt instructions on the wiki?
<patagonicus>
It seemed to hang, but I didn't investigate for long - happy to run it again if you want to debug it. I had a single command that was basically just a shell one liner (I don't remember what exactly it was doing) run for >12h.
<patagonicus>
Cross compiling was also a lot faster.
<thefloweringash>
I was mostly curious if it was an oversight in the setup module or something deep and difficult. it sounds like the latter
<patagonicus>
Yeah, one reason I ditched that path. Though I should have just gone to IRC way earlier anyway.
orivej has quit [Ping timeout: 258 seconds]
<patagonicus>
I also tried bootstrapping on the official Ubuntu that Hardkernel provides for the HC2, but that's an 18.something LTS and the libraries where to old for nix >= 2.0 and then I ran into problems trying to compile nix >= 2.0 with the nix 1.x version I had. And then the machine just died.
orivej has joined #nixos-aarch64
<ar>
/39
hyperfekt has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<gmr>
patagonicus: you seem to prefer odroid over pine64 - i'm curious as to the reason(s) for that
<srk>
I was quite happy with Odroid XU4, haven't used any pine64 so can't really compare, I guess it also depends if you want armv7 or aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<patagonicus>
gmr: The HC2 got recommended by a coworker for a storage setup - small, inexpensive machine that has GBit ethernet and can host a 3.5" HDD and enough power to run GlusterFS.
<patagonicus>
The ROCKPro64 NAS case looks huge in comparison - three HC2 stacked probably have less volume than one of them. And I'd like to play around a bit with having multiple machines instead of a single one.
<patagonicus>
But, tbh, I didn't look around too much. And I've wanted to buy a Pinebook Pro to keep in the office as a personal machine, but since I haven't been in the office in months and won't be (at least not regularly) for the rest of the year, I have less need for that.
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
Ashy has left #nixos-aarch64 ["WeeChat 1.9.1"]
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
<patagonicus>
Sigh. Lost the connection to the Pi again. Guessing it's the same error. Maybe I'll just wait for the HC2.
<srk>
connect usb<->uart if you can to catch them
<patagonicus>
Ah, right, UART is a good idea.
<patagonicus>
But it will require hacking together a cable. Sigh. Not today.
alp has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rajivr has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Client Quit]
alp has joined #nixos-aarch64
alp has quit [Client Quit]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
lordcirth has joined #nixos-aarch64
<betaboon>
flokli: can you confirm that openldap fails to cross-compile for aarch64 ? oO
<flokli>
upstream seems to at least know what crosscompiling is: configure: WARNING: Crossing compiling... all bets are off!
<flokli>
I mean, some nixpkgs cross-investigation is needed. It might result in some PR upstream that makes it behave better, but first we need to see how it breaks
spacekookie has quit [Quit: **aggressive swooshing**]
spacekookie has joined #nixos-aarch64
spacekookie has quit [Client Quit]
spacekookie has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jwaksbaum[m]>
patagonicus: I'm not positive what your situation is, but I've had a lot of success using an Amazon ec2 instance as a nix arm build machine for the pi, just paying a few dollars for a few hours. Though that was for aarch64, not sure if they have armv7l
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
<delroth>
+1, m6g.xlarge is like $0.04/h at spot price in us-east-2
<delroth>
and it's decently fast
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<patagonicus>
jwaksbaum[m]: I *think* once I have the HC2 it should be fast enough that I don't mind building locally. More so once I have my cluster of three set up and I'm basically just waiting to see if I can get NixOS to boot before I buy the other two.
orivej has quit [Ping timeout: 246 seconds]
<jwaksbaum[m]>
The hc2 is a lot faster?
orivej has joined #nixos-aarch64
<patagonicus>
Probably not a lot. I could only play around for like two days before it broke, but it felt faster than the RPi when compiling. But I didn't time anything.
<delroth>
just get one of the HoneyComb LX2K boards :-) not overkill at all
<delroth>
(mITX board with 16x A72 @ 2GHz and up to 64GB DDR4)
<patagonicus>
I think if I'd go with something like that, I'd rather built an x86 based server in a regular case. :D
<patagonicus>
I'm mostly intrigued by having three machines with a HDD each in a very small form factor. It's probably not the simplest or cheapest solution for getting some storage, but setting up the cluster stuff should be fun.
<patagonicus>
Hmm. If I just move ext4 / partition to a USB drive, will u-boot be able to load it? On the RPi3, I mean.
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 260 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
<jwaksbaum[m]>
<delroth "just get one of the HoneyComb LX"> I checked this out of curiosity and saw the $750 price, quite the step up from a pi
orivej has joined #nixos-aarch64
quinn has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<betaboon>
dnsmasq seems to fail to cross-compile on aarch64 and armv7l not finding dbus/dbus.h. anyone cares to confirm ?
<samueldr>
I'm not positive it handles pkgsCross.armv7l-linux and pkgsCross.aarch64-multiplatform or whatever their actual name is
<gchristensen>
heh
bennofs has joined #nixos-aarch64
<flokli>
someone sneaked in some minimal cross in nixos/tests/systemd-binfmt.nix
<flokli>
so at least the toolchains should be there
bennofs_ has quit [Ping timeout: 264 seconds]
<samueldr>
someone you? :
<samueldr>
:)*
* flokli
whistles inoocently
<samueldr>
ah, at least having the toolchains is a good first step
orivej has quit [Quit: No Ping reply in 180 seconds.]
<samueldr>
I'd really like to have the sd image and iso image built (but not published!) with cross
<flokli>
same here
orivej has joined #nixos-aarch64
<flokli>
on the building part
<samueldr>
and maybe the systemd build breaking when it doesn't build
<samueldr>
oops, let me rephrase, systemd cross-build being part of tested
<flokli>
but what's the point of then still having to build everything by yourself if you want to build an image for your pi or something
<srk>
samueldr: why not published?
<srk>
flokli++ :D
<{^_^}>
flokli's karma got increased to 33
<samueldr>
srk: because it'd confuse people to choose between sd_image-aarch64-linux and sd_image-aarch64-linux-but-with-a-cross-built-userland
<srk>
oh right, how about for armv7l only?
<samueldr>
anyway, it's not like we were publishing the sd image and iso for ARM
<flokli>
samueldr: ah, you mean, not "promoted"
<flokli>
but still in the cache
<samueldr>
so it's a moot point anyway
<samueldr>
yeah
<samueldr>
built, so in the cache and on hydra
* flokli
nods
<samueldr>
but not one we publish next to the iso image
<samueldr>
I'd like to get the aarch64 images published
<flokli>
I think we're even not that far from having the minimal image built.
<samueldr>
no we're not
<flokli>
Theres some udisks dependencies, and gobject-introspection broken AFAIK
<samueldr>
and someone that knows deeply about cross is looking at g-i
<samueldr>
it's probably one of the worst offender right now
<flokli>
<3 <3 <3
<samueldr>
once this unblocks, it may unblock a bunch of more trivial things to fix
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 2.8]
h0m1 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
FRidh has quit [Ping timeout: 256 seconds]
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<samueldr>
finally have my first mediatek kernel built
<samueldr>
that surely will help ashkitten for that phone, considering I'm betting one of the issue is common to all recent mediatek kernels
<ashkitten>
oh, neat
<ashkitten>
still hasn't been shipped
<samueldr>
but I hate how it includes a binary from MTK to build, which is **extremely obviously** based on the dtc source code
<samueldr>
DTC is GPL
<samueldr>
though the binary, at least for xiaomi-begonia, ships with full debugging symbols
<samueldr>
and it's obvious that it comes from the android fork of DTC, so it might be possible to do someting with ghidra or some other tool to map all unknown bits
<betaboon>
the weird package-selection of cross-trunk was what i was referring to earlier. i would realy like to go towards having the same package-set cross-compiled for armv7l and aarch64 that we currently do for x86. and then push forward to get that fully working
<betaboon>
I'm cross-compiling for armv7l alot currently. and it mostly works. just some quirks here and there.
<samueldr>
I, sadly, can't try the kernel until later tonight, it's only unlockable around a bit before 23:00 :(
<ashkitten>
time-limited bootloader unlocking?
<samueldr>
yes
<samueldr>
168 hours
<ashkitten>
never heard of that before. gross
<samueldr>
yep
<samueldr>
older xiaomi devices had 72 hours
<samueldr>
it's an understandable reason, but still extremely frustrating and terrible
<samueldr>
vendors were opening boxes, flashing bad system images (like malware bad), and re-sealing the boxes :(
<ashkitten>
wow
<samueldr>
yes, extremely understandable, still extremely user hostile
<samueldr>
which is worst than only user hostile!
Thra11 has quit [Ping timeout: 260 seconds]
FRidh has quit [Quit: Konversation terminated!]
Thra11 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
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 240 seconds]
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
spacekookie has quit [Quit: No Ping reply in 60 seconds.]
spacekookie has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
julm has joined #nixos-aarch64
alp has joined #nixos-aarch64
<samueldr>
the wait is killing me!!
<samueldr>
I can't wait to see how close the blind port got me
julm has quit [Quit: migration to hardened profile]
<ryantrinkle>
samueldr: oh, is that the waiting period before you can unlock?
<ryantrinkle>
i just got a oneplus 7 pro, and it has a 1-week wait
<samueldr>
they have a waiting period too, now?
* samueldr
drags oneplus one notch down into the list
<ryantrinkle>
only the ones that are sold via t-mobile
<ryantrinkle>
i bought used ones
<ryantrinkle>
$350 each
<samueldr>
ah
<samueldr>
nice
<samueldr>
you say each, that sounds like you have one for mobile nixos use ;)
<ryantrinkle>
haha yes, actually
<ryantrinkle>
or rather
<ryantrinkle>
i am planning to keep a spare on hand
<ryantrinkle>
for general messing around
<ryantrinkle>
of which mobile nixos would certainly be my top choice :)
<samueldr>
nice
<samueldr>
from research I did, it's likely to be using the new dynamic partitions
<samueldr>
and possibly DRM for its display
<samueldr>
(DRM as in the good kind, not the bad kind)
julm has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<craige_>
I'm finding myself building a lot os SD images lately and they're all generically. I was wondering if there was a flag I could use to change them from just ...nixos-sd-image-20.03post-gt... to something including a hunam readable unique identifier?
<craige_>
Morning :-)
<samueldr>
what a time to be awake, the sun's setting in what, an hour?
<samueldr>
uh, I just don't really care about the filename
<craige_>
Not on this side of the globe. BEautiful sunny day. Cool nad sunny winter's morning.
<craige_>
I'm building munltiple images unique to each aarch64 device. So I'm thinking ahead, if I want to know which image belonged to which machine without rebuilding...
<samueldr>
I see
<samueldr>
I think the main problem is that the infra for sd image extremely assumes the generic sd image
<samueldr>
so the tools don't exist
<craige_>
I'd assumed that - glad to have it confirmed though. Thank you samueldr++ :-)
<{^_^}>
samueldr's karma got increased to 239
<craige_>
I'll hopefully be doing one for my Pine64 today as well. Will be nice to get that out of the drawer or a bit.
<samueldr>
which pine64 board?
<craige_>
oh and Librem-5 dev kit is landing here soon too.
<craige_>
Braveheart.
<samueldr>
ah
<samueldr>
not using the mobile nixos one? :)
<samueldr>
(no worries, I'm extremely for people implementing it in another manner)
<samueldr>
note that u-boot for the pinephone still doesn't have gfx init
<samueldr>
or, maybe better called display init
<craige_>
Not using any right now - I've been too busy since I last played with it (mobile-nixos). Don;t even recall where my tooling was up to, something about calling mobile-nixos into nixops...
<samueldr>
but mobile-nixos doesn't support calling (yet)!
<craige_>
If I get the time to return to it, perhaps that's asomething I can address.
<samueldr>
(that was a joke about the fact you said "calling mobile-nixos into nixops")
<samueldr>
I guess now it's possible, there is a documented entry point to import Mobile NixOS properly
knerten2 has joined #nixos-aarch64
<craige_>
\o/
<craige_>
Working day is underway here so humour is just missed :-)
knerten1 has quit [Ping timeout: 240 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]