h0m1 has quit [Ping timeout: 244 seconds]
h0m1 has joined #nixos-aarch64
knerten2 has joined #nixos-aarch64
matias_ is now known as cript0nauta
knerten1 has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 256 seconds]
quinn has quit [Quit: ZNC 1.7.5 - https://znc.in]
orivej has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
<ashkitten> samueldr: btw do you have any idea where to look for kernel sources for the cosmo?
quinn has joined #nixos-aarch64
<ashkitten> hmm i found https://github.com/dguidipc/cosmo-android-kernel but it doesn't look like it's been updated since february and the kernel of the latest build is from june
<ashkitten> this looks promising
mla has quit [Remote host closed the connection]
mla has joined #nixos-aarch64
<samueldr> ashkitten: no I don't and yeah you found probably what I would have sent you
<samueldr> the dguidipc I believe is the official source
<samueldr> which means that POO they, too, are not updating their kernel sources on time
<samueldr> ugh, kernel source without history
<samueldr> what a user-hostile thing
<samueldr> yeah, that gemian fork is likely not bad, probably good
<samueldr> notkit is involved with non-android-linu on android devices
<samueldr> non-android-linux*
orivej has quit [Ping timeout: 256 seconds]
quinn has quit [Quit: ZNC 1.7.5 - https://znc.in]
<ashkitten> samueldr: should i name the device planet-cosmo?
<samueldr> planet- is the right prefix
<samueldr> (that's what postmarketOS uses for the gemini pda)
<samueldr> I don't know if it should be cosmo or cosmocommunicator
<ashkitten> does it affect much?
<samueldr> nothing really
<ashkitten> okay
<ashkitten> just gonna go with planet-cosmo for now, name = "Cosmo Communicator" manufacturer = "Planet Computers"
<samueldr> like generally the name would be the same as projects such as lineageos or twrp uses, e.g. geminipda https://twrp.me/planet/planetgeminipda.html
<samueldr> but AFAICT neither have named it!
<samueldr> ashkitten: sounds good
<samueldr> and at worst it's a trivial change
<ashkitten> ye
<ashkitten> hmm not sure about all the other stuff tbh
<samueldr> right
<ashkitten> the soc is mediatek... something
<ashkitten> screen is 1920x1080? i think?
<samueldr> it's always fun finding those facts :)
<samueldr> you have to unpackbootimg a boot.img
<samueldr> which could be TWRP, or stock boot.img
<samueldr> (or find the info elsewhere, but I don't know where really)
<samueldr> so, for the SoC
<ashkitten> 2160x1080
<samueldr> >> The Cosmo is based on the powerful Mediatek P70
<samueldr> then I put Mediatek P70 on a search engine
<samueldr> and hope to find the MTxxyy name
<samueldr> doesn't look like it's trivially (first result) findable
<samueldr> though there's luck!
<samueldr> we can get the info out of the defconfig for the device
<samueldr> I know it's the defconfig since it's the only one that's been edited in that repo
<ashkitten> mt6771
<samueldr> yeah
<samueldr> so it looks like planet computers haven't even had their BSP customized to change the name from the default defconfig name
<samueldr> (or whoever does the software part for them?)
<samueldr> k71v1_64 looks like is a generic mediatek platform base according to an online search
<samueldr> that phone also uses that name heh https://www.gsmarena.com/vivo_y17-9666.php
<samueldr> weird though they're not on the same SoC
<samueldr> weird, I have no idea why the defconfig name is the same then
<ashkitten> they don't even change the usb vid/pid it looks like
<ashkitten> Bus 001 Device 020: ID 0e8d:201c MediaTek Inc.
<samueldr> VIDs/PIDs is a bit more complex AFAIUI
<samueldr> as in, maybe it's part of their contract so they don't have to buy their owns
<samueldr> and anyway getting their owns would mean they need their own driver variants without real need
<samueldr> (AFAIUI for windows... though I might be wrong?)
<ashkitten> so i've got a twrp.img
<ashkitten> what is unpackbootimg?
<samueldr> (my mice just died)
<samueldr> my mouse*
<samueldr> it's the inverse of mkbootimg ;)
<samueldr> it's a tool that unpacks boot imgs
<samueldr> sorry
<samueldr> it's a tool that's available if you nix-shell /path/to/mobile-nixos/shell.nix
<samueldr> it'll be in that shell
<ashkitten> btw samueldr you may be interested in http://support.planetcom.co.uk/index.php/Linux_for_Cosmo
<samueldr> >> Remember that you can install TWRP only on the EMPTY_RECOVERY_BOOT_2 partition
<samueldr> weird!
<ashkitten> ugh, kernel/default.nix looks long
<samueldr> you started off of which device?
<samueldr> I can chunk the explanation in more abstract pieces
<ashkitten> xiaomi-begonia, i guess
<samueldr> good
<samueldr> since there's a thing in there that's unique for it that you will likely need
<samueldr> it patchelfs some bad binary garbage that you should ask planet computers to provide the GPL source of
* samueldr adds to TODO list, to ask for it from xiaomi
<samueldr> the installTargets and postInstall are likely not needing any change
<samueldr> so really, what you'll have to change is (1) the source (2) the version [so it matches, the nixos kernel builder will fail otherwise] (3) the patches
<ashkitten> where is the kernel version?
<samueldr> out of (3) you're likely to need the mtkfb one, center-logo too, fix-bootloader-cmdline has already been done for you
<samueldr> in the Makefile
<ashkitten> right i see
<samueldr> though, you're left with figuring out a config file for the kernel
<samueldr> two weeks ago I would have said "uuuuh, try to extract it from a boot.img file, using binwalk and some ungodly amount of manual steps, and maybe it won't be there"
<samueldr> since then I figured out a better way
<samueldr> if you replace it with the (incomplete configuration) defconfig file https://github.com/gemian/cosmo-linux-kernel-4.4/blob/master/arch/arm64/configs/k71v1_64_bsp_defconfig
<samueldr> you can use `bin/kernel-normalize-config planet-cosmo` to generate it
<samueldr> (btw, all of this assumes nixpkgs-unstable, adjust NIX_PATH accordingly)
<ashkitten> $ bin/kernel-normalize-config planet-cosmo
<ashkitten> trace: ***********************************
<ashkitten> trace: * Evaluating device: planet-cosmo *
<ashkitten> trace: ***********************************
<ashkitten> error: The option `mobile.system.system' is used but not defined.
<ashkitten> (use '--show-trace' to show detailed location information)
<ashkitten> sh: line 1: /bin/nconf: No such file or directory
<samueldr> hmm, that's bad, it tries to continue if the eval fails :)
<clever> ,locate bin nconf
<samueldr> clever: forget about it
<samueldr> it's in *that* kernel
<{^_^}> Couldn't find in any packages
<samueldr> ashkitten: you'll need to add he mediatek entry in the hardware-mediatek.nix module
<samueldr> ashkitten: it should be relatively straight-forward
<ashkitten> did that
<samueldr> oh
<ashkitten> it was complaining about that before, but i'm not sure what it's complaining about now
<samueldr> ashkitten: just validating, both the option and the config?
<ashkitten> oh
<ashkitten> right, not the config
<samueldr> it is unknown yet if you need the fb-refresher quirk, so you can add it for now and once you have something booting you can try without it
<ashkitten> think it needs fb-refresher?
<ashkitten> ah yeah
<samueldr> because in my (limited) experience with mediatek, you're at a coin toss situation
<samueldr> the older kernel for the x018d needed it, but not the newer one for the begonia
<samueldr> if you don't need it but have it active, it does nothing harmful other than banging the framebuffer a number of time per second
<samueldr> if you need it and don't have it, well, either no display at all or only the first frame
<ashkitten> i'm gonna go do some other stuff for a bit, i'll get back to this after
<samueldr> no worries
<samueldr> I'm likely not going to be there for much longer tonight
<samueldr> but anyway I see some open questions
<samueldr> like how to install it
<samueldr> you could install it using their custom os thingy
<ashkitten> i'm not sure whether or not fastboot boot/flash works
<samueldr> but it seems SOO inconvenient!
<samueldr> fastboot boot I'd bet on another coin toss
<ashkitten> i'll try it out when i do
<samueldr> begonia's doesn't actually boot
<samueldr> I don't recall for x018d
<samueldr> fastboot flash is more likely
<samueldr> and probably much more convenient
<samueldr> and you're likely able to flash onto those other partitions
<samueldr> which... I find it weird that they didn't just do a fastboot thing
<samueldr> hmm, I can see one reason: resizing the partition
<samueldr> I used unpackbootimg on the TWRP image to see https://gist.github.com/samueldr/fd79437f5d5672a1b6dc0a2d7d14f1b6
<samueldr> ramdis, second, tags offsets don't match, but otherwise begonia's values are good
<samueldr> looks like the kernel commandline is okay to keep as-is, the verity option will not be needed
<samueldr> and it turns out their TWRP build does have the kernel config built-in https://gist.github.com/237d79352aca84b857e9d3f3c05bd4c2
<samueldr> and this one from their linux-cosmo-boot https://gist.github.com/b346611ff69c42846ed39f72075b2996
<ashkitten> samueldr: alright, i'm back
<ashkitten> looks like the rgb order patch doesn't work
<ashkitten> er, doesn't apply
<samueldr> look at the patch, it should be trivial to do the same on your tree :)
<samueldr> (or maybe the x018d variant applies)
<samueldr> unless mediatek somehow made the 4.4 kernel different for no reason, it literally changes an #if 0 to an #if 1
<ashkitten> looks like it's applied to drivers/misc/mediatek/video/mt6785/videox/mtkfb.c
<samueldr> (are you adept with git and git format-patch? that's how I produce those)
<ashkitten> so probably just a different file
<ashkitten> do i need the patch to just see if it boots?
<samueldr> nope
<ashkitten> cool
<samueldr> you'll have the red and blue components swapped
<samueldr> that's it
<ashkitten> how do i build the boot image again?
<samueldr> nix-build --argstr device planet-cosmo -A build.android-bootimg # IIRC
<samueldr> (typing this off the cuff)
<ashkitten> ty
<samueldr> ensure it builds against nixpkgs-unstable :) won't work against 20.03
<samueldr> that's the #if that needs to be changed
<ashkitten> my nixpkgs is based on nixos-unstable
<samueldr> it literally says where in a pixel the colours are
<samueldr> goo
<samueldr> good*
<ashkitten> (a few weeks out of date i think)
<ashkitten> error: attribute 'targetPrefix' missing, at /home/ash/Projects/mobile-nixos/overlay/mruby-builder/mruby/default.nix:157:43
<samueldr> ooh, you might be in a bad place, depending if few fews or many fews
<samueldr> ooh. right...
<samueldr> *that* fix
<samueldr> -I nixpkgs=channel:nixos-unstable
<ashkitten> alright
<samueldr> I couldn't figure a way to make it compatible with that much older of a nixpkgs because that pkg-config change is... quite invasive
<ashkitten> i'll update my nixpkgs soon, it's just a bit of a hassle to do it often
<ashkitten> yeah np
<samueldr> I understand
<ashkitten> (i also still have a bunch of uncommitted changes to my nixos-config and i don't want to update my nixpkgs until those are committed)
<ashkitten> kernel is building
<samueldr> oh, hm, there's also something that's totally undocumented, and really in need to be
<samueldr> you're likely going to need to enable some kernel configs
<samueldr> if you use `bin/menuconfig planet-cosmo` it'll put you into nconfig, which is basically another menuconfig the kernel has
<samueldr> or if you prefer, though it's not user-friendly, you can edit the config.aarch64 file directly
<samueldr> note that removing an option does not disable it! note that =n is not the reverse of =y!
<samueldr> the reverse of =y is # CONFIG_X_Y_Z is not set
<samueldr> I usually `nvim -d ../other-device/kernel/config.aarch64 kernel/config.aarch64` and I'm sloppy :(
<ashkitten> do i need KERNEL_GZIP, etc?
<samueldr> I believe one of them is already in your config
<samueldr> probably GZIP
<samueldr> or maybe not?
<samueldr> enable GZIP but the others I guess are not required?
<samueldr> and even then I have two devices without GZPI enabled
* samueldr makes it all up on the fly
<ashkitten> ugh
<ashkitten> ../drivers/input/touchscreen/mediatek/NT36xxx/nt36xxx_mp_ctrlram.c:1829:5: error: 'snprintf' size argument is too large; destination buffer has size 32, but size argument is 4096 [-Werror,-Wfortify-source]
<ashkitten> i have no idea how to debug kernel build errors
<samueldr> >> Linux version 4.4.146 (dguidi@supernova) (Android (4691093 based on r316199) clang version 6.0.2
<samueldr> using strings on their kernel I can see it's build using an older clang
<samueldr> I would try using either gcc6 ot gcc49 kernel builder
<ashkitten> ty
cole-h has quit [Quit: Goodbye]
<ashkitten> heh
<samueldr> it *may* be necessary
<ashkitten> let's see how gcc6 goes
<samueldr> yeah
<samueldr> somehow those kernel "developers" can make it that a kernel successfully builds, but does not boot with a given compiler
<ashkitten> 60% of the time it works every time
<ashkitten> no good with gcc6
<ashkitten> trying with your makefile patch thingy
<ashkitten> /nix/store/ypag3bh7y7i15xf24zihr343wi6x5i6g-bash-4.4-p23/bin/bash: ../tools/dct/DrvGen.py: /usr/bin/python: bad interpreter: No such file or directory
<ashkitten> augh
<samueldr> oh
<samueldr> you'll need python2 (most likely) and to patchshebangs into tools
<samueldr> so it almost looks like a cross between x018d and begonia for mediatek quirks!
<ashkitten> neato
FRidh has joined #nixos-aarch64
stiell has quit [Ping timeout: 246 seconds]
<ashkitten> hmmm
<ashkitten> how can i list partitions with fastboot
<samueldr> maybe an unlisted oem getvar comman
<samueldr> command*
<samueldr> getvar partition-layout
<samueldr> well
<samueldr> fastboot oem getvar partition-layout
<samueldr> otherwise, they should matche the partname (as in gpt partname, not filesystem labels)
<samueldr> but I'm not sure about that
<ashkitten> i love how the install scripts just dd to a partition
<samueldr> it's basically what happens when fastboot flashes
<ashkitten> not sure how to discover the gpt partname though
<samueldr> if you can boot TWRP they are under /dev/block
<samueldr> it's not the usual udev scheme
<samueldr> TWRP should have adb enabled
<ashkitten> is that /dev/block/by-name?
<samueldr> I think yes
<ashkitten> from android:
<ashkitten> Cosmo_Communicator:/ $ ls /dev/block/by-name/
<ashkitten> EMPTY_NORMAL_BOOT_3 boot cam_vpu1 dtbo frp linux logo metadata nvram persist protect2 scp2 spmfw system userdata
<ashkitten> EMPTY_NORMAL_BOOT_4 boot_para cam_vpu2 expdb gz1 lk md1dsp nvcfg otp proinfo recovery sec1 sspm_1 tee1 vendor
<ashkitten> EMPTY_RECOVERY_BOOT_2 cache cam_vpu3 flashinfo gz2 lk2 md1img nvdata para protect1 scp1 seccfg sspm_2 tee2
<ashkitten> lots of partitions here
<ashkitten> but they look like they match the thingy
<samueldr> heh
<samueldr> so it's likely fastboot flash EMPTY_NORMAL_BOOT_3
<ashkitten> i'm not sure where the $1 argument in the install sh comes from
stiell has joined #nixos-aarch64
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-aarch64
<samueldr> from the built-in recovery
<ashkitten> hmph
<ashkitten> doesn't seem to be working with fastboot
<samueldr> as in fastboot doesn't want to flash EMPTY_NORMAL_BOOT_3?
<samueldr> bummer if so, but you could still `dd` over adb I guess
<ashkitten> tried to flash twrp.img to EMPTY_RECOVERY_BOOT_2 and then boot into that from the selection, it just hangs and reboots
<ashkitten> yeah but i don't have root
<ashkitten> i'll do it tomorrow
<samueldr> if you have TWRP you have root :)
<ashkitten> when i have an sdcard
<ashkitten> so i can install twrp
<samueldr> another fine option
<samueldr> ooh
<samueldr> I see now
<samueldr> you haven't run TWRP yet
<ashkitten> yes
<samueldr> since you need the sd card for their installer thingamajig, right?
<ashkitten> yes
stiell has quit [Ping timeout: 246 seconds]
<ashkitten> and fastboot doesn't seem to be very functional on this device
<samueldr> it's been becoming less and less useful
<samueldr> across the board
<ashkitten> rip
<ashkitten> okay, i'll table this for tomorrow then
stiell has joined #nixos-aarch64
stiell has quit [Ping timeout: 256 seconds]
stiell has joined #nixos-aarch64
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 244 seconds]
<gmr> what is the x018d? is that ashkitten 's device?
<ashkitten> no, some other mtk device
<gmr> mt6771
<gmr> * mt6771 ? er sorry i'm backreading blind(ly) - cool thanks i'm following now. i'm generally avoiding such devices (for reasons of santiy) anyways nowadays
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp_ has joined #nixos-aarch64
alp_ is now known as alp
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
knerten2 has quit [Ping timeout: 264 seconds]
bennofs_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
bennofs has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 272 seconds]
orivej_ has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
mvnetbiz_ has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 256 seconds]
Thra11 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 240 seconds]
Thra11 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 260 seconds]
Thra11 has joined #nixos-aarch64
FRidh has quit [Ping timeout: 258 seconds]
FRidh has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 256 seconds]
Thra11 has joined #nixos-aarch64
dongcarl has quit [Read error: Connection reset by peer]
dongcarl has joined #nixos-aarch64
alp has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 264 seconds]
Thra11 has quit [Ping timeout: 240 seconds]
ryantrinkle has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-aarch64
alp has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
rsa has quit [Quit: leaving]
pinkieval has quit [Read error: Connection reset by peer]
pinkieval has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
ingenieroariel has joined #nixos-aarch64
ingenieroariel is now known as Guest56561
alp has quit [Ping timeout: 260 seconds]
Guest56561 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
ingenieroariel_ has joined #nixos-aarch64
ingenieroariel_ has quit [Client Quit]
ingenieroariel_ has joined #nixos-aarch64
ingenieroariel_ has quit [Client Quit]
ingenieroariel_ has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
ingenieroariel_ has quit [Client Quit]
ingenieroariel_ has joined #nixos-aarch64
ingenieroariel_ has quit [Remote host closed the connection]
ingenieroariel_ has joined #nixos-aarch64
alp has joined #nixos-aarch64
ingenieroariel_ has quit [Client Quit]
ingenieroariel_ has joined #nixos-aarch64
ingenieroariel_ has quit [Remote host closed the connection]
DigitalKiwi has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
kgtzy[m] has joined #nixos-aarch64
alp has quit [Ping timeout: 260 seconds]
<ashkitten> acquired microsd
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<ashkitten> grrrr
<ashkitten> i dont see a way to use the keyboard with dvorak properly using their provided keymap
<ashkitten> they have a custom keyboard model in the linux system
<ashkitten> but idk how to make it actually do anything
<ashkitten> er
<ashkitten> i'm sure it works for qwerty layout
<ashkitten> but the dvorak variant on top of that does bad things
<ashkitten> like the s key is -
<ashkitten> btw samueldr the twrp image straight up does not boot
<ashkitten> rooted android boots, gemian boots
<ashkitten> twrp has a green bar on the side and then reboots (presumably a panic)
<ashkitten> (and flashes with fastboot, huh)
<samueldr> wow, what a joke
<ashkitten> so i guess uh..
<samueldr> so I guess that means you can flash mobile nixos with fastboot?
<ashkitten> yeah, presumably
<ashkitten> and now i have twrp to grab a ramoops
<samueldr> that's going to be helpful :)
<samueldr> with xiaomi-begonia I never missed a ramoops
<samueldr> compared to I don't remember which qualcomm device, where ramoops sometimes weren't there
<samueldr> gmr: just in case, x018d is an asus phone, "ZenFone Max Plus (M1)" (a mouthful), which too uses a mediatek cpu
<ashkitten> woah i got a sad face screen
<ashkitten> it was blue
<samueldr> good news, it boots to the initrd!
<samueldr> R and B are swapped
<ashkitten> right
<samueldr> some kind of purplish baby blue?
<ashkitten> looked light
<samueldr> yeah
<samueldr> most likely something failed at init, you're gonna have "init killed" as a panic reason in the ramoops I bet
<ashkitten> gonna need path to ramoops again
<samueldr> (though no init logs as it is because ugh, I had issues)
<samueldr> /sys/fs/pstore/... something in there
<ashkitten> ty
<samueldr> you can search for the string "Kernel panic"
<samueldr> generally there will be only one
<samueldr> [ 4.058774] -(3)[1:loader]Kernel panic - not syncing: Attempted to kill init! exitcode=0x00006300
<samueldr> 0x6300 encodes the exit status of the thing that failed, too, but I forget how
<ashkitten> hmmmm
<ashkitten> not sure what this is good for, for me
<samueldr> you might want to set CONFIG_PANIC_TIMEOUT to some value like 5, 10, 20
<samueldr> so you'd be able to read the error on the sad face
<ashkitten> oh cool
<samueldr> or 0 to wait forever
<DigitalKiwi> [nix-shell:~]$ which cabal
<DigitalKiwi> /nix/store/lzzm0ghp5k5qsw7kmgfv1304cbk6w8pm-cabal-install-3.2.0.0/bin/cabal[nix-shell:~]$ which ghc/nix/store/5xbnrdw7fy5ckay8l0sb7jb7gakyqqkp-ghc-8.8.3/bin/ghc
<samueldr> this is something I need to get into some useful guidelines
<samueldr> and harmonize between builds
<DigitalKiwi> hot off the presses! get it now on your local friendly community server
<DigitalKiwi> nix-shell -p ghc cabal-install -I nixpkgs=channel:nixos-unstable
<DigitalKiwi> it only took half a day to build
<ashkitten> gotta rebuild the entire kernel to change the panic timeout config ;-;
<ashkitten> i feel like that should be a kernel param thing
<samueldr> it might be
<samueldr> panic= [KNL] Kernel behaviour on panic: delay <timeout>
<samueldr> timeout > 0: seconds before rebooting
<samueldr> timeout < 0: reboot immediately
<samueldr> timeout = 0: wait forever
<samueldr> Format: <timeout>
<samueldr> (sorry for the long paste)
<samueldr> so... uh... it is
<ashkitten> hah
<samueldr> I guess the guidance could be 5 for fast~ish reboots on panic, in the kernel settings, and configurable for the build for development to 0
<ashkitten> oh right
<ashkitten> so the cosmo's screen is landscape
<ashkitten> (not actually according to the phone)
<ashkitten> but we should orient mobile-nixos to match that
<ashkitten> No such file or directory - open /sys/class/android_usb/android0/iProduct (Error: ENOENT)
<ashkitten> is what the sad phone screen says
<ashkitten> it still only shows for a second, even though i flashed the build with 20s panic timeout
<ashkitten> guessing that has to do with mobile.usb.mode
<samueldr> yes
<samueldr> oh, hmm... maybe the one on the command line somehow doesn't apply?
<samueldr> or maybe mediatek has a custom path with bad changes
<ashkitten> samueldr: i did it in the kernel config lol
<samueldr> ah
<samueldr> uh
<samueldr> OH
<samueldr> the phone adds to the kernel command line
<samueldr> how much can we bet that it adds a panic= value?
<samueldr> I don't remember if it appends or prepends
<ashkitten> dunno
<ashkitten> lemme check twrp
<ashkitten> can get the actual cmdline from there
<samueldr> yeah
<ashkitten> no panic cmdline
<samueldr> aw
<samueldr> at least you know it's the usb thing
<ashkitten> entire cmdline is this
<ashkitten> console=tty0 console=ttyS0,921600n1 vmalloc=496M slub_max_order=0 slub_debug=OFZPU androidboot.hardware=mt6771 firmware_class.path=/vendor/firmware loop.max_part=7 has_battery_removed=0 androidboot.verifiedbootstate=green androidboot.bootpartition=TWRP androidboot.verifiedbootstate=green androidboot.bootpartition=TWRP root=/dev/ram androidboot.veritymode=enforcing bootopt=64S3,32N2,64N2
<ashkitten> androidboot.selinux=permissive buildvariant=eng androidboot.meta_log_disable=0 androidboot.dtbo_idx=0 printk.disable_uart=1 bootprof.pl_t=5200 bootprof.lk_t=3576 bootprof.logo_t=2547 boot_reason=4 androidboot.serialno=ZSIRKFGU59OR9P6H androidboot.bootreason=kernel_panic gpt=1 usb2jtag_mode=0 mrdump_ddrsv=yes mrdump_cb=0x11e000,0x2000
<ashkitten> maybe that will be useful to reference
<samueldr> your serial number shows :/
<ashkitten> welp
<samueldr> (though AFAIK there is nothing bad in showing it)
<samueldr> (it's not like it was your IMEI)
<ashkitten> i forgot phones just have numbers that if leaked can be dangerous :/
<ashkitten> what an awful concept
<samueldr> yeah
<ashkitten> how do i figure out the correct mobile.usb.mode
<samueldr> since it can't do android_usb, it's gadgetfs
<samueldr> you could look under /sys for the right paths
<samueldr> (in TWRP)
<ashkitten> what paths am i looking for?
<samueldr> I don't recall :/
<ashkitten> also it doesn't look like CONFIG_USB_GADGETFS is enabled in the kernel
<ashkitten> not sure if that's actually relevant
<samueldr> yeah it should be
<samueldr> it's gadgetfs it's 99.99% sure
<samueldr> oh right
<samueldr> the mountpoint for configfs is variable
<samueldr> so it might not be where I set it
<ashkitten> huh
<ashkitten> so do i need to enable the kernel option?
<samueldr> oh, you said is *doesn't look like* it's enabled
<samueldr> I misread you
<samueldr> CONFIG_USB_GADGETFS being unset is fine
<samueldr> CONFIG_USB_GADGET is the one that is important
<ashkitten> ah
<samueldr> (I had to check on other devices)
<ashkitten> anyway looks like there's no configfs mount in twrp at least
<samueldr> hmm
<samueldr> I wonder if there's another scheme in-between for mediatek devices
<samueldr> TWRP surely uses some kind of usb gadgetery
<samueldr> or else you couldn't adb into it
<samueldr> though maybe the configfs mount is implicit
<ashkitten> maybe
<ashkitten> !!!
<ashkitten> mobile nixos splash!
<samueldr> it's now likely stuck looking for NIXOS_SYSTEM
<ashkitten> right
<ashkitten> i'll put that on the microsd
* samueldr can't wait to dig himself out of the yak shave mountain
<ashkitten> since i don't need that anymore
<samueldr> you're gonna download the rootfs from hydra, right?
<ashkitten> yeah
<samueldr> neat
<samueldr> note that you most likely still need to get that patch goinf for RGBA/BGRA order :)
<ashkitten> right
<ashkitten> i'll do that once i verify it boots
<ashkitten> i think i need to clean some stuff out of the kernel config as well
<ashkitten> android networking is enabled
<ashkitten> firefox, why did you think it was a good idea to open rootfs.zst as a text file in browser instead of downloading :/
<ashkitten> ha
<samueldr> see, I'm sloppy as heck too with that
<samueldr> that's why I need to make a tool that checks those
<ashkitten> hmmm wonder if i can use fastboot to flash the sdcard while it's in the device
<samueldr> I'd say unlikely
<samueldr> though, you have the source for it!
<ashkitten> yeah, heh
<samueldr> it's relatively unusual to have the source for it available
<samueldr> like, you have the downstream Qualcomm aboot or abl available, but not often the OEM's version
<ashkitten> neat
<ashkitten> *glances at free -h on twrp*
<samueldr> it's not "sd card vs. internal storage", but actually two different internal storage schemes
<samueldr> not specific to the device, but generic to fastboot
<ashkitten> i'm pushing the system image to a tmpfs on twrp because i have enough ram :p
<samueldr> heh
<ashkitten> whaaa
<ashkitten> it didn't work?
<ashkitten> no space left on device...
<ashkitten> oh, tmpfs has a size limit by default
<ashkitten> meh, lemme use 90% of my ram with this system image
<ashkitten> would be smaller if i could decompress on the fly but twrp doesn't have a zstd binary
<samueldr> tmpfs defaults to ram/2
<samueldr> dd over adb
<ashkitten> can you?
<samueldr> yes
<ashkitten> oh, duh
<ashkitten> pipes
<samueldr> see the device-specific notes :)
<samueldr> you'd probably want to of= on the right device though
<ashkitten> yeah
<ashkitten> that'd be /dev/mmcblk1
<ashkitten> er
<ashkitten> /dev/block
<samueldr> maybe you want to do this on a partition?
<samueldr> though I guess linux doesn't really care
<ashkitten> oh
<ashkitten> sure, i guess
<ashkitten> i forgot it's not a full disk image
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
<ashkitten> the colors actually look correct, samueldr
<ashkitten> problem: looks like the display is not initialized correctly and there is a bar on the left side of the screen, not sure exactly what's coloring it
<ashkitten> and the touchscreen is initialized wrong
<ashkitten> the touchscreen doesn't match the display at all
<samueldr> might be that gemian's kernel does something
<samueldr> (for the colors)
<ashkitten> it's like it's rotated 90 degrees
<samueldr> ah
<samueldr> that's "trivial" to fix, but there is no mechanism
<ashkitten> hm
<samueldr> uh
<samueldr> no
<samueldr> that's not it
<samueldr> that's for the display
alp has joined #nixos-aarch64
<ashkitten> well, the display should be upright according to the keyboard
<ashkitten> it seems like the touchscreen is in the correct orientation
<ashkitten> but the display itself is not
<samueldr> yeah
<samueldr> weird, I thought I had something for that because of that chuwi device
<samueldr> but I only see a calibration thing
<samueldr> xinput --map-to-output DEVICE DISPLAYNAME
<samueldr> I don't know with a framebuffer driver like this one how it will act though
<ashkitten> hmm the screen also does not turn off when the lid is closed
<ashkitten> but we can look at that after
<samueldr> that's... something I haven't really looked at for any devices :)
<samueldr> nothing about suspend states or similar
<ashkitten> there's also some awful whine noise in nixos
<samueldr> eww
<ashkitten> bit terrifying lol
<samueldr> so yeah, once you're on the desktop of that image, you're in uncharted territory for us both :)
<ashkitten> haha
<ashkitten> i'm glad i got it to boot to desktop, i need to start my day a bit so i'll be back to this in a while
<samueldr> no problems
<ashkitten> a hint i'd follow is treeki's twrp, since it seems to have correct display and no whine :p
<samueldr> oh, yeah, forgot ninji_ had a twrp
<ashkitten> that's the one i used :p
<samueldr> it's using a prebuilt kernel
<ashkitten> oh dear
* samueldr checks for a config file
<samueldr> btw, once you have a kernel(.gz), ungzip it, and run binwalk -e
<samueldr> if it has a kernel config embedded (e.g. /proc/config.gz, or other IKCONFIG options) it will be extracted
<samueldr> D00730: Linux make config build file, ASCII text
<ashkitten> hoping that whine is not harmful, but honestly i bet it's just the display
<samueldr> could be the backlight for the display too
<ashkitten> yeah
<samueldr> /sys/class/leds (iirc) there should be lcd-backlight
<samueldr> echo 20 | sudo tee /sys/class/leds/lcd-backlight/brightness
<samueldr> or something like that
<ashkitten> it was definitely at full power
<samueldr> most devices start at full power
<samueldr> did it change the whine?
<ashkitten> i haven't checked
<samueldr> ah
<ashkitten> i was building the kernel with that config
alp has quit [Ping timeout: 244 seconds]
<ashkitten> it didn't like that
<ashkitten> dunno why
<ashkitten> ramoops doesn't seem to give me much useful
<samueldr> can you share it?
<samueldr> that's unlikely to be the oops from that boot as it panics at 3 seconds in
Thra11 has quit [Ping timeout: 258 seconds]
<samueldr> hmm... not good
<samueldr> OH, I completely forgot about mediatek uart cables until I remembered just now that fl*kli had one
<samueldr> oof, I'm a bit spooped by the use of a USB A to C adapter to do this
<ashkitten> yeah
<samueldr> though anyone can figure out the proper type-c pinout using that
<samueldr> I'll try with the micro usb first, I hope I have the right adapters around
<samueldr> oh, I guess the micro to type-c adapters could do too
<ashkitten> oh weird, the whine isn't there now
<ashkitten> i didn't do anything
<samueldr> I didn't either
<ashkitten> i would hope so
<samueldr> maybe it's a couple circumstances that need to happen, and it happens even with other systems
<ashkitten> hmmm
<ashkitten> also still annoyed about the keyboard layout
<ashkitten> i can't use the built-in keyboard rn because of that
<ashkitten> even on gemian
<samueldr> yeah :/
<samueldr> I don't recall how I came to the conclusion before you got yours that they had done a goof
<samueldr> and made "their own layout"
<ashkitten> probably here
<samueldr> like, when configured as qwerty, is it qwerty as expected?
<ashkitten> sure but it doesn't match the keycaps
<samueldr> does it match the keycap location on the qwerty edition?
<ashkitten> yes
<samueldr> if so it's less worse than I thought
<samueldr> ah, less bad
<samueldr> (still not good)
<ashkitten> i honestly wish they'd made their own keyboard firmware though, and set the layout in that
<samueldr> I wonder, short of doing a udev remaping, what could be done
<ashkitten> because right now it just does not work
<ashkitten> honestly thinking about bugging them to see if i can get them to ship me qwerty keycaps, but they probably wouldn't
<ashkitten> and i'd probably have a hell of a time swapping them on anyway
julm has quit [Quit: reboot]
<ashkitten> this phone has so many problems :/
<ashkitten> maybe i can pull the custom layout from android or smth
julm has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
<DigitalKiwi> why's this happening
<DigitalKiwi> t184256: can i do a nix-collect-garbage on nix-on-droid or does it break it
<DigitalKiwi> t184256: i did something that broke it and i'm not sure if it was that or something else
<t184256> DigitalKiwi: in theory, it should be fine
<t184256> In practice, I've done that a dozen times and it was OK
<samueldr> DigitalKiwi: looks like it's something like sha256 = ""; which is not a good hash
<samueldr> though I don't grok what's going on in your case
<DigitalKiwi> samueldr: yeah but like how's it getting there from nixpkgs
<DigitalKiwi> and it works on other places :?
alp has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
alunduil has quit [Ping timeout: 246 seconds]
chessai has quit [Ping timeout: 240 seconds]
TheNumb has quit [Ping timeout: 246 seconds]
chessai has joined #nixos-aarch64
alunduil has joined #nixos-aarch64
cstrahan has quit [Ping timeout: 244 seconds]
dsal has quit [Ping timeout: 260 seconds]
angerman has quit [Ping timeout: 244 seconds]
feepo has quit [Ping timeout: 244 seconds]
chessai has quit [Ping timeout: 244 seconds]
prusnak has quit [Ping timeout: 272 seconds]
pkral has quit [Ping timeout: 260 seconds]
taktoa[c] has quit [Ping timeout: 260 seconds]
alunduil has quit [Ping timeout: 272 seconds]
jackdk has quit [Ping timeout: 272 seconds]
elvishjerricco has quit [Ping timeout: 240 seconds]
davidtwco has quit [Ping timeout: 260 seconds]
NekomimiScience has quit [Ping timeout: 244 seconds]
c00w has quit [Ping timeout: 265 seconds]
claudiii_ has quit [Ping timeout: 272 seconds]
blackriversoftwa has quit [Ping timeout: 272 seconds]
tdeo has joined #nixos-aarch64