<clever> samueldr: i'm also thinking it would be 2 uFL connectors, not full anteannas, because the CM4 might get burried deep inside a product
<clever> and you may choose to only connect one of them, and now you have to tell the software which one to use
<clever> if both anteannas where onboard, why give the user a choice?
<samueldr> [citation needed] Key E for M.2 seems indeed to support antennas
<samueldr> yeah, I assumed connectors of some sort
<samueldr> hm, I'm probably wrong
<samueldr> things are confusing when the specs are not openly accessible :(
<clever> i also had an idea a few days ago, what about pci-e?
<clever> what if the CM4 was in a pci-e 4x form-factor
<samueldr> that would be interesting
<clever> with 1 pci-e lane, and then gpio sprinkled on the other pins
<samueldr> only if it's actually compatible with PCI-e though
<clever> obviously, its host not device, so never try putting it on a pc
<samueldr> if it isn't it should have another form factor!
<clever> its a host-only pci-e controller i believe
<samueldr> clever: hosts can be on a PCIe card
<clever> so you would be abusing the pci-e edge connector, like previous models abused sodim
<samueldr> the new fancy gaming NUC is IIRC
<veleiro> pi has always been kinda non accessible right? did they ever replace that
<veleiro> GPU blob
<samueldr> it's definitely not the freeer of options
<clever> veleiro: rpi-open-firmware can boot nixos on the pi2 and pi3, without any blobs involved
<samueldr> clever: you dropped the *
<clever> but you loose 3 arm cores (easy to fix, lazy), and you loose all video output forms, and hw accel
<samueldr> :)
<veleiro> lol
<clever> you also loose netboot and usb boot
<veleiro> ah sounds like a winner
<clever> but its open source, so anybody can improve it further!
<veleiro> well that raspi managed to offer more than 4gb ram is attractive but its
<veleiro> probably still not worth building on
<samueldr> do you mean building as in building packages or building as in building a product on?
<veleiro> but if that compute module format could be a shared standard among boards
<clever> part of the problem i can see with any shared standard, is all of the gpio alt functions
<samueldr> I'm waiting for an M.2 NVMe SSD and its USB adapter to get here, and I'm gonna benchmark the renegade elite (so, RK3399) compared to a pi4
<veleiro> building a product with and developing software
<clever> i often see other boards having a "pi compatible" 40pin header
<veleiro> nice learning platform though
<samueldr> yeah, building a product on top of pretty much any SBC is a bit scary
<clever> but can they do every single mode the pi can? https://elinux.org/RPi_BCM2835_GPIOs
<clever> on the same pins
* samueldr is curious about libre.computer's offer
<clever> your going to have to either draw the line somewhere, or put in some ridiculus muxing
<samueldr> I know the people there *care* a lot about stuff like that
<clever> theres also the eoma86 stuff
<veleiro> the beaglebone black had a nice hefty gpio list
<veleiro> got 2 of them i need to reuse
<samueldr> good, libre.computer doesn't pretend to be compatible, only the same form factor
<clever> veleiro: isnt the beaglebone the one with PRU's?
<veleiro> ah, yes, but i dont know much about using them
<clever> from what ive see, the PRU is basically a realtime core, that can emulate almost any peripheral
<clever> so thats about the only way you can meet the random altfunction and pinouts of another board, and emulate its features fully
<samueldr> can you make it emulate an LED?
<clever> any waveform on gpio
<samueldr> :)
<veleiro> cool
<clever> in theory, i can also do the same thing with the VPU on the rpi, with the open firmware
<clever> you have 2 rtos capable cores, that are basically unused, and they can run entirely from L2 cache, so no dram latency
<clever> you can even configure it so the arm can write to the L2 cache, so you can skip some cache management logic and more dram latency
<clever> there are also tricks you can do, if you want output only at high datarates
<clever> i have a proof of concept, that can (in theory) spew out 24 uart signals at once, at up to 75,000,000 baud (in theory)
orivej has quit [Ping timeout: 256 seconds]
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
<veleiro> its a real shame that anbox is built with snaps
knerten1 has joined #nixos-aarch64
colemickens_irc has quit [Quit: Connection closed for inactivity]
knerten has quit [Ping timeout: 264 seconds]
patagonicus0 has joined #nixos-aarch64
<veleiro> damn i'm going to have to pin home manager builds too for the PBP
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-aarch64
patagonicus has quit [Ping timeout: 260 seconds]
patagonicus0 is now known as patagonicus
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
<samueldr> ,stty
<{^_^}> echo "stty rows $(tput lines) cols $(tput cols)"
<samueldr> {^_^}++
<{^_^}> {^_^}'s karma got increased to 211
<veleiro> samueldr thanks for the nixos-mobile nixpkgs targeting advice!
<veleiro> i am able to use what's cached on firefox
<veleiro> had to switch back to 5.7 kernel on that target though
<veleiro> although i'm getting the hang of this and can see how to use a cached 5.4 too
<lopsided98> Has there been any work on getting patchShebangs to work right with cross-compiled Perl modules? I'm seeing that miniperl (for the build arch, installed in perl.dev) gets set as the shebang rather than host perl.
<samueldr> not that I know of, though sadly I don't know everything
<lopsided98> thanks, I think I found a fix
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
Piece_Maker has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 240 seconds]
Piece_Maker is now known as Acou_Bass
orivej has quit [Ping timeout: 240 seconds]
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
lordcirth has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lordcirth__ has quit [Ping timeout: 244 seconds]
Thra11 has quit [Quit: WeeChat 2.8]
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej_ has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 264 seconds]
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej_ has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
alp has quit [Ping timeout: 272 seconds]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
alp has joined #nixos-aarch64
lordcirth has quit [Ping timeout: 260 seconds]
Thra11 has joined #nixos-aarch64
lordcirth has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 256 seconds]
cidkidnix has joined #nixos-aarch64
<cidkidnix> samueldr: it's been awhile but I'm the lad that was porting op5/T to nixos-mobile, I might have more time to do so since I'm getting a pinephone to tinker with aswell
<cidkidnix> so maybe that PR I made ages ago will actually boot again
cidkidnix has quit [Remote host closed the connection]
FRidh has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 246 seconds]
<sphalerite> samueldr: I'm ready to test linux 5.8 on the bob, is it still relevant? x)
<samueldr> yeah, get yourself the suzyqable for the EC console
<samueldr> basically just run 5.8 on it; udevadm settle may fail (should fail?)
<samueldr> but another way to confirm that is to have a storm of https://chromium.googlesource.com/chromiumos/platform/ec/+/master/common/virtual_battery.c#322
<sphalerite> where do I get it from?
<samueldr> because the kernel is (AFAIUI) looping trying to read the battery because it assumes that the error means the battery was disconnected so it tries to re-read to assert the status
<samueldr> "it" being?
<sphalerite> the kernel
<samueldr> right, it's not back into nixpkgs I presume
<samueldr> you could run a mobile nixos build I figure
<samueldr> to the best of my knowledge, asus-dumo should work on all gru targets as the kpart embeds all device trees for rk3399
<samueldr> Image 13 (fdt@11)
<samueldr> Description: rk3399-gru-bob.dtb
<samueldr> this tree should work
<samueldr> uh...
<samueldr> yeah, work too well
<sphalerite> that probably only works with depthcharge?
<samueldr> I wouldn't think so
<samueldr> right, you have u-boot now
<samueldr> the problem is highly likely to be dependent on the EC and sbs-battery (the kernel driver)
<samueldr> so any way it ends up being used should fail properly
alp has joined #nixos-aarch64
<samueldr> you can also just simply copy the 5.7 derivation in nixpkgs and make your own 5.8
<sphalerite> right, I'll just try deploying it with a nixpkgs revthat has 5.8 then
<samueldr> or revert the commit that removed 5.8
<sphalerite> true
<sphalerite> building…
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
<sphalerite> grpmh config failed
<samueldr> hm?
<sphalerite> oooh pff I based it on the wrong branch
<sphalerite> never mind me
<sphalerite> no wonder there was a merge conflict.
<sphalerite> interesting though, git will let you revert a commit that's not an ancestor of HEAD>
<sphalerite> s/>/.
<samueldr> :|
<samueldr> git is so weird
<samueldr> some parts are extremely worried about semantics
<samueldr> some parts are extremely not worried about semantics
<sphalerite> git revert is just git cherry-pick with reverse patching.
<samueldr> did you know that `bad` *has* to be an ancestor of `good* in a git bisect?
<samueldr> so you can't find a commit that introduced a fix using the default words!
<sphalerite> isn't it the other way round?
<samueldr> exactly
<sphalerite> no I mean, git requires good to be an ancestor of bad
<samueldr> yes
<samueldr> I had it backwards
<samueldr> but still, that's pretty arbitrary
<sphalerite> yeah
<samueldr> why not go with whichever is an ancestor of the other??
<sphalerite> yeah
<sphalerite> but hey, git was never a really great software suite
<sphalerite> it has its strengths… and its weaknesses.
<samueldr> yeah
<sphalerite> hasn't stopped it from being extremely widespread x)
<samueldr> I still think it's dumb luck that github did "social programming" the least worst first
<sphalerite> I remember way back when, there was gitorious and stuff
<sphalerite> I definitely started using git before I knew github was a thing
<samueldr> I was a mercurial user back then
<sphalerite> I think I published my git projects to google code and gitorious
<samueldr> its UX was way better :(
<sphalerite> so I've heard
<sphalerite> I never enjoyed hg because I was already damaged by git and found the differences in terminology annoying
<samueldr> differences in terminology sure made "getting git" initially quite confusing
<sphalerite> git was definitely a step up from svn though :D
<samueldr> that I never had the chance to use
<sphalerite> and svn was a massive step up from no version control
<sphalerite> it's probably better that way :p
<samueldr> I upgraded (self-taught) from none to mercurial during CEGEP (post-secondary here)
<sphalerite> https://github.com/lheckemann/Pirates/releases/tag/a-rendre I used git for a lycée project :D
<samueldr> heh
<samueldr> I forced my teammates to use mercurial even though there was absolutely no customary use of source control
<sphalerite> hehe
<samueldr> they hated it at first, but they quickly understood how it helps compared to trying to manually handle those things
<sphalerite> yep
<sphalerite> what is up with this weird perl5.30.3-urxvt-bidi-2.15 package…
alp has quit [Ping timeout: 272 seconds]
<samueldr> bidi is bidirectional
<sphalerite> it keeps popping up in builds for my aarch64 stuff and takes ages to build (well, to run the tests technically I think)
<sphalerite> yeah
<samueldr> well, you have to figure out why you have urxvt then :)
<sphalerite> well… I sure didn't specify it
<sphalerite> it seems to be on the system path but I didn't put it there
<sphalerite> oooh the sway module adds it.
<sphalerite> pfff.
<samueldr> I was just about to ask if you were swaying
<samueldr> that makes me think; how much I would like if the options system had a `lib.mkRemoveFromList`
<sphalerite> well in sway's case it's easy to deactivate it
<sphalerite> but hey it's finished building so wheeee
<samueldr> by using mkForce?
<samueldr> that's kind of annoying because you lose whatever defaults are added!
<sphalerite> no, sway adds programs.sway.extraPackages to systemPackages
<sphalerite> and you can change that to only remove what sway adds
<samueldr> hm?
<samueldr> how do you manipulate systemPackages?
<sphalerite> by setting programs.sway.extraPackages
<sphalerite> that's why I said "in sway's case"
<samueldr> right, no mkForce
<samueldr> but still the same idea
<samueldr> might be even worse here? any of those extra packages actually needed?
<sphalerite> huh, this problem should already be happening in stage 1, right?
<samueldr> depends on kernel modules maybe
<samueldr> why?
<samueldr> not sure if sbs-battery is =m or =y
<sphalerite> because it didn't get past stage-1
<sphalerite> (just merged the PR fixing the issue that caused that)
<samueldr> and you have the cable plugged-in?
<sphalerite> #92081
<sphalerite> yeah
<{^_^}> https://github.com/NixOS/nixpkgs/pull/92081 (by CrystalGamma, 6 weeks ago, merged): makeModulesClosure: handle builtin modules better
<samueldr> I'm confused
<samueldr> probably because I'm not asking the right questions
<samueldr> how did it fail?
<sphalerite> btrfs was missing from the initramfs
<samueldr> oh
<samueldr> that's not the problem we're looking for :)
<sphalerite> yeah
<sphalerite> and I was already familiar with it
<samueldr> look at the EC logs (for me it's the last of the consoles)
<sphalerite> so I merged the fix (above) and am now deploying with that fix
<samueldr> "Unhandled VB reg %x" should be spammed if you had the battery drivers going
<samueldr> but I guess that's not in stage-1
<samueldr> show-off
<sphalerite> I get [ 60.871252] sbs-battery 9-000b: Unknown chemistry: OTS0
<sphalerite> but other than that it seems fine?
<samueldr> that's the AP (linux), and not an issue
<samueldr> hmm
<samueldr> nothing on the EC console?
<sphalerite> a couple of errors on the EC log, but not spammy
kahiru has quit [Read error: Connection reset by peer]
<samueldr> might be specific to having all modules bulit-in
<sphalerite> well, I just might do a localyesconfig to try it out :p
<samueldr> or it's actually specific to gru-dumo, somehow, even though the virtual battery driver is the same
<samueldr> (I looked at the DTs, there's no gru with some other battery gauge thingy)
<sphalerite> oh wait, my earlier gist is wrong
<samueldr> also, `udevadm settle` fails in stage-2, after hanging
<sphalerite> fixed
<sphalerite> mine just boots all the way without any hangs or log spam
<sphalerite> I'll give localyesconfig a shot I guess
kahiru has joined #nixos-aarch64
<sphalerite> I'll do that, that's quicker.
<sphalerite> aw, it doesn't like how a bunch of config things aren't enabled.
<samueldr> nixos' verification thing?
<samueldr> (I really should get on with using that in mobile nixos)
<sphalerite> yeah
<sphalerite> CRYPTO_USER_API_HASH, DMIID, TMPFS_POSIX_ACL, TMPFS_XATTR
<samueldr> it can be disabled IIRC
<samueldr> system.requiredKernelConfig = lib.mkForce []; # I guess
<samueldr> though yes, an *actual* fix will be to use this
<sphalerite> "I require this kernel conf--" "NO YOU DON'T"
<sphalerite> building :)
<samueldr> it works well enough
<samueldr> (but yeah, I really don't want to ignore that for much longer)
<samueldr> (but I'll have to somehow find a way to remove some of the defaults for older kernels :/)
<samueldr> (now I really want a lib.mkRemoveFromList)
<sphalerite> eeeeh I think that could get kind of hairy
<samueldr> love it or don't, it's the only part of system configs that can't be overriden cleanly
<samueldr> it's all or nothing :/
cole-h has quit [Quit: Goodbye]
<sphalerite> there's a bunch of options that aren't specified in your config.aarch64 fwiw
alp has joined #nixos-aarch64
<sphalerite> is that intentional?
<samueldr> probably not
<samueldr> or maybe it's something with how menuconfig does it
<sphalerite> including initramfs support
<samueldr> hm?
<sphalerite> wait what
<sphalerite> it is listed in the config
<sphalerite> but the config derivation still goes through the questions
<samueldr> I really had trouble when first starting with Mobile NixOS when trying to reuse most of the nixos kernel infra
<samueldr> I don't know what I'm doing wrong, or if it has assumptions baked-in that clashed
<samueldr> that's why I ended up re-using only some parts of it
<samueldr> now that I know more about *everything* related to that I'll end up taking a second glance
<sphalerite> huh
<sphalerite> I haven't really had many problems with
<sphalerite> probably haven't used it as intensively as you either though :)
<samueldr> it was for using a complete config file like those
<samueldr> but at the time I sure had much more to learn about Nix, Nixpkgs and NixOS
<sphalerite> and linuxManualConfig didn't do it?
<samueldr> that's close to 1.5 years ago
<samueldr> eons
<samueldr> I only remember that I had troubles :)
<sphalerite> hehe ok
<sphalerite> kernel's still building..
<sphalerite> are there fairly powerful aarch64 machines available in hardware to normal people nowadays?
<sphalerite> It doesn't need to be like the packet machines, but I would appreciate something a little stronger than my rk3399s
<sphalerite> oh yeah, the clearfog thing I guess
<samueldr> yeah
<sphalerite> maybe I should buy one.
<samueldr> honeycomb
<sphalerite> thefloweringash: would you recommend it?
<samueldr> clearfog is the other product
<samueldr> I follow jon nettleton on twitter and IIRC he's close to being "done" with the firmware work
<samueldr> dunno what that means
<samueldr> I still don't know what to expect of that system :/
<samueldr> neat, still looking into that MIPI issue with the gru-dumo
<sphalerite> hm, my dad has a jetson nano which he isn't using, I wonder if that's any faster than rk3399
<samueldr> and using an upcoming patch from the rk3399 list it seems that things are getting worse :/
<sphalerite> quad a57…
<sphalerite> vs quad A53+dual A72
<samueldr> IIRC big.LITTLE is hard
<samueldr> so it might just because it's not working with big.LITTLE
<samueldr> hmm, reading the trace more carefully maybe it's "better" in that it fails at boot too
<samueldr> which might better point towards the issue
<sphalerite> as opposed to failing when?
<samueldr> when the display is being powered down
<samueldr> (and powered back up)
<sphalerite> oooooooh
<sphalerite> I'm not sure that happened at any point when I was testing it
<samueldr> oh, it's not using the same interface
<samueldr> it's a scarlet issue
<samueldr> might even be specific to those with the innolux panel (dumo AFAICT)
<samueldr> so I might be the only individual on this planet doing anything mainliney with it :|
<samueldr> or even remotely developerey as the chromeos-4.4 kernel doesn't work *either* on it
<samueldr> which is highly surprising considering chromeos works
<samueldr> what annoys me the most is that when this was contributed to the kernel *obviously* no one had tried it
<samueldr> because it didn't even work at all (support for at least my rev of scarlet)
<sphalerite> ah
<sphalerite> all vendors using mainline for everything when
<sphalerite> also power supply for the jetson nano has gone missing
<sphalerite> well, finished building the kernel
<sphalerite> it boots fine too
<sphalerite> actually, it took a long time to get to the login prompt
<sphalerite> oh and the wifi doesn't work
<sphalerite> but I guess that's just because it's a different chip
criptonauta__ has joined #nixos-aarch64
criptonauta_ has quit [Read error: Connection reset by peer]
<sphalerite> hm, I wonder if I can get suspend working on the bob again. lol
<samueldr> sphalerite: took a long time?
<samueldr> like, two more minutes?
<samueldr> try `udevadm settle`
<samueldr> and uh, did you confirm there was or not a storm of messages in the EC console?
<sphalerite> yeah no message storm
<sphalerite> ah no, the long wait was because the wifi wasn't working :)
<sphalerite> the wait-online service timed out
<samueldr> ah
<samueldr> weird :/
<samueldr> I assumed the virtual battery driver would do the same for every gru
<samueldr> unless... somehow the cros-ec uses virtual battery for scarlet/dumo, but not for other grus?
<samueldr> ugh, more issues that'll go undiagnosed
quinn has joined #nixos-aarch64
evils has quit [Read error: Connection reset by peer]
evils has joined #nixos-aarch64
alp has quit [Remote host closed the connection]