| Wizzup | arno11: on the n900 pw question... it's difficult/complicated. what you (imo) really need is the ability to use a serial device with the n900, and (probably) also some external power supply | 00:08 |
|---|---|---|
| Wizzup | arno11: something like this: http://n900.elektranox.org/serial-adapter-gallery.html | 00:09 |
| Wizzup | arno11: then you can boot just the kernel to say init=/bin/sh and probe modules one by one | 00:09 |
| Wizzup | and if you use a lab power supply you can just see the power usage on the display | 00:09 |
| Wizzup | basically what I wrote here: https://github.com/maemo-leste/bugtracker/issues/545#issuecomment-997493915 | 00:10 |
| Wizzup | something like that is what I ran: https://github.com/maemo-leste/bugtracker/issues/545#issuecomment-990214823 | 00:11 |
| Wizzup | the problem is that for these tests, you really probably don't even want the display on, or the keyboard enabled, initially | 00:11 |
| Wizzup | arno11: perhaps more feasible is just trying to identify blockers from a running maemo leste system, but this is also not at all easy unfortunately, we do have a way to print the (sub)system that is blocking idle, and then we can maybe guess the driver | 00:12 |
| Wizzup | tsc2005 blocks idle for one, see https://lists.dyne.org/lurker/message/20211127.145147.a3d42f2e.en.html and https://github.com/maemo-leste/bugtracker/issues/321 | 00:14 |
| gnarface | dunno if it's important or not, but anecdotally, in relation to the specs on the 2 main pinephone models, it should be mentioned for completeness there's also a 3GB version of the regular (allwinner) pinephones' motherboards in the wild | 10:32 |
| gnarface | i just remembered that i'd forgotten to mention it when it came up before | 10:32 |
| Wizzup | gnarface: I think they sell that, right? | 10:55 |
| Wizzup | oh, of the regular pinephone | 10:56 |
| * Wizzup waking up | 10:56 | |
| gnarface | yes, they sell them too, and they sell the boards as a replacement part | 12:18 |
| gnarface | so you can theoretically upgrade a 2GB one to a 3GB one by replacing the mainboard | 12:19 |
| Wizzup | tmlind: if you recall, do you know why in particular having the modem on spi is problematic? | 13:53 |
| Wizzup | uvos and I were looking yesterday and he said the main problem was some big userspace blob on android that is required for it to work at all | 13:54 |
| Wizzup | or he said that was what he recalls anyway | 13:54 |
| uvos | Thats just why looking at the android implementation is only semi-usefull | 14:05 |
| uvos | the qmi over usb mapphones use the same blob | 14:05 |
| uvos | its not related what exactly is bus senstive in the mainline kernel | 14:06 |
| uvos | i have no idea about that | 14:06 |
| tmlind | i think there's a separate qmi driver for spi in the v3.0.8 kernel sources, no idea how much work making that work with the usb qmi in the mainline kernel could be | 14:06 |
| tmlind | if the spi driver just implements a network interface maybe it would be simple | 14:06 |
| tmlind | hmm no i guess the transport is usb underneath qmi.. | 14:06 |
| uvos | the kernel side is super simple on android | 14:06 |
| Wizzup | we found this: https://github.com/STS-Dev-Team/android_kernel_motorola_omap4-common/tree/cm-11.0/drivers/net/spi | 14:06 |
| uvos | tmlind: could you point us to where usb qmi is implemented in mainline? | 14:07 |
| uvos | ie what driver this is | 14:07 |
| tmlind | i think the kernel parts are drivers/usb/class/cdc-wdm.c, not sure though | 14:10 |
| Wizzup | so this file is a network device over spi for the mdm6600 according to the comment in the file: https://github.com/STS-Dev-Team/android_kernel_motorola_omap4-common/blob/cm-11.0/drivers/net/spi/qmi_net.c | 14:11 |
| tmlind | yeah but i think that's not how the mainline kernel does qmi, it's mostly the libqmi doing i believe | 14:13 |
| tmlind | on the kernel side it seems to be cdc_wdm and qmi_wwan modules | 14:16 |
| tmlind | so some kind of spi ethernet device would need to be implemented i think similar to usb ethernet similar to qmi_wwan | 14:18 |
| Wizzup | that doesn't sound too easy but conceptually also perhaps not too hard | 14:24 |
| Wizzup | uvos: so for mz617, | 15:25 |
| Wizzup | oops | 15:25 |
| Wizzup | so for mz617, which partitions can we safely nuke? | 15:25 |
| Wizzup | and can we re-partition somehow? to merge partitions? | 15:25 |
| uvos | Wizzup: we can not modify the partition table in any way its singed and the bootloader relies on the exact table to function anyhow (since it checks partitions for integrety) | 16:26 |
| uvos | im not exactly sure for mz617, it depends on if you want to sacrifice android or not | 16:27 |
| uvos | you can use cache and emtstorage if you need to keep android | 16:27 |
| uvos | and preinstall | 16:28 |
| uvos | if you dont care about android you can also eat system and data | 16:28 |
| uvos | system needs to stay ext3, the bootloader checks this | 16:28 |
| uvos | otherwise it dosent care about these partitions | 16:28 |
| uvos | (its not only ext3 but also the exact fs label and uuid) | 16:29 |
| uvos | data and emtstorage are probubly the only ones of usefull size | 16:31 |
| uvos | for a rootfs that is | 16:31 |
| uvos | we could use a btrfs spaned volume to span all the partitions together | 16:32 |
| uvos | for rootfs maybe | 16:32 |
| uvos | and use system as ext3 for boot | 16:32 |
| uvos | since the 3.0.8 kernel wont be able to mount a btrfs volume to kexec a kernel there | 16:33 |
| Wizzup | uvos: heh yeah @ btrfs | 16:47 |
| Wizzup | that's a good idea | 16:47 |
| uvos | there is also cdrom | 16:51 |
| uvos | its small | 16:51 |
| uvos | but thats where i have kexecboot | 16:51 |
| uvos | iirc | 16:51 |
| uvos | on mz617 | 16:52 |
| Wizzup | and I guess we need to be able to actually format these partitions somehow | 16:58 |
| Wizzup | like, we can't from android, and not from kexecboot | 16:58 |
| Wizzup | also, I think if btrfs uses more than one device, it needs an initramfs unfortunately | 16:58 |
| Wizzup | (as root) | 16:58 |
| Wizzup | hm: https://unix.stackexchange.com/questions/435250/is-it-possible-to-boot-to-a-raid1-btrfs-root-file-with-no-initramfs | 16:59 |
| Wizzup | well this is fine really | 16:59 |
| uvos | we dont want to use raid | 17:14 |
| uvos | we want to use span | 17:14 |
| uvos | raid would be terrible | 17:14 |
| Wizzup | raid0 is span | 17:14 |
| uvos | no | 17:15 |
| uvos | raid0 is striped | 17:15 |
| Wizzup | oh, right | 17:15 |
| Wizzup | ok, you're right | 17:15 |
| Wizzup | but the same principle applies | 17:15 |
| uvos | on a single device this would mean allways doing random reads/writes | 17:15 |
| Wizzup | it needs to find all the devices | 17:15 |
| Wizzup | I don't know if what you describe exists though | 17:16 |
| uvos | yes it dose | 17:16 |
| uvos | btrfs has a spaned mode | 17:16 |
| Wizzup | oh yes | 17:16 |
| Wizzup | ok, -d single | 17:16 |
| Wizzup | maybe also with -m single | 17:17 |
| uvos | yes both | 17:17 |
| Wizzup | so how do we do this in a method that isn't completely a pita | 17:17 |
| uvos | we have an installer | 17:17 |
| uvos | we flash it to system with the contense of boot | 17:18 |
| Wizzup | can we have the user kexec to a usb stick (or microsd on usb stick) which then runs a script that sets this up? | 17:18 |
| uvos | that boots, sets up the partitions | 17:18 |
| Wizzup | ah | 17:18 |
| uvos | we can just use fastboot | 17:18 |
| Wizzup | wait so what is actually on /boot ? | 17:18 |
| Wizzup | or 'boot' rather | 17:18 |
| uvos | the android kernel | 17:18 |
| uvos | that bit needs to stay | 17:18 |
| uvos | ofc | 17:18 |
| uvos | since kexecboot uses it | 17:18 |
| uvos | besides its signed you cant change it anyhow | 17:18 |
| Wizzup | oh, sorry, you said we flash it to system | 17:18 |
| uvos | yes | 17:18 |
| uvos | we flash leste boot + small rootfs to system | 17:19 |
| uvos | the small rootfs sets up everything else | 17:19 |
| Wizzup | ok, so leste boot is kernel, dtb, and some busybox with btrfs-progs | 17:19 |
| uvos | and then prompts the user for wifi to download the real rootfs image to flash to the spaned volume | 17:19 |
| uvos | jup | 17:19 |
| Wizzup | argh, that would require making some ui for wifi | 17:20 |
| uvos | not really | 17:20 |
| Wizzup | can't we have the image on usb or so? | 17:20 |
| uvos | could just be a cli program | 17:20 |
| Wizzup | oh, they would use otg with keyboard? | 17:20 |
| uvos | sure but that requires everyone to have an otg cable | 17:20 |
| uvos | id rather it just pull it via wifi really | 17:20 |
| uvos | Wizzup: we have fbkeyboard | 17:20 |
| Wizzup | what I meant to ask is how do you type in your wifi credentials without a keyboard | 17:20 |
| Wizzup | ok | 17:20 |
| uvos | fbkeyboard works great | 17:21 |
| Wizzup | wifi to mean feels less reliable but if that works, then great | 17:21 |
| Wizzup | to me* | 17:21 |
| uvos | seams the simplest for the user | 17:21 |
| uvos | to me | 17:21 |
| uvos | its also how destop installers work | 17:21 |
| uvos | after all | 17:21 |
| Wizzup | what if we set up usbnet and ssh and just have them rsync | 17:21 |
| uvos | sure | 17:21 |
| uvos | but thats more involved for the user too | 17:21 |
| uvos | since he has to use the cli on his desktop | 17:22 |
| uvos | the wifi method could be fully automated after the fastboot call | 17:22 |
| uvos | besides asking the user for wifi pw via fbkeyboard | 17:22 |
| uvos | wait no | 17:23 |
| uvos | all this is unessecary | 17:23 |
| uvos | you can add to a btrfs span while its mounted | 17:23 |
| uvos | so we can simply flash a leste rootfs to data or emtstorage (need to try if fastboot allows either of those with an unsinged image, but probubly) | 17:24 |
| uvos | and then when leste boots the first time it adds the spans | 17:24 |
| uvos | ether data or emstorage would be big enough for this maneouver | 17:25 |
| Wizzup | leste rootfs needs over a gigabyte | 17:25 |
| Wizzup | unless we also have btrfs compress, then it might be smaller | 17:25 |
| uvos | emstorage is 8 | 17:25 |
| uvos | and data is 4 iirc | 17:25 |
| uvos | so no problemo | 17:25 |
| Wizzup | oh, then we can just dd a leste image indeed | 17:25 |
| uvos | you cant dd | 17:26 |
| Wizzup | well fastboot | 17:26 |
| uvos | but you can ask fastboot nicely | 17:26 |
| uvos | im not sure it will allow it | 17:26 |
| Wizzup | would be worth checking | 17:26 |
| Wizzup | btw, I have a mz617 here that is the 16G version | 17:26 |
| uvos | yeah mine is 16g too | 17:26 |
| Wizzup | I didn't try kexecboot yet (since the utags file has 23 in it, not 16) | 17:26 |
| uvos | i used custom utags for it | 17:27 |
| uvos | it boots from cdrom, as i say | 17:27 |
| Wizzup | ok so we could try to set up a loopback and format it as btrfs, rsync an image (minus boot) and try to use fastboot | 17:27 |
| Wizzup | ok, well, if we can have a utags file for 16G that would be good for users (me :D ) | 17:27 |
| uvos | needs to be exact size | 17:27 |
| uvos | im not sure if the partion table is different | 17:28 |
| uvos | besides different sizes | 17:28 |
| uvos | i think not | 17:28 |
| uvos | so same utags should be fine | 17:28 |
| Wizzup | ok | 17:31 |
| Wizzup | what do you think about btrfs compression? | 17:31 |
| Wizzup | I think it might make sense given the space contraints | 17:31 |
| Wizzup | zstd should be quite good for this | 17:33 |
| uvos | idk omap4 is pretty slow too | 17:36 |
| uvos | on the 32gb variants it seams excessive for sure | 17:37 |
| bencoh | if that thing has a microsd slot I wouldn't bother with compression | 17:38 |
| uvos | they dont | 17:38 |
| bencoh | oh | 17:38 |
| uvos | its 16gb with 12 or so usable | 17:39 |
| Wizzup | zstd is quite fast though | 17:39 |
| uvos | quite tight | 17:39 |
| uvos | or 32gb with 25 or so usable | 17:39 |
| uvos | pretty ok | 17:39 |
| Wizzup | well, let's just get it working and then we can see :) | 17:40 |
| arno11 | Wizzup: for pm stuff: thank you for helping me to understand :) | 18:48 |
| arno11 | freemangordon: i maybe found something interesting about slow shutdown | 18:50 |
| arno11 | event 4 - gpio_keys: client bug: event processing lagging behind 12ms, your system is too slow | 18:52 |
| arno11 | twl4030 keypad client bug: event processing lagging behind 12ms, your system is too slow | 18:52 |
| arno11 | it happens on other distros and seems related to CONFIG_USB_AUTOSUSPEND_DELAY=2 in kernel config | 18:53 |
| arno11 | the delay is too low | 18:54 |
| Wizzup | arno11: yeah so it's not trivial unfortunately, and most of it requires kernel work/dev | 18:58 |
| Wizzup | finding what blocks is just the first step, the second is then to actually fix the drivers | 18:59 |
| arno11 | yup, makes sense | 19:05 |
| freemangordon | arno11: what it is? | 19:23 |
| arno11 | i don't know exactly how it works atm, but increasing the delay could help apparently | 19:30 |
| arno11 | bbl | 19:35 |
| Wizzup | arno11: when you get back, can you share some links on this finding? | 19:39 |
| uvos | arno11: thats harmless really | 19:54 |
| uvos | this is just libinput complaining that it cant keep up with evdev events which is fine and expected on a heavly loaded n900 (like during shutdown) | 19:54 |
| uvos | you can make this happen at any time on d4 to by loading its io alot and then madly swipeing at the ts | 19:55 |
| uvos | i also suspect this sort of thing will be compleatly unavoidable when/if we get off mode working on n900 | 19:56 |
| uvos | considering how long the n900 takes to wake up from ret and off | 19:56 |
| sicelo | this happens even on my i5-4300M + 16GB RAM | 20:02 |
| Wizzup | sicelo: your system is too slow | 20:11 |
| sicelo | yeah, libinput needs amd epyc :-p | 20:16 |
| Wizzup | hey, that's what they tested it on ;) | 20:22 |
| Wizzup | uvos: did you find the time to look at the derive tree from atrix2? | 20:22 |
| Wizzup | s/derive/device/ | 20:22 |
| arno11 | Wizzup: https://bugzilla.redhat.com/show_bug.cgi?id=1891286 | 20:29 |
| arno11 | https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4709 | 20:29 |
| arno11 | https://bbs.archlinux.org/viewtopic.php?id=262690 | 20:31 |
| arno11 | https://askubuntu.com/questions/1292691/why-am-i-getting-event-processing-lagging-behind-msg-in-ubuntu-20-10 | 20:34 |
| arno11 | apologies guys, didn't see last msgs :P | 20:37 |
| humanbeta | How to take screenshot with Pinephone? | 20:59 |
| humanbeta | I tested Qshot for screenshot, but I don't know how to save..it has Save As-button and I can write filename, but what then? | 21:03 |
| humanbeta | The Meamo 5 keyboard shortcut (volume down+power button) for screenshot doesn't work. | 21:09 |
| humanbeta | also ctrl+shift+p doesn't work. | 21:22 |
| uvos | Wizzup: i lost the script for the signal map | 21:22 |
| uvos | _again_ since sre also lost his script | 21:23 |
| uvos | but i just rewrote it | 21:23 |
| uvos | https://github.com/IMbackK/unsignalmap | 21:25 |
| uvos | now that wont happen again | 21:25 |
| Wizzup | heh | 21:26 |
| Wizzup | uvos: https://github.com/tmlind/dtb-signalmap not sure if helpful, you probably had this already and referred just to the python part | 21:26 |
| uvos | heh | 21:27 |
| uvos | no thats the same thing | 21:27 |
| uvos | anyhow | 21:27 |
| uvos | should have guesed tmlid also had a version of this | 21:27 |
| uvos | Wizzup: anyhow its here now https://uvos.xyz/maserati/stockinfo | 21:28 |
| Wizzup | it seems to have less entries than xt875 | 21:31 |
| uvos | 1 modem | 21:31 |
| Wizzup | pardon my ignorance but which are the modem ones | 21:33 |
| Wizzup | ipc_* ? | 21:33 |
| uvos | very likely this is omap4->omap2 comms | 21:34 |
| uvos | inter processor comunication baseband proc wake | 21:34 |
| uvos | and | 21:34 |
| uvos | inter processor comunication application proc wake | 21:34 |
| uvos | etc | 21:34 |
| uvos | whats wierd | 21:34 |
| uvos | is the missing cpcap-* | 21:34 |
| uvos | also lm3532_reset is the same | 21:35 |
| uvos | which is annoying | 21:35 |
| uvos | since that means 1 it exists and 2 the gpio is the same | 21:35 |
| uvos | but its not working | 21:35 |
| uvos | maybe its on another bus | 21:35 |
| uvos | no its not bus1devices = "lm3532"; | 21:36 |
| uvos | huh | 21:36 |
| uvos | no idea why its not working | 21:36 |
| uvos | regulator different maybe | 21:37 |
| uvos | hmm not it must be getting power otherwise the backlight would simply be off | 21:37 |
| Wizzup | maybe this is silly but you're sure the python unsignalmap does the right thing? | 21:41 |
| Wizzup | (just in case that might explain the diff) | 21:41 |
| Wizzup | also, I think this confirms that the modem is not on usb, eh | 21:41 |
| uvos | it decodes the bionic signalmap the same as the file | 21:42 |
| uvos | also the signalmap for edison is simply mutch shorter (raw bytes) | 21:42 |
| uvos | also the gpios of edison are all the same as bionic (when listed) | 21:43 |
| uvos | so | 21:43 |
| uvos | im pretty sure | 21:43 |
| uvos | at least the accelrometer not working is no suprise | 21:49 |
| uvos | it uses lis3dh like d4 not kxtf9 like bionic | 21:49 |
| uvos | but it also has the magnetometer like bionic, unlike d4/3 | 21:50 |
| uvos | thats sad kxtf9 is the better chip | 21:50 |
| uvos | Wizzup: modem is spi | 21:52 |
| uvos | Modem@0 type = <0x2400>; is the same as xt910 but unlike xt875/xt894 so 0x2400 is probubly the spi variant | 21:53 |
| Wizzup | yeah :( | 21:54 |
| uvos | yeah usb mbm6600 is 0x1e0001 across the board | 21:54 |
| uvos | so besides the spi modem | 21:57 |
| uvos | the only unsolved mystery is why whats wrong with lm3532 | 21:57 |
| uvos | probubly the same thing thats wrong with lm3532 on the d3 so would be good to find out | 21:58 |
| uvos | otherwise its just copy bionic dts, replace the accel node with the one from d4 and add the shutter button to the omap matrix and were done here | 21:59 |
| Wizzup | oh, right, the d3 also had backlight problems | 22:00 |
| uvos | same exact thing | 22:00 |
| Wizzup | yeah | 22:00 |
| uvos | dts entries and gpios are the same as on d4 | 22:00 |
| uvos | but writeing there dosent do anything | 22:00 |
| Wizzup | wrt modem on spi, this also means currently we don't get an audio card, can we get it without modem? | 22:01 |
| uvos | sure we can | 22:01 |
| uvos | you just have to eject it from the dts for me/mb865 | 22:02 |
| Wizzup | right | 22:02 |
| uvos | me865 seams exatcly the same btw | 22:02 |
| uvos | same dts same signal map to the byte | 22:02 |
| Wizzup | yeah was just about to ask :) | 22:04 |
| uvos | me865 is just the retail non-att branded version | 22:05 |
| uvos | its not a huge suprise its the same device | 22:05 |
| uvos | presumably only the modem firmware differs | 22:05 |
| uvos | if that | 22:05 |
| Wizzup | mhm | 22:06 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!