*** amccarthy is now known as Guest1350 | 08:00 | |
*** amccarthy_ is now known as amccarthy | 08: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 inside | 14: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 devicetree | 14: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 partition | 14:46 |
SebastianoGaleazzo[m] | https://github.com/arch-dev/android_device_motorola_exynos9610-common | 14: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.dtsi | 14:49 |
SebastianoGaleazzo[m] | * https://github.com/arch-dev/android_device_motorola_exynos9610-common | 14: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.dtsi | 14:49 |
T42 | <elros34> if /vendor is in dts then yeah add it back together with boot to fstab | 14: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*rpm | 15: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 slot | 15:06 |
T42 | <elros34> yes official devices | 15:06 |
T42 | <elros34> but they use aosp hadk instruction | 15:07 |
T42 | <elros34> I think they may use this _b partitions for some cases | 15: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 correct | 20:25 |
spiiroin | the 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 atm | 20:27 |
spiiroin | assuming 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 |
spiiroin | also, 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 it | 20:33 |
spiiroin | piggz: 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 end | 20:34 |
spiiroin | ... and what you seem to have is: one device that always reports the same type regardless of what is at the other end | 20:34 |
T42 | <adampigg> yeah | 20:34 |
T42 | <adampigg> spiiroin: https://paste.mozilla.org/ct67BsU7#L99 states usb0 doesnt exist, but im sure it does | 20:35 |
spiiroin | you could take udevadm traces for both pc and wall charged and see if there are any property value differences - even transient ones might be useful | 20:35 |
T42 | <adampigg> i will | 20:36 |
spiiroin | @adampigg that "network interface usb0 does not exist" should basically be: test -e /sys/class/net/usb0 && echo EXISTS || echo DOES_NOT | 20:43 |
spiiroin | does mtp work? if it does -> sort of rules out major problems with gadget config -> leaves nw issues | 20:46 |
T42 | <adampigg> Ok, ill check | 20:49 |
T42 | <adampigg> Thx | 20:49 |
T42 | <adampigg> Yes mtp works | 20:49 |
T42 | <adampigg> Its a little slow to start, but does work | 20:50 |
spiiroin | btw, 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 failure | 20:51 |
spiiroin | one thing, connman by default expects developer mode things to happen in rndis0 -> main.conf needs tweaking if usb0 is what is needed | 20:52 |
T42 | <adampigg> Spiiroin yes i have that | 21:27 |
spiiroin | @adampigg and you are sure usb0 is there? and /sys/class/net/usb0 exists & points to sane place? | 23:13 |
spiiroin | one thing one might try: disable interface check and see what happens. by making network_interface_exists() simply return true or stte | 23:14 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!