[experimental-tmp4] dts: msm8939: htc-a51dtul: Add support for HTC Desire 820 Dual SIM #316
Conversation
|
This is a huge and amazing writeup! Sorry, didn't read it all yet, but a thing I caught:
Seems like it always stops on the valid entry, probably exits the loop when it matches? |
There was a problem hiding this comment.
The changes themselves look good to me.
Is there any chance you can add your device to -next (use i.e. rebase/dts branch) in a way similar to this:
and check that it still works properly? We want to eventually switch to the new branch, even though there is still a bit of work to do before we can, but I want to make sure the changes for two branches are in-sync so we don't miss stuff.
If you don't have the time, I will add it myself there later, but then it won't be tested...
rom4nik
force-pushed
the
master-htc-a51dtul
branch
from
b7a9103 to
7d34c63
Compare
Yeah, that would make sense - when it doesn't see
Sure, sorry. Unfortunately it seems that this phone also doesn't like too many DTBs, like Meanwhile Removing other .dts from Also I've checked that it can boot https://github.com/msm8916-mainline/linux, at least with a UART only .dts there. As for menu options:
Flashing pmOS rootfs sparse image to system or userdata partition makes lk2nd log |
TravMurav
changed the title
I guess this happens even in the old lk2nd? Maybe we need to stop some watchdog then... I marked this PR like others that target "-next" (sorry, our naming for this historically is quite weird as we initially weren't sure if things will work and then it stuck). We will go through them when the branch is switched to the main one and maybe ask to re-test or (very unlikely) suggest changes if we change the dts model again, then merge it. Feel free to submit a second PR with the changes you had before, targeting master and I will merge it if you want to make use of that too. (note that two branches have slightly different feature sets) |
It does, but would watchdog be possible reason for these reboots, if during flashing the UI of lk2nd is not frozen and I can use buttons? (=> I assume that the watchdog is also continuously taken care of) Another thing is that after booting to msm8916-mainline and debug-shell I could get a kernel panic (something about |
|
lk2nd runs UI and fastboot in separate threads so they won't generally hang each other. But as I understood you, the device dies after ~30s regardless of what you do in lk2nd?
Can you run something like stress-ng to excercise /all/ the ram you have? Maybe you're missing some reserved memory? |
TravMurav
force-pushed
the
rebase/dts
branch
from
59b79de to
2de75fa
Compare
rom4nik
force-pushed
the
master-htc-a51dtul
branch
from
8666c4f to
bd91cd8
Compare
|
Rebased on
No, sorry. If I'm not doing anything, phone stays alive. When I'm flashing pmOS rootfs via I'll check stress-ng next. |
HBOOT on this device is pretty quirky and has two bugs that made preparing .dts quite confusing. My versions of stuff:
a51dtul HBOOT bugs?
1.
fastboot boot lk2nd.imgdoesn't boot lk2nd imagesIt will print into logs the DTBs found inside image pushed via fastboot, but then it'll ignore it and boot from local boot partition without really saying so. Example logs:
1a. empty boot partition - erased with
fastboot erase lk2ndfrom booted lk2nd:In this particular scenario I'm always seeing only 3 DTBs despite 342,343,344,345 in
qcom,msm-idin .dts - no clue why. In some code blocks I've added comments on the right side, you might need to scroll horizontally to see them.1b. same lk2nd flashed to boot and then
fastboot booted over USB:1c. lk2nd flashed to boot,
fastboot boot mystery-twrp-dumped-from-phone.img:And then it hangs, after some time (watchdog?) resets into ramdump mode and boots back to lk2nd. Weird, at least it disproves my early suspicion that
fastboot bootis completely broken.2. DTB reuse bug with lk2nd-appended-dtb images
I have no idea if this is supposed to be a feature or a bug, but it made figuring out a minimal .dts here extremely confusing, especially since for a long time I assumed that this phone needs appended DTBs like
htc-m8qlul.Basically, you can take a current prebuilt
lk2nd-msm8916-appended-dtb.img(in spite of device being QCDT) from latest GH release, flash it to boot partition, and then kinda sorta boot despite no HBOOT-approved DTBs in image, by either:adb reboot(I have some TWRP found on XDA a while ago)Right now it seems to not occur on
lk2nd-msm8916.imgbuilds.Also I don't remember exact steps and can't reproduce it right now, but while going through a loop of:
edit .dts -> rebuild -> fastboot flash lk2nd build-lk2nd-msm8916/lk2nd.img -> fastboot reboot, a few times I might have been able to warm boot into a DTB that later wouldn't cold boot. I'm not sure if that was a case of HBOOT reusing DTB from last successful lk2nd DTB selection, or maybe I misremember things. That was weird.Since then I've added a
$DATEvariable tomodelvar in my .dts.template and ran this oneliner for reliable reflashing:I also had modfied makefile to include
LK2ND_VERSION := $(LK2ND_VERSION)-dirty-/\)-$(shell date +%T), just to be sure I have both latest build of my lk2nd and DTB, built at the same moment. I'm not mentioning this bug in .dts since you probably won't run into it unless you don't know what you're doing and really want to makelk2nd-appended-dtb.imgwork somehow.With that I was finally quite confident that my changes in .dts are actually applied and can be used to assess the kinda blackbox (to me) HBOOT + lk2nd behavior further.
a51dtul HBOOT, lk2nd and journey to minimal viable .dts
As a general note, IIRC, on this device there's surprisingly very little needed to cold boot lk2nd:
qcom,msm-idhas to be344, changing any other value inqcom,*vars will result in just a warning from HBOOTrules.mk, unlikehtc-m8qlulwith the same SoClk2nd.img(QCDT) to boot partition instead oflk2nd-appended-dtb.img, unlikehtc-m8qlulSo just to give some ideas for others and myself next time I look at this, here's a kinda step-by-step journal of how I arrived at current .dts (it was actually much more chaotic due to HBOOT bugs mentioned above, but IMO it's still worth noting how HBOOT responded to various changes).
lk2nd,keysThat was borrowed from https://github.com/msm8916-mainline/lk2nd/blob/541dd6768ab7bc03208be3fb2e031303c4a30d34/dts/msm8916/msm8939-htc-m8qlul.dts, without it the power button and volup were doing scroll and voldown was doing nothing.
IDs from kernel source
So just for reference, here's where I initally got the magic board numbers from. I've taken the kernel source from htcdev.com untouched and reuploaded to GH just for convenience of online searches and linking in this PR.
htc,project-id,htc,hw-id,qcom,board-id:https://github.com/rom4nik/kernel_release-a51ul-3.10.28-g1e0287c/blob/b3d118eff02b0a30c930bbf2a3e09e05ee5ac266/arch/arm64/boot/dts/qcom/msm8939-a51dtul.dts#L18-L22
qcom,msm-id:https://github.com/rom4nik/kernel_release-a51ul-3.10.28-g1e0287c/blob/b3d118eff02b0a30c930bbf2a3e09e05ee5ac266/arch/arm64/boot/dts/qcom/msm8939.dtsi#L27
And I also saw
239inmsm8939-mtp.dtsin lk2nd repo. idk, maybe in HTC kernel it was overriden somewhere else in .dts files.htc,project-id,htc,hw-idSince a51dtul HBOOT is happy to boot DTBs without that, I've removed those as well. I assumed they'd be necessary on my phone since
m8qlulhad them.However, I feel it's important to note that on HTC phones
qcom,msm-idmust be set to whatever the HTC kernel source had ashtc,project-id, otherwise HBOOT will not be interested in those DTBs. I didn't know that, and combined withfastboot bootbug described above for a long while I thought that the second time DTBs were listed, it was HBOOT telling me what it it wants?Source for this:
qcom,msm-id1. So if you take the easy route and use
qcom,msm-id = <239 0>andqcom,board-id = <1 0>, HBOOT will refuse to boot the flashed image:Again, don't let yourself get lured into
fastboot booting unless you reflash the image every time anyway and realize that you're actually just using this command as a "continue local boot". I've wasted many days by this.2. You could just use
<344 0>, obtained by the "least changes" route from<239 0>. HBOOT will boot that, but will complain:(with
qcom,board-idstill set to<1 0>)lk2nd also will complain a bit, showing
DTB - <344 0x1 0 0x0>in yellow color on LCD under serial number, and in logs:Where did that
0x10000come from here?3. Setting
qcom,msm-id = <342 0>, <343 0>, <344 0>, <345 0>;, since that's almost the numbers that HTC source had:HBOOT logs with above +
qcom,board-id = <1 0>:lk2nd doesn't show yellow DTB line on LCD, no complaints in logs:
Still, there's a mismatch of
soc version:0x10000vs0x0in DTBs, so let's try to fix that.4.
qcom,msm-id = <342 0x10000>, <343 0x10000>, <344 0x10000>, <345 0x10000>HBOOT:
No complaints from lk2nd. So HBOOT still complains about
pcbid:0x80vs0x1, but by now I could guess that it's first number inqcom,board-id.To sum up, I'm not sure what these
htc,project-ids were, maybe some regional variants? I saw thatm8qlulhas just oneproject-id, but even though my device is just aBoard pid:344according to HBOOT, I guess it wouldn't hurt to give it DTBs for all 4 IDs, to make HBOOT and lk2nd happier.qcom,board-idSo this was just a journey to get fewer complaints in HBOOT logs. We're keeping
qcom,msm-id = <342 0x10000>, <343 0x10000>, <344 0x10000>, <345 0x10000>.1.
qcom,board-id = <0x80 0>HBOOT:
No complaints from HBOOT and lk2nd, nice!
2. But maybe let's try
qcom,board-id = <0x0 0>, <0x1 0>, <0x2 0>, <0x80 0>, since HTC kernel had more IDs (htc,hw-id = <0 0>,<1 0>,<2 0>,<128 0>).HBOOT:
Still no complaints from HBOOT and lk2nd. I've left just
<0x80 0>in submitted .dts for now to avoid bloating prebuilt images with DTBs for devices that I don't even know if exist.What next?
I haven't had time to try booting mainline kernel yet, I'm just happy I could realize the HBOOT bugs/glitches wasn't me incorrectly noting down what works and what doesn't. So far I can say that the mystery TWRP built for stock bootloader doesn't boot via lk2nd - it complains about lack of appended DTB, of all things. Oh well.
So, it'd be great if you could let me know if the code's okay and hopefully if there's any fault in my reasoning above.
Unrelated:
moserialwas too slow to catch some of HBOOT/lk2nd logs, sometimes it would glitch out and omit some lk2nd logs if there was a lot of HBOOT logs, e.g. during listing of DTBs in lk2nd.img built with fullrules.mk. Even just usingstty -F /dev/ttyACM0 115200andcat /dev/ttyACM0gave me full(er?) logs.