<ashkitten>
luckily i can ssh in now, since i've got ethernet :p
<samueldr>
rndis with networking shenanigans, or usb otg ethernet adapter?
<ashkitten>
otg ethernet
<samueldr>
neat, I feel dumb, I didn't think about that
<ashkitten>
eh i didn't either
ky0ko has joined #nixos-aarch64
<samueldr>
especially since I have a type-c dock which has PD in, and ethernet
<ashkitten>
hah
<samueldr>
to use with a phone :|
<samueldr>
I literally had it to use it with mobile nixos... in the future...
<ashkitten>
well now you can :p
<samueldr>
yes, and it will be useful for the initial dev cycle for stage-2 things *facepalm*
<ashkitten>
hmph.. why can't i connect to servers outside my network...
<ashkitten>
`curl: (7) Couldn't connect to server`
<ashkitten>
(when trying to curl google.com's ip)
<ashkitten>
and i can't traceroute because that uses icmp
<ashkitten>
oh, right
<ashkitten>
i can't use curl as non-root
<ashkitten>
of course...
<ashkitten>
:/
<samueldr>
that doesn't sound right to me
<samueldr>
I don't think that curl is privileged
<ashkitten>
doesnt sound right to me either, yet here we are
<samueldr>
maybe it's broken, but if so, it's likely something else than ping
<ashkitten>
probably
<ashkitten>
the weird part is i can curl a network-local site as non-root
<ashkitten>
wait
<ashkitten>
no i can't
<ashkitten>
sorry, i lied
<samueldr>
it happens to the best of us
<ashkitten>
boy that would've been janky tho
* samueldr
is excited to the prospect of wired networking
<ashkitten>
working networking at all would be a gift
<ashkitten>
i only thought of wired networking because my options are that, a wifi dongle, or bluetooth
<samueldr>
wi-fi dongle was something I thought of, but hadn't tried yet
<ashkitten>
honestly i might mess around with bluetooth anyway if i can get these privilege issues fixed, since it'd let me browse untethered from my desktop
<ashkitten>
also, ky0ko (who is not here) is trying to get stuff working for another phone that uses icnss for wifi, but she said it looks like the kernel module is somewhat device specific which could end up being a pain
<ky0ko>
hi i'm here
<ashkitten>
what
<ky0ko>
i joined immediately after you vocally expressed surprise that i wasn't here
<Church->
ashkitten: Pinephone?
<ky0ko>
essential ph-1
<ky0ko>
and also motorola one hyper
<samueldr>
pinephone has wi-fi
<samueldr>
so no :)
<ky0ko>
i wish i had a pinephone to play with...
<samueldr>
I believe google-marlin (pixel [1] xl)
<ashkitten>
i have that phone
<ashkitten>
ky0ko is working on the other phones she listed
<ashkitten>
she's not doing nixos dev though
<ashkitten>
just pmos
<samueldr>
that's nice, postmarketOS or mobile-nixos---- ah then that answers it
<samueldr>
:)
<ky0ko>
i potentially could do nixos dev, down the line, but PmOS is more my thing
<samueldr>
anyway, cross-pollination is a real thing
<samueldr>
and I'm totally in with people doing other non-androids on android phones
<samueldr>
alright, so my pixel 2 kernel doesn't have the right config for the ethernet adapter, but the included usb hub works!
<samueldr>
so only a trivial formality
<ashkitten>
yeah so the thing about the wifi module is, like i mentioned, it's somewhat device specific (though i'm not sure how much), but i figured that might be easier to get working in the short term than halium
<samueldr>
without research, I assume it would apply for most devices with the same SoC
<samueldr>
in fact I'll try on oneplus 3 if you succeed
<ashkitten>
that would be great. i'm not 100% sure how to package the module and ky0ko still has to get it working on the other devices first, but we'll let you know
<clever>
samueldr: something else in my recent research, is that ive pretty much confirmed, the roku2 is almost identical to the rpi1
<samueldr>
nice
<clever>
samueldr: its even got the identical ethernet/hub chip
<clever>
the only real difference, is the lack of a gpio header, the IR receiver onboard, and that it has per-device signing keys
<clever>
the roku2 also has onboard wifi
<ashkitten>
samueldr: by the way, would command line arguments be changed when booting a generation from mobile-nixos recovery vs booting directly into the system?
<samueldr>
yes
<samueldr>
_kip_initramfs will be in the cmdline with boot_as_recovery for normal boots
<samueldr>
will be missing for recovery boot
<ashkitten>
okay, that explains why i don't see the _kip_initramfs argument in /proc/cmdline
<ashkitten>
well
<ashkitten>
hm
<samueldr>
not if you didn't boot in recovery mode
<ashkitten>
so the thing is, when i flash the boot image without boot_as_recovery, i see _kip_initramfs in /proc/cmdline
<ashkitten>
but when i flash the one with boot_as_recovery, it always boots to recovery anyway
<samueldr>
that's weird, I wonder if the boot somehow fails and triggers recovery mode, which in our case is the same stage-1 with one conditional
<samueldr>
I wonder if daniel//rf[m] will see the same issue with the change
<ashkitten>
hmm dns resolution fails even as root
<ashkitten>
i'm guessing this will all clear up once we fix the capabilities config
<ashkitten>
not sure what that entails though
<samueldr>
oh I'm so excited
<samueldr>
just tried firefox on the pixel 2 and it's way more than "usable"
<samueldr>
I tried one of the worst experience website (new reddit) and it's just as usable as on my desktop
<ashkitten>
oh that's great
<ashkitten>
firefox has proper touchscreen support right? no fishing around for scrollbars?
<samueldr>
right
<samueldr>
it's not complete, but good enough
<samueldr>
it doesn't respect the touchscreen APIs so a website cannot use things like multi-finger inputs
<samueldr>
but you can actually use it
<ashkitten>
ahh
<ashkitten>
well, better than whatever terminal program this is
<samueldr>
on a sad note, that one usb adapter with ethernet built-in doesn't work, but since it has PD input, and a usb hub, I use it to power the phone AND plug another usb ethernet dongle :3
<ashkitten>
haha
<samueldr>
I don't think this is TSA approved
<ashkitten>
i would be surprised if the tsa has jurisdiction over your home
<samueldr>
right, it's CTSA
<samueldr>
;)
<samueldr>
what I meant is going to the airport with an amazing amount of dongles plugged in the cellphone
<ashkitten>
hah
<ashkitten>
so suspicious~
<ashkitten>
hmmm so what would i have to touch in order to fix capabilities?
<samueldr>
I'm not sure it's capabilities anymore
<samueldr>
got side-tracked in trying networking on my phone
<ashkitten>
what else could it be?
<samueldr>
I don't know, but my research tends to say it can't be disabled since some 2.6 version kernel
<samueldr>
though one thing you could try, change "# CONFIG_SECURITY is not set" to "CONFIG_SECURITY=y"
<samueldr>
I'll boot back my pixel 2 to see if its networking works
<samueldr>
uh, if ping works
<samueldr>
ping works on it
<samueldr>
while there's going to be a bunch of useless differences, maybe diffing marlin and walleye can help
<samueldr>
(after trying to build with CONFIG_SECURITY=y, just in case)
<ashkitten>
a friend says capabilities can't override uid=0
<samueldr>
maybe I missed something, does it work as root or not?
<ashkitten>
ping does not
<samueldr>
if it doesn't as root, then it's not capabilities
<samueldr>
oh
<ashkitten>
curl does
<samueldr>
CONFIG_ANDROID_PARANOID_NETWORK=y
<samueldr>
I would assume this is your issue
<ashkitten>
comment that out?
<ashkitten>
or =n?
<samueldr>
yes, and add " is not set"
<samueldr>
=n is not a thing :/ kernel config files are confusing
<ashkitten>
:/
<samueldr>
I don't know what it does, but it's something postmarketOS tells to disable
<samueldr>
"# CONFIG_XXX is not set" is "=n"
<samueldr>
if it's missing, it'll be answered with the default answer for that question on build
<samueldr>
normally you'd be using make menuconfig, but I'm too dumb to make it work right
<samueldr>
oh, that's nixpkgs (though it applies to nixos)
<ashkitten>
hmph
<ashkitten>
i don't have a good way to reset the channel to that commit i think
<samueldr>
sorry, I don't use channels personally, so I don't know how one would set the channel to a specific commit (that might not have been a channel release)
<ashkitten>
right
<ashkitten>
i don't usually use channels but i haven't integrated this device into my nixos-config repo yet
<samueldr>
you're living on the bleeding edge, I don't have better recommendations yet :)
<ashkitten>
hmm has it been built for nixos-20.03?
<ashkitten>
or i suppose i could drop back to nixos-19.09
<samueldr>
both haven't had aarch64 builds for a small while due to an oopsie
<ashkitten>
yeah i'll just drop back
<ashkitten>
oh, dang
<samueldr>
yeah :/
<samueldr>
I don't really have a good recommendation right now
<ashkitten>
fair enough
orivej has quit [Ping timeout: 240 seconds]
<ashkitten>
samueldr: ky0ko says she thinks she can get my device running a mainline kernel, it'll just need a device tree file, which needs to be appended to the kernel image
<ashkitten>
does mobile-nixos support that in the build?
<samueldr>
I don't think so out of the box
<samueldr>
OEM kernels have Image.gz-dtb target to their makefile for that I think
<samueldr>
I don't know if there would be any problems to simply having a postBuild step cat Image.gz that.dtb > Image.gz-dtb
<samueldr>
I guess not, since that's basically what happens
<ashkitten>
my main concern is having it not require rebuilding the kernel
<ashkitten>
otherwise we could just throw the dtbs in the kernel tree itself
<samueldr>
I don't know if the nixos-built mainline kernel will have all the options you need enabled already
<ashkitten>
oh i see
<samueldr>
though it could
<samueldr>
I kinda assumed it wouldn't be outright mainline, but a mainline-based WIP tree
<samueldr>
the easiest way to get going may be having a mainline-based kernel directory next to the oem kernel directory
<samueldr>
and having a build tailored for the device
<ashkitten>
the point of dtbs is to have a common kernel with just a device specific dtb
<samueldr>
I want to continue allow supporting oem and mainline kernels in parallel
<samueldr>
yep
<clever>
one problem i ran into with some open firmware choices
<clever>
the official firmware puts the firmware at the top of ram
<clever>
but, the top of ram, depends on how much ram you have
<samueldr>
though, the kernel needs to have the right options enabled, and not all options are enabled in the nixos default kernel build
<clever>
and i dont know how the vc4 relocations work
<clever>
my "fix" was to put firmware at bottom of ram instead
<samueldr>
(and for many phones "mainline" is more mainline-flavoured than actually mainline)
<samueldr>
(they will require patches)
<clever>
but!, linux unpacks the zImage to a fixed address
<clever>
which you must set in the KConfig file, at compile time
<clever>
some arm targets override it
<clever>
but, if i require that, you cant use OEM kernels
<clever>
or upstream ones
<clever>
the zImage itself (the decompressor) is relocatable, but it will unpack the internal Image to a static physical address, and then rig up the page tables from there
<clever>
my current plan for that, is to either have linux decide where the firmware lives (allocate and load like DMA stuff), or put a hole in the middle of ram
* clever
heads off to bed
<ky0ko>
the way operating systems like postmarketos, netbsd, alpine, etc. handle this with mainline is to do it the same way as an x86 distribution kernel - enabling all the options, with anything not strictly needed in the core for loading initramfs and more modules - as modules in an initramfs
<ky0ko>
also... i've never seen an arm device with a zImage
<clever>
ky0ko: arm32 hard requires a compressed image, arm64 doesnt support compression
<ky0ko>
they've all been either a plain Image, an Image.gz, xipImage, or uImage
<ky0ko>
including all three of the arm32 devices I am using on my desk right now, for my day job, which is to port linux to arm devices
<ky0ko>
:)
<clever>
last i looked, `make menuconfig` doesnt allow no compression on arm32, and patching it to claim support just breaks the build
<clever>
on a 4.19 kernel
<clever>
ky0ko: what does `file` report for the Image?
<clever>
i can see how xipImage might be different, ive not enabled xip support, since i dont have any rom/nand in the address space
<ashkitten>
hmph, qtwebkit apparently didnt build at that point either
<ashkitten>
er
<ashkitten>
webkitgtk, i mean
<ashkitten>
and my phone crashed trying to build it, even though i got a cooling pad out of the freezer for it!
<clever>
ky0ko: ah, thats uboot stuff, not plain linux
<ky0ko>
our build scripts build a plain uImage, then package it with uboot's mkimage utilities.
<ky0ko>
err, plain Image
<ky0ko>
oh, also for compressed images there's CONFIG_AUTO_ZRELADDR
<ky0ko>
which calculates the load address at runtime and makes that entirely irrelevant
<clever>
i'll have to look into that some more tomorrow, heading to bed now
<ky0ko>
kk, g'night
<ashkitten>
hrngnf i'm struggling so hard to find a revision of nixpkgs that has everything i need built
lovesegfault has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-aarch64
<ashkitten>
okay i give up, i can't find a revision with both firefox and webkitgtk
<ashkitten>
idk why webkitgtk is even needed
<ashkitten>
i guess i can try without the installation-device profile
<ashkitten>
omg, onboard is why webkitgtk is included
<ashkitten>
whyyy
<ashkitten>
because gnome's frickin, yelp thing
<ashkitten>
for the help popup
<ashkitten>
i give up for real now
kcalvinalvinn has joined #nixos-aarch64
kcalvinalvin has quit [Ping timeout: 260 seconds]
kcalvinalvinn has quit [Client Quit]
wavirc22 has quit [Read error: Connection reset by peer]
Aleksejs has quit [Quit: Goodbye]
Aleksejs has joined #nixos-aarch64
zupo has joined #nixos-aarch64
greizgh has quit [*.net *.split]
misuzu has quit [*.net *.split]
{^_^} has quit [*.net *.split]
claudiii has quit [*.net *.split]
misuzu has joined #nixos-aarch64
claudiii has joined #nixos-aarch64
{^_^} has joined #nixos-aarch64
greizgh has joined #nixos-aarch64
<thefloweringash>
maybe I'm slightly pessismistic about this, but my step #1 of trying to get linux to work on my aarch64 laptop was to get a rock64 for building
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<srk>
thefloweringash: hah, not at all, for my armv7 laptop it's almost required to have powerful external builder as well
<thefloweringash>
my laptop is faster than the rock64
<thefloweringash>
I just wanted something to iterate on that wasn't the target device, and didn't feel bad about leaving on for days to build something
<srk>
ah, I see
<srk>
I don't feel bad running this 5W machine 24/7 :D
<srk>
need to actually measure how much power it uses when idle and loaded + display
wavirc22 has joined #nixos-aarch64
FRidh2 has joined #nixos-aarch64
FRidh has quit [Ping timeout: 250 seconds]
vika_nezrimaya has joined #nixos-aarch64
bdju has quit [Quit: Lost terminal]
bdju has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
vika_nezrimaya has quit [Ping timeout: 256 seconds]
v0|d has quit [Ping timeout: 258 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
kai_w has quit [Quit: Konversation terminated!]
dongcarl has quit [Read error: Connection reset by peer]
wavirc22 has quit [Read error: Connection reset by peer]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<samueldr>
yep, working with an aarch64 device works
<samueldr>
ashkitten: you may be interested in the community box... read the README and understand why it can be treated as not trustable
<samueldr>
but, with that said, you can iterate quickly using it, and once you have a known working solution, do it for real
<samueldr>
that's what I do, use it for quick builds, and once I have something I know works, build it on my local pristing aarch64 builder
<ashkitten>
hm
<ashkitten>
i guess that may be better than waiting an indeterminate amount of time for a hydra build of firefox to actually succeed
<ashkitten>
though it'd still take all day at least to build firefox
<samueldr>
hmm, I should setup a system.img for the example on the release.nix built by hydra
<samueldr>
so it'd track complete successful native builds
<ashkitten>
that would be good
<samueldr>
and serve as a trustable image source
<samueldr>
(I'd need to compress it though I think, which means it won't be fastboot flashable directly I think, though meh)
<ashkitten>
as-is i have no easy way to figure out what nixpkgs revision will have both firefox and webkitgtk succeeding
<ashkitten>
both of which are ofc extremely non-trivial to build
<samueldr>
yeah, I haven't had to deal with stage-2 as much as stage-1 previously
<samueldr>
yes :/
<ashkitten>
it's unfortunate that release channels don't block on aarch64 tests failing
<samueldr>
unstable should, on some tests, but not that it matters here
<gchristensen>
let's work for that in 20.09?
<samueldr>
yes
<ashkitten>
that would be fantastic, yes
<samueldr>
now that we can
<samueldr>
(with the fixed eval)
<ashkitten>
these sorts of problems impact nixos a lot more than other distros i think, because we can't just use the last successful build of something due to purity
<ashkitten>
i am concerned why firefox builds are suddenly timing out on hydra though, they were nowhere near 10 hours before
<ashkitten>
what changed?
NickHu1 is now known as NickHu
NickHu has joined #nixos-aarch64
NickHu has quit [Changing host]
NickHu has joined #nixos-aarch64
FRidh2 has quit [Quit: Konversation terminated!]
<qyliss>
Technically not an aarch64 question but close enough I reckon:
<qyliss>
If I have a package that theoretically supports "32-bit ARM", but doesn't get any more specific than that, what do I put in meta.platforms?
<samueldr>
all arms welcome too
<samueldr>
I think it's not what the package theorietically does, but what was tested that's in meta.platforms, no?
<qyliss>
Oh really? I've always operated under the assumption that platforms are, like, supported platforms.
<qyliss>
And then you mark broken if it doesn't work on a platform it's supposed to
<samueldr>
I'm now doubting as I said it
<samueldr>
though good question, I don't think armv6l/armv7l matters much if there's no assembly trickery
<qyliss>
I think my way is much more useful, because otherwise e.g. Darwin users get a bunch of needlessly unsupported packages
<samueldr>
>> The list of Nix platform types on which the package is supported. Hydra builds packages according to the platform specified. If no platform is specified, the package does not have prebuilt binaries. An example is:
<samueldr>
supported upstream or supported by nixpkgs?
<samueldr>
though I do agree with what you mean
<qyliss>
We should clarify that then
<samueldr>
thinking quickly, I'm thinking we may need both
<qyliss>
Anyway, there's lib.systems.doubles.arm, do you think it would be okay to do that in my platforms?
<samueldr>
platforms the package supports, and package *we* support
<samueldr>
oops, platform*
<qyliss>
although, I'd still have to filter for Linux...
<qyliss>
I suppose there are only four different 32-bit ARM linux platforms
<qyliss>
So I can just copy the strings.
<qyliss>
What would "platforms we support" mean?
<qyliss>
If a package builds on a platform, I'd say it's supported.
<samueldr>
that the maintainer / packagers have tested, maybe?
<qyliss>
If it doesn't, but upstream supports that platform, it's meta.broken on that platform.
<samueldr>
there's so much stuff blindly adding platforms.unix
<samueldr>
that does not work on e.g. darwin
<samueldr>
usage of meta.platforms is definitely inconsistent
<samueldr>
and I don't know what's the best way forward
<qyliss>
I think having better FreeBSD support will help with that
<qyliss>
It's much closer to Darwin, and much easier to test on.
<samueldr>
yeah
<samueldr>
or platforms.linux, while it's only x86_64-linux
<qyliss>
I think it's better to be over-broad, too
<samueldr>
I still need to continue combing through the build failures on aarch64 and unlist all those x86_64-only packages
<samueldr>
my peeve with that is that the list of failures on hydra becomes close to useless
<qyliss>
well, they can be fixed
<qyliss>
But I'd still rather somebody got a package than didn't.
<samueldr>
well, they can be fixed if platform is too restrictive
<qyliss>
True, but being over-broad is a better user experience
<samueldr>
platforms is probably overloaded
<samueldr>
not sure what a good solution can be for all use cases
<samueldr>
though yeah, doubles.arm is probably fine for your use case when consdiering your use case of meta.platforms, qyliss
<qyliss>
I did further research and it turns out I need armv7 anyway, lol.
<qyliss>
(for KVM)
<qyliss>
And also, KVM on 32-bit ARM is being dropped from Linux 5.7
<qyliss>
So this may be irrelevant anyway, h.h.
<qyliss>
*hehe
<samueldr>
:|
<qyliss>
Can't say I know why you'd _want_ KVM on 32-bit ARM
<samueldr>
run nixos system tests
<qyliss>
But just noticed that crosvm supports it, and our crosvm package does not.
<samueldr>
there's one 32 bit arm that's not listed in there that exists, not sure what's up with our list, but I assume it's the extra-complicated arm specs
<samueldr>
armv8 is a 32 bit arm
<samueldr>
and there is one, maybe two, 32 bit only armv8 chips
<samueldr>
designs*
<samueldr>
not sure if there are chips with that design
<samueldr>
just to make things more complicated than they need
<ashkitten>
samueldr: how can i run menuconfig for the kernel configs in mobile-nixos?
<samueldr>
[21:45:17] <samueldr> normally you'd be using make menuconfig, but I'm too dumb to make it work right
<samueldr>
[21:45:26] <samueldr> (or don't care enough to look into it)
<samueldr>
:)
<ashkitten>
okay
<samueldr>
last time I tried the issue was that menuconfig was invoked for the running system
<samueldr>
so it screwed with everything aarch64 and set it up for x86_64
<ashkitten>
ah
<samueldr>
I would wager it's something simple to invoke it right, but then it would be nice if using menuconfig automatically saved on top of the existing file
<samueldr>
so I kinda set myself a big hurdle that if I look into it, it should also do the other bits
<ashkitten>
fair
<ashkitten>
hmm is linux-firmware already included in the builds somehow?
<ashkitten>
i'm going to need it for ath10k
<ashkitten>
once i figure out the config option to build in ath10k
<samueldr>
I don't know if it is
Church- has quit [Quit: WeeChat info:version]
<ashkitten>
it would need to be built into the boot image i'm guessing?
<samueldr>
the (I assume mainline) kernel that knows about ath10k, yes, the module, it would be easier
<samueldr>
firmwares and modules can all be handled in the boot image IIRC
<samueldr>
asus-dumo does for firmwares
<ashkitten>
okay
<ashkitten>
i'm not building a mainline kernel btw, just backporting ath10k from linux 4.20
<samueldr>
modules you can see with qemu-x86_64
<samueldr>
nice
<ashkitten>
it will need stuff from linux-firmware but i'm not sure how to put that in the boot image
<samueldr>
ugh, that's so dumb, two params for that helper function :)
<samueldr>
I could have split on / and kept the last element, or there may even be a basename-like function already in nixpkgs
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ashkitten>
hmmmm okay so can i just dump all of linuxFirmwareNonfree in stage-1?
<ashkitten>
mostly just to test
<samueldr>
if boot.img still fits yes
<samueldr>
your main issue is that boot.img has a maximum size
<samueldr>
aw, there's no partitions listing for google-marlin in the repo
<ashkitten>
how does that chromebook know where to load its firmware from?
<samueldr>
the kernel has defaults
<samueldr>
and IIRC /firmware/ is one of them
<ashkitten>
oh i see, this config symlinks it to /lib/firmware
<samueldr>
oh, you're right, /lib/firmware, not /firmware
zupo_ has joined #nixos-aarch64
h0m2 has quit [Quit: WeeChat 2.7.1]
h0m1 has joined #nixos-aarch64
h0m1 has quit [Client Quit]
<ashkitten>
hmmm even though i set CONFIG_ATH10K=y and CONFIG_ATH10K_PCI=y it doesn't say anything about ath10k in the kernel log
h0m1 has joined #nixos-aarch64
<samueldr>
has the device tree been modified accordingly?
<samueldr>
there's no ACPI-like system to describe and query the hardware, well, there is, it's the device tree, which is somehow shipped inside the kernel rather than a static blob inside the device
<ashkitten>
oh, i just did lspci
<ashkitten>
it shows that cnss_wlan_pci is being used for the device
<ashkitten>
but i'm assuming that can't find its firmware
<ashkitten>
i'm going to disable CONFIG_CNSS and hope ath10k loads after that
<ashkitten>
why aren't we building these as loadable modules, anyways?
<samueldr>
partly for removing complexity
<samueldr>
if they were built as modules, each system.img would end up needing to be rebuilt for every devices
<samueldr>
(or some trickery to forward the module files from boot.img)
<ashkitten>
ah
<samueldr>
it's also the default for many defconfig on android
<samueldr>
I'm willing to bet setting =m to a bunch of those will break
<samueldr>
OEM kernels are not good code
<samueldr>
if I disable audio on motorola-addison, to reduce the size of boot.img, I lose all usb gadget mode functionality
<samueldr>
it's a tangled mess of undeclared dependencies
<ashkitten>
oof
<samueldr>
though I'm not against doing it!
<samueldr>
but there's so much to do, this allows me to abstract some complexity in the boot chain
<ashkitten>
well, i'm sure we can do it properly if we have mainline kernels
<samueldr>
I think the *actual* solution will be to kexec to a modular kernel from a minimal kernel
<ashkitten>
ah fair
<samueldr>
or yes, mainline, but not all devices will be mainlinable
<samueldr>
though I'm sure kexec will bring its lot of headaches too :/
<lordcirth_>
You talking about using a Linux kernel as a bootloader?
<lordcirth_>
IIRC Power8/9 systems do that?
<ashkitten>
everyone does it already
<samueldr>
yep, kinda, and yes, everyone does it already
<samueldr>
due to the main complexity of requiring a framebuffer GUI with touch input, all solutions I looked into were not appropriate, requiring as much work as re-doing it :(
<ashkitten>
it doesn't look like ath10k is being built, even though i have the config options set
<samueldr>
it might get disabled by another option, make menuconfig I think would make this obvious
<samueldr>
it *is* a failing in developer experience that make menuconfig isn't being handled nicely in mobile nixos
<ashkitten>
i'm gonna try and get menuconfig working
<ashkitten>
i think it's just ARCH=arm64 menuconfig
<samueldr>
mobile-nixos#108 I just opened an issue tracking it
<samueldr>
though it would be nice if it can be done without having a checkout of the kernel
<ashkitten>
hmph, why isnt ld finding ncurses libraries to link against
<ashkitten>
or idk
<ashkitten>
it's spitting out errors about undefined references when i do make menuconfig
<samueldr>
is it in nativeBuildInputs?
<samueldr>
or uh, how are you using `make menuconfig`? through a bespoke nix-shell in the kernel source tree?
<ashkitten>
i'm in `nix-shell -p gcc ncurses`
<samueldr>
right, so ignore that last comment, it doesn't apply
<ashkitten>
samueldr: apparently qualcomm removed the options for ath10k
<ashkitten>
they're not in menuconfig at all
<samueldr>
doesn't surprise me
<samueldr>
though grep for CONFIG_the_right_name in Kconfig files, maybe it's because an option masks it
<ashkitten>
nope
<ashkitten>
it's in some makefile and some c files but no kconfig
<samueldr>
such a tangled mess :(
<ashkitten>
i guess i've got no choice but to use qualcomm's drivers unless we can mainline this device
<ashkitten>
damn, i made the mistake of being hopeful
<ashkitten>
i can tell that firmware is being loaded because if i don't point the cmdline at /vendor/firmware i get errors about how stuff like venus can't find its firmware
<ashkitten>
but cnss is not logging very much
<ashkitten>
dmesg | grep -i cnss gives me
<ashkitten>
cnss soc:qcom,cnss: for AR6320 segments only will be dumped.
<ashkitten>
it doesn't complain about firmware whether or not i use /vendor/firmware
minicom has quit [Ping timeout: 256 seconds]
minicom has joined #nixos-aarch64
<ashkitten>
ah
<ashkitten>
there's some interesting binaries in /vendor/bin
<ashkitten>
cnss-daemon and cnss_diag specifically
<ashkitten>
i assume i'd need libhybris for that
<ashkitten>
samueldr: you said you have some time scheduled in the future for getting libhybris working, right? or am i misremembering?
<samueldr>
working and well acquainted with yes
<samueldr>
I know that graphics, and most likely wireless and cellular will need it
<ashkitten>
right, yeah
<ashkitten>
can i ask when in the future that is? not tryin to be pushy or anything c:
<samueldr>
I'm not sure I know myself, I have re-prioritized some stuff lately
<samueldr>
but most likely months
<samueldr>
well
<samueldr>
it's at least not at the top of the stack right now
<ashkitten>
alright, lmk if you want me to test anything. i'm gonna stop flailing trying to get wifi working for now, probably flash lineageos so i can have a phone in the meantime honestly
<samueldr>
totally understandable, I'll try to remember
<ashkitten>
i'll try to get a screen replacement for my other pixel xl so i can use that for messing about
zarel_ has quit [Ping timeout: 240 seconds]
zarel has joined #nixos-aarch64
zarel has quit [Read error: Connection reset by peer]