How do i generate DTSi data files? - Android Q&A, Help & Troubleshooting

Hi there,
i was searching the forum and the inet without any luck about information on how to create or generate *.dtsi files which are placed (in my case) in:
Code:
android\system\kernel\oppo\msm8939\arch\arm\boot\dts\qcom\15018\
im bringing up a new device the "Oppo R7S" which is a sibling device of the "R7 Plus".
So far i was able to compile and boot CyanogenMod succefully. Everything worked except for the Videorecorder
Here are a few pictures: http://community.oppo.com/en/forum.php?mod=viewthread&tid=45106&extra=&page=2
I have noticed that the display driver that my rom has used in my bring-up was either the one for the 15018/R7Plus or for the 15011/R7.
I can't remember which one. I went back to stock before i wrote it down. However it is not the one which should be used which is 15023.
This is where i noticed i must have missed something. I checked my panel in the stock rom using DevCheck and under Graphics it lists the Panel:
Code:
oppo15023samsung s6e3fa3 1080p cmd mode dsi panel
so i checked my stock rom where it gets that info.
On the stock rom i have a file in "system/etc/" it is named
Code:
pp_calib_data_oppo15023samsung_s6e3fa3_1080p_cmd_mode_dsi_panel.xml
But this couldn't be it. So i assumed it must be the display driver in the kernel.
I looked into the CyanogenMod sources https://github.com/CyanogenMod/android_kernel_oppo_msm8939/tree/cm-13.0/arch/arm/boot/dts/qcom
and i was right. There was no 15023 display driver.
Long story short. How do I create and generate those dtsi files?
At the moment this is an Unofficial Rom but i plan to make it an Official Rom as soon as all problems have been fixed.
I hope anyone can help me on my porting "adventure"
This is my device tree: https://github.com/Celoxocis/android_device_oppo_r7sf

---

celoxocis said:
I have noticed that the display driver that my rom has used in my bring-up was either the one for the 15018/R7Plus or for the 15011/R7.
I can't remember which one. I went back to stock before i wrote it down. However it is not the one which should be used which is 15023.
This is where i noticed i must have missed something. I checked my panel in the stock rom using DevCheck and under Graphics it lists the Panel:
Code:
oppo15023samsung s6e3fa3 1080p cmd mode dsi panel
so i checked my stock rom where it gets that info.
It gets that info from the kernel device tree.
On the stock rom i have a file in "system/etc/" it is named
Code:
pp_calib_data_oppo15023samsung_s6e3fa3_1080p_cmd_mode_dsi_panel.xml
But this couldn't be it.
Click to expand...
Click to collapse
Yeah, that's just Qualcomm's color calibration stuff.
So i assumed it must be the display driver in the kernel.
I looked into the CyanogenMod sources https://github.com/CyanogenMod/android_kernel_oppo_msm8939/tree/cm-13.0/arch/arm/boot/dts/qcom
and i was right. There was no 15023 display driver.
Long story short. How do I create and generate those dtsi files?
Click to expand...
Click to collapse
dts(i) is essentially just code. It's not autogenerated. In the CM kernel we only include the device tree files for devices we actually support (at the moment that's 14005, 15011 and 15018). For getting those files for your devices, the best source is a stock ROM release. Look's like you're lucky: https://github.com/oppo-source/R7plus-5.1-kernel-source/tree/master/arch/arm/boot/dts/15022
Click to expand...
Click to collapse

---

maniac103 said:
dts(i) is essentially just code. It's not autogenerated. In the CM kernel we only include the device tree files for devices we actually support (at the moment that's 14005, 15011 and 15018). For getting those files for your devices, the best source is a stock ROM release. Look's like you're lucky: https://github.com/oppo-source/R7plus-5.1-kernel-source/tree/master/arch/arm/boot/dts/15022
Click to expand...
Click to collapse
OMG, i was looking the other day at oppo-source github but i let myself fool by the "R7plus-5.1-kernel-source" naming and didn't look for the dts folder.
Thanks so much!
Could i simply copy the entire 15022 folder into
Code:
"cm-13.0\android\system\kernel\oppo\msm8939\arch\arm\boot\dts\qcom"
and compile the CM-rom?
I have a working device-tree and a working cm-rom, except proper display drivers. My guess is, it would include the display driver files in the kernel at my next compile.
Or would i have to edit specific files to make it work?
So far all i did was to simply copy the
Code:
cp cyanogenmod_r7plus_defconfig cyanogenmod_r7sf_defconfig which is in
cm-13.0/android/system/kernel/oppo/msm8939/arch/arm64/configs
and edit Android.mk in
cm-13.0/android/system/device/oppo/msm8939-common#
to include "r7sf"
Code:
LOCAL_PATH := $(call my-dir)
ifneq ($(filter r7sf f1f r5 r7 r7plus, $(TARGET_DEVICE)),)
One last question. What is the best way to make the Oppo R7Sf Officially supported by CM?
My device tree is already on github. I will soon commit the latest changes to it. I would really love for it to be included in CM Officially.

