**** BEGIN LOGGING AT Tue Feb 16 03:00:33 2021 Feb 16 05:13:34 Morning! Feb 16 05:13:56 Tofe: Which image are you using to flash? So I'll make sure I use the exact same one ;) Feb 16 05:32:11 Hmmz and now I have wifi.... Feb 16 05:32:19 Could it be the kernel somehow isn't flashed anymore.... Feb 16 05:32:36 I did fastboot flash boot with my newly created kernel image and all works somehow... Feb 16 05:32:49 And BT too Feb 16 05:33:10 Let me try with the kernel from the archive I flashed yesterday evening Feb 16 05:35:12 Both files you provided above look identical to mine.... Feb 16 05:36:21 Yup kernel from yesterday evening (before overwriting with your files) also work when I do "fastboot flash boot" :S Feb 16 05:37:40 So my preliminary conclusion would be that the issue is in the updater. Since I've only been flashing the whole image the whole time (incorporating all your changes) and not just the kernel. This is actually the first time in some days I use fastboot flash boot to flash a new .fastboot Feb 16 06:24:39 I guess I could confirm that by adding a name in the defconfig and see if that shows up in journal after flashing the .zip Feb 16 06:47:52 Herrie: I'm using tissot_images_V10.0.24.0.PDHMIXM_9.0 (latest stock ROM, from this summer iirc) Feb 16 06:49:10 ok, we'll have a closer look at the updater, it's a good lead Feb 16 06:50:40 Also it's true that when I toy with defconfig, I flash the kernel directly from fastboot, so I wouldn't necessarily see the failure in the updater Feb 16 07:05:17 Tofe: adding name to defconfig and flashing zip would be a good way to confirm or you have another idea? Feb 16 07:09:12 no, that's a good idea; you can also check the defconfig in /proc/defconfig.gz Feb 16 07:13:38 I've seen these custom names added in some defconfigs so I tought that might be the easiest way Feb 16 07:39:33 Yes, and you also have the buildtime hardcoded in the kernel and shown at bootup: "Linux version 4.9.188 (oe-user@oe-host) (gcc version 10.2.0 (GCC)) #1 SMP PREEMPT Wed Feb 10 19:44:49 UTC 2021" (in your last paste, which tends to confirm it was an old kernel) Feb 16 08:18:41 Tofe: OK so I guess we can be pretty sure that it's the updater binary somehow Feb 16 08:18:52 Now how to build a newer one is the question :P Feb 16 08:27:23 I guess it's this one: https://github.com/LineageOS/android_bootable_recovery/tree/lineage-16.0/updater Feb 16 08:31:42 Seems we're pulling in UBPorts version (https://github.com/ubports/halium_bootable_recovery/commits/halium-9.0) via Android manifest (https://github.com/Halium/android/blob/halium-9.0/default.xml#L60) Feb 16 08:39:52 Herrie: don't we flash it with our own script ? Feb 16 08:42:37 Yes, however package_extract_file is inside the updater binary: https://github.com/webOS-ports/android-update-package/blob/master/META-INF/com/google/android/updater-script#L13 Feb 16 08:43:19 https://github.com/ubports/halium_bootable_recovery/blob/halium-9.0/updater/install.cpp#L171 Feb 16 08:43:21 isn't the culprit in run_program("/tmp/ui-print-wrapper.sh", "/tmp/webos_deploy.sh"); ? Feb 16 08:45:37 I would say this line somehow fails: https://github.com/webOS-ports/android-update-package/blob/master/META-INF/com/google/android/updater-script#L27 Feb 16 08:48:18 ah, yes, you're right Feb 16 08:48:37 where does "###BOOT_PARTITION###" come from ?... Feb 16 08:50:50 Yeha grepping in my build directory now ;) Feb 16 08:52:58 tmp-glibc/work/tissot-webos-linux/luneos-dev-package/1.0.3+gitAUTOINC+b69bf00f60-r0/temp/run.do_deploy.204398: sed -i -e s:\#\#\#BOOT_PARTITION\#\#\#:/dev/block/mmcblk0p22:g \ Feb 16 08:53:08 So seems we replace it during build with actual partition Feb 16 08:55:08 well, that failed Feb 16 08:55:33 I can confirm I have this in my script inside zip: package_extract_file("boot.img", "/dev/block/mmcblk0p22"); Feb 16 08:56:23 mmmh. and it's the right partition ? not boot_b ? Feb 16 08:56:33 Trying to find the list of partitions Feb 16 08:56:56 /dev/disks/by-partlabel Feb 16 08:57:49 it's also somewhere in recovery, but I can't remember where Feb 16 08:58:39 This seems to say that 22 = a, 23 = b: https://github.com/chenxiaolong/DualBootPatcher/pull/1056/files#L461 Feb 16 08:59:00 So I guess I was flashing A and booting B :P Feb 16 09:02:42 TWRP tells me current slot = B Feb 16 09:03:46 Seems we're flashing to _a: https://github.com/Tofee/meta-smartphone-1/blob/testing/halium-9.0/meta-xiaomi/recipes-core/initrdscripts/initramfs-scripts-halium/tissot/machine.conf#L2 Feb 16 09:03:59 So I guess it would be good to mention it somewhere to boot from slot A ;) Feb 16 09:06:48 At least mystery solved: User error :P Feb 16 09:39:47 Herrie: yes, we do everything with slot A Feb 16 10:13:25 Tofe: With regards to LiveDisplay, that might be a solution indeed, seems it's LineageOS custom though. So if buillding from AOSP source it might not work? Feb 16 10:31:11 that's possible Feb 16 10:31:43 I'm not really satisfied with the hack, but it just works until we find better Feb 16 10:43:26 Tofe: For sure helps the bootup speed, I'm sure Feb 16 11:02:38 I'm just trying to catch an event that happens after wcnss is fully initialized Feb 16 11:03:11 and that's very late in Android's boot sequence Feb 16 13:48:07 Tofe: Isn't wcnss qcom specific so it won't work on Mediatek etc? Feb 16 13:49:49 Yes seems it's qcom specific Feb 16 13:50:01 Which is fine for our Xiaomi targets, but won't work on the Volla for example Feb 16 13:58:21 And on other targets such as Hammerhead and Tenderloin which would probably use non-qcom wifi such as Broadcom Feb 16 14:16:06 if there's no wcnss, there no problem, probably Feb 16 14:16:12 +is Feb 16 14:22:13 Probably also true ;) Feb 16 14:22:38 Though MTK is a different and even more picky option from what I understood Feb 16 14:23:28 here we are just waiting till livedisplay is running, it's not specific to wcnss Feb 16 14:23:46 "On mtk we need 3 modules And 1 echo, ONLY AFTER CONTAINER START Else reboot" Feb 16 14:23:47 it just happens to solve the wlan issue for qcom devices Feb 16 14:26:07 We're getting in pretty good shape by the looks of it already Feb 16 14:26:18 RIL doesn't really do a whole lot for me though Feb 16 14:26:25 I see oFono coming and going in logs Feb 16 14:26:32 Will debug that a bit later probably Feb 16 15:04:47 If we get ofono working, I'll definitely want to merge the branch into our testing Feb 16 15:42:12 Well oFono seems OK-ish but I don't get modems at my end somehow Feb 16 15:51:31 Tofe: Ah seems our ril_subscription.conf is wrong simply Feb 16 15:53:03 We don't put binder in there yey Feb 16 15:53:05 yet Feb 16 16:03:23 I.e. we don't put the rilbinder yet Feb 16 16:06:37 Retrying with new config Feb 16 16:26:14 Hmmz that doesn't help a whole lot it seems Feb 16 17:35:05 Herrie: we never actually switched any device to rilbinder ? Feb 16 17:35:48 I'll try to find something in the logs, around january 12 when I committed the recipe Feb 16 17:36:17 Tofe: Yeah we did the updates but never switched it seems Feb 16 17:36:50 Not sure why, but anyway most of legwork should've been done already Feb 16 17:36:53 ah, no logs for those days, maybe the bot was down Feb 16 17:37:15 yes, ofono-ril-plugin is the main piece Feb 16 17:39:12 Yeah and I think we enable it in the build as well for ofono but we might need to do something similar to bluebinder in rdepends? Not sure there Feb 16 17:43:50 Herrie: hint: https://github.com/hybris-mobian/ofono-config-ril-binder/blob/bullseye/ril_subscription.conf.binder Feb 16 17:48:26 [gbinder] ERROR: Can't open /dev/hwbinder: Permission denied Feb 16 17:49:34 If I put /dev/hwbinder with 0666 rights, it works Feb 16 17:49:49 Ah OK Feb 16 17:50:15 That's something we might need to fix somewhere Feb 16 17:50:25 Question is where... Feb 16 17:53:06 Seems we might need to update udev rules :) Feb 16 17:53:18 We still have 7.1 ones Feb 16 18:04:00 Tofe: I don't have a Tissot Halium ready here now... Feb 16 18:04:05 But this should do: cat root/ueventd*.rc vendor/ueventd*.rc | grep ^/dev | sed -e 's/^\/dev\///' | awk '{printf "ACTION==\"add\", KERNEL==\"%s\", OWNER=\"%s\", GROUP=\"%s\", MODE=\"%s\"\n",$1,$3,$4,$2}' | sed -e 's/\r//' > 70-tissot.rules Feb 16 18:04:14 Ah I could actually run on device ;) Feb 16 18:06:17 Here's Mer's script for it ;) Feb 16 18:06:18 https://github.com/mer-hybris/droid-hal-device/blob/master/helpers/makeudev Feb 16 18:12:24 Pulled from device: /android/uevent.rc and /android/vendor/uevent,rc: https://paste.ubuntu.com/p/QKvtNDMgqT/ Feb 16 18:13:55 Ah that one is broken :S Feb 16 18:15:33 This is the correct one: https://paste.ubuntu.com/p/bt3Whwhbvp/ Feb 16 18:17:02 https://github.com/Tofee/meta-smartphone-1/pull/9/files Feb 16 18:17:08 That should be the correct ones at least Feb 16 18:19:07 hwbinder and vndbinder are added Feb 16 18:30:10 thanks Feb 16 18:37:43 so I guess we should migrate all our halium-9 device to transport:binder Feb 16 18:38:45 ... and same for bluebinder Feb 16 18:39:19 for the latter, the kernel need to have the BT_VHCI option Feb 16 18:40:54 I'll do the ofono_conf migration Feb 16 18:42:20 are s2, sagit and yggdrasil on halium-9 ? Feb 16 18:42:51 and oxygen? Feb 16 18:44:07 only yggdrasil and sagit it seems Feb 16 18:46:30 done Feb 16 18:53:11 S2 and Oxygen I'll work on Feb 16 18:53:19 Oxygen is somewhere next on my list Feb 16 18:53:26 Should be straight forward Feb 16 19:16:50 Tofe: OK I get a network bar now at least Feb 16 19:16:55 So udev rules + conf work Feb 16 19:17:47 Ofono give me ril_0 and ril_1 for "dbus-send --print-reply --system --dest=org.ofono / org.ofono.Manager.GetModems" Feb 16 19:17:49 So that looks good Feb 16 19:45:24 :) great Feb 16 19:54:38 webos-telephonyd still doesn't really like 2 sims but well Feb 16 19:54:43 THat's nothing too urgent Feb 16 20:05:40 Tofe: You probably want to update the udev rules for Rosy too ;) Feb 16 20:07:08 ah, right Feb 16 20:14:59 You sure the Rosy ones are correct? Feb 16 20:15:03 You have very few... Feb 16 20:16:20 Based on https://github.com/Herrie82/android_device_xiaomi_rosy-2/blob/halium-9.0/rootdir/ueventd.qcom.rc I would expect some more Feb 16 20:18:16 well I just wrote the command from halium's documentation Feb 16 20:18:16 I'll double-check Feb 16 20:18:24 Well 7.1 is not correct it seems ;) Feb 16 20:18:34 Documentation Feb 16 20:20:07 https://docs.halium.org/en/latest/porting/debug-build/udev.html this is incorrect? Feb 16 20:21:13 You're doing it on device or in build dir? Feb 16 20:21:17 on device Feb 16 20:21:47 I used these: cat /android/ueventd*.rc | grep ^/dev | sed -e 's/^\/dev\///' | awk '{printf "ACTION==\"add\", KERNEL==\"%s\", OWNER=\"%s\", GROUP=\"%s\", MODE=\"%s\"\n",$1,$3,$4,$2}' | sed -e 's/\r//' >/media/internal/udev1.txt Feb 16 20:21:52 cat /android/vendor/ueventd*.rc | grep ^/dev | sed -e 's/^\/dev\///' | awk '{printf "ACTION==\"add\", KERNEL==\"%s\", OWNER=\"%s\", GROUP=\"%s\", MODE=\"%s\"\n",$1,$3,$4,$2}' | sed -e 's/\r//' >/media/internal/udev1.txt Feb 16 20:22:08 Well change the file name Feb 16 20:22:15 It could be you only have one file on ROsy Feb 16 20:22:29 You might have only /android/ueventd*.rc Feb 16 20:23:22 commit amended Feb 16 20:25:06 Looks better I guess Feb 16 20:25:13 yes it does Feb 16 20:25:14 Still quite some deletions but well Feb 16 20:25:55 Sent this one as well: https://github.com/Tofee/meta-webos-ports/pull/5/files Feb 16 20:26:11 Still need to add memnotify patches to kernel, but since you fixed the module itself, I don't expect issues there Feb 16 20:26:18 Forces me to be less lazy on those :P Feb 16 20:27:14 Herrie: don't forget the BT_VHCI flag in these kernels Feb 16 20:28:52 https://github.com/Tofee/meta-smartphone-1/commit/a4b1314b870f93fb8db83b3ff662e0e3407a4c21#diff-d7ff825a6194aa5964b0931d03e2d29ff9410ba48a8ae3e75cc8f1d10aa62ee3 basically it's this Feb 16 20:30:01 frankly I'm not sure the 2 other flags are useful, I just kept the same as sailfish example Feb 16 20:34:26 CONFIG_BT_HCIBFUSB = Bluetooth HCI BlueFRITZ! USB driver. This driver provides support for Bluetooth USB devices with AVM interface: AVM BlueFRITZ! USB Feb 16 20:34:42 Fritz! is a "famous" German network equipment manufacturer Feb 16 20:35:13 CONFIG_BT_HCIBTUSB = Bluetooth HCI USB driver. This driver is required if you want to use Bluetooth devices with USB interface. Feb 16 20:35:23 So first one not so much probably, 2nd one useful ;) Feb 16 20:35:49 I added the flags, let me bump SRCREV for kernel as well in your meta-smartphone tree Feb 16 20:40:40 There we go: https://github.com/Tofee/meta-smartphone-1/pull/10 Feb 16 20:41:14 I guess we're ready for a big merge ;) Feb 16 20:41:35 Only thing not covered is this rfkill bit I guess? Feb 16 20:41:43 But that can be done later anyway as well Feb 16 20:46:13 yes, and maybe we can detect rfkill and switch off bluebinder or something like that Feb 16 20:46:39 Herrie: so, let's merge testing/halium-9.0 ? Feb 16 20:46:51 I think we're iso-functional here Feb 16 20:47:30 I'll just review the changes (mostly the earliest ones) to be sure Feb 16 20:48:11 Yeah I think we should be pretty good Feb 16 20:48:20 Needs polishing for sure here and there but well Feb 16 20:48:39 It's pretty close to 7.1 in terms of functionality Feb 16 20:51:59 https://github.com/Tofee/meta-smartphone-1/commit/86c83745880548a26abf662d74bad923d7fafe75 we should be careful with that commit Feb 16 20:52:07 that's the one I had in mind Feb 16 20:55:24 I'll do the 2 PRs, and we'll see. Anyway, in the next steps, I want to merge the work I did with hammerhead-mainline a while ago Feb 16 20:59:49 Tofe: Yeah that commit is tricky Feb 16 20:59:58 https://github.com/shr-distribution/meta-smartphone/pull/122 and https://github.com/webOS-ports/meta-webos-ports/pull/449 now exist Feb 16 21:00:25 For the lxc-config we could make it halium version or android header version specific maybe? Feb 16 21:00:45 Herrie: that's a possibility; but maybe it'll just work Feb 16 21:00:56 Also true Feb 16 21:01:14 I'll see if I can mock up something for good old Tenderloin soon Feb 16 21:02:38 Maybe mako could be switched to halium 9.0, if there's a Lineage image out there Feb 16 21:07:18 Seems there are some builds for Mako Feb 16 21:08:20 For Tenderloin there's some Evervolv build but they changed some standard LOS definitions such as lineage.dependencies into ev.dependencies, so that will be a pain Feb 16 21:14:33 For Mako only found images, no device tree yet Feb 16 21:33:43 well, we'll see Feb 16 21:43:43 Tofe: can you rebase both halium PRs so that they don't have the merge commits inside? Feb 16 22:13:34 JaMa: sure Feb 16 22:13:47 JaMa: it's just an interactive rebase where I take off the merge commits, right? Feb 16 22:15:06 ah no even without interactive, even easier Feb 16 22:15:46 JaMa: done Feb 17 01:43:58 Tofe: thanks, if there were no conflicts resolved in that merge commit, rebase should remove them automatically keeping the git history a bit cleaner and easier to read **** ENDING LOGGING AT Wed Feb 17 02:59:56 2021