<hexa-> the form factor looks amazing
<hexa-> can I expect them to do line rate (1 gbit) crypto?
<hexa-> and is 4GB enough to enjoy nixos on such a device?
<hexa-> thinking of the memory consumption of the likes of zfs
<samueldr> 4GB is enough for nixos
<samueldr> not sure what zfs requires though
<samueldr> I'm using nixos on a pinebook pro with the same CPU, desktop style use and it works just fine
<samueldr> 4GB ram too
<samueldr> so it's more about the filesystem overhead I guess
<gchristensen> my machine with 1G works fineish with zfs
<samueldr> a friend of mine says that 4GB is not enough for serious ZFS use
<samueldr> but I'm not sure I trust that friend about that
<gchristensen> it is a myth
<samueldr> never actually used ZFS
<samueldr> (my friend)
<gchristensen> pretty much every memory concern w.r.t. ZFS is FUD around dedup
<samueldr> ah
<samueldr> good to know
<gchristensen> (don't use dedup)
* andi- wonders how well deluge would run on that thing...
<andi-> I still have that Thinkpad with dedup on (and 16G or RAM) works like a charm :)
<andi-> (don't do it!)
<samueldr> probably fine
<gchristensen> its fine as long as you're operatinally fantastic
<gchristensen> and/or ready to lose all yoru data without fear
<samueldr> fine was about deluge
<gchristensen> ah
<samueldr> though I personally use transmission for... my isos
<andi-> How well does transmission scale these days? Say 2k torrents?
<samueldr> oh, I don't seed that many isos
<samueldr> so I couldn't say
<samueldr> I'm actually curious what's the best daemon/client pair now
<gchristensen> I wish I could just ask somebody to fech my ISOs and deliver them to me via scp in exchange for something
<andi-> I keep on hearing rtorrent is great for scale..
<samueldr> been using transmission only due to inertia mainly
<hexa-> yep, deluge is a major use case here as well
<andi-> samueldr: can you run cryptsetup benchmark on either/or both of the pinebook & pinephone?
<hexa-> the 16GB eMMC is probably a bit on the small end though
<hexa-> what andi said, pretty please
<samueldr> pinephone is not the same CPU
<samueldr> but I can run it on an RK3399 that is not power-starved like the pinebook pro, I have another RK3399 system that has enough power
<andi-> pretty please :)
<samueldr> andi-: do you want to also know about the pinephone's?
<andi-> samueldr: if you are bored.
<thefloweringash> now I'm curious. what's up with the power for the pinebook pro?
<samueldr> I say that, but it's actually fine
<samueldr> I was thinking about thermals
<samueldr> though it *is* starved if running too long, and will dip in the battery
<samueldr> well, if the CPU is hammered for too long
<samueldr> so if you run without the battery plugged, I think it will throttle down
<samueldr> the pinebook pro only has 5V input
<samueldr> no fancy power delivery higher wattage input
<samueldr> so charging from type-c or the barrel jack is functionally identical
<samueldr> not a terrible drawback for the complexity
<samueldr> and I think it makes it simpler to know you can charge it with anything that does the basic 5V up to 3A usb
orivej has quit [Ping timeout: 255 seconds]
<andi-> Yeah but I would love to only need usb-c PD for all my portable devices :)
<samueldr> it does work with a PD charger, simply no fancy mode
<samueldr> "legacy" power
<samueldr> next trip I might actually live the type-c only "dream"
<samueldr> (nightmare?)
<andi-> It is allright
<andi-> I went to the US with just one charger with me. That worked for phone, notebook & switch
<samueldr> and funny enough I had a PD power brick that came with all the worldwide plugs with a product!
<hexa-> pretty happy with usb-c for everything
<gchristensen> if I plug my apple usb-c charger in to my dell xps, the kernel gets bogged down with interrupts
<thefloweringash> ಠ_ಠ
<thefloweringash> which device is at fault?
<samueldr> thus "nightmare?"
<andi-> That sounds like… working as intended..
<samueldr> I think apple's implementation may not be totally "right", or at the very least, marginal, from what I heard
<gchristensen> thefloweringash: dunno :P
<andi-> samueldr: <3
<samueldr> which has good thermals
<colemickens> gchristensen does it also start throttling the CPU?
<colemickens> I have a specific dongle, that if I use with my XPS, forces the XPS into 0.4Ghz mode. There's some MSR register I can set to make it stop doing that, but then it does weird things like say I have 100000 hours of battery left instead of saying "charging over AC".
<samueldr> :|
<andi-> so those numbers are like half of what the Atom I currently use produces. Not to bad. Probably good enough for most of my usage.
<hexa-> indeed not to shabby
<hexa-> I'm seriously tempted
<andi-> does it have any hardware aes support?
<samueldr> not sure
* colemickens wishes he could get a pine phone pro so bad
<andi-> I might just buy one for remote backups at $otherlocation
<samueldr> Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
<samueldr> Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
<samueldr> in case both core had different sets
<andi-> almost sounds like it
<samueldr> doesn't look like it does have different features
<hexa-> even sha2
<samueldr> (reminder that it's big.LITTLE)
<hexa-> 2x A72, 4x A53
<samueldr> oops, my pinephone kernel build stops me from benchmarking cryptsetup
<samueldr> (not a modular kernel)
<samueldr> Required kernel crypto interface not available.
<samueldr> Ensure you have algif_skcipher kernel module loaded.
<samueldr> andi-: though the pinephone is a bog standard allwinner A64, unless it has bad thermals, you can compare to that, if you can find comparison
<samueldr> (I don't have an a64 machine I can lazily run this on)
<thefloweringash> I got that on my test too. Still wishing for mainline support
<samueldr> oh, maybe I do
<samueldr> thefloweringash: on your test on what?
<thefloweringash> I was curious about my honeycomb
<samueldr> ah
<samueldr> though here it's most likely because I have a non-modular kernel with only a subset enabled
<thefloweringash> mainline kernel starts, but doesn't seem to have pcie yet so I can't actually boot
<samueldr> like I think I'm missing the usb mouse drivers
<samueldr> I haven't looked at it more yet
<samueldr> I'm actually more interested in not fixing that, and rather adding kexec support to the stage-1 boot gui to make it a stage-0
<thefloweringash> I guess I haven't tried a "standard" nixos build of the vendor source tree. I'm just used to vendor kernels not building if you turn on more than their narrow subset
<samueldr> hah
<samueldr> pinephone is almost mainline
<thefloweringash> yeah, i've been seriously impressed by the mainlining effort for both sunxi and rockchip
<samueldr> both are mainly community based
<samueldr> sunxi mostly is
<samueldr> and their hw is cheap, so it's quite accessible
<samueldr> rockchip I know there is some work from rockchip that is being "foreced" to be mainline by some projects
<samueldr> e.g. libre.computers are part of those that do
<thefloweringash> and I guess google too?
<samueldr> they have rockchip engineers making mainlinable patches
<samueldr> oh, right
<samueldr> forgot about the big G :)
<samueldr> yeah, those help too
<samueldr> I had u-boot in mind, which google doesn't make use of
<samueldr> AFAIK libre.computer are the main reason rockchip contributed DDR4 SBL to mainline u-boot for rk3399
<samueldr> like, they sent me the preview patches at some point
<ryantrinkle> samueldr: i tried the pinephone thing last night, and had a bit of an issue
<ryantrinkle> very little was cached, so it took a few hours to build; not sure whether that's expected or not
<samueldr> which issue?
<ryantrinkle> second, when i dumped it on the SD, it booted from eMMC instead
<samueldr> stage-1 yes, stage-2 no, but stage-2 needs to be built natively
<ryantrinkle> i did all my building on an aarch64 machine on packet
<samueldr> hmmm, I wonder if my u-boot build could be booting the system on the eMMC as a priority
<samueldr> though I do have the factory test program still on the eMMC
<samueldr> so I don't think so
<samueldr> looking at the serial output it'd be obvious if my u-boot build was used
<ryantrinkle> ok, i'll go back to that image and send the output
<ryantrinkle> samueldr: that's the output; i'm sitting in the uboot shell now
<samueldr> >> U-Boot 2020.01 (Jan 09 2020 - 12:17:54 +0000) Allwinner Technology
<samueldr> that's not ours I think
<ryantrinkle> is there a way i can check what's on the image?
<samueldr> on the eMMC?
<samueldr> or SD card?
<samueldr> not sure though for either
<samueldr> U-Boot 2020.04-rc3 (Jan 01 1970 - 00:00:01 +0000)
<samueldr> that's the one it should be using from my PR
<samueldr> NOTICE: BL31: Found U-Boot DTB at 0x4070528, model: PinePhone
<samueldr> though yours seems to have usb working
<samueldr> that's interesting
<samueldr> I haven't looked at it yet
<ryantrinkle> oh uh
<samueldr> would be helpful to use UMS from u-boot to flash the eMMC
<ryantrinkle> the img has all zeros for a very long time at the beginning
<samueldr> that's normal
<samueldr> 30MB of them I thin
<samueldr> think*
<ryantrinkle> but isn't uboot supposed to be at 8kb?
<samueldr> with a small sliver for u-boot at some location
<samueldr> yeah
<samueldr> though you shouldn't need to burn u-boot manually to your sd card
<samueldr> it should be in the disk-image
<samueldr> building and flashing u-boot is more about upgrading your u-boot or playing around with u-boot
<ryantrinkle> yeah, that makes sense
<ryantrinkle> but i'm reading straight from the disk-image file
<samueldr> just checking, did you literally use the command from the readme?
<ryantrinkle> all zeros at 8k
<samueldr> hmm
<ryantrinkle> i'm not reading from the sdcard
<samueldr> right, that was written while you were saying that
<ryantrinkle> makes sense
<samueldr> 00002000: 1600 00ea 6547 4f4e 2e42 5430 f733 e867 ....eGON.BT0.3.g
<samueldr> using xxd -a result
<samueldr> note that I never tried a full native build on aarch64
<samueldr> maybe it's broken!
<samueldr> (working on things to improve that)
<ryantrinkle> ah, i see
<ryantrinkle> so, how can i build as similarly to you as possible
<samueldr> 0x2000 == 1024*8
<ryantrinkle> right; that's where i'm looking too
<ryantrinkle> all-native definitely sounds like it might be the issue
<samueldr> from an x86_64 system, using that dummy rootfs PR
<samueldr> I build disk-image
<samueldr> flash the image, resize the dummy partition, flash a previously built system.img on top of that partition
<samueldr> the system.img... unsure which attribute
<samueldr> but it's one built on native aarch64 for an android device
<samueldr> btw I'm not gonna merge that dummy rootfs PR and instead make a less dummy, but working dummy system that can be booted into for a "full" cross-compiled system, even though if "almost useless"
<samueldr> likely to boot into a minimal GUI that goes something like "congrats, now you need to build a system"
<ryantrinkle> so, a while back, i did get something working that is fully cross
<Danct12[m]> btw, i got a pinephone dev phone few months ago
<Danct12[m]> i wonder when i can try nixos on there
<ryantrinkle> but it's a very limited definition of "working"
<ryantrinkle> Danct12[m]: right now, if i can get my shit together with samueldr's help :)
<ryantrinkle> i've got a braveheart, not a devkit
<ryantrinkle> i'm not sure exactly what the differences are
<samueldr> the PR is there, the mess you encounter is not pinephone specific I think :)
<Danct12[m]> well mine isn't a dev kit, but a dev phone :)
<samueldr> Danct12[m]: do you know if the dev phone can run the same software as braveheart?
<Danct12[m]> it's like your unique braveheart, but not the braveheart design
<Danct12[m]> it can
<samueldr> then the PR should work, with the same caveats are other devices
<Danct12[m]> it's just the same device, braveheart only has a few changes to hardware
<samueldr> blargh, really need to sweep up the loose ends with building a system >_<
<samueldr> sure, but it could have had an incompatible change! I didn't know :)
<Danct12[m]> one device type on postmarketos works on cross devices
<samueldr> good
<Danct12[m]> i also have a pinetab as well, but then the work is just the same as the pinephone.. just without the modem :D
<Danct12[m]> by the way i am currently working on a boot image for pinephone/tab, this image will enable mass storage device and allowing you to do wtf you want, even comes with telnet access for idk, just do whatever you want
<Danct12[m]> your phone emmc now acts as a flash drive
<samueldr> I was going to make a u-boot config that you would burn to sd card to do only UMS with eMMC (mass storage)
<samueldr> in fact it would have been done already, except in the defconfig somehow usb doesn't work?
<samueldr> something I had to take a look at later
mvnetbiz_8 has joined #nixos-aarch64
<samueldr> but a bootable *linux* system with gadgets doing this is also a good idea
<samueldr> especially since u-boot won't have display init or anything interactive other than serial
<samueldr> fastboot also can work
<samueldr> especially useful for fastboot flash here
<samueldr> fastboot boot isn't working as well
<samueldr> though I figure with fastbootd with recent android devices, fastboot from a linux gadget could be made now
mvnetbiz_ has quit [Ping timeout: 255 seconds]
mvnetbiz_8 is now known as mvnetbiz_
<Danct12[m]> i think that doesn't work i guess
<samueldr> hm?
<Danct12[m]> or maybe it works but it's just i dont know how
<samueldr> fastbootd from linux? something to be explored :)
<samueldr> it's quite new
<Danct12[m]> talking about u-boot usb config thing
<samueldr> ah
<samueldr> it seems it should work, according to ryantrinkle's u-boot log usb is detected
<samueldr> it uses the pine64-lts defconfig though, probably with modded dts?
<samueldr> built in january if the build date can be trusted
<samueldr> (probably can)
<Danct12[m]> nah it's not modded dts
<Danct12[m]> by the way mine comes with a shell which could be useful to chroot to a broken phone
<samueldr> the factory image uses directly the pine64 lts build?
<samueldr> sure! as I said, doing it from linux is a good thing
<samueldr> you get much more bang for the buck
<Danct12[m]> :D
<Danct12[m]> well the factory test image or postmarketOS uses pine64-lts uboot
<Danct12[m]> and that script only loads the pinephone dtb and pretty much it
<samueldr> right, then it should be trivial to fix the pinephone u-boot config
h0m1 has quit [Ping timeout: 240 seconds]
<samueldr> see which options are dropped or device tree bits missing
<Danct12[m]> also join #pinedev on freenode
<samueldr> didn't know about that one
h0m1 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
Ultrasauce has quit [Remote host closed the connection]
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-aarch64
Ultrasauce has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
lovesegfault has quit [Quit: WeeChat 2.7.1]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
zupo has joined #nixos-aarch64
LnL has joined #nixos-aarch64
LnL has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
t184256 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
wavirc22 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
Valodim has joined #nixos-aarch64
<Valodim> hey folks :)
<Valodim> I got nixos to work on my rpi4, but pulse is unable to find any sound card. I googled aroud a bunch, but I can't really tell: is audio output expected to be working?
<clever> Valodim: is a card listed in /proc/asound/cards ?
<Valodim> at work right now. I'll check when I'm home :)
vcunat has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiii has joined #nixos-aarch64
lovesegfault has joined #nixos-aarch64
lovesegfault has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-aarch64
<Valodim> clever: says "------ no soundcards -------"
<Valodim> "cat -v /proc/device-tree/soc/audio/status" also says "disable"
<Valodim> I'm using pretty much the exact config from "With GPU" on https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi
<Valodim> ooh I have a device now
<Valodim> dtparam=audio=on in firmwareConfig did it
<Valodim> pulseaudio isn't happy yet, but it's a step :)
<Valodim> it works \o/
<samueldr> thanks for updating the wiki page!
<samueldr> (I fixed the heading so it's part of the raspberry pi 4 subsection)
<Valodim> thanks!
<Valodim> seems like the sound is somehow bound to the X session
<Valodim> when I run pulseaudio without an X session, it can't find the soundcard
<Valodim> it can when I run it with sudo, or in an X session
<samueldr> could be something about logind rather than X
<samueldr> (totally a guess)
<Valodim> yeah something like that
<Valodim> so now that sound works.. any experience with bluetooth? :)
<Valodim> hardware.bluetooth.enable = true; doesn't do the trick, unfortunately :D
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 258 seconds]
tilpner_ is now known as tilpner
<Valodim> seems bluetooth is at odds with uart, and there is enable_uart=1 in /boot/config.txt by default. hmm
<Valodim> I can get a controller to work with btattach
zupo has joined #nixos-aarch64
vcunat has quit [Quit: Leaving.]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 256 seconds]
zupo_ has quit [Client Quit]
zupo has joined #nixos-aarch64
kai_w has joined #nixos-aarch64
zupo has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
lovesegfault has quit [Ping timeout: 260 seconds]
zarel has quit [Ping timeout: 255 seconds]
zarel has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
zarel has quit [Read error: Connection timed out]
zarel has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lovesegfault has joined #nixos-aarch64