Sunday, 2022-11-13

*** amccarthy is now known as Guest135008:00
*** amccarthy_ is now known as amccarthy08:00
SebastianoGaleazzo[m]Hi everyone. I've a question regarding fixup-mountpoints step in hadk doc (and hadk-hot doc). In case of treble device with a/b partitions and without dynamic partitions support, fstab files do not have /boot and /vendor mount points (also some others mount points are missing). Do we have to add all missing mount points to fstab or it's just enough adding "vital" partitions like /boot, /vendor? In add to this, if inside14:36
SebastianoGaleazzo[m]fixup-mountpoints partitions have slot suffix _a/_b (like boot_a mapped to sda32, boot_b mapped to sda33), is enough adding generic "/dev/block/bootdevice/by-name/boot       /boot ..." inside fstab or we must choose a specific slot (like _a slot) so it becomes  "/dev/block/bootdevice/by-name/boot_a       /boot ..."?14:36
T42<elros34> are you sure you really missing /vendor? Usually  /boot and /system ( or / for system-as-root) are missing  because they are moved to dts. You can check what is defined in your devicetree14:42
T42<elros34> about suffix, if you have "*by-name/boot" in fstab then in fixup you use same "*by-name/boot" and choose block device which coresponds to _a partition14:46
SebastianoGaleazzo[m]https://github.com/arch-dev/android_device_motorola_exynos9610-common14:49
SebastianoGaleazzo[m]This is the device and in fstab /vendor and /boot aren't present... But vendor mount point is present inside following dts file:14:49
SebastianoGaleazzo[m]https://github.com/LineageOS/android_kernel_motorola_exynos9610/blob/lineage-18.1/arch/arm64/boot/dts/exynos/exynos9609-robusta2_common.dtsi14:49
SebastianoGaleazzo[m] * https://github.com/arch-dev/android_device_motorola_exynos9610-common14:49
SebastianoGaleazzo[m]This is the device  tree and in fstab /vendor and /boot aren't present... But vendor mount point is present inside following dts file:14:49
SebastianoGaleazzo[m]https://github.com/LineageOS/android_kernel_motorola_exynos9610/blob/lineage-18.1/arch/arm64/boot/dts/exynos/exynos9609-robusta2_common.dtsi14:49
T42<elros34> if /vendor is in dts then yeah add it back together with boot to fstab14:53
SebastianoGaleazzo[m]Ok so adding "/dev/block/by-name/bootdevice/boot      /boot ..." in fstab and again "/dev/block/by-name/bootdevice/boot" inside fixup-mountpoints mapped to _a block device (say it sda32) so it becomes "block/bootdevice/by-name/boot sda32" will do the trick? (Same thing for vendor partition?)14:59
T42<elros34> yes that should create correct systemd mount units in droid-hal-device*rpm15:02
SebastianoGaleazzo[m]Ok thank you! The thing which made it not clear to me at least was that in fixup-mountpoints some devices map partitions using suffix to their respective block devices (like pdx213)15:04
SebastianoGaleazzo[m]* (like pdx213) without choosing one specific slot15:06
T42<elros34> yes official devices15:06
T42<elros34> but they use aosp hadk instruction15:07
T42<elros34> I think they may use this _b partitions for some cases15:08
SebastianoGaleazzo[m]Ah ok now it's clear... I didn't know it. Thank you very much!😁15:09
spiiroin@edp_17 You have an interesting case too... my guess would be that there are 3 "charger" devices ps (=wall charger?) / usb (= pc connection) / wireless. of which usb-moded uses the "usb" one - which probably is correct20:25
spiirointhe problem comes from: there are events only from battery device. a possible workaround could be to poll chargers when there are battery events - which is not something that usb mode has logic for atm20:27
spiiroinassuming the trace (where usb has online=1) was taken with phone connection - one thing you might check: do you get ps go online=1 with wall charger?20:29
spiiroinalso, does that affect that mystery battery.online=N value? (wild guess: 1=no charger, 2=ps/wall charger, 4=usb/pc conn, 8=wireless charger)20:30
T42<adampigg> spiiroin: oh, as you are here .... on the ppp, with the new config, im now getting prompts for mode.  if i select dev mode, it up's the interface, but then downs it20:33
spiiroinpiggz: that ^ is also somewhat relevant to your case. the expectation is something like: either there are several "charger devices" which have name/something revealing function (wall charger, usb conn to pc, wireless charger), *or* one device that has type property that changes / what is connected to the other end20:34
spiiroin... and what you seem to have is: one device that always reports the same type regardless of what is at the other end20:34
T42<adampigg> yeah20:34
T42<adampigg> spiiroin: https://paste.mozilla.org/ct67BsU7#L99 states usb0 doesnt exist, but im sure it does20:35
spiiroinyou could take udevadm traces for both pc and wall charged and see if there are any property value differences - even transient ones might be useful20:35
T42<adampigg> i will20:36
spiiroin@adampigg that "network interface usb0 does not exist" should basically be: test -e /sys/class/net/usb0 && echo EXISTS || echo DOES_NOT20:43
spiiroindoes mtp work? if it does -> sort of rules out major problems with gadget config -> leaves nw issues20:46
T42<adampigg> Ok, ill check20:49
T42<adampigg> Thx20:49
T42<adampigg> Yes mtp works20:49
T42<adampigg> Its a little slow to start, but does work20:50
spiiroinbtw, if you run usb moded in debug mode - something like: systemctl stop usb-mode ; usb_mode -TDl - it prints out also successfully executed commands. now I'm guessing it does not even try to because of that interface check failure20:51
spiiroinone thing, connman by default expects developer mode things to happen in rndis0 -> main.conf needs tweaking if usb0 is what is needed20:52
T42<adampigg> Spiiroin yes i have that21:27
spiiroin@adampigg and you are sure usb0 is there? and /sys/class/net/usb0 exists & points to sane place?23:13
spiiroinone thing one might try: disable interface check and see what happens. by making network_interface_exists() simply return true or stte23:14

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!