Day 27
(I may have skipped Day 26, it was filled with droidmedia debugging, I might come back to the notes,)
Let’s build the Lineage 19.1 kernel. Maybe it has better wifi, maybe video decoding.
Merging it gives hundreds of conflicts.
So I choose to just cherry-pick my commits
[HABUILD_SDK]$ git checkout -b hybris-19.1 origin/lineage-19.1
[HABUILD_SDK]$ git cherry-pick 9a1ba77f8b2b…eb682b239d51
[HABUILD_SDK]$ make -j$(nproc --all) hybris-hal libui_compat_layer
Ramdump on first boot…
And I tought I had everything prepared… for example, the /lib/modules already had the folder with the new kernel modules copied.
And init_enter_debug was created to stop and see if telnet works before any other crash.
As usual, there are no /sys/fs/pstore logs
Grepping thorugh this kernel there is no asusdebug.c either.
I can:
1, build a recovery-only Lineage img, to ease my debugging
2. enable back some of the kernel arguments I commented out (as they were redundant with vendor_boot)
3. run mer kernel checker to see if I merged some configs wrongly
4. build a new vendor_img too (that has dtb.img inside) and/or a dtbo.img
That last option seems the most promising - the crash is so early it could be from dtb.
[HABUILD_SDK]$ make -j$(nproc --all) vendorbootimage dtboimage
Hmm the dtbo and dtb imgs are not re-generated.
And unpacking the vendor_boot.img looks like I need to do step 2 avove too, too few kernel arguments now:)
But how to make dtb.img and dtbo.img?
Well, make dtboimage dtbimage doesn’t do anything, so I remove the targets and run them again.
The dtbo.img seems to be of the same size as before, but the dtb one is very different.
Chances are vendor_boot is the only one I need to re-flash…
$ diff <(xxd /mnt/datas/sake/backup/dtbo.img) <(xxd dtbo.img)
181273,181277c181273,181277
< 002c4180: 0000 0000 6474 626f 7633 f305 4129 686a ....dtbov3..A)hj
< 002c4190: 2f2d ff64 5fef f3b7 b93d b05b 2a0a 6ff4 /-.d_....=.[*.o.
< 002c41a0: 0b60 cb3d 7aa5 0c0b b30a 5973 f9a6 5b3b .`.=z.....Ys..[;
< 002c41b0: d500 7bc8 523e 4ba5 fd36 285b 6efe 88e3 ..{.R>K..6([n...
< 002c41c0: 3217 01dd fe97 9780 0000 0000 0000 0000 2...............
---
> 002c4180: 0000 0000 6474 626f 1d1e c038 232a c9e7 ....dtbo...8#*..
> 002c4190: dc03 e709 562b a5de 3483 103d f747 2e7f ....V+..4..=.G..
> 002c41a0: 3230 372f 67d2 d26f e429 b093 704d f895 207/g..o.)..pM..
> 002c41b0: 81c9 ec7e 1725 13ad 8e2f 1f66 4ef0 96fe ...~.%.../.fN...
> 002c41c0: e368 515b 0003 114f 0000 0000 0000 0000 .hQ[...O........
$ sudo fastboot flash vendor_boot vendor_boot.img
$ sudo fastboot boot hybris-recovery.img
Stuck at logo, more than 60 seconds.
Let’s just flash it instead of booting it, and also flash dtbo.
No good result.
Actually, even worse, what I think it is “stuck at logo” before is actually instant reboot to bootloader with the logo stuck on screen.
I look at the (still downloadable) vendor_boot and boot images for lineage 19.1 and surprise! they use image header v4, and gzip compression,
So I am alone with lz4 and header 3…?
Let’s give this kernel one more try: to split the parameters between vendor_boot and hybris-boot images, I selectively comment out some for one build and the others for the other build.
Neither does this idea fly.
So there is something in this kernel that crashes, in those …35661 commits.
Using meld to diff
/mnt/datas/sake/lineage/kernel/asus/sm8350
/mnt/datas/sake/hadk/kernel/asus/sm8350
Maybe I need to update BOARD_VENDOR_KERNEL_MODULES_LOAD in BoardConfig.mk ?
Wait, what do these options did?
CONFIG_POWER_RESET_QCOM_DOWNLOAD_MODE=y
CONFIG_POWER_RESET_QCOM_DOWNLOAD_MODE_DEFAULT=y # this is now gone
CONFIG_POWER_RESET_QCOM_REBOOT_REASON=y
Woow Qualcomm download mode enabled by default - CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT - - kernelconfig.io
This is not the same config, but the description reminds me of Ramdump mode.
It may mean that disabling all of the above might disable ramdump screen (and get a regular reboot;)
Some power-saving new flags:
CONFIG_QCOM_RIMPS=y
lead me to
# Increase sleep duration (seconds) during IMPS
# 0 implies no periodic wake up from IMPS. Periodic wakeup is
# unnecessary if Idle Scan is disabled.
gImpsModSleepTime=0
Maybe I should try those on my current kernel.
Some GKI stuff, CONFIG_MSM_PERFORMANCE_QGKI is now explicitely enabled.
“new” entry
# CONFIG_PSTORE_DEFLATE_COMPRESS is not set
I am interesting in anything pstore related of course.
But the kernel diff is huge and inscrutinable…
…
Let’s search more about QCOM download mode.
A tool named QPST is mentioned on xda for example.
However, the tool is used with some params I don’t understand to recover a bricked device…
I am more interesting in downloading the error log.
Like Linaro / qcomlt / qdl · GitLab
Let’s flash vendor_boot from before (lineage 18.1)
qdl is available in Archlinux AUR
But it is not usable without mbn files.
QXDM5 / QCAT / PCAT / QDART / QRCT … scr*w it, closed tools to inspect my device.
Let’s disable those DOWNLOAD configs and reflash, see if it still calls bootloader ramdump…
Noope, still see the ramdump on whatever bug I’m stepping on and I don’t have telnet to run dmesg…
Disabling some more (CONFIG_QCOM_MINIDUMP, CONFIG_QCOM_MICRODUMP) but still ramdump screen ffs.
I found this dtsi def, msm-imem-dload-type
Used in drivers/power/reset/msm-poweroff.c too, not only drivers/power/reset/qcom-dload-mode.c
So for now my experiment to just upgrade the kernel is a failure and I cannot telnet and debug the error.