---

celoxocis said:
OMG, i was looking the other day at oppo-source github but i let myself fool by the "R7plus-5.1-kernel-source" naming and didn't look for the dts folder.
Thanks so much!
Could i simply copy the entire 15022 folder into
Code:
"cm-13.0\android\system\kernel\oppo\msm8939\arch\arm\boot\dts\qcom"
and compile the CM-rom?
Click to expand...
Click to collapse
You'll also need to add a top level dts file and add it to the Makefile. You can use the r5 commit as reference: http://review.cyanogenmod.org/143086
You'll also need to make some small modifications to get a working accelerometer: http://review.cyanogenmod.org/144868
What DTS to you use currently? Normally you should get an error by the bootloader as no DTS for 15022 is currently included.
One last question. What is the best way to make the Oppo R7Sf Officially supported by CM?
My device tree is already on github. I will soon commit the latest changes to it. I would really love for it to be included in CM Officially.
Click to expand...
Click to collapse
Let's make it work first Once we have it working (by adding the missing kernel bits), we can have ciwrl fork the device tree to CM and include it in nightlies. Please make sure to put up all required changes outside of the device tree to Gerrit.
Gesendet von meinem R7plusf mit Tapatalk

---

maniac103 said:
You'll also need to add a top level dts file and add it to the Makefile. You can use the r5 commit as reference: http://review.cyanogenmod.org/143086
You'll also need to make some small modifications to get a working accelerometer: http://review.cyanogenmod.org/144868
Let's make it work first Once we have it working (by adding the missing kernel bits), we can have ciwrl fork the device tree to CM and include it in nightlies. Please make sure to put up all required changes outside of the device tree to Gerrit.
Gesendet von meinem R7plusf mit Tapatalk
Click to expand...
Click to collapse
Thank you! Well the good thing is i made no changes except those mentioned above outside of the device tree. I tracked changes in the R7 Plus device tree and forked the device tree for the R7S.
And of course removed the bits which were not needed such as fingerprint support. While tracking Uberlaggydarwins F1f device tree i knew what i had to remove.
Thank you! I have seen the R5 commit and already made a diff check last night between 15011 and 15018 to see which files are common files and which are different, this way i can "base" my 15022 DTS files off.
The common files are probably refreshed (newer) files from CM than those from Oppo's github.
As far as i have noted:
Code:
meaning:
"+" = Identical(common) between 15011 and 15022
"<----" = means 15022 differs here:
+msm8939-bus.dtsi
+msm8939-camera.dtsi
+msm8939-coresight.dtsi
+msm8939-cpu.dtsi
+msm8939-gpu.dtsi<----
+msm8939-iommu.dtsi
+msm8939-iommu-domains.dtsi
+msm8939-ion.dtsi
+msm8939-ipcrouter.dtsi+
+msm8939-mdss.dtsi<----
+msm8939-mdss-pll.dtsi+
+msm8939-pm.dtsi<----
+msm8939-regulator.dtsi<----
+msm8939-smem.dtsi
+msm8939-smp2p.dtsi
+msm-gdsc-8916.dtsi
+msm-iommu-v2.dtsi
+msm-pm8916.dtsi<----
+msm-pm8916-rpm-regulato.dtsi
+skeleton64.dtsi
Not identical / different naming (diff 15011 / 15018):
(not compared with 15022 yet)
msm8939-audio-internal_codec.dtsi
msm8939-camera-sensor-mtp.dtsi
msm8939-common.dtsi
msm8939-mtp.dtsi
msm8939-pinctrl.dtsi
msm8939-v3.0-gpu.dtsi
msm8939-v3.0-pm.dtsi
msm8939-v3.0.dtsi
I can do the DTS files changes and can also do the changes in:
Code:
arch/arm/boot/dts/qcom/Makefile
drivers/input/touchscreen/synaptics_oppo/synaptics_oppo_driver_3508.c
but to be honest the changes below scare me off. I'm not an developer/coder. Im an Windows/Linux/Unix Systems Integrator my skills for coding are limited to simple scripts :-/
Code:
drivers/usb/phy/phy-msm-usb.c
sound/soc/codecs/wcd9xxx-mbhc.c
sound/soc/msm/msm8939-slimbus.c
maniac103 said:
What DTS to you use currently? Normally you should get an error by the bootloader as no DTS for 15022 is currently included.
Click to expand...
Click to collapse
I have not enable insecure adb for adb logging during boot. But I think it is using the DTS file for 15018. Devcheck shows the panel (display driver) as 15018.
I finished compiling CM13.0-20160520
and in this version i don't know why both but Cameras stopped working. Previously they worked but Videocamera did not. I guess this will fix once i include and compile the 15022 DTS files.
Orientation / Rotate is actually inverted. When i rotate the phone 90° Left the Display will rotate 90° right and vice versa. So it is inverted. Same with 180° degree. It will be upside/down.
Not sure what happened here, it worked in an older version. Maybe the "timestamp" fix from a few weeks ago worked for the R7S?
Display driver is 15018 but I'm working on that
Everything else works perfectly fine!
Previously to fix the audio and microphone i used the audio_platform_info.xml and mixer_paths_mtp.xml from the R7Plus.
I did compare mixer_paths_mtp.xml of the R7Plus and R7S from ColorOS stock and they only differed in one single line. It worked.
Only thing left are the TFA9890 profiles for the R7S https://github.com/oppo-dev/proprietary_vendor_oppo/commit/c66367fa3970afe98e1398a532c8553fc61d2f53
So it is not much to fix before everything works as most of the work has been done for the R7Plus by you guys

