tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 246 seconds]
tilpner_ is now known as tilpner
samrose has quit [Ping timeout: 246 seconds]
samrose_ has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
quinn has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
patagonicus7 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
patagonicus has quit [Ping timeout: 264 seconds]
patagonicus7 is now known as patagonicus
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 [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
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: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: Textual IRC Client: www.textualapp.com]
greizgh has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
quinn has quit [Ping timeout: 246 seconds]
quinn has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 240 seconds]
Darkmatter66 has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
gmr has left #nixos-aarch64 ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
bigvalen[m] has quit [Quit: Idle for 30+ days]
orivej has joined #nixos-aarch64
<hsngrmpf[m]> I emulating aarch64 on armv7l significantly more efficient than on x86_64?
orivej has quit [Quit: No Ping reply in 180 seconds.]
<hsngrmpf[m]> * Is emulating aarch64 on armv7l significantly more efficient than on x86_64?
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
pbb has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
orivej_ has quit [Ping timeout: 240 seconds]
alp has quit [Ping timeout: 264 seconds]
alp has joined #nixos-aarch64
<angerman> hsngrmpf[m]: I’d assume your x86_64 hardware is a lot more powerful than your armv7l system. Such that any loss in efficiency (if any at all) would be easily compensated.
alp has quit [Ping timeout: 264 seconds]
<Mic92> hsngrmpf[m]: I would assume that emulation aarch64 on x86 is faster because more tuned.
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp_ has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp_ has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
alp has quit [Ping timeout: 272 seconds]
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
noonien has quit [Quit: Connection closed for inactivity]
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
colemickens_irc has quit [Quit: Connection closed for inactivity]
orivej has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<samueldr> it depends if it's *emulation* or *virtualization*
<samueldr> if you can virtualize armv7l on your aarch64 hardware, it's likely to be faster than emulation on x86_64
<samueldr> because full blown emulation is slow
<samueldr> how, about qemu-user emulation at the process level?
<samueldr> now*
<samueldr> that's where performance must be tested
alp has quit [Ping timeout: 246 seconds]
<Mic92> All instructions have a different size in aarch32 compared to aarch64, no?
<Mic92> So I don't see how this can be virtualized.
<samueldr> it can
<samueldr> I don't know the details
<Mic92> Don't you have 64 bit registers that needs to be put into two 32 registers?
<samueldr> if you have a raspberry pi, or other cheap~ish sbc that also supports armv7l it's trivial to test
<samueldr> no clue about the low level details
<samueldr> but the (stalled) effort at getting native armv7l cache artifacts built on that
<samueldr> since there's no speedy armv7l hardware for native build, it was instead running as a VM (with hardware accelerated virtualization) on an aarch64 server that has support for 32 bit
<Mic92> I can see how aarch64 can virtualize armv7
<samueldr> at least, with theflowering//ash's help, that was the best way forward we found, and it is "verifiably trustable"; as in we can start from NixOS artifacts, cross-compile an armv7l VM, automatically
<samueldr> and then at that point it does native builds, so a native build of the same VM could be done
cole-h has joined #nixos-aarch64
<hsngrmpf[m]> I am interested in the other way round. Emulating aarch64 on an armv7l. Just wondering how big the overhead would be. Because if it's low, then you could just use the aarch64 binary cache on armv7l devices and skip the whole hassle with armv7l binaries.
<hsngrmpf[m]>
<samueldr> oof, misread that
<samueldr> now I see the confusion
<hsngrmpf[m]> Apart from that I found out something very interesting today. Modern Raspberry OS can be switched 64 bit mode with one single config option 😂 https://www.raspberrypi.org/forums/viewtopic.php?t=250730 . After that the aarch64 version of nix works flawlessly. So no need at all anymore for armv7l on RPi. At least not if one is running a recent rpi OS version.
<hsngrmpf[m]> I tried setting this up today, but no luck. It can emulate x86 without problem, but aarch64 wouldn't work. Maybe just a config issue. I will do a benchmark in case I get it working.
<hsngrmpf[m]> But if you're stuck at some older raspbian or some other hardware which is actually limited to armv7l, then the emulating aarch64 could be interesting.
v0|d has joined #nixos-aarch64
<theotherjimmy[m]> Mic92, armv7a is a 32bit instruction word, and aarch64 is a 32bit instruction word; instructions are the same size on armv7a and aarch64. As for virtualization, you generally have a 32bit guest inside a 64bit host, so you don't have to worry about about packing registers like you mentioned
<theotherjimmy[m]> Also, most processors that can do aarch64 can also switch modes to execute armv7a instructions as well.
<samueldr> theotherjimmy[m]: I misunderstood that at first, the idea is to run aarch64 binaries on armv7 :)
<theotherjimmy[m]> Yeah, I noticed. I just wanted to clear up any further missunderstanding
<theotherjimmy[m]> It should be possible to emulate aarch64 on armv7a, but per might not be very good
<theotherjimmy[m]> You're likely to get better perf out off x86_64 because of reduced register presure
rajivr has quit [Quit: Connection closed for inactivity]
alp has joined #nixos-aarch64
quinn has joined #nixos-aarch64
<samueldr> I've been lucky with pre-ordering projects
<samueldr> and now I'm thinking of extending my luck a bit more
<samueldr> their last blog posts has interesting bits
<samueldr> >> The D.V.T. design brings with it a newly added SPI Flash which will allow Pocket P.C. to more easily boot multiple operating systems on the same Pocket P.C.
<samueldr> SPI Flash!
<samueldr> the (unnamed) A53 CPU is likely the allwinner R8
<samueldr> ah, no
<samueldr> not R8, since that is 32 bit
<samueldr> but likely an allwinner
<samueldr> ^ some hardware details
orivej has joined #nixos-aarch64
<samueldr> RTL8723DS could be an issue, but it seems every inexpensive hw with wi-fi is getting realtek these days
<theotherjimmy[m]> Seems like it's an A64
<theotherjimmy[m]> > Allwinner, who makes the A64 processor and LPDDR3 RAM that we use in Pocket P.C.
<{^_^}> error: syntax error, unexpected ',', expecting ')', at (string):320:10
<theotherjimmy[m]> From the last link
<samueldr> theotherjimmy[m]: I was thinking it could be one of the A64 derivatives
<samueldr> but that is technically "just like the A64"
<samueldr> like the R18
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
<theotherjimmy[m]> I read that as the A64 processor is used in the Pocket P.C. and they also use Allwinner LPDDR3 RAM
<samueldr> theotherjimmy[m]: ah, duh
<samueldr> I hadn't seen that section of that last link
<samueldr> that makes it "even better" as it's a well-known ecosystem
<theotherjimmy[m]> Yep, that's a cool form factor too
<samueldr> "kind of" pricey at 199$USD, for something without modem
<samueldr> but dang does it look cool
<samueldr> I now have to read more on LoRa
<samueldr> and what it actually means
<theotherjimmy[m]> Yeah, or 300 w/ Modem
<samueldr> like, could I have a LoRa gateway at home and use it for internet?
<theotherjimmy[m]> You can connect to all the LoRa things! which is almost nothing :/
<samueldr> even at slow speed
<theotherjimmy[m]> You could but yeah dat speed
<samueldr> I don't even know (yet) speed wise we're talking what
<samueldr> or is that another scam from bit telcos and only big telcos can do that?
<theotherjimmy[m]> If the ublox thing is the one I'm thinking of, the link between the CPU and the modem is limited to being transmiited over a 1.5Mbit/sec UART
<samueldr> oh, not bad
<theotherjimmy[m]> I remember that it was like 50Kb/s reliably, but those numbers may reflect how well Austin has adopted it more than anything else
<samueldr> though reading about it I still don't understand if it's something that end-users deploy or that you're expected to use a telco-provided network
<theotherjimmy[m]> Yeah, I'm not sure either. When you're developing the tech for a big company, that sort off thing can easily be lost in translation.
ingenieroariel has joined #nixos-aarch64
<samueldr> AH, I thought the website was broken
<samueldr> no, it was juste really slow without a loading indicator
<samueldr> I have a feeling that "Canada" being all yellow like that is...
<samueldr> they don't understand what a country is
<samueldr> though it looks like the answer is "maybe telco, maybe community operated"
<samueldr> so, as far as I understand things, I don't want to try to understand further and I can see that it's likely not going to be useful in my limited use cas
<samueldr> use case*
<samueldr> like, it really seems to be for IoT, if I wanted to e.g. ssh over that it would be a pain
<samueldr> and for reliably transmitting data through a network, but not low latency
<samueldr> though I might be wrong
<ingenieroariel> I just got my pinephone :) last year's version with the factory test postmarket image.
<ingenieroariel> what are the last commits/branches known to work with that one?
alp has quit [Ping timeout: 240 seconds]
<samueldr> there's a PR opened with updates
<ingenieroariel> this one for mobile-nixos? https://github.com/noneucat/mobile-nixos/tree/pinephone-crust
<samueldr> but since you're on the braveheart device (as I understand) you can just use master
<ingenieroariel> yes, it is a braveheart device
<{^_^}> mobile-nixos#188 (by noneucat, 2 weeks ago, open): [WIP] pine64-pinephone-braveheart: implementation of Crust
<samueldr> yeah, that crust branch uses binary blobs due to cross-compilation issues for the time being
<samueldr> though we probably can push on updating with 5.8 and latest u-boot without crust
<ingenieroariel> ok, I'll try that
<ingenieroariel> and for nixpkgs I use your feature/or1k-toolchain branch?
<ingenieroariel> or latest nixpkgs master?
<noneucat> nearly everything should be mainlined in 5.8
<noneucat> maybe we should look at using the default kernel instead of pine64's fork
<samueldr> noneucat: yeah, or picking patches if required
<samueldr> ingenieroariel: AFAIK there's no or1k toolchain working with nixpkgs, so plain old `nixos-unstable`
<ingenieroariel> ok, so plain old nixos-unstable with noneucat's branch
<samueldr> if you want to try crust yeah
<samueldr> otherwise plain mobile-nixos#master + nixpkgs#nixos-unstable should work*
<ingenieroariel> ok, otherwise the other one with u-boot hardcoded to my hardware version (as it is master now)
<samueldr> (firefox still hasn't built for nixos-unstable latest)
<samueldr> yeah
<ingenieroariel> and what do I get when I compile the image?
<samueldr> depends what you compile
<ingenieroariel> a sample boot like the android one or is there a configuration that would let me get all the way to a terminal?
<samueldr> you can use the native-built generic rootfs of the demo to get the demo system https://hydra.nixos.org/build/124510983
<samueldr> which is an xfce+awesome based thingy that's serviceable, but not "a finished product"
<samueldr> basically "how to fake having a phone environment two weeks before last nixcon"
<ingenieroariel> haha - cool
<samueldr> if you just `nix-build --argstr device pine64-pinephone-braveheart` within the root of the project (with the proper NIX_PATH for nixpkgs) you should get a totally useless system that appears to hang
<samueldr> (1) that's a bug that I should just fix instead of explain to everyone multiple times why
<samueldr> (2) it successfully booted to a system that is configured to do absolutely nothing
<samueldr> so even if the splash wasn't making you think it hung, you'd have a login prompt :)
<samueldr> I really need to go back to the drawing board and understand how to *properly* take control of the VT in a way that is less harmful for devices with a console
<noneucat> reminds me - need to clean up & make a pr w/ my phosh stuff
<samueldr> noneucat: to Nixpkgs, right?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<noneucat> an example config for mobile-nixos
<noneucat> and nixpkgs if the original phosh pr goes stale
<samueldr> good
<samueldr> just checking because the idea is not to accumulate things that should be in Nipkgs proper ;)
<noneucat> agreed
<samueldr> always be a superset that aims squarely to harmonize all device quirks
ingenieroariel has quit [Ping timeout: 245 seconds]
<noneucat> a quirk i've been noticing with my phosh on nixos is that it seems to dislike some part of the graphics stack
orivej has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
<noneucat> it frequently freezes up with complaints about lima in the kernel logs
<samueldr> might be something about mesa
<noneucat> that's what i suspect too
<noneucat> i'll have to look into it some more
<samueldr> I would be willing to bet some of the distros for the pinephone just ship some edge or master of mesa
<samueldr> as many do the same with the pinebook pro
orivej has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 240 seconds]
ingenieroariel has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 265 seconds]