<sphalerite>
hrm. Learning, once again, that SD cards are slow.
<sphalerite>
mobile-nixos people: what's your "workflow" for using nixos? I'm considering putting my pinephone in my nixops deployment
<sphalerite>
Or does the installed system also need mobile-nixos-specific config?
<sphalerite>
(as opposed to the boot partition)
h0m2 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
alp has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
v0|d has quit [Ping timeout: 256 seconds]
alp has quit [Ping timeout: 244 seconds]
orivej has quit [Ping timeout: 256 seconds]
Acou_Bass has quit [Ping timeout: 264 seconds]
Acou_Bass has joined #nixos-aarch64
<sphalerite>
pinephone people: is it safe to do whatever with the eMMC partition layout, or is u-boot hiding there somewhere?
zupo has joined #nixos-aarch64
<Ke>
why would mobile nixos be different from desktop?
<Ke>
well I guess the lack of nixos.org downloadable installer, but you can create your own once and just use that
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sphalerite>
Ke: there's a bunch of modules that are part of mobile-nixos but not of nixos itself, and I'm wondering if they affect the system as well or only the boot partition
zupo has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 256 seconds]
Acou_Bass has joined #nixos-aarch64
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
Acou_Bass has quit [Ping timeout: 260 seconds]
zupo has quit [Client Quit]
orivej has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
toon has joined #nixos-aarch64
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 240 seconds]
<samueldr>
sphalerite: I don't know if I count as a mobile nixos person, but I found that on the site
<samueldr>
noneucat has a branch of Nixpkgs with some phosh stuff updated; haven't taken time to look into it
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Acou_Bass has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sphalerite>
samueldr: trying to revive mobile-nixos-on-xiaomi-tissot, and I'm having some trouble with getting USB networking or adb happening so that I can actually access the device from outside
<sphalerite>
bit of a chicken-and-egg problem since I rely on adb or networking to get into the device :D
<sphalerite>
any suggestions?
<sphalerite>
actually for a start I could say what exactly I'm doing :D I've got mobile.adbd.enable = true; and mobile.boot.stage-1.networking.enable = true;
<sphalerite>
but it doesn't seem to be registering as a USB device at all (nothing pops up in the host laptop's journal)
<sphalerite>
maybe I can rip them from my non-broken daily driver tissot
<sphalerite>
adb root + adb pull /firmware/image = love
<sphalerite>
hm, I'm setting `mobile.boot.stage-1.fail.delay = 1200;` so that I have some time to poke around with adb, but it seems to kill adbd pretty quickly and shut down regardless…
<sphalerite>
ok, mobile.boot.stage-1.shell.shellOnFail = true; works better even though I don't have access to that shell :D
<samueldr>
IIRC there is a bug with the failure
<samueldr>
with the delay*
<samueldr>
I saw that recently
<samueldr>
anyway I want to re-do that bit so that by default it waits for a prompt from the display
<samueldr>
since now I can
<sphalerite>
where is the feature -> function name mapping defined for android_usb? I can only find it for gadgetfs
<samueldr>
there is none
<samueldr>
android_usb is universal
<samueldr>
while gadgetfs the exact driver for a specific feature may vary
<samueldr>
sphalerite: anything specific you wanted to do?
<sphalerite>
trying to get the mac address set
<sphalerite>
my first attempt was poking System.run("ip", "link", "set", @interface, "address", @mac) into dhcpd-task.rb, but that seems not to work for $some_reason
<sphalerite>
the weird thing is, it works if I do it from the adb shell
<samueldr>
and I figure you don't have the log for that run to know why it failed?
<sphalerite>
no :D is the log saved somewhere? I checked the journal
<samueldr>
it should be if the boot is completed to the system
<samueldr>
(I think)
<sphalerite>
it failed on my first attempt because I put it before the address setting with ifconfig, because the mac address can only be set when the link is down
<sphalerite>
but actually it seems to have worked this time round
<sphalerite>
sort of
<samueldr>
is `ip` part of busybox?
<sphalerite>
aah it seems the changed address doesn't get preserved
<sphalerite>
yes
<samueldr>
good
<samueldr>
because we can't really add anything major to the initrd, it's already just over the line for motorola-addison
<sphalerite>
make busybox slimmer? :D
<sphalerite>
hrm
<samueldr>
that's not even where most of the "cruft" comes from
<sphalerite>
64 bytes from fe80::dcad:beff:feef:cafe%enp7s0f3u1u2: icmp_seq=4 ttl=64 time=0.346 ms (DUP!)
<sphalerite>
at least it does work better than I thought
<samueldr>
it mostly comes from systemd/udevd; which we can probably get fixed somehow
<samueldr>
still, 3.18 is "finished", but you can at least harmonize with other platforms with an ALS
<samueldr>
(though it may be that android_usb's rndis parts are common with the other gadget mode driver)
<sphalerite>
right so I've found what I'm looking for: /sys/class/android_usb/android0/f_rndis/ethaddr — but I think it should be written to before the rndis function is enabled…
<samueldr>
possible
<sphalerite>
and I'm not sure where that should fit in with the current module structure :/
<samueldr>
I'm checking out the tree for tissot to look at it
<samueldr>
blah, this might take a while
<samueldr>
forgot how long a linux git clone could take
<samueldr>
looking through addison's kernel tree, another 3.18, I see two gadget functions with that printed
<samueldr>
"using random %s ethernet address\n", "self"
<samueldr>
u_ether and u_qc_ether
<samueldr>
qc is most likely for qualcomm
<samueldr>
both end up being transcluded via #include "u_...ether.c" in drivers/usb/gadget/android.c
<sphalerite>
do you know about git's --reference option?
<samueldr>
you could identify whether it's qc or not with some of the lines beforehand
<samueldr>
you can `adb cat /sys/fs/pstore/console-ramoops > some-file.log` if it helps you
<sphalerite>
oh dear
<samueldr>
note that in some instances, on some devices, I've sometime had issues getting the ramoops to stick
<sphalerite>
it seems to contain thousands of attempts at printing call traces
<samueldr>
IIRC things would get ugly with wcnss if the files were not where they were expected to be
<sphalerite>
not sure wcnss is to blame here
<sphalerite>
the kernel ring buffer seems to be getting absolutely hammered anyway
<samueldr>
ah
<samueldr>
that's not too surprising
<sphalerite>
but what this did tell me is that it seems to be a watchdog that triggers the reboot, and that's (empirically) only after the attempt to enable wcnss
<sphalerite>
(one of very few which seem to be intact and not interleaved with more of themselves or buffer overruns)
<sphalerite>
oooh this is a warning about a slow interrupt handler?
<samueldr>
that's what it looks like
<samueldr>
I thought you meant just some logging that someone added to the kernel
<samueldr>
some OEM kernels are full of useless logging
<sphalerite>
no no
<sphalerite>
that wouldn't spam as badly :p
<samueldr>
you'd be surprised
<sphalerite>
at least, not as far as I can tell from your patches
<sphalerite>
not thousands of lines per second
<samueldr>
yeah, not that much
<sphalerite>
oooh I see
<sphalerite>
because this is doing memory management stuff in the irq context
<sphalerite>
which is a Bad Thing™
<samueldr>
check if the ALS kernel has that too
<samueldr>
AFAIUI the ALS kernels end up shedding bad OEM code because mainline changes forces them to
<sphalerite>
huh, even though it's based on an ancient stable?
<samueldr>
it's also *probably* transparent, the way the changes are done is explained with transparency
<samueldr>
hm?
<samueldr>
oh, right
<samueldr>
you have a device with a kernel upgrade
<samueldr>
forgot about that
<sphalerite>
do I? x)
<samueldr>
`no you don't
<samueldr>
3.18 too
<samueldr>
ALS is updated to the latest of the 3.18 series
<sphalerite>
ah right
<sphalerite>
hm, lineageos uses a 4.x kernel though
<samueldr>
but devices/xiaomi-tissot/kernel/default.nix advertises as 3.18
<sphalerite>
yeah that's because I had difficulty upgrading to a more recent lineageos kernel
<samueldr>
so yes, you do
<samueldr>
but going with ALS shouldn't be an issue considering you're already running 3.18
<sphalerite>
fair enough
<samueldr>
it should be a drop-in replaccement
<samueldr>
for the 4.x kernel, you might need to follow the lineageos upgrade/installation instructions, assuming you might not have
<samueldr>
because it might be that the bootloader or firmware bits are important
<samueldr>
another option is that the kernel needs another compiler to be selected
<samueldr>
right now it's using gcc6, but even newer devices require gcc49
<samueldr>
(or clang)
<sphalerite>
oh wow
<samueldr>
like, xiaomi-lavender's kernel builds fine under gcc6, but will fail to boot
<samueldr>
but build it with gcc49 and it's fine
<samueldr>
which, to me, is hecking weird
<samueldr>
this _might_ be related to it wanting clang, never tried with clang since at the time clang wouldn't work
cole-h has quit [Quit: Goodbye]
<samueldr>
Linux version 4.9.188-perf+ (buildkite-agent@lineage-buildkite) (Android (6052599 based on r353983c1) clang version 9.0.3 (https://android.googlesource.com/toolchain/clang 745b335211bb9eadfa6aa6301f84715cee4b37c5) (https://android.googlesource.com/toolchain/llvm 31c3f8c4ae6cc980405a3b90e7e88db00249eba5) (based on LLVM 9.0.3svn)) #1 SMP PREEMPT Tue Aug 4 02:41:19 UTC 2020
<samueldr>
tissot's lineageos kernel is built with clang
<samueldr>
to me this says that it might not boot even if it builds with gcc6
<samueldr>
because who knows what kind of weird thing makes this a sad reality
<sphalerite>
well… not as drop-in as I hoped. It fails to build
<sphalerite>
and I need to go to bed
<samueldr>
hah, to next time I guess
<sphalerite>
I suspect it's a fairly easy fix, but yeah bed
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
tilpner has quit [Max SendQ exceeded]
tilpner_ has quit [Remote host closed the connection]
tilpner_ has joined #nixos-aarch64
tilpner_ has quit [Remote host closed the connection]
tilpner_ has joined #nixos-aarch64
tilpner_ has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
quinn has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
tilpner_ is now known as tilpner
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
alp has quit [Ping timeout: 244 seconds]
toon has quit [Ping timeout: 240 seconds]
toon has joined #nixos-aarch64
cript0nauta has quit [Remote host closed the connection]
cript0nauta has joined #nixos-aarch64
cript0nauta has quit [Remote host closed the connection]