---

celoxocis said:
Thank you! I have seen the R5 commit and already made a diff check last night between 15011 and 15018 to see which files are common files and which are different, this way i can "base" my 15022 DTS files off.
The common files are probably refreshed (newer) files from CM than those from Oppo's github.
Click to expand...
Click to collapse
I'd suggest going a different route: diff e.g. the 15018 DTS between Oppo's release at oppo-source and CM. Then take the 15022 DTS off Oppo's kernel and apply the 15018 diff generated before onto that. You'll see at least the changes for the accelerometer interrupt and for the tfa9890 (the latter had reset pin and regulator definitions in the sound card in Oppo's kernel and has an own instantiation in ours)
I can do the DTS files changes and can also do the changes in:
Code:
arch/arm/boot/dts/qcom/Makefile
drivers/input/touchscreen/synaptics_oppo/synaptics_oppo_driver_3508.c
Click to expand...
Click to collapse
The Makefile changes are required, the TS driver likely doesn't need any changes as the 15018 kernel already supports 15022. (BTW, the 15022 TS firmware is named differently from 15018. Make sure you're using the right one.)
but to be honest the changes below scare me off. I'm not an developer/coder. Im an Windows/Linux/Unix Systems Integrator my skills for coding are limited to simple scripts :-/
Code:
drivers/usb/phy/phy-msm-usb.c
sound/soc/codecs/wcd9xxx-mbhc.c
sound/soc/msm/msm8939-slimbus.c
Click to expand...
Click to collapse
You don't need those; those were required for the R5's USB/headset mux. When pointing to the R5 support commit I was mostly referring to the DTS changes, not the (C) code changes.
I have not enable insecure adb for adb logging during boot. But I think it is using the DTS file for 15018. Devcheck shows the panel (display driver) as 15018.
Click to expand...
Click to collapse
Why not? It's only a matter of building -eng instead of -userdebug. I somewhat doubt it's using the 15018 DTS. The DTS features the model number (https://github.com/CyanogenMod/andr.../boot/dts/qcom/msm8939-v3.0-mtp-15018.dts#L23) which the bootloader uses to figure out the DTS to use. If the bootloader fell back to use 15018, that would be kinda weird.
I finished compiling CM13.0-20160520
and in this version i don't know why both but Cameras stopped working. Previously they worked but Videocamera did not. I guess this will fix once i include and compile the 15022 DTS files.
Click to expand...
Click to collapse
Maybe. It's unclear without further debugging. You can look in dmesg whether the kernel drivers found the right camera sensor. What blobs are you using? r7plus' verbatim or did you copy others off the stock ROM?
Orientation / Rotate is actually inverted. When i rotate the phone 90° Left the Display will rotate 90° right and vice versa. So it is inverted. Same with 180° degree. It will be upside/down.
Not sure what happened here, it worked in an older version.
Click to expand...
Click to collapse
It's not just the panel being inverted? You can check whether orientation is correct in recovery. If it is, the accelerometer is off and needs further debugging/fixing.
Maybe the "timestamp" fix from a few weeks ago worked for the R7S?
Click to expand...
Click to collapse
With the old state of timestamps being off the issue was that orientation changes stopped working altogether after some time. It's unrelated to your issues which must be isolated to DTS, as sensor HAL + kernel driver is working just fine on r5, r7 and r7plus.
Only thing left are the TFA9890 profiles for the R7S https://github.com/oppo-dev/proprietary_vendor_oppo/commit/c66367fa3970afe98e1398a532c8553fc61d2f53
Click to expand...
Click to collapse
That's mostly trivial as most of those files are straight copies from the stock ROM, they're just renamed. Only the .eq files need conversion (text -> binary), you can use this tool for doing that.

---

maniac103 said:
I'd suggest going a different route: diff e.g. the 15018 DTS between Oppo's release at oppo-source and CM. Then take the 15022 DTS off Oppo's kernel and apply the 15018 diff generated before onto that. You'll see at least the changes for the accelerometer interrupt and for the tfa9890 (the latter had reset pin and regulator definitions in the sound card in Oppo's kernel and has an own instantiation in ours)
Click to expand...
Click to collapse
You are right. That is the better route. I will see the changes and be able to apply add/delete the changes onto the 15022 DTS files.
maniac103 said:
The Makefile changes are required, the TS driver likely doesn't need any changes as the 15018 kernel already supports 15022. (BTW, the 15022 TS firmware is named differently from 15018. Make sure you're using the right one.)
Click to expand...
Click to collapse
Yes I saw the TS file naming in the source and have included those in my blob list already.
Should i use
Code:
"ifeq ($(CONFIG_OPPO_COMMON_SOFT),y)
+dtb-$(CONFIG_ARCH_MSM8916) += msm8939-mtp-15022.dtb
or rather
Code:
+dtb-$(CONFIG_ARCH_MSM8916) += msm8939-v3.0-mtp-15022.dtb
as the R7S was later released than the R7 Plus. It should be based of the R7 Plus.
maniac103 said:
Why not? It's only a matter of building -eng instead of -userdebug. I somewhat doubt it's using the 15018 DTS. The DTS features the model number (https://github.com/CyanogenMod/andr.../boot/dts/qcom/msm8939-v3.0-mtp-15018.dts#L23) which the bootloader uses to figure out the DTS to use. If the bootloader fell back to use 15018, that would be kinda weird.
Click to expand...
Click to collapse
I got curious too. I'm compiling and -eng version, once done I will flash and check the bootlog.
maniac103 said:
Maybe. It's unclear without further debugging. You can look in dmesg whether the kernel drivers found the right camera sensor. What blobs are you using? r7plus' verbatim or did you copy others off the stock ROM?
Click to expand...
Click to collapse
I extracted the dmesg and pasted it into pastebin here: http://pastebin.com/306q3xZS
maniac103 said:
It's not just the panel being inverted? You can check whether orientation is correct in recovery. If it is, the accelerometer is off and needs further debugging/fixing.
Click to expand...
Click to collapse
Im using TWRP which has no rotation. I will flash CM recovery later and check if its correct in the recovery.
maniac103 said:
That's mostly trivial as most of those files are straight copies from the stock ROM, they're just renamed. Only the .eq files need conversion (text -> binary), you can use this tool for doing that.
Click to expand...
Click to collapse
Thanks! I was looking how i would convert those two files a few weeks ago but didn't find sources.
This is a simple C-file compile?
Code:
gcc calc-biquad.c -o calc-biquad
While working on the sources and checking the diff's i discovered this difference between 15018 and 15022 (both oppo source).
Which i think could be the cause of the inverted rotation issue
Letf is 15018 and Right is 15022
(see attachment)

---

celoxocis said:
Should i use
Code:
"ifeq ($(CONFIG_OPPO_COMMON_SOFT),y)
+dtb-$(CONFIG_ARCH_MSM8916) += msm8939-mtp-15022.dtb
or rather
Code:
+dtb-$(CONFIG_ARCH_MSM8916) += msm8939-v3.0-mtp-15022.dtb
as the R7S was later released than the R7 Plus. It should be based of the R7 Plus.
Click to expand...
Click to collapse
Release date isn't relevant there. Check /sys/devices/soc0/revision - if it says 3.0 adding 3.0 to the DTS name is the right thing to do.
I extracted the dmesg and pasted it into pastebin here: http://pastebin.com/306q3xZS
Click to expand...
Click to collapse
dmesg alone likely isn't sufficient here. From it it looks like the sensors don't come up, though. Not sure what exactly the problem is, but are you sure you have the right blobs? Initializing the camera is mostly done by the blobs. If you say it worked some time ago, please try whether the r5 introduction kernel commit broke anything for you.
Thanks! I was looking how i would convert those two files a few weeks ago but didn't find sources.
This is a simple C-file compile?
Code:
gcc calc-biquad.c -o calc-biquad
Click to expand...
Click to collapse
Yeah, except you'll need the math library (-lm).
While working on the sources and checking the diff's i discovered this difference between 15018 and 15022 (both oppo source).
Which i think could be the cause of the inverted rotation issue
Letf is 15018 and Right is 15022
(see attachment)
Click to expand...
Click to collapse
Yes, it could. It's almost as likely that the difference is normal, though, as those properties tell the driver how the sensor is mounted in the device, and the mounting orientation isn't necessarily the same between 15018 and 15022. Worth a try though.

---

maniac103 said:
Release date isn't relevant there. Check /sys/devices/soc0/revision - if it says 3.0 adding 3.0 to the DTS name is the right thing to do.
Click to expand...
Click to collapse
Thanks! Checked and its "3.0" i applied 3.0 files.
maniac103 said:
dmesg alone likely isn't sufficient here. From it it looks like the sensors don't come up, though. Not sure what exactly the problem is, but are you sure you have the right blobs? Initializing the camera is mostly done by the blobs. If you say it worked some time ago, please try whether the r5 introduction kernel commit broke anything for you.
Click to expand...
Click to collapse
I just finished adding 15022 files into the kernel and started the compile. I will look into the problem as soon as i finish flashing the new rom.
I found my eeprom file for the camera too. I used to extract all blobs because i did not know which was the correct one.
maniac103 said:
Yes, it could. It's almost as likely that the difference is normal, though, as those properties tell the driver how the sensor is mounted in the device, and the mounting orientation isn't necessarily the same between 15018 and 15022. Worth a try though.
Click to expand...
Click to collapse
Yes i agree. I read about it online when i discovered the difference. The sensor is probably mounted differently in the R7S. We will see as soon as the compile is finished and i flashed the rom
So far the compile runs through without any complains to my kernel additions. I went with the suggested route. Diff CM-15018<->Oppo-15022 applied those changes to the Oppo-15022 files and got CM-15022.
I did not create a different defconfig for the R7S. I sticked with the settings from R7Plus. Just renamed it for dependency mode.
I noticed something. While i fixed up the TFA9890 files.
where did you get the "left.tfa9890_n1b12.patch" file from? it's not in the R7S nor R7Plus ColorOS stock rom.
i see one patch "TFA9890_N1C3_1_7_1.patch" which is renamed to "left.tfa9890_n1c2.patch"
i can see a second "coldboot.patch" but that looks empty and has not the same content as "left.tfa9890_n1c2.patch"
is it a generic file which is required for TFA9890? if yes. i guess i can simply copy and paste it. as "left.tfa9890_n1c2.patch" is identical in both roms?
for the compile i just copied the R7plus file as i didn't know where it came from.

---

n1c2/3 and n1b12 are just different revisions of the tfa9890. r7plus stock firmware carried both files IIRC; it should be OK to omit n1b12 if the r7s doesn't have that revision.
Gesendet von meinem R7plusf mit Tapatalk

---

maniac103 said:
n1c2/3 and n1b12 are just different revisions of the tfa9890. r7plus stock firmware carried both files IIRC; it should be OK to omit n1b12 if the r7s doesn't have that revision.
Gesendet von meinem R7plusf mit Tapatalk
Click to expand...
Click to collapse
Ok i will just leave that file out of the blob list.
I had time today to flash my new build today and test it, which included the 15022 kernel inclusions and as i hoped all the issues i had, are gone!
Thanks alot for your help!
As far as tested:
Both cameras work!
Videocamera works!
All Sensors + GPS, Wifi work too!
Flashlight works.
Rotation issue fixed too! The guess about the sensor mounting was right!
Display driver is the correct one!
I have yet to grab a boot log. "adb logcat" before and while booting the device should be enough to catch everything. right?
The only thing left to do is to filter out the proper camera blobs.
Im using JackPotClavin's Android-Blob-Utility for that.
Can i leave out the blobs for Camera, Camera autofocus, Camera chromatix which are referenced in "lib64/" ?
I have seen that the R7Plus nor the R7f use these blobs in the proprietary-files.txt.
I will try to commit all changes to github on the next weekend. Once i finish updating the blobs list with the proper camera blobs.

---

celoxocis said:
The only thing left to do is to filter out the proper camera blobs.
Im using JackPotClavin's Android-Blob-Utility for that.
Click to expand...
Click to collapse
That's one option, another one would be strace'ing the camera daemon (in adb shell):
Code:
su
setprop ctl.stop qcamerasvr
strace -f -eopenat /system/bin/mm-qcamera-daemon
That'll tell you what blobs it tries to open.
Can i leave out the blobs for Camera, Camera autofocus, Camera chromatix which are referenced in "lib64/" ?
I have seen that the R7Plus nor the R7f use these blobs in the proprietary-files.txt.
Click to expand...
Click to collapse
Yeah, you can, the media stack is 32 bit only.

---

maniac103 said:
That's one option, another one would be strace'ing the camera daemon (in adb shell):
Code:
su
setprop ctl.stop qcamerasvr
strace -f -eopenat /system/bin/mm-qcamera-daemon
That'll tell you what blobs it tries to open.
Yeah, you can, the media stack is 32 bit only.
Click to expand...
Click to collapse
I finished the blob list but there is something i have been trying to fix for days and i can't really figure out whats the cause.
It is Wifi:
In Oppo Stock ColorOS everything is fine and stable. Wifi just works out of the box. It keeps switching between 2.4Ghz and 5Ghz depending where im in the house. (Signal strength)
I have a AVM Fritzbox 7490 with the latest firmware and all features. Dual band etc.
In CyanogenMod i keep having "drop outs". The Wifi is just dropping out. Like i have it turned off.
When i force it to use only 2.4Ghz band in wifi advanced options, it never happens. I believe it happens when it should automatically switch between 2.4Ghz and 5Ghz.
In my device tree im already using the "WCNSS_qcom_wlan_nv_15022.bin" as my "WCNSS_qcom_wlan_nv.bin"
I have already checked following files and made a diff for what the cause could be:
p2p_supplicant_overlay.conf = same as stock
WCNSS_qcom_cfg.ini = same as stock
wpa_supplicant.conf = wifi-direct settings disabled. we don't need that.
wpa_supplicant_overlay.conf = same as stock
It seems like i can fix the issue when enabling "Always allow Wi-Fi Roam Scans" and "Use legacy DHCP client" in Developer Options.
But here is the problem as soon as i reboot the device those settings are unchecked.
How can i make it permanent? Is there a way to make it permanent in the device tree? to compile the ROM using those settings as default?
I can even replicate the problem by turning off those two settings and walking around the house.
Any idea?
Update:
After hours of testing. With and without the above options.
Forced 5Ghz wifi is not stable at all. I tried all combinations getting 5Ghz to work, with no luck.
Forced 2.4Ghz works fine with and without above options. So my conclusion. It is definitly something wrong with how prima handles the 5Ghz.
In stock both work fine.