<veleiro>
so you cant cross compile nixos, but lots of nixpkgs you can?
<veleiro>
looks like its not easy at least
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 272 seconds]
h0m1 has joined #nixos-aarch64
<samueldr>
can't say if it's lots, but there's a slice of it that can, yes
<samueldr>
and can't say that you can't cross-compile nixos
<samueldr>
but a big slice of it you could recently, if not still
knerten2 has joined #nixos-aarch64
knerten1 has quit [Ping timeout: 240 seconds]
<veleiro>
lol
<veleiro>
love the careful wording
veleiro has quit [Remote host closed the connection]
veleiro has joined #nixos-aarch64
e has quit [*.net *.split]
evils has quit [*.net *.split]
samrose has quit [*.net *.split]
LnL has quit [*.net *.split]
edcragg has quit [*.net *.split]
aminechikhaoui has quit [*.net *.split]
FireFly has quit [*.net *.split]
srk has quit [*.net *.split]
hyperfekt has quit [*.net *.split]
hyperfekt has joined #nixos-aarch64
FireFly has joined #nixos-aarch64
aminechikhaoui has joined #nixos-aarch64
srk has joined #nixos-aarch64
evils has joined #nixos-aarch64
samrose has joined #nixos-aarch64
LnL has joined #nixos-aarch64
edcragg has joined #nixos-aarch64
edk_ has joined #nixos-aarch64
Thra11 has quit [Quit: WeeChat 2.8]
veleiro` has joined #nixos-aarch64
veleiro has quit [Ping timeout: 240 seconds]
veleiro`` has joined #nixos-aarch64
veleiro` has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
kloenk has quit [Ping timeout: 260 seconds]
edk_ is now known as e
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
mvnetbiz_8 has quit [Quit: Ping timeout (120 seconds)]
mvnetbiz_8 has joined #nixos-aarch64
cptchaos83 has quit [Remote host closed the connection]
dongcarl has quit [Read error: Connection reset by peer]
cptchaos83 has joined #nixos-aarch64
dongcarl has joined #nixos-aarch64
disasm has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
cript0nauta has joined #nixos-aarch64
criptonauta__ has quit [Read error: Connection reset by peer]
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<thefloweringash>
sphalerite: weak recommendation. I mostly wanted it for the cpu, so I haven't tried most of the exotic peripherals. I also haven't managed to get mainline booting on it yet (I should try again). Still have some quirks too: very occasionally disappears and seems to need a hard reset
<sphalerite>
thefloweringash: hmm ok. How is the CPU? Does it make waiting for builds noticeably less annoying?
<thefloweringash>
it does chromium in about 6 hours instead of the 3 days it takes on my rock64
kgtzy[m] has left #nixos-aarch64 ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
<sphalerite>
hm, and rock64 is rk3328 which is 4×a53… like rk3399 but without the 2 big cores I guess
<sphalerite>
that does sound nice
<thefloweringash>
I'm guessing having an nvme ssd instead of a usb3 external drive helps a bit too
<sphalerite>
oh yeah
<sphalerite>
I should see how long chromium takes on my nanopi m4
<sphalerite>
it has a SATA SSD for /tmp and /nix so that should be reasonably good
<thefloweringash>
imho, the most satisfying thing really is getting to bring regular peripherals like a regular computer. Pick your favorite large or fast ssd, a decent chunk of memory (up to 64gb max), your favorite case, etc
<sphalerite>
yeah
<sphalerite>
I mean, I mounted my nanopi in an ATX case as well but it's, uh…
<sphalerite>
a little ghetto
<sphalerite>
ha, how do I actually build chromium? I just tried nix-build '<nixpkgs>' -A chromium --check but that just rebuilds the wrapper :D
<thefloweringash>
good question, I just wait for the PR with a version bump to test
<veleiro>
but that includes linux 5.7.12 and for whatever reason linux is still building,
<samueldr>
heh, it'll most likely happen whenever you ugprade nixpkgs and (1) deps of Linux change or (2) Linux upgrades
<veleiro>
so its not cached
<samueldr>
it'll never be cached unless you built it yourself
<samueldr>
it's not being built on the Hydra build farm
<veleiro>
werent we talking about this the other day?
<samueldr>
for firefox!
<veleiro>
oh, so linux is an exception
<samueldr>
since it uses patches
<veleiro>
gotcha. I wasnt aware of this but now that makes sense
<veleiro>
yeah i just remembered
<samueldr>
whenever an input to a derivation changes, its output location/hash changes, so it ends up looking for it, and when it can't find it, it builds it
<veleiro>
damn, this is like the 10th time ive build 5.7...
<samueldr>
inputs include things like dependencies
<veleiro>
maybe ill check what i have cached in the store...
<veleiro>
yeah i just forgot to think about that. derp
<samueldr>
yeah :)
<samueldr>
I hope that 5.9 is good enough to use it straight up by default
<samueldr>
5.8 IIRC lacks the battery driver
<veleiro>
well i couldve just used the LTS kernel i suppose
<veleiro>
better to test out this fix anyways
<veleiro>
is the suspend issue related?
<veleiro>
being on 5.7 and when I close the laptop, it wont wake again
<samueldr>
suspend doesn't work with the mainline ATF
<samueldr>
it only works with the binary blob from rockchip
<samueldr>
(ATF is a component used to build u-boot)
<samueldr>
using LTS won't help you since it needs even more patches than 5.7 does :)
<veleiro>
ah
<veleiro>
maybe its not suspend
<samueldr>
it might be
<samueldr>
I say it doesn't work, I don't remember what fails, but it might be resuming that fails
alp has joined #nixos-aarch64
<veleiro>
i might be confusing separate issues for the same one
<veleiro>
9 out of 10 times on booting 5.7 it wouldnt happen
<veleiro>
i think that's the hang issue
<veleiro>
then maybe the one ive also seen is the display is just off after booting?
rajivr has quit [Quit: Connection closed for inactivity]
<samueldr>
it shouldn't hang or not work with the current workaround, at least not according to my tests
<veleiro>
building that fix as per above. i was still pulling in master from the repo
alp has quit [Ping timeout: 272 seconds]
<dimenus>
dumb question, what wifi tool did you intend to have this image used with?
<veleiro>
dimenus: what image are you using
<dimenus>
samueldr's pbp image
<samueldr>
dimenus: uh... the wired ethernet usb adapter I usually use
<samueldr>
wireless is basically a non-starter where I live so I forget about it
<samueldr>
the wifi driver is there, though
<samueldr>
you're left with whatever the installer image profile of nixos gives you by default
<samueldr>
so I guess wpa_supplicant and manual settings?
cript0nauta has quit [Remote host closed the connection]
criptonauta_ has joined #nixos-aarch64
<veleiro>
dimenus here's how i bring in the pbp repo into my own configs
<samueldr>
I wonder what this means for bootloader unlocking
<samueldr>
and running non-android
<samueldr>
though, do remember that newer snapdragon android devices most likely already use UEFI
<samueldr>
so it's also quite likely that it means absolutely nothing
<veleiro>
they were responsible for secure boot
<samueldr>
yes, and codified in their platform requirements for shipping secure boot on consumer computer hardware is that secure boot must allow enrolling keys
<samueldr>
so that's nothing new
<samueldr>
meanwhile qualcomm's UEFI for recent snapdragons, I don't know if it uses "Secure Boot" as part of the spec, but it does not matter because it's only UEFI technically speaking
<samueldr>
the boot flow goes directly through to ABL which is a UEFI programs that, along with exiting the UEFI services, does the android boot usual things
<samueldr>
so UEFI in itself has no more meaning than another technology name
<samueldr>
which is why the question stands: what does it mean here that they're using their own UEFI rather than the SoC vendor's
<samueldr>
might even be interesting to know on the qualcomm-based windows laptops, who made the UEFI firmware
<clever>
in theory, the pi series of chips could support secureboot
<clever>
the maskrom is capable of verifying a signature for the firmware, with per-device keys
<clever>
and that firmware could then use pub-priv keys to verify further stages
<samueldr>
what I'm curious about is whether the UEFI on the surface duo will be made available to end-users, or if it's like qualcomm's where it's only an implementation detail
<clever>
but the pi4 has the same key burned into every unit, and ive not investigated older models closely
<samueldr>
the Allwinner A64 has facilities that allows secure boot
<samueldr>
and AFAICT most SBCs you buy have the facilities unburned
<samueldr>
(if not all)
<clever>
the other problem with the pi, is that the main key for the firmware is symetric (same key to sign and verify), and you can read it once an os is running
<clever>
and once you know it, you can make a custom firmware, that doesnt enforce security
<samueldr>
(I have no more knowledge about the topic than what I just said; don't know if it's actually solidly secure or not)
<samueldr>
(but at the very least, I know that if you lose the keys to sign your images you're SOL)
<clever>
same for the pi series of chips
<clever>
but since the key is pre-burnt, and the same, its rather hard to loose
<samueldr>
yeah :)
<samueldr>
though in reality you don't really interact with those programs the same way
<samueldr>
e.g. *you* don't sign your kernels
<samueldr>
what's signed is the bootloadery bits
<clever>
you could specially order some pi's that arent burnt, but the official bootcode.bin and start4.elf dont enforce signatues
<clever>
yeah
<clever>
on the pi4, the maskrom will validate either bootcode.bin or recovery.bin, and run it
<clever>
bootcode.bin then brings dram up, and runs start4.elf
<clever>
and start4.elf runs linux
<clever>
but start4.elf isnt signed, so all security is out the window
alp has joined #nixos-aarch64
<veleiro>
is there some guide or good documents, or issues where i can look at
<veleiro>
multiarch status with nixos?
<veleiro>
and nixpkgs
<veleiro>
i still dont understand what can and cant be done well
<veleiro>
for instance i was trying to build an SD image for armv7 on my x86
quinn has joined #nixos-aarch64
<veleiro>
but i can compile aarch64 linux on x86 apparently
<samueldr>
that's not multiarch, per se, multiarch is for compatible architectures like using 32 bit libraries on 64 bit systems, e.g. i686 on x86_64
<veleiro>
oh oops
<samueldr>
the proper search term would be cross-compiling here
<veleiro>
cross compiling
<samueldr>
yeah
<veleiro>
replace everything i said with cross compiling lol
<samueldr>
I don't know of any good guide or document :/
<samueldr>
the Nixpkgs manual has some bits relevant, but it's quite thick
<theotherjimmy[m]>
samueldr: suspend on PBP in mainline TF-A dose not set a resume source, so it goes to sleep foverever. Even if you manage to get past that, the LPDDR4 throws another wrench into the resume path. If you get past that, there's something going very wrong with the page tables on resume. So that's where we are now
<samueldr>
theotherjimmy[m]: thanks for the update :)
<theotherjimmy[m]>
Welcome. I have not touched it this week. I brought it up because I noticed someone asking about it when reading the backlog
<samueldr>
no worries, it's not like you were under any kind of obligation
<theotherjimmy[m]>
heh, true
<theotherjimmy[m]>
I just happen to work on TF-A for arm, so I figured I could maybe fix suspend as part of my job
<samueldr>
I wonder if you/me/us could ask for pine64 to, in turn, ask for guidance to rockchip
<samueldr>
yeah :) that's convenient
<theotherjimmy[m]>
I got bogged down with "real" work this week, so I have not poked it yet
<samueldr>
I know that libre.computer work _with_ rockchip on their rockchip platforms when working with open source
<theotherjimmy[m]>
huh, that's cool
<theotherjimmy[m]>
If we get this working in upstream, it should be a slightly deeper sleep than the closed-source ATF blob
<samueldr>
I could be wrong, but AFAIUI the big rk3399 update earlier this year / late this year in u-boot was a part of that
<theotherjimmy[m]>
As in, upstream turns off more stuff in suspend than the blob/fork does
<samueldr>
oh, cool
Acou_Bass has joined #nixos-aarch64
<theotherjimmy[m]>
Oh, I forgot about the M0 reset ording bug in mainline. So we're up to 4 bugs that all can individually break suspend
<theotherjimmy[m]>
with 32 cores, 4-way smt (I think)
<samueldr>
still hoping for *more* to come in the not-an-SBC and affordable workstation type machine
<theotherjimmy[m]>
Yeah, that's a gap in the aarch64 space, to my knowlage
<theotherjimmy[m]>
with the Honeycomb being the only reasonable thing there
<samueldr>
probably one that is causing a bunch of hurt :(
<theotherjimmy[m]>
But even then, it's a bit more expensive because of the 4x10Gb etherenet
<samueldr>
going back to the linus rant about aarch64; we need "the mac mini of arm"
<samueldr>
or maybe more aptly "the nuc of arm"
<samueldr>
something that is not necessarily blazing fast, but something you can realistically do your work on
<theotherjimmy[m]>
Totally agreed. It should be possible to have 8xA76 in a box for < 500$.
zupo has quit [Ping timeout: 256 seconds]
<theotherjimmy[m]>
We have this weird thing where you can buy a 384 core server for 10k, and an 8 core phone cpu for 300, but no middle ground
<theotherjimmy[m]>
It's like they only go for max # of clusters or 2 clusters
evils has quit [Quit: Lost terminal]
<samueldr>
oh, phone CPUs are weirdly even out of phase with SBCs
<samueldr>
even if we could get something closer to higher end phones in an SBC form factor it would help I think
<theotherjimmy[m]>
Well it's qualcomm and mediatek, which are uncommon for SBCs
evils has joined #nixos-aarch64
<samueldr>
yeah
<theotherjimmy[m]>
and qualcomm is not known for upstreaming much
<samueldr>
I know :)
alp has quit [Ping timeout: 272 seconds]
<theotherjimmy[m]>
Qualcomm's clusters are really weird too: 1x super speedy boi + 1x speedy boi + 2x boi in one cluster and 4x low power boi in another
<theotherjimmy[m]>
So if you think that big.LITTLE scheduling is hard, I have something else for ya
<samueldr>
eek
<theotherjimmy[m]>
Oh, my mistake 1x Super speedy +3x speedy.