dts: qcom: msm8916-mf601: initial support #310
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
185264646
changed the title
185264646
force-pushed
the
msm8916/mf601_chg
branch
2 times, most recently
from
fd5d1a9
to
705107b
Compare
stephan-gh
reviewed
May 18, 2023
| @@ -0,0 +1,313 @@ | |||
| // SPDX-License-Identifier: GPL-2.0-only | |||
| // A common dtsi for MF601xx series LTE modem dongles. | |||
There was a problem hiding this comment.
Do you actually know someone who has and could test this dtsi on a different model? It usually doesn't make sense to create share common properties in a .dtsi when it's not clear yet which models actually exist and what their differences are.
There was a problem hiding this comment.
Do you actually know someone who has and could test this dtsi on a different model? It usually doesn't make sense to create share common properties in a .dtsi when it's not clear yet which models actually exist and what their differences are.
I got the infomation from the photos and EDL-dumped vendor Android images for them(At least 3 variants, such as mf601_mb_v05, mf601_s_v02, mf601_sl_v02(7) and so on) and tested on one. All of the stuff except the naming and usage of the LEDs looks identical. There's also a MF32xx series that should also be able to share this dtsi. There are many people owning other models, maybe i can contact with them. I'll just let it hang there for some time to wait for some others who might be interested in.
185264646
commented
May 20, 2023
Comment on lines
+8
to
+9
| model = "Tong Heng Wei Chuang 4G Modem Stick MF601SL_CT_V07"; | ||
| compatible = "thwc,mf601sl-v7", "qcom,msm8916"; |
There was a problem hiding this comment.
Also applies to MF601SL_CT_V02，maybe common across all MF601SL-xxx?
stephan-gh
reviewed
May 22, 2023
Document the new thwc,mf601sl-v7 device tree bindings used in their device trees. Signed-off-by: Yang Xiwen <[email protected]>
This commit adds support for the MF601 series WiFi/LTE dongle made by Tong Heng Wei Chuang based on MSM8916. Compared to previous UFI-001C, MF601 ships more peripherals, such as battery/charger, SD Card slot, more LEDs and buttons etc. Note: The original firmware does not support 64-bit OS. It is necessary to flash 64-bit TZ firmware to boot arm64. Currently supported: - All CPU cores - Buttons - LEDs - Modem - SDHC - USB Device Mode / Host Mode - UART Signed-off-by: Yang Xiwen <[email protected]>
Signed-off-by: Yang Xiwen <[email protected]>
185264646
force-pushed
the
msm8916/mf601_chg
branch
from
705107b
to
0580683
Compare
|
There seems to be something wrong with this DTS. It doesn't work. I don't see any ADB or RNDIS device |
This device has some strange quirks. Please do not flash any addtional firmware except Also, welcome to attach your debug UART log. |
this is random kernel oops dmesg. |
It's a known quirk. That's why i didn't send email to mainline. Don't flash any firmware except Again, please restore the original Android image you dumped and ONLY flash By the way, from the limited log you put here, the device tree you are using seems not identical to this one.
You should consult the original author. |
|
Here is UART |
|
another panic from UART |
I requested more than once for you to RESTORE stock Android image, please. Don't blame on this dts because the crash is resulted from the "base package" you flashed which is made by handsomemod. It's COMPLETELY BROKEN and SHOULD NOT be flashed. You both are reqporting an invalid issue. By the way, the dts is not even written by me. The debian image has completely nothing to do with me. Please find the original author and report the issue to him. Or follow the directions that i already suggested more than once above. Try this image: |
|
Your dts compiled kernel 6.5 |
|
No blame, these UART logs are to help the community fix bugs. |
I've uploaded a pmos image, you can try that. Remember to restore Android system first |
where？ |
https://www.123pan.com/s/fMlTjv-9v0Wd.html code:1357
Note: I found some recent commits in pmos broke some compatibities, so i edited the source and regenerated it recently without testing. It still occasionally crash for my device. Welcome to use this image for a few days and reboot for some times. |
|
I migrated mf601sl-v7 dt to 6.7-rc5, its works fine. Reason of kernel oops is SoC temperature overheating. I use |
Thanks for your testing. A Tested-by tag from you is welcomed. I will send this patch upstream when we have another mf601 model with different LED layout (which means another dts). |
|
How to do the |
You can read https://docs.kernel.org/translations/zh_CN/process/submitting-patches.html#reported-by-tested-by-reviewed-by-suggested-by-fixes . Generally, you have two choices. The formal one is that when i submit the patch upstream with email, you reply to the email with "Tested-by: xxxx [email protected]". The maintainer will add the tag to the commit log and apply it to their tree, which will finally be merged to torvalds' tree. The other is not so formal, you can simply attach your Tested-by tag here, then i add it to the commit log and send it. You'll be notified when i send that upstream. Either one is okay, It's up to you. Either way, you'll have to provide your real name and a working email address. Though you can still use a fake name, but a working email is mandatory |
|
Okay, both are fine for me |
|
I added two notes. dont forget it |
Thanks. To limit cpufreq you can also add an opp table to dts. Refer to #325 |
a-andre
reviewed
Mar 11, 2024
|
|
||
| led-message-red { | ||
| color = <LED_COLOR_ID_RED>; | ||
| function = LED_FUNCTION_INDICATOR; |
There was a problem hiding this comment.
I suggest to use LED_FUNCTION_STATUS here and above, because IMO both functions represent the same and then STATUS should be preferred.
|
Hi? Are u still working here? When will this patch be available in the kernel tree? |
Sorry. i'm busy these days. For upstream, we'll need at least one more user of the common dtsi, or it'll be possibly rejected. Quite a lot work needs to be done here |
|
eMMC with 8G works fine. but eMMC with 4GB panic, can u confirm it? |
Yes. I can. The crash log you posted is very similar to mine. Though I don't have a 8GB version and can't figure out the reason. For now, i can confirm the following facts on my device:
So unless i can get it completely fixed, I won't submit this patch to upstream. Can you figure out the real reason for the crashes? If it's over-temp, i can workaround it with a dedicated opp-table in the dts to limit the CPU freq. But if it's emmc issue, i don't know how to fix it. With the facts above, we can say it of course can be fixed in software. Though i don't know how and where. |
|
Can u share ur sbl1 and rpm firmware? I flash my android firmware. Boot 1st Boot 2nd Boot 3rd Boot 4th Boot 5th |
|
Oh, I forget reserved memory for GPS. but I added its also has NULL panic. I think maybe more memory should be reserved? |
Maybe. Remember to compare with decompiled dtb from Android. It's an important reference. |
Android reserved memory: venus_qseecom_mem, audio_mem and default region |
It shouldn't cause any issue. modem and venus image are relocable and only communicate with linux with some known documented and safe channels. BTW, you may try disable all unnecessary sub-systems and try again(venus, modem etc..). i.e. write "none" to '/boot/lk2nd_rproc_mode'. msm8916-mainline/lk2nd#113 |
|
Then I don't know the what cause NULL pointer. Are u trying disabled them? |
I've already tried. Actually i never enable modem as it consumes too much RAM. But anyway i don't think it's the reason. As i've said above, restoring rpm and sbl1 seems to work. I suggest you trying disable all modules in the dts and only leave UART/CPU nodes on and see if it still crashes. We need to be sure that the things before linux are working as intended. |
|
u are right, flash ur sbl1 and rpm, kernel stable but i dont know why I flashing my original sbl and rpm firmware its not working |
|
My stick run over 2 days. Its stable. I think its can merged |
Try to put some pressure on it (i.e. Anyway, this patchset needs a lot of improvement as i've said (merging dtsi and dts or supporting at least another model), removing ALso i'm more than hesitated to see more users with different models sharing their experience with this dts. I'll consider continue to work on this with enough feedback. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Not fully tested yet. Only a draft.
TODO: How do we handle LEDs? Entirely in userspace or some with default-trigger? Do we need to follow the downstream usage of the LEDs?
Feedback is welcomed.
Tested peripherals: