Is Galileo supported or not? - Redmi Note 9S / Note 9 Pro (Indian Model) Question

Hello, please can you report your experience with Galileo reception and custom ROMs?
Development team reported, through official forum, that Galileo is not supported but smartphone was advertised with Galileo support.
It is still advertised as supported in italian, spanish and indian page. It has been removed from all the other pages (de, fr, uk, se, cn, id, ru and global).
According to european laws, advertising a product with different real specification is prohibited and sanctioned and customer have the right to ask for a replacement of refund.
Please, if you have a custom ROM, can you check if it is supported or not?

Interesting, the official galileo webpage still lists the note 9 pro as supported device. The GPStest app shows no usage of galileo satellites on my phone.

Thank you very much for sharing this link! The same for me with GPSTest. Attached you can find a screenshot. Once I saw a satellite with PRN 236, which is unknown and I can't find any reference about it using google.
Leni_YO said:
Interesting, the official galileo webpage still lists the note 9 pro as supported device. The GPStest app shows no usage of galileo satellites on my phone.
Click to expand...
Click to collapse

simone982 said:
Hello, please can you report your experience with Galileo reception and custom ROMs?
Development team reported, through official forum, that Galileo is not supported but smartphone was advertised with Galileo support.
It is still advertised as supported in italian, spanish and indian page. It has been removed from all the other pages (de, fr, uk, se, cn, id, ru and global).
According to european laws, advertising a product with different real specification is prohibited and sanctioned and customer have the right to ask for a replacement of refund.
Please, if you have a custom ROM, can you check if it is supported or not?
Click to expand...
Click to collapse
according to qualcomm-snapdragon-720g-mobile-platform-product-brief.pdf it is supported by hardware
Code:
GPS, Glonass, BeiDou, Galileo, QZSS,
and SBAS
• NavIC support
• Dual-Frequency GNSS (L1 + L5)
According to Xiaomi_Kernel_OpenSource xiaomi use (qcom) source branch
Code:
Branch: curtana-q-oss
Base tag: LA.UM.8.9.r1-07100-SM6xx.0
Looking into GPS relevant source code at hardware/qcom/gps/tree/?h=LA.UM.8.9.r1-07100-SM6xx.0 and compare it with e.g. newer branch sm8150 (Snapdragon 855) hardware/qcom/gps/tree/?h=LA.UM.8.1.r1-14500-sm8150.0
there is missing code for dual frequency GNSS support for branch SM6xx
Code:
...
void
+GnssAdapter::requestSvPolyForClient(LocationAPI* client, const LocationCallbacks& callbacks) {
+ if (callbacks.gnssSvPolynomialCb) {
+ LocationCallbacks oldCallbacks = getClientCallbacks(client);
+ if (!oldCallbacks.gnssSvPolynomialCb) {
+ LOC_LOGd("request sv poly");
+ GnssAidingDataSvMask svDataMask = GNSS_AIDING_DATA_SV_POLY_BIT;
+ mLocApi->requestForAidingData(svDataMask);
+ }
+ }
+}
+
+void
+GnssAdapter::reportSvPolynomial(const GnssSvPolynomial &svPolynomial)
+{
+ for (auto it=mClientData.begin(); it != mClientData.end(); ++it) {
+ if (nullptr != it->second.gnssSvPolynomialCb) {
+ it->second.gnssSvPolynomialCb(svPolynomial);
+ }
+ }
+}
+
+void
...
+typedef uint32_t LocSvDgnssMeasStatusMask;
+#define LOC_MASK_DGNSS_EPOCH_TIME_VALID 0x1 /**< DGNSS Epoch time is valid */
+#define LOC_MASK_DGNSS_MEAS_STATUS_PR_VALID 0x2 /**< Pseudo Range correction is valid */
+#define LOC_MASK_DGNSS_MEAS_STATUS_PRR_VALID 0x4 /**< Pseudo Range rate correction is valid */
...
+#define GNSS_SV_MEAS_HEADER_HAS_DGNSS_CORRECTION_SOURCE_TYPE 0x08000000
+#define GNSS_SV_MEAS_HEADER_HAS_DGNSS_CORRECTION_SOURCE_ID 0x010000000
+#define GNSS_SV_MEAS_HEADER_HAS_DGNSS_REF_STATION_ID 0x020000000
+#define GNSS_SV_MEAS_HEADER_HAS_REF_COUNT_TICKS 0x040000000
...
+ /** Unique SV Identifier.
+ * SV Range for supported constellation is specified as below:
+ * - For GPS: 1 to 32
+ * - For GLONASS: 65 to 96
+ * - For SBAS: 120 to 158 and 183 to 191
+ * - For QZSS: 193 to 197
+ * - For BDS: 201 to 237
+ * - For GAL: 301 to 336
+ * - For NAVIC: 401 to 414 */
...
+// carrier frequency of the signal tracked
+#define GPS_L1CA_CARRIER_FREQUENCY (1575420000.0)
+#define GPS_L1C_CARRIER_FREQUENCY (1575420000.0)
+#define GPS_L2C_L_CARRIER_FREQUENCY (1227600000.0)
+#define GPS_L5_Q_CARRIER_FREQUENCY (1176450000.0)
+#define GLONASS_G1_CARRIER_FREQUENCY (1602000000.0)
+#define GLONASS_G2_CARRIER_FREQUENCY (1246000000.0)
+#define GALILEO_E1_C_CARRIER_FREQUENCY (1575420000.0)
+#define GALILEO_E5A_Q_CARRIER_FREQUENCY (1176450000.0)
+#define GALILEO_E5B_Q_CARRIER_FREQUENCY (1207140000.0)
+#define BEIDOU_B1_I_CARRIER_FREQUENCY (1561098000.0)
+#define BEIDOU_B1C_CARRIER_FREQUENCY (1575420000.0)
+#define BEIDOU_B2_I_CARRIER_FREQUENCY (1207140000.0)
+#define BEIDOU_B2A_I_CARRIER_FREQUENCY (1176450000.0)
+#define BEIDOU_B2A_Q_CARRIER_FREQUENCY (1176450000.0)
+#define QZSS_L1CA_CARRIER_FREQUENCY (1575420000.0)
+#define QZSS_L1S_CARRIER_FREQUENCY (1575420000.0)
+#define QZSS_L2C_L_CARRIER_FREQUENCY (1227600000.0)
+#define QZSS_L5_Q_CARRIER_FREQUENCY (1176450000.0)
+#define SBAS_L1_CA_CARRIER_FREQUENCY (1575420000.0)
+#define NAVIC_L5_CARRIER_FREQUENCY (1176450000.0)
...
maybe Xiaomi use custom branch of LA.UM.8.9.r1-07100-SM6xx.0
doubt, if snapdragon 720G (sm7125) really based on sm6xx/atoll source code branch

Thank you for your answer. I'll try to ask also on ROM threads if someone with different kernel can give us feedback

Oh, there is a newer branch LA.UM.8.9.r1-08900-SM6xx.0 from April 29, 2020 which add more DGNSS stuff

moreroid said:
Oh, there is a newer branch LA.UM.8.9.r1-08900-SM6xx.0 from April 29, 2020 which add more DGNSS stuff
Click to expand...
Click to collapse
I have rooted redmi note 9s.
Maybe someone knows how to modify the kernel or gps.confg or some other way.
To improve the handling of gps galileo and dual gps.
How someone knows how to do it.
Then I can test it.
That's a question for developers anyway.

sad, current xiaomi.eu V11.0.10.0.QJWMIXM (curtana) release don't include latest gps related source branch
one change between LA.UM.8.9.r1-07100-SM6xx.0 and LA.UM.8.9.r1-08900-SM6xx.0 was:
Code:
- LOC_LOGD("%s]: Delta:%" PRIi64 "ns time too large, retry number #%u...",
- __FUNCTION__, sinceBootTimeDeltaNanos, i+1);
+ LOC_LOGd("Delta:%" PRIi64 "ns time too large, retry number #%u...",
+ sinceBootTimeDeltaNanos, i + 1);
but old result was found
Code:
curtana:/ # getprop ro.build.fingerprint_real
Redmi/curtana_global/curtana:10/QKQ1.191215.002/V11.0.10.0.QJWMIXM:user/release-keys/1595409748
curtana:/ # strings /vendor/lib64/hw/[email protected] | grep Delta:
%s]: Delta:%lins time too large, retry number #%u...

Same (previous) version in 11.0.4.0 joyeuse.
A developer here said that something should be enabled by Xiaomi in boot/vendor
https://forum.xda-developers.com/showpost.php?p=83170851&postcount=739
moreroid said:
sad, current xiaomi.eu V11.0.10.0.QJWMIXM (curtana) release don't include latest gps related source branch
one change between LA.UM.8.9.r1-07100-SM6xx.0 and LA.UM.8.9.r1-08900-SM6xx.0 was:
Code:
- LOC_LOGD("%s]: Delta:%" PRIi64 "ns time too large, retry number #%u...",
- __FUNCTION__, sinceBootTimeDeltaNanos, i+1);
+ LOC_LOGd("Delta:%" PRIi64 "ns time too large, retry number #%u...",
+ sinceBootTimeDeltaNanos, i + 1);
but old result was found
Code:
curtana:/ # getprop ro.build.fingerprint_real
Redmi/curtana_global/curtana:10/QKQ1.191215.002/V11.0.10.0.QJWMIXM:user/release-keys/1595409748
curtana:/ # strings /vendor/lib64/hw/[email protected] | grep Delta:
%s]: Delta:%lins time too large, retry number #%u...
Click to expand...
Click to collapse

simone982 said:
Same (previous) version in 11.0.4.0 joyeuse.
A developer here said that something should be enabled by Xiaomi in boot/vendor
https://forum.xda-developers.com/showpost.php?p=83170851&postcount=739
Click to expand...
Click to collapse
for curtana Xiaomi must take newer qcom source branch LA.UM.8.9.r1-08900-SM6xx.0 (April 29, 2020) compile it and provide it in usual way
current used(?) qcom source branch LA.UM.8.9.r1-07100-SM6xx.0 (December 25, 2019) is supposed to old for dgnss (dual-frequency gps) support
there is no excuse it wouldn't work for Xiaomi

There is a discussion here about the lack of galileo and dual gps.
https://c.mi.com/thread-3124154-5-1.html

Galileo support has been removed also from italian and spanish page

moreroid said:
for curtana Xiaomi must take newer qcom source branch LA.UM.8.9.r1-08900-SM6xx.0 (April 29, 2020) compile it and provide it in usual way
current used(?) qcom source branch LA.UM.8.9.r1-07100-SM6xx.0 (December 25, 2019) is supposed to old for dgnss (dual-frequency gps) support
there is no excuse it wouldn't work for Xiaomi
Click to expand...
Click to collapse
Moderator xiaomi handed over
this valuable information to xiaomi developers.
https://c.mi.com/thread-3124154-5-1.html

Yes, thanks, I saw
kriss3 said:
Moderator xiaomi handed over
this valuable information to xiaomi developers.
https://c.mi.com/thread-3124154-5-1.html
Click to expand...
Click to collapse

Italian customer service told me that Galileo is not supported in Redmi Note 9 Pro. That's disappointing and what a shame for Xiaomi!

I've also have a Mi A2 and developers are able to update Qualcomm drivers by themselves, is it because this super partition system that they're not able to do this for curtana/joyeuse?

It seems that kernel source for joyeuse has been published here:
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/gram-q-oss
I'll dig into this

simone982 said:
It seems that kernel source for joyeuse has been published here:
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/gram-q-oss
I'll dig into this
Click to expand...
Click to collapse
I have xiaomi eu miui 12 i used the cortana kernel
Kernel] [MIUI-AOSP] Yuki- ユ キ Kernel [curtana, excalibur, gram, joyeuse]
The aosp kernel seems to have a newer branch
maybe galileo and dual gps would work
Unfortunately, I do not have aosp.
https://c.mi.com/thread-3424963-1-0.html
https://forum.xda-developers.com/redmi-note-9-pro/development/kernel-yuki-kernel-3-0-t4182393
Rebased over LA.UM.8.9.r1-10600-SM6xx.0 (AOSP variant only)
Merge tag 'LA.UM.8.1.r1-16200-sm8150.0'
Wifi, Audio tag used LA.UM.8.9.r1-10600-SM6xx.0
Net Wireward
Enable PSI monitor
Add pidfd backport
Fixed boot on Joyeuse (Miui variant)
Last xiaomi changes (Miui variant)
Disable LMK
Removed
[TESTING] exec: Add node tampering blacklist function
[TESTING] allow power @ 2 and perf 2 to tampering blacklist

https://forum.xda-developers.com/showpost.php?p=83804167&postcount=15
I asked already if someone can check
kriss3 said:
I have xiaomi eu miui 12 i used the cortana kernel
Kernel] [MIUI-AOSP] Yuki- ユ キ Kernel [curtana, excalibur, gram, joyeuse]
The aosp kernel seems to have a newer branch
maybe galileo and dual gps would work
Unfortunately, I do not have aosp.
https://c.mi.com/thread-3424963-1-0.html
https://forum.xda-developers.com/redmi-note-9-pro/development/kernel-yuki-kernel-3-0-t4182393
Rebased over LA.UM.8.9.r1-10600-SM6xx.0 (AOSP variant only)
Merge tag 'LA.UM.8.1.r1-16200-sm8150.0'
Wifi, Audio tag used LA.UM.8.9.r1-10600-SM6xx.0
Net Wireward
Enable PSI monitor
Add pidfd backport
Fixed boot on Joyeuse (Miui variant)
Last xiaomi changes (Miui variant)
Disable LMK
Removed
[TESTING] exec: Add node tampering blacklist function
[TESTING] allow power @ 2 and perf 2 to tampering blacklist
Click to expand...
Click to collapse

simone982 said:
https://forum.xda-developers.com/showpost.php?p=83804167&postcount=15
I asked already if someone can check
Click to expand...
Click to collapse
I have miui 12 europe redmi note 9s
This is the newest one I downloaded from November 14 Cortana.
Everything's fine with the kernel.
The GPS works.
It does not detect only galileo and dual gps frequency,
but never detected it.
Although the 720g snapdragon supports
Someone needs to do a gps fix to detect galileo and dual gps

Related

A10.1IT G8: Do we have multi-touch?

Did anyone get http://labs.teague.com/projects/ChordedKeyboard/ working on A10.1IT G8?
we have multitouch but with just up to 2 points.
So u can't play a piano with more then 2 fingers at the same time...
I didn't try the app.
I've heard rumours that this is a software limitiation, not hardware.
BTW, the site I mentioned is not an app, it's a web page.
sciurius said:
I've heard rumours that this is a software limitiation, not hardware.
Click to expand...
Click to collapse
As far as I could understand, it's a "software limitation", but the problem is that to eliminate this limitation, a new touchscreen driver must be written. Honestly, I think that even if all needed specs and sources for it are available (I doubt it), there're not many people around able to write device drivers, and even less are interested in developing this particular driver...
A bit of info about A101g8 is here: http://forum.xda-developers.com/showpost.php?p=21095289&postcount=60
In GPL'ed 2.6.29-omap1 gen8 kernel touchscreen driver is called "hanvon" (probably, after Hanvon-10, a Chinese tablet), and also a generic dualtouch driver for Pixcir is included in the latest mainline kernels.
oh if it software realtes we schold be able to fine some info in the datasheets of the controller - lets have a look
Thanks to schollbert we know:
Touchscreen subsystem
• Pixcir capacitiv touchscreen unit (TR16C0 controller, USB interface)
• Ti USB hub
EDIT:
hmm the "datasheet" schollbert had is a brouchure - in chineese...
but its telling 2-10 fingers... if i got it right
As far as I could understand, the touchscreen driver (hanvon.c) in GPL'ed 2.6.29-omap1 has some implementation of the "multitouch protocol A" (i.e. the old one, superseded by "protocol B" in recent mainline kernels). At least, it issues necessary ABS events.
The device itself maps to /dev/input/event3 and /dev/input/event4, but event4 seems not working.
The problem is that tslib driver (at least, its older versions) refuses to work with hanvon, because hanvon doesn't issue all necessary events out of the box (namely, it lacks ABS_PRESSURE). On some forum I found someone with similar problem and, strangely, but only a little dirty fix was needed to make hanvon and tslib friends:
Code:
--- hid-hanvon.c.old 2012-01-04 21:17:34.000000000 +0400
+++ hid-hanvon.c 2012-03-10 19:30:59.822992148 +0400
@@ -110,6 +110,7 @@
#ifdef CONFIG_HID_HANVON_10_MONO_TSP_EMULATION
input_event(td->dev, EV_KEY, BTN_TOUCH, 0);
+ input_event(td->dev, EV_ABS, ABS_PRESSURE, 0); // little dirty fix for tslib
input_sync(td->dev);
#endif
@@ -171,6 +172,7 @@
/* touchscreen emulation */
hid_map_usage(hi, usage, bit, max,
EV_KEY, BTN_TOUCH);
+ input_set_abs_params(hi->input, ABS_PRESSURE, 0, 1, 0, 0); // little dirty fix for tslib
return 1;
case HID_DG_TIPSWITCH:
@@ -238,6 +240,7 @@
#ifdef CONFIG_HID_HANVON_10_MONO_TSP_EMULATION
// issue button press
input_event(input, EV_KEY, BTN_TOUCH, 1);
+ input_event(input, EV_ABS, ABS_PRESSURE, 1); // little dirty fix for tslib
#endif
// next time, we'll only rearm timer and
// issue position update if ts emulation.
@@ -297,6 +300,7 @@
#ifdef CONFIG_HID_HANVON_10_MONO_TSP_EMULATION
// issue button release
input_event(input, EV_KEY, BTN_TOUCH, 0);
+ input_event(input, EV_ABS, ABS_PRESSURE, 0); // little dirty fix for tslib
input_sync(input);
#endif
// start debouncer.
This patch reports support of ABS_PRESSURE, and also issues this event together with BTN_TOUCH in TSP emulation mode (not sure if it's needed, though).
I'm not sure how real "multitouch" and "dualtouch" must look like, but now when I start ts_test and press two fingers in Draw mode -- it successfully draws a line between them...
In theory, it seems possible to port multitouch support from recent mainline kernels to 2.6.29-omap1, but practically it requires very good coding skills and some time.

[Q] Modem with oFono/oFono-ril?

Hi Guys,
what do you think, is it possible (would be possible) to use oFono/ofono-ril for the modem for our Wave? In theory oFono could be used with any modem that supports standard AT commands...
More info here: http://ofono.org/ and here http://gitorious.org/android-n900/ofono-ril/trees/gingerbread
Sadly Wave's CP doesn't support most of standard AT commands. :[
Rebellos said:
Sadly Wave's CP doesn't support most of standard AT commands. :[
Click to expand...
Click to collapse
heja Rebellos, dzieje się coś ciekawego w tej materii czy raczej możemy zapomnieć o andku na W 2 ?
pozdro z mazowsza
AT+CALC
Code:
Polecenie (tryb AT):
AT+CLAC
Odpowiedź:
AT+CLAC
&C
&D
&E
&F
&S
&V
&W
E
I
L
M
Q
V
X
Z
T
P
\Q
\S
\V
%V
D
A
H
O
S0
S2
S3
S4
S5
S6
S7
S8
S9
S10
S11
S30
S103
S104
+ICF
+IFC
+IPR
+GMI
+GMM
+GMR
+GCAP
+GSN
+DR
+DS
+WS46
+SYNCML
+BATGETLEVEL
+BATUPDATE
+BATGETTABLE
+UPLOADUNSET
+CRLP
+CV120
+CSSN
+CREG
+CGREG
+CFUN
+GCAP
+CSCS
+CSTA
+CR
+CEER
+CRC
+CMEE
+CGDCONT
+CGDSCONT
+CGTFT
+CGEQREQ
+CGEQMIN
+CGQREQ
+CGQMIN
+CGEREP
+CGPADDR
+CGDATA
+CGCLASS
+CGSMS
+CSMS
+CMGF
+CSAS
+CRES
+CSCA
+CSMP
+CSDH
+CSCB
+FDD
+FAR
+FCL
+FIT
+ES
+ESA
+CMOD
+CVHU
+ACSENSOR
+RTCCTEST
+KEYSHORT
+PROXIMIT
+GEOMAGSS
+FIRMVERS
+APPINSTALL
+APPUNINSTALL
+APPLAUNCH
+TKSHELL
+CSQ
+CBC
+CPAS
+CPIN
+CMEC
+CKPD
+CIND
+CMER
+CGATT
+CGACT
+CGCMOD
+CPBS
+CPBR
+CPBF
+CPBW
+CPMS
+CNMI
+CMGL
+CMGR
+CMGS
+CMSS
+CMGW
+CMGD
+CMGC
+CNMA
+CMMS
+FTS
+FRS
+FTH
+FRH
+FTM
+FRM
+CHUP
+CCFC
+CCUG
+COPS
+CLCK
+CPWD
+CPWC
+CUSD
+CAOC
+CACM
+CAMM
+CPUC
+CCWA
+CHLD
+CIMI
+CGMI
+CGMM
+CGMR
+CGSN
+CNUM
+CCLK
+CLVL
+CMUT
+CLCC
+COPN
+CPOL
+CPLS
+CTZR
+CCWE
+CTZU
+CLAC
+CLIP
+COLP
+CSGT
+CRMP
+CDIP
+CTFR
+CLIR
$QCSIMSTAT
$QCCNMI
$QCCLR
$QCDMG
$QCDMR
$QCDNSP
$QCDNSS
$QCTER
$QCSLOT
$QCPINSTAT
$QCPDPP
$QCPDPLT
$QCPWRDN
$QCDGEN
$BREW
$QCSYSMODE
$QCCTM
$SUSBC
$NWMDCHNG
$SHPSLEEP
Is it helpful?
nie dajcie umrzec temu projektowi nie dajcie
That's bad news if the CP doesn't support most of the standard AT commands... So this doesn't help at all?
anghelyi said:
Hi Guys,
what do you think, is it possible (would be possible) to use oFono/ofono-ril for the modem for our Wave? In theory oFono could be used with any modem that supports standard AT commands...
More info here: http://ofono.org/ and here http://gitorious.org/android-n900/ofono-ril/trees/gingerbread
Click to expand...
Click to collapse
What you're saying just doesn't make sense. Why would you wanna use a oFono RIL on a Samsung device?
The RIL is just used to channel (and translate) android java phone/sim/modem related commands to the lower hardware layer on/for the radio processor. Thus the vendor RIL need to apply to the hardware of THAT vendor (i.e.Samsung). Why re-invent the wheel?
Now, there are some exceptions due to the fact that the RIL code is fairly closed source (although GPL'd AFAIK ==> should be released), that there are some project(s) that would like to make a "Free RIL"...
BTW. All GSM modems support the "standard AT set" (or your phone would probably not work!) The tricky part is how to access it from outside the AOS & RIL. But that's another topic.
E:V:A said:
What you're saying just doesn't make sense. Why would you wanna use a oFono RIL on a Samsung device?
Click to expand...
Click to collapse
I don't get your point... oFono is a platform agnostic library for mobile apps, with a lot of supported modems (even with standard AT command support) and oFono RIL is a RIL implementation based on it. Why not to use it?If it works with the N9 why not try to build it for Wave?
E:V:A said:
Now, there are some exceptions due to the fact that the RIL code is fairly closed source (although GPL'd AFAIK ==> should be released), that there are some project(s) that would like to make a "Free RIL"...
BTW. All GSM modems support the "standard AT set" (or your phone would probably not work!) The tricky part is how to access it from outside the AOS & RIL. But that's another topic.
Click to expand...
Click to collapse
RIL isn't GPL, it's Apache License, like most of Android platform, so doesn't have to be released.
Yea, there actually are handlers for AT cmds inside of AMSS, but modem initialization, nor any more advanced usage can't be done with these alone.
Rebellos said:
RIL isn't GPL, it's Apache License, like most of Android platform, so doesn't have to be released.
Yea, there actually are handlers for AT cmds inside of AMSS, but modem initialization, nor any more advanced usage can't be done with these alone.
Click to expand...
Click to collapse
Rebellos, how this works? like.. the modem access is through AT and then call for the other things?
anghelyi said:
I don't get your point... oFono is a platform agnostic library for mobile apps, with a lot of supported modems (even with standard AT command support) and oFono RIL is a RIL implementation based on it. Why not to use it?If it works with the N9 why not try to build it for Wave?
Click to expand...
Click to collapse
Dammit! You're absolutely right. I did the classical error of not "following the f%&ing links" before posting! So I have obviously confused the oFono project with a completely different one... Actually this seem to be a very cool project! We should try to get some of these guys involved over here or vice verse.
anonimo1w said:
Rebellos, how this works? like.. the modem access is through AT and then call for the other things?
Click to expand...
Click to collapse
Try to be a little more specific. On many platforms the phone application processor (UI/UX) does much of its normal communication (phone calls, sms, sim etc) to/from the baseband processor (modem) via an AT interface. However, in many cases this AT interface is "embedded" in other transport layers like IPC, I2C or what have you. In addition, the actual physical control mechanisms (like putting modem to sleep/wake up, power save, RF power, booting, test modes etc.) are usually done through GPIO or other forms of UART. Honestly, it's quite a mess to explain, because there are many variations on how this is handled. (That's why they needed the RIL in the first place.) Finally, since I don't have a Wave, I don't know how that is done. I just know they use a Qualcomm modem... and some of their manuals are available.
In modern SHP based phones hierarchy of transport layers is like:
1) oneDRAM
2) SHP IPC protocol with packet types listed below: (as per Samsung Jet S8000)
Code:
typedef enum
{
FIFO_PKT_NONE = 0, // 0
FIFO_PKT_KEY, // 1
FIFO_PKT_SIM, // 2
FIFO_PKT_PROTO, // 3
FIFO_PKT_TAPI, // 4
FIFO_PKT_PHONESTATUS, // 5
FIFO_PKT_FILE, // 6
FIFO_PKT_LCD, // 7
FIFO_PKT_LED, // 8
FIFO_PKT_SOUND, // 9 Sound means voice here
FIFO_PKT_SOUND_DATA, // 10
FIFO_PKT_H324M, // 11
FIFO_PKT_AMR_DATA, // 12
FIFO_PKT_AMR_CTRL, // 13
FIFO_PKT_CLOCK, // 14
FIFO_PKT_BOOT, // 15
FIFO_PKT_FLIP, // 16
FIFO_PKT_SYSTEM, // 17
FIFO_PKT_USBPROTO, // 18
FIFO_PKT_USBFILE, // 19
FIFO_PKT_USBDIAG, // 20
FIFO_PKT_IRDAPROTO, // 21
FIFO_PKT_IRDAFILE, // 22
FIFO_PKT_IRDADIAG, // 23
FIFO_PKT_TIMER, // 24
FIFO_PKT_DEBUG, // 25
FIFO_PKT_DIAGNOSE, // 26
FIFO_PKT_SPECIAL_BOOT, // 27
FIFO_PKT_CALL_TIME, // 28
FIFO_PKT_ALARM, // 29
FIFO_PKT_FIFO_INTERNAL,// 30
FIFO_PKT_USBCRCPROTO, // 31
FIFO_PKT_USBCRCFILE, // 32
FIFO_PKT_USBCRCDIAG, // 33
FIFO_PKT_VIBRATOR, // 34
FIFO_PKT_AMLED, // 35 AppMgr LED
FIFO_PKT_AMVIB, // 36 AppMgr Vibrator
FIFO_PKT_AMLCD, // 37 AppMgr LCD Backlight
FIFO_PKT_DATA_PCSYNC,
FIFO_PKT_CTRLCMD_PCSYNC,
FIFO_PKT_DATA_WSSSYNC,
FIFO_PKT_TIME, // 41 TimeMgr
FIFO_PKT_DVB_H_CAS_SIM, // 42 DVB-H CAS SIM
FIFO_PKT_DVB_H_CAS_TEST,// 43 DVB-H CAS Test module.
FIFO_PKT_DVB_H_CAS, // 44 DVB-H CAS Common usage.
FIFO_PKT_DVB_H_CAS_IPS, // 45 DVB-H CAS IPS usage.
FIFO_PKT_DVB_H_DebugLevel, //46 receive debug level from MSM
FIFO_PKT_Forced_Assert, // 47
FIFO_PKT_MEMORY, // 48
FIFO_PKT_NV, // 49 // NvMgrLite
FIFO_PKT_LBS, // 50 LBS
FIFO_PKT_SIM_JSR177, // 51 S8000_JSR177_kjseo
FIFO_PKT_USER = 0x80,
FIFO_PKT_DVBH = FIFO_PKT_USER + 0x06,
FIFO_PKT_DVBH_SVC,
FIFO_PKT_DVB_H_LAYER1,
FIFO_PKT_DVB_PLAYER,
FIFO_PKT_AV_PLAYER,
FIFO_PKT_PH, // BB -> MM : Protocol Handler FIFO Type
FIFO_PKT_PH_LITE, // MM -> BB : Protocol Handler Lite FIFO Type
FIFO_PKT_FX = 0x90,
FIFO_PKT_BLUETOOTH ,
FIFO_PKT_TESTMODE, // Testmode
FIFO_PKT_DRV, // driver
FIFO_PKT_AGENT,
FIFO_PKT_DEVMGR,
FIFO_PKT_SECUREBOOT,
FIFO_PKT_MAX
} FifoType;
In Wave there are also few "service" packets added. Not sure for what are these.
Actually while in intialization of modem there are used SECUREBOOT, FM (direct access to Bada file system by CP), IPC_PACKET (not listed here or named differently) BOOT, SIM (managing sim contacts and logging) and some others. Packets that are managing telephony are PROTO and TAPI (telephony API)
TAPI packets does split into few subtypes
TAPI_TYPE_CALL = 0 //53 subtypes
TAPI_TYPE_NETTEXT = 1 //around 10 subtypes
TAPI_TYPE_NETWORK = 2 //23 subtypes
TAPI_TYPE_SS = 3 //48 subtypes
TAPI_TYPE_AT = 4 //34 subtypes
TAPI_TYPE_DMH = 5 //n subtypes, called API_IDs (must be nonzero)
TAPI_TYPE_CONFIG = 6 //n subtypes, called API_IDs (must be nonzero)
Click to expand...
Click to collapse
TAPI layer splits into contexts, which might be called "channels" for managing telephony functions
CALL (3 max)
NETTEXT (SMS/MMS, few allowed)
NETWORK (up to one)
SS (security related AFAIR)
AT (this is probably route of AT commands)
Click to expand...
Click to collapse
modem
i dont know this part but i want to know wave s8500 modem work or not ics 4.0.4?
yasotharan13 said:
i dont know this part but i want to know wave s8500 modem work or not ics 4.0.4?
Click to expand...
Click to collapse
stop annoying everyone!! it's not working yet!!

Huawei Open-Source Release - Broadcom DHD Open-Source Driver for S7 Froyo Working

Found this on Huawei's webpage: http://www.huaweidevice.com/worldwi...=toDownloadFile&flay=software&softid=NDcwODE=
open source_wlan.tar_S7_Android2.2
Would be nice if someone has the time to look at this.
The binary file that shipped with my Huawei firmware has version 4.218.248.17
Edit:
Tested and working. Forgot to update text here.
Mirrored the file for convenience for everyone who wants this. The first link actually was wrong, so I changed it.
Put this in an Android tree (such as /hardware/broadcom), do breakfast/lunch after envsetup, and perform 'make dhdko' with the kernel files present at /kernel. This is for Froyo. To build for Gingerbread, LOCAL_MODULE_TAGS cannot be equal to 'user', so you need to change Android.mk to say 'optional' instead. That's if you want to use Android.mk to build. If you are not building the whole tree, remember to make a folder /lib/modules/, or dhd.ko will not copy from the product obj folder properly.
Not sure how this will build for ICS/Jellybean, but at least now we have the source code that actually builds a proper module.
Kernel objects need to be in the right place. I did something to the effect of:
make -C kernel O=/sources/aosp/out/target/product/s7/obj/KERNEL_OBJ ARCH=arm CROSS_COMPILE=arm-eabi-
Built module works fine and is the same version shipped with Android 2.2 (4.218.248.17).
The driver is actually eerily similar to the bcm4329 kernel 3.4 bcm4329 driver. So much so i figured out what caused the sdio timeout.
Offending code causing emulate domain manager error om 2.6.35 when removed, sdio timeout when added:
dhd_linux.c:
Code:
static int
dhd_watchdog_thread(void *data)
{
dhd_info_t *dhd = (dhd_info_t *)data;
/* This thread doesn't need any user-level access,
* so get rid of all our resources
*/
#ifdef DHD_SCHED
if (dhd_watchdog_prio > 0) {
struct sched_param param;
param.sched_priority = (dhd_watchdog_prio < MAX_RT_PRIO)?
dhd_watchdog_prio:(MAX_RT_PRIO-1);
setScheduler(current, SCHED_FIFO, &param);
}
#endif /* DHD_SCHED */
DAEMONIZE("dhd_watchdog");
/* Run until signal received */
while (1) {
if (down_interruptible (&dhd->watchdog_sem) == 0) {
offender---------> dhd_os_sdlock(&dhd->pub);
if (dhd->pub.dongle_reset == FALSE) {
For kernels : http://threader.zapto.org/experimental/s7/wifi/bcm4329-30-09-13.tar.bz2

[DEV] [R&D] Linux 3.14 kernel for Exynos5420-based devices [WIP] [SM-P600/601]

I thought I'd post an update since some progress has been made, though there are still some things missing.
The current plan is to make a unified kernel for all Universal 5420-based devices, including our Note, the 12.2, and Tab S. I've managed to forward-port a lot of the necessary drivers to Linux 3.14. Most come from Samsung's Universal 5422, 5430, 5433 and 7420 kernels (Linux 3.10), while other stuff such as the Mali GPU drivers were taken from one of Linaro's 3.14 kernel trees along with Mali platform support for the Exynos5420-based Arndale Octa board. Currently I have only been focusing on SM-P600 support since that's the tablet I will be testing it on, but once I make sure it runs I'll be adding in support for other devices as well.
What's done so far:
* Maxim max77802 drivers (PMIC, regulator)
* Maxim max77888 drivers (PMIC, MUIC, LED, regulator, haptic)
- These will be used as a base for max77803 support since it's essentially the same driver
* Samsung's TN extension features
* Samsung's USB notify layer
* Samsung's battery/charger/fuelgauge drivers
Also:
* The sii8240 driver has been pulled in, though it doesn't compile yet
* The sensors are all supported in mainline so their drivers can easily be cherry-picked
Todo:
* Port over the LCD driver (LSL101DL01 / LSL122DL01)
- It needs to be adapted to the new display port driver (exynos-dp) instead of the old s5p-dp driver.
- It also requires device tree support, which is absent in 3.4, whereas board files are not supported in 3.14.
- This is beyond my skill and knowledge so if there's anyone reading this who can- and is willing to help please contact me.
* Write a board-specific DT blob.
* Probably a few more things that I'm forgetting.
Source/changelog: here
Feel free to fork this if you wish to help with development, just make sure to notify me if you do.
Original post:
Hi guys,
As some of you may know, the Linux kernel for ARM has long migrated from the use of board files to the use of device tree blobs for providing hardware descriptions to the kernel. Still, Samsung seems to insist on relying on all this unnecessary junk code instead of migrating to the use of device trees for their Exynos devices. Currently, the only Exynos5420-based device trees in existance are for development boards such as the Arndale Octa and the SMDK5420. No device tree exists for the UNIVERSAL5420 board and its variants which are found in the Galaxy Note and Tab series. So, I decided to write one.
I am no programming expert but seeing as the device tree syntax is not that complex, I thought, how hard can it be? The hardest part is basically combing through all the board files and searching for whatever stands up as being relevant in the device tree format as well as figuring out the correct unit-addresses, most of which seem to be listed in /arch/arm/mach-exynos/include/mach/map.h.
I'm using the SMDK5420 device tree as a base since it seems to be a watered-down development version of the UNIVERSAL5420 board. Still, there's a lot of stuff that needs to be added in and certain bits also need replacing. So far I have added in the nodes for the Maxim MAX77802 PMIC and its regulators as well as the nodes for the charger and a few 'skeletons' for the screen, the ARM Mali GPU and the Wolfson WM5102 codec. Some of these may still have incorrect unit addresses and other bits may still be incorrect or unnecessary.
If this project becomes successful it might:
Allow us to run higher kernel versions (i.e. above Linux 3.4) on our devices.
Make it easier to create ports of open source bootloaders such as u-boot or kexecboot for our devices.
Open up new doors in getting Global Task Scheduling (big.LITTLE MP) to work on the universal5420, as has been achieved on exynos5420-based development boards.
The project is located in my git repository here along with the SM-P600 board files and other references.
This is obviously still in early development but if anyone here who is familiar with the device tree syntax is willing to review my code and provide some constructive criticism it would be much appreciated.
For further information on the device tree and its syntax, here are some helpful links:
http://www.devicetree.org/Device_Tree_Usage
https://www.power.org/documentation/epapr-version-1-1/
https://www.kernel.org/doc/Documentation/devicetree/
http://lwn.net/Articles/572692/ (Device trees I: Are we having fun yet?)
http://lwn.net/Articles/573409/ (Device trees II: The harder parts)
Click to expand...
Click to collapse
XDA:DevDB Information
Unified Exynos 5420 Kernel, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain
Source Code: https://github.com/sigma-1/universal5420-device-tree
Kernel Special Features:
Version Information
Status: Testing
Created 2014-10-31
Last Updated 2015-08-27
Well ... Wish you luck with the Development ...
Andmoreagain said:
Hi guys,
As some of you may know, the Linux kernel for ARM has long migrated from the use of board files to the use of device tree blobs for providing hardware descriptions to the kernel. Still, Samsung seems to insist on relying on all this unnecessary junk code instead of migrating to the use of device trees for their Exynos devices. Currently, the only Exynos5420-based device trees in existance are for development boards such as the Arndale Octa and the SMDK5420. No device tree exists for the UNIVERSAL5420 board and its variants which are found in the Galaxy Note and Tab series. So, I decided to write one.
I am no programming expert but seeing as the device tree syntax is not that complex, I thought, how hard can it be? The hardest part is basically combing through all the board files and searching for whatever stands up as being relevant in the device tree format as well as figuring out the correct unit-addresses, most of which seem to be listed in /arch/arm/mach-exynos/include/mach/map.h.
I'm using the SMDK5420 device tree as a base since it seems to be a watered-down development version of the UNIVERSAL5420 board. Still, there's a lot of stuff that needs to be added in and certain bits also need replacing. So far I have added in the nodes for the Maxim MAX77802 PMIC and its regulators as well as the nodes for the charger and a few 'skeletons' for the screen, the ARM Mali GPU and the Wolfson WM5102 codec. Some of these may still have incorrect unit addresses and other bits may still be incorrect or unnecessary.
If this project becomes successful it might:
Allow us to run higher kernel versions (i.e. above Linux 3.4) on our devices.
Make it easier to create ports of open source bootloaders such as u-boot or kexecboot for our devices.
Open up new doors in getting Global Task Scheduling (big.LITTLE MP) to work on the universal5420, as has been achieved on exynos5420-based development boards.
The project is located in my git repository here along with the SM-P600 board files and other references.
This is obviously still in early development but if anyone here who is familiar with the device tree syntax is willing to review my code and provide some constructive criticism it would be much appreciated.
For further information on the device tree and its syntax, here are some helpful links:
http://www.devicetree.org/Device_Tree_Usage
https://www.power.org/documentation/epapr-version-1-1/
https://www.kernel.org/doc/Documentation/devicetree/
http://lwn.net/Articles/572692/ (Device trees I: Are we having fun yet?)
http://lwn.net/Articles/573409/ (Device trees II: The harder parts)
XDA:DevDB Information
UNIVERSAL5420 Device Tree, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain
Kernel Special Features:
Version Information
Status: Testing
Created 2014-10-31
Last Updated 2014-11-01
Click to expand...
Click to collapse
Dear friend , maybe @xluco can help us get the device tree so that we can clear a way for AOSP and such ROMs to our SM-P600/1 ... Good Luck
With Best Wishes
Hitman1376​
hitman1376 said:
Dear friend , maybe @xluco can help us get the device tree so that we can clear a way for AOSP and such ROMs to our SM-P600/1 ... Good Luck
With Best Wishes
Hitman1376​
Click to expand...
Click to collapse
Thanks, unfortunately I'm not that familiar with the android source code. At least it will probably be easier to gather all the device information once we get everything into a single file.
But anyway, I did an adb pull of the /dev, /proc and /sys directories from my p600. Found lots of useful info, especially for calculating some of the interrupt values. The gpu node is also complete, although I have yet to update my repo.
I'm also going to grab myself a development board tomorrow in hopes of getting a better picture of what I'm doing. I need to be able to visualize things as I work on this stuff.
Well ... Finally Good news ...
Andmoreagain said:
Thanks, unfortunately I'm not that familiar with the android source code. At least it will probably be easier to gather all the device information once we get everything into a single file.
But anyway, I did an adb pull of the /dev, /proc and /sys directories from my p600. Found lots of useful info, especially for calculating some of the interrupt values. The gpu node is also complete, although I have yet to update my repo.
I'm also going to grab myself a development board tomorrow in hopes of getting a better picture of what I'm doing. I need to be able to visualize things as I work on this stuff.
Click to expand...
Click to collapse
Well ... seems like you know what to do ( And managed it out well :good: ... I took a look into the GitHub ... Good work :good: ) ... but , if there were any problems , I would be glad to help ( I own a P601 but it doesn't matter ... their almost the same ... ) ...
Wish you luck with the Development
Hitman1376​
Excellent project mate, good luck! I'd offer some support but I don't know a single thing about device trees
Some updates!
Hey guys!
I had to take a long break from this project due to school and other stuff, but I'm at it again. I have done some homework along the way, and since there now exists a flattened device tree for the universal5422 board and several newer Exynos devices, it makes this work much easier since the universal5420 and 5422 are identical in many aspects, though not completely.
Now, to better explain what this project is all about and to clear up some confusion, a flattened device tree or a device tree blob is not the same thing as the android "device tree", required for compiling android for a specific device. The so-called flattened device tree is compiled as a separate binary along the kernel and describes the hardware of the device to the kernel in order to load the correct device drivers. In the past, ARM devices had to rely on so-called board files, such as all the board-*.c and dev-*.c files found in the arch/arm/mach-exynos directory of the stock kernel's source code for our device. This was a problematic solution, mostly because:
A) It meant that each vendor had to throw together a special branch of linux for every single device, containing a huge amount of device-specific code in order to load the necessary drivers.​
B) There is an ongoing project, called the Android Mainlining Project, and I quote:
The goal of this project is to ultimately mainline all patches required to run the current released version of Android. The purpose of mainlining these patches is 3-fold:
to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel
to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code
to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers
To "mainline" a patch means to have it included in Linus Torvalds' kernel.org kernel, in a released (non-rc) version.​
Click to expand...
Click to collapse
For some basic info regarding the Board File to Device Tree Migration, this document would be a good start.
"The Device Tree is a data structure for describing hardware. Rather than hard coding every detail of a device into an operating system, many aspects of the hardware can be described in a data structure that is passed to the operating system at boot time."
Click to expand...
Click to collapse
Now, some updates:​
I finally have a decent picture of each and every device available on our board, their addresses, and configurations. I have also documented which device is connected to which I2C (inter-integrated circuit) bus, but there are still several things that need to be figured out regarding this whole I2C labyrinth.
To begin with, the aliases listed in the generic exynos5420.dtsi device tree are as follows:
aliases {
mshc0 = &mmc_0;
mshc1 = &mmc_1;
mshc2 = &mmc_2;
pinctrl0 = &pinctrl_0;
pinctrl1 = &pinctrl_1;
pinctrl2 = &pinctrl_2;
pinctrl3 = &pinctrl_3;
pinctrl4 = &pinctrl_4;
i2c0 = &i2c_0;
i2c1 = &i2c_1;
i2c2 = &i2c_2;
i2c3 = &i2c_3;
i2c4 = &hsi2c_4;
i2c5 = &hsi2c_5;
i2c6 = &hsi2c_6;
i2c7 = &hsi2c_7;
i2c8 = &hsi2c_8;
i2c9 = &hsi2c_9;
i2c10 = &hsi2c_10;
gsc0 = &gsc_0;
gsc1 = &gsc_1;
spi0 = &spi_0;
spi1 = &spi_1;
spi2 = &spi_2;
usbdrdphy0 = &usbdrd_phy0;
usbdrdphy1 = &usbdrd_phy1;
};
Click to expand...
Click to collapse
As you can see, the I2C's are numbered from 0 to 10, making them 11 in total, where i2c's 4 - 10 apparently have the "high speed" or hs setting enabled.
This is a bit confusing to me, because the I2C buses that are actually in use, as seen in rootfs/sys/bus/i2c/devices, gives a different set of numbers:
i2c-0
i2c-1
i2c-3
i2c-7
i2c-8
i2c-10
i2c-17
i2c-18
i2c-22
i2c-24
Click to expand...
Click to collapse
And here are the devices assigned to them:
i2c-0
[email protected]
[email protected] (screen)
i2c-1
[email protected]
i2c-3
[email protected]
[email protected]
[email protected]
[email protected]
i2c-7
[email protected]
i2c-8
[email protected] (the digitizer or epen)
(?)@9 // device name not listed, but the address is the same as that of the maxim pmic on i2c-7 //
i2c-10
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
i2c-17
(?)@25
(?)@48
[email protected]
i2c-18
[email protected]
i2c-22
[email protected]
i2c-24
[email protected]
[email protected]
In the "drivers" folder I also found the following, but they were not assigned to a bus or an address:
exynos_edid
exynos_hdcp
ir-kbd-i2c
Click to expand...
Click to collapse
Anyway, if the i2c buses only go from 0 - 10 in the generic Exynos5420 device tree, then why do we also have 17, 18, 22 and 24 appearing here?
Furthermore, here is how their addresses are listed in the stock source code (arch/arm/mach-exynos/include/map.h)
#define EXYNOS5_PA_IIC(x) (0x12C60000 + ((x) * 0x10000))
#define EXYNOS5420_PA_HSIIC0 0x12CA0000
#define EXYNOS5420_PA_HSIIC1 0x12CB0000
#define EXYNOS5420_PA_HSIIC2 0x12CC0000
#define EXYNOS5420_PA_HSIIC3 0x12CD0000
#define EXYNOS5420_PA_HSIIC4 0x12E00000
#define EXYNOS5420_PA_HSIIC5 0x12E10000
#define EXYNOS5420_PA_HSIIC6 0x12E20000
Click to expand...
Click to collapse
Aaaand if we look into rootfs/proc/iomem, we find this:
12c60000-12c60fff : s3c2440-i2c
12c70000-12c70fff : s3c2440-i2c.1
12c70000-12c70fff : s3c2440-i2c
12c90000-12c90fff : s3c2440-i2c.3
12c90000-12c90fff : s3c2440-i2c
12cd0000-12cd0fff : exynos5-hs-i2c
12e00000-12e00fff : exynos5-hs-i2c
12e20000-12e20fff : exynos5-hs-i2c.6
12e20000-12e20fff : exynos5-hs-i2c
12c60000-12c60fff : s3c2440-i2c.0
12cd0000-12cd0fff : exynos5-hs-i2c.3
12e00000-12e00fff : exynos5-hs-i2c.4
Click to expand...
Click to collapse
I'm currently working on building CM12 with some additional packages such as i2c-tools and some extra kernel debugging features. But in the meantime, if anyone here can help solve this entire I2C puzzle then it would be of great help. We have the devices, their addresses, etc., but which bus is which compared to the generic Exynos5420 device tree "header" (for lack of a better term) is my biggest question at the moment.
If the final outcome of this project actually works, then there won't be anything standing in the way of compiling, say, linux-linaro-lsk-v3.10-android with full HMP support. Sure, some proprietary kernel drivers may have to be integrated such as the Mali drivers but I have already tried to bake them into linux 3.14 and it compiled without any errors whatsoever. Hell, we might even be able to finally upgrade them by grabbing the latest sources from ARM! In any case it's worth a try because f*ck the sammy police!
So as far as I can tell, Samsung have decided that despite having five free I2C ports, they're going to move four of their I2Cs to be bit-banged on GPIOs. I think this should be sufficient for those four (11, 17, 22 and 24) in a device tree:
Code:
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpd1 4 0 /* sda */
&gpd1 5 0 /* scl */
>;
i2c-gpio,delay-us = <1>;
#address-cells = <1>;
#size-cells = <0>;
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpb3 6 0 /* sda */
&gpb3 7 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa1 5 0 /* sda */
&gpa1 4 0 /* scl */
>;
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa2 2 0 /* sda */
&gpa2 3 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
};
The addresses of the other ports appear to agree with the existing code in exynos5420-pinctrl.dtsi:
Code:
s3c2440-i2c.0 = [email protected]
s3c2440-i2c.1 = [email protected]
s3c2440-i2c.2 = [email protected]
s3c2440-i2c.3 = [email protected]
exynos5-hs-i2c.0 = [email protected]
exynos5-hs-i2c.1 = [email protected]
exynos5-hs-i2c.2 = [email protected]
exynos5-hs-i2c.3 = [email protected]
exynos5-hs-i2c.4 = [email protected]
exynos5-hs-i2c.5 = [email protected]
exynos5-hs-i2c.6 = [email protected]
-d
Well, HMP is trully what's left missing from this tab. I mean we've got good roms, AOSP support, having its hardware completely unlocked would be the last piece of the puzzle at it were ... Personally it would give me smooth Linux via framebuffer, at it stands it's CPU (core) limited, often maxing all 4 cores, having 8 cores to stretch its legs even with throttling in place (it) would be a blessing. Smooth desktop OS on a Note tablet would be a first.
Hmmm, having no (significant) kernel experience my support would be confined to that of encouragement ... oh well. Good luck to you sir!
I'm out of town and left my laptop at home, but here's a new draft for the iic nodes I made on my phone:
Code:
[email protected] {
[email protected] {
};
[email protected] {
};
};
[email protected] {
[email protected] {
};
};
[email protected] {
[email protected] {
};
[email protected] {
};
[email protected] {
};
[email protected] {
};
};
[email protected] {
clock-frequency = <400000>;
status = "okay";
[email protected] {
compatible = "maxim,max77802";
interrupt-parent = <&gpx0>;
interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&max77802_irq>;
wakeup-source;
reg = <0x9>;
voltage-regulators {
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
regulator-min-microvolt = <700000>;
regulator-max-microvolt = <1300000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck2_reg: BUCK2 {
regulator-name = "vdd_arm";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1500000>;
regulator-apply-uV;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck3_reg: BUCK3 {
regulator-name = "vdd_int";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck4_reg: BUCK4 {
regulator-name = "vdd_g3d";
regulator-min-microvolt = <700000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck6_reg: BUCK6 {
regulator-name = "vdd_kfc";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1500000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
ldo2_reg: LDO2 {
regulator-name ="VMEM2_1.2V_AP";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo3_reg: LDO3 {
regulator-name = "VCC_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo4_reg: LDO4 {
regulator-name = "VMMC2_2.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo5_reg: LDO5 {
regulator-name = "VHSIC_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo6_reg: LDO6 {
regulator-name = "VXPLL_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo8_reg: LDO8 {
regulator-name = "VMIPI_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo9_reg: LDO9 {
regulator-name = "VADC_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo10_reg: LDO10 {
regulator-name = "VMIPI_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo11_reg: LDO11 {
regulator-name = "VDDQ_PRE_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo12_reg: LDO12 {
regulator-name = "VUOTG_3.0V_AP";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo14_reg: LDO14 {
regulator-name = "VABB1_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo15_reg: LDO15 {
regulator-name = "VHSIC_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo17_reg: LDO17 {
regulator-name = "VG3DS_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo18_reg: LDO18 {
regulator-name = "CAM_ISP_SENSOR_IO_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo19_reg: LDO19 {
regulator-name = "VT_CAM_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo23_reg: LDO23 {
regulator-name = "KEY_LED_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo24_reg: LDO24 {
regulator-name = "CAM_AF_2.8_PM";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo25_reg: LDO25 {
regulator-name = "VCC_3.3V_MHL";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo26_reg: LDO26 {
regulator-name = "VCC_3.0V_MOTOR";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo27_reg: LDO27 {
regulator-name = "VSIL_1.2A";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo28_reg: LDO28 {
regulator-name = "VCC_1.8V_MHL";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo29_reg: LDO29 {
regulator-name = "TSP_VDD_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo30_reg: LDO30 {
regulator-name = "VMIFS_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo32_reg: LDO32 {
regulator-name = "IRLED_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo33_reg: LDO33 {
regulator-name = "VCC_2.8V_AP";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo35_reg: LDO35 {
regulator-name = "CAM_SENSOR_CORE_1.2V";
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
};
};
};
[email protected] {
[email protected] {
};
};
[email protected] {
[email protected] {
};
[email protected] {
};
[email protected] {
};
[email protected] {
};
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpd1 4 0 /* sda */
&gpd1 5 0 /* scl */
>;
i2c-gpio,delay-us = <1>;
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpb3 6 0 /* sda */
&gpb3 7 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa1 5 0 /* sda */
&gpa1 4 0 /* scl */
>;
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa2 2 0 /* sda */
&gpa2 3 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
[email protected] {
};
};
EDIT:
Oh and some great news! I just had a long and interesting conversation with a local who noticed me while I was writing this earlier and asked me about it. Surprisingly, after I told him about my project he said he knew exactly what I was talking about. Turned out he's a developer who specializes in embedded linux systems and has actual experience with writing flattened device trees. What's even better is that he's willing to help me with this!
This has just taken an interesting turn so stay tuned...
Hi mate!
I really want to help you but I don't know how to programming in Linux(for the moment) and I know little bit in Android. My hoght school profile is based on IT and programming but unfortunately i don't make on these langage, I'm making only C++ and C#.The point is: I want to help you and the CM devs to resolve the bugs. I'm waiting response form Sand Pox.
If u find me useful pm to me and I will try to help u. Good luck !
Good luck!
Kryptocid said:
Hi mate!
I really want to help you but I don't know how to programming in Linux(for the moment) and I know little bit in Android. My hoght school profile is based on IT and programming but unfortunately i don't make on these langage, I'm making only C++ and C#.The point is: I want to help you and the CM devs to resolve the bugs. I'm waiting response form Sand Pox.
If u find me useful pm to me and I will try to help u. Good luck !
Click to expand...
Click to collapse
Hey! I just sent you a PM
I just put up a new repo with the current progress. I'll add more reference stuff later on, but here's the link to the repo: https://bitbucket.org/sigma-1/exynos5420_lt03wifi_dts
Hallo?
So, I think it's time to declare my research on the flattened device tree officially over. What I have thrown together so far gives me a good idea of how the fdt should eventually look like, although it's not completely accurate.
What should happen now is basically device driver development. Since I'm aiming for Linux 3.18.y there are some things that need to be considered. The SM-P600 relies on certain drivers that are exclusively present in the stock kernel, but some of them can also be found in other Samsung kernels which range from v3.4 to 3.10.
Some of these drivers can be swapped out for generic drivers, while others need to be ported over. My current plan is to start by compiling a system with only just the minimal hardware support to make it boot.
Android's branch of the 3.18 kernel has much of the required support already, but there are at least two major drivers that must be implemented, namely the LCD driver and drivers for the max77803 pmic from Maxim Integrated. The latter does not play that much of an essential part as the max77802 pmic which is already supported in the kernel, but one of the things it controls is the charging mechanism which I believe is pretty much essential.
Also, there is no support for the proprietary battery/charger/fuelgauge drivers from Samsung. Hopefully the generic driver works just as well even though I literally have no idea how it will work out.
Our max17050 fuel gauge is already supported, it's just the max77803 "charger" part that needs to be figured out.
Once the device boots, the rest of the drivers can be implemented one by one as kernel modules once they have been adapted to linux 3.18. That's also where device tree overlays come in, which is one of the cool features of the device tree implementation.
So, I guess I'm off to learn how to write linux device drivers. Guess I'll just write the LCD driver from scratch. The Maxim drivers all look very similar so the 3.4 verson can probably just be upgraded in accordance with the ones already present in Linus' tree.
Another thing to note here is that the ARM Mali GPU drivers are not present in the upstream linux kernel. On the other hand, they have been reverse-engineered and implemented into the Direct Rendering Manager (DRM). What that means though is that the proprietary libs will no longer work. Instead, libdrm would have to be implemented into the android source along with its exynos-specific support libs.
The Mali/Midgard drivers could be implemented into the kernel source, but I personally like the open source alternative better as long as it works.
Andmoreagain said:
So, I think it's time to declare my research on the flattened device tree officially over. What I have thrown together so far gives me a good idea of how the fdt should eventually look like, although it's not completely accurate.
What should happen now is basically device driver development. Since I'm aiming for Linux 3.18.y there are some things that need to be considered. The SM-P600 relies on certain drivers that are exclusively present in the stock kernel, but some of them can also be found in other Samsung kernels which range from v3.4 to 3.10.
Some of these drivers can be swapped out for generic drivers, while others need to be ported over. My current plan is to start by compiling a system with only just the minimal hardware support to make it boot.
Android's branch of the 3.18 kernel has much of the required support already, but there are at least two major drivers that must be implemented, namely the LCD driver and drivers for the max77803 pmic from Maxim Integrated. The latter does not play that much of an essential part as the max77802 pmic which is already supported in the kernel, but one of the things it controls is the charging mechanism which I believe is pretty much essential.
Also, there is no support for the proprietary battery/charger/fuelgauge drivers from Samsung. Hopefully the generic driver works just as well even though I literally have no idea how it will work out.
Our max17050 fuel gauge is already supported, it's just the max77803 "charger" part that needs to be figured out.
Once the device boots, the rest of the drivers can be implemented one by one as kernel modules once they have been adapted to linux 3.18. That's also where device tree overlays come in, which is one of the cool features of the device tree implementation.
So, I guess I'm off to learn how to write linux device drivers. Guess I'll just write the LCD driver from scratch. The Maxim drivers all look very similar so the 3.4 verson can probably just be upgraded in accordance with the ones already present in Linus' tree.
Another thing to note here is that the ARM Mali GPU drivers are not present in the upstream linux kernel. On the other hand, they have been reverse-engineered and implemented into the Direct Rendering Manager (DRM). What that means though is that the proprietary libs will no longer work. Instead, libdrm would have to be implemented into the android source along with its exynos-specific support libs.
The Mali/Midgard drivers could be implemented into the kernel source, but I personally like the open source alternative better as long as it works.
Click to expand...
Click to collapse
Keep it up! Good work
Is it worth considering a possible arm port of Ubuntu? How about Ubuntu Touch to make use of SPEN?
So far it looks as though your effort has the depth and scope ... is it something you would consider worth exploring?
xda_nikita said:
Is it worth considering a possible arm port of Ubuntu? How about Ubuntu Touch to make use of SPEN?
So far it looks as though your effort has the depth and scope ... is it something you would consider worth exploring?
Click to expand...
Click to collapse
I actually intend on starting with building a regular Linux rootfs with a desktop distro such as Ubuntu before jumping on to a full android build. In regards to s-pen functionality, I won't be focusing on that until everything else is working as it should. I hope it can be supported eventually though. I myself would love to be able to draw directly in GIMP or InkScape with the s-pen.
My first aim is to get the u-boot bootloader up and running. That alone would open up a lot of possibilities for future development as well as true multi boot.
So I've been tinkering with this a bit, and I'm currently pulling in some Samsung drivers to a linux-linaro v3.13 tree. I decided to go with this particular kernel base since it's not too different from linux 3.10 and because it has native support for exynos5420 which upstream android/linux-3.10 doesn't. My original thought was to use linux 3.18, but it just presented me with too much incompatibility with the 3.10 drivers.
I've also found a suitable driver for the max77803 PMIC. It's actually for max77888, but our stock driver is based on the max77888 driver and they're almost identical for that matter. Pulled it in from a 3.10 tree along with the battery+motor drivers and a driver for the sii8240 chip. I'm still fixing up some missing includes before I start diffing it against the stock drivers. I'll post an update once it all compiles without an issue.
Edit:
Fixed up some build errors with the sec_battery driver, now running into some "field has incomplete type" error with max17050 fuelgauge driver. Not sure what to make of this so if anyone has any ideas it would be greatly appreciated.
Code:
LD drivers/base/built-in.o
CC drivers/battery/sec_battery.o
CC drivers/battery/sec_adc.o
CC drivers/battery/max17050_fuelgauge.o
In file included from drivers/battery/max17050_fuelgauge.c:15:0:
include/linux/battery/sec_fuelgauge.h:60:19: error: field 'fuel_alert_wake_lock' has incomplete type
struct wake_lock fuel_alert_wake_lock;
^
scripts/Makefile.build:308: recipe for target 'drivers/battery/max17050_fuelgauge.o' failed
make[2]: *** [drivers/battery/max17050_fuelgauge.o] Error 1
scripts/Makefile.build:455: recipe for target 'drivers/battery' failed
make[1]: *** [drivers/battery] Error 2
Makefile:816: recipe for target 'drivers' failed
make: *** [drivers] Error 2
Source code: https://bitbucket.org/sigma-1/linux-linaro-3.13-2014.01
I also find Samsung's 3.10 kernels a bit odd looking in some aspects. They still use deprecated macros such as __devinit and __devexit that shouldn't be present in 3.10 at all. Anyway, I'm gonna continue to try and sort this out.
Hi not a developer (so far) but did someone read about this device here?
There is a Linux running on an Samsung Exynos5422 Cortex™-A15
Its maybe helpfull to get some stuff thats not supported from Samsung opensource
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825
peterpan07 said:
Hi not a developer (so far) but did someone read about this device here?
There is a Linux running on an Samsung Exynos5422 Cortex™-A15
Its maybe helpfull to get some stuff thats not supported from Samsung opensource
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825
Click to expand...
Click to collapse
Yeah, the Exynos series of SoC's are all supported upstream, including Exynos 5420. The current kernel base I'm using comes from Linaro and not Samsung OSRC and it has most of the required support already. The upstream kernel actually has much better and advanced support for the Exynos series than any of Samsung's stock kernels. They just seem to be more interested in actually providing upstream support for the development boards while end-user devices such as phones and tablets get no such support. It's understandable and in most cases this doesn't really make much difference to the end-user. Exynos 5420 is a special case though IMO because our stock kernel still doesn't properly support all the capabilities it has to offer.
The issue we're facing is basically that Samsung's phones and tablets rely on hardware that isn't entirely supported upstream. Like I've mentioned before, an example would be the PMICs that are commonly used in Samsung's products. Usually these are chips manufactured by Maxim Integrated and while a handful of these chips have upstream kernel support, most of them don't and their drivers are exclusively found in Samsung OSRC kernel trees. Thankfully the PMICs are the least of my worries in this context because these drivers are all based on one another and all look pretty similar for that matter. Basically the only thing that truly needs to be worked upon in this early phase is the driver for our LCD (LSL101DL01). If simply adding OF/Device Tree support to the driver doesn't work then it may have to be rewritten in order for it to work properly with linux v3.10 and higher. I simply haven't started looking into it enough to be able to say anything about it at this point.
The PMICs are my current priority, since support for max77802/803 will also be needed for the u-boot bootloader as far as my understanding goes. Otherwise it doesn't seem like u-boot requires much driver support compared to the kernel.
Current todo list:
- Apply upstream patches for max77802 support
- Get max77803 (muic, motor, leds, charger), max17050 (fuel gauge) and Samsung's battery drivers working
- Forward-port the LCD driver to play nicely with Linux v3.10 or higher
- Add device tree bindings for all of the above
Again, any help would be appreciated. I'm personally just learning things as I go along so if there's anyone here who has experience with C/kernel programming and might be willing to contribute to this project or even just provide some insight or ideas, then please let me know! The more, the merrier!

Bypass bootloader lock of Redmi 5A(riva) without permission from xiaomi.

Recently I have reverse engineered aboot (emmc_appsboot.mbn) from ROM riva_images_V8.5.7.0.NCKCNED_20171025.0000.00_7.1_cn ( en.miui.com/thread-1026306-1-1.html )(because this is my first post and I don't have permission to post outside link, you have to add http in those url), and discovered a way to bypass bootloader lock by using several bugs in Xiaomi customized aboot.
Xiaomi's aboot is based on Qualcomm's little kernel which is open sourced and can be download at source.codeaurora.org/quic/le/kernel/lk/ , so I will use function name inside those source file in discussion below even though some of those function have been modified by Xiaomi.
Relevant function to verify and boot linux is boot_linux_from_mmc, so I'll start from here:
boot_linux_from_mmc: call boot_verifier_init()
boot_verifier_init: set device state to GREEN​ boot_linux_from_mmc: call verify_signed_bootimg()
verify_signed_bootimg: call boot_verify_image()
boot_verify_image: call read_der_message_length() to get length of signature
boot_verify_image: if length of signature is too large, then boot_verify_image will return false to indicate verification failure
boot_verify_image: otherwise call and return verification result of verify_image_with_sig(inlined)
verify_image_with_sig: set device state to RED if image is not signed by Xiaomi.​ verify_signed_bootimg: call splash_screen_mmc() to show "The system has been destroyed" if verification failed
verify_signed_bootimg: shoudown device if splash_screen_mmc() succeed, otherwise continue boot​ boot_linux_from_mmc: call send_rot_command()
send_rot_command: check device state, if it's YELLOW or RED, than boot will failed because it try to read embedded cert which is not initialized by Xiaomi​
To successfully bypass bootloader lock we need:
1. make sure device state is GREEN so that send_rot_command won't failed, this can be achieved by making read_der_message_length return a large value to avoid calling verify_image_with_sig.
one way to do this is to append[NOTE1] image with a large length encoded in der (eg. 0x30, 0x83, 0x19, 0x89, 0x64)
2. make sure splash_screen_mmc() failed so that booting process can be continued.
this can be achieved by change the magic number in the header of splash partition from "SPLASH!!" to any other value (eg. "19890604")
Steps to bypass:
0 note that all those steps can be done offline, so no information will send to Xiaomi or anyone
0 in this tutorial I'll demonstrate how to use twrp recovery with locked bootloader
1 using test point to enter EDL mode(will void your warranty!!!)
2 unzip MiFlash, you should see QSaharaServer.exe and fh_loader.exe
3 create a sub folder called "tmp"
4 extract prog_emmc_firehose_8917_ddr.mbn & rawprogram0.xml & splash.img from riva_images_V8.5.7.0.NCKCNED_20171025.0000.00_7.1_cn and put them into "tmp"
5 append a 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64 to twrp-3.2.1-0-riva.img then put the resulting file to "tmp" and rename it to "recovery.img"
6 change the first 8 byte in splash.img to "19890604"
7 create "hack_splash.xml" inside "tmp", then copy&paste relevant section from rawprogram0.xml to "hack_splash.xml", the resulting file should look like this:
Code:
<?xml version="1.0" ?>
<data>
<program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="splash.img" label="splash" num_partition_sectors="40960" physical_partition_number="0" size_in_KB="20480.0" sparse="false" start_byte_hex="0x14000000" start_sector="655360" />
</data>
8 create "twrp.xml" inside "tmp", then copy&paste relevant recovery section from rawprogram0.xml to "twrp.xml", the resulting file should look like this:
Code:
<?xml version="1.0" ?>
<data>
<program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="recovery.img" label="recovery" num_partition_sectors="131072" physical_partition_number="0" size_in_KB="65536.0" sparse="false" start_byte_hex="0x1c200000" start_sector="921600" />
</data>
9 run "QSaharaServer.exe -p \\.\COM10 -s 13rog_emmc_firehose_8917_ddr.mbn -b tmp" to initialize firehose. (replace COM10 with the COM port of you phone, the same as below)
10 run "fh_loader.exe --search_path=tmp --port=\\.\COM10 --sendxml=hack_splash.xml" to flash modified splash
11 run "fh_loader.exe --search_path=tmp --port=\\.\COM10 --sendxml=twrp.xml" to flash twrp recovery
12 done
If you want flash custom ROM, you just need to append[NOTE1] boot.img
NOTE1: append should work in most case, but not always. the corrected place to write 0x30, 0x83, 0x19, 0x89, 0x64 is calculate from image header, it's defined as:
Code:
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned dt_size; /* device_tree in bytes */
unsigned unused; /* future expansion: should be 0 */
....
};
and then calculate:
Code:
if (hdr->page_size && (hdr->page_size != page_size)) {
page_size = hdr->page_size;
page_mask = page_size - 1;
}
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask);
second_actual = ROUND_TO_PAGE(hdr->second_size, page_mask);
dt_size = hdr->dt_size;
dt_actual = ROUND_TO_PAGE(dt_size, page_mask);
imagesize_actual = (page_size + kernel_actual + ramdisk_actual + second_actual + dt_actual);
imagesize_actual is the place to write
NOTE2: There may be a easier way to enter EDL considering there are so many bug(eg. uninitialized stack variable, buffer overrun, missing bound check) in Xiaomi's modification, but I haven't bothered to check since my goal is achieved.
NOTE3: I suspect other model from Xiaomi may have similar bugs that bootloader lock can be bypassed using this method, but I don't have other phones to confirm my belief.
xaacnz said:
Xiaomi's aboot is based on Qualcomm's little kernel which is open sourced and can be download at source.codeaurora.org/kernel/lk/
Click to expand...
Click to collapse
Did you meant: source.codeaurora.org/quic/le/kernel/lk
abdihaikal said:
Did you meant: source.codeaurora.org/quic/le/kernel/lk
Click to expand...
Click to collapse
Yes, they must have removed the original url.
Code:
[email protected]:~/lk$ git remote show origin | head
* remote origin
Fetch URL: https://source.codeaurora.org/kernel/lk/
Push URL: https://source.codeaurora.org/kernel/lk/
HEAD branch (remote HEAD is ambiguous, may be one of the following):
aosp/master
github-kernel_lk/aosp/master
Remote branches:
APSS.FSM.3.0 tracked
APSS.FSM.3.0.r5.1.1 tracked
APSS.FSM.3.0.r6 tracked
Thank you for the method.
I tried ot and flashed TWRP only, but when I use it to flash custom ROMS, the device wont boot. It will show for a millisecond a picture of penguin and then goes off.
Any ideas??
Thanks
xaacnz said:
Recently I have reverse engineered aboot....
If you want flash custom ROM, you just need to append[NOTE1] boot.img
NOTE1: append should work in most case, but not always. the corrected place to write 0x30, 0x83, 0x19, 0x89, 0x64 is calculate from image header, it's defined as:.
Click to expand...
Click to collapse
You need to patch boot.img inside those ROMS by appending 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64
utumno00 said:
Thank you for the method.
I tried ot and flashed TWRP only, but when I use it to flash custom ROMS, the device wont boot. It will show for a millisecond a picture of penguin and then goes off.
Any ideas??
Thanks
Click to expand...
Click to collapse
I am amazed and I dont know how to tell that I thank you. Can you help me? I patch and i flash what?
xaacnz said:
You need to patch boot.img inside those ROMS by appending 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64
Click to expand...
Click to collapse
Let's say you want flash https://forum.xda-developers.com/android/development/rom-crdroid-v3-8-5-redmi-5a-t3752066
1 download crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
2 extract boot.img from crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
3 patch the extracted boot.img just like what you did with twrp-3.2.1-0-riva.img
4 put the patched boot.img back in crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
5 flash the modified crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
utumno00 said:
I am amazed and I dont know how to tell that I thank you. Can you help me? I patch and i flash what?
Click to expand...
Click to collapse
Success!!
I tried with Viper ROM though, as it was the one I had already downloaded.
Is the crDroid the one that you suggest?
Have you tried the Oreo one?
I want to thank you one more time for the help.
Greetings from Greece and Colombia.
xaacnz said:
Let's say you want flash https://forum.xda-developers.com/android/development/rom-crdroid-v3-8-5-redmi-5a-t3752066
1 download crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
2 extract boot.img from crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
3 patch the extracted boot.img just like what you did with twrp-3.2.1-0-riva.img
4 put the patched boot.img back in crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
5 flash the modified crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
Click to expand...
Click to collapse
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
utumno00 said:
Success!!
I tried with Viper ROM though, as it was the one I had already downloaded.
Is the crDroid the one that you suggest?
Have you tried the Oreo one?
I want to thank you one more time for the help.
Greetings from Greece and Colombia.
Click to expand...
Click to collapse
Can you share your own rom base on LOS 15.1? Please
xaacnz said:
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
Click to expand...
Click to collapse
It's has some custom modifications like swapping back & recent app buttons as I'm left handed, I will try to build a more generic one once I get some free time.
boyrobbie said:
Can you share your own rom base on LOS 15.1? Please
Click to expand...
Click to collapse
@xaacnz
That's a very informative post :good:
Perhaps you can dump the firmware related partitions before and after unlocking the bootloader 'officially', so that it can be easier for us to find (possible) ways to unlock (not bypass) devices based on Xiaomi's implementation of Qualcomm LK.
I'm tagging @osm0sis to take part in the discussion.
xaacnz said:
It's has some custom modifications like swapping back & recent app buttons as I'm left handed, I will try to build a more generic one once I get some free time.
Click to expand...
Click to collapse
Thanks for your kindness, i'm waiting for that
Titokhan said:
@xaacnz
That's a very informative post :good:
Perhaps you can dump the firmware related partitions before and after unlocking the bootloader 'officially', so that it can be easier for us to find (possible) ways to unlock (not bypass) devices based on Xiaomi's implementation of Qualcomm LK.
I'm tagging @osm0sis to take part in the discussion.
Click to expand...
Click to collapse
All stages of bootloader except PBL can be found in fastboot ROM, and PBL can be obtained by using testpoint: https://alephsecurity.com/2018/01/22/qualcomm-edl-1/
The 'official' unlocking process is:
1 submit cpuid which is eFused in soc to Xiaomi.
2 Xiaomi sign the cpuid with it's private RSA key.
3 write the signature to 'devinfo' partition at offset 0xE4.
The verification process is:
1 read the signature from 'devinfo' partition.
2 verify it using public key embedded in aboot.
3 decode the verification result as base64.
4 compare the decoded value with cpuid read from soc, bootloader is unlocked if it's the same.
There are some bugs in verification process:
1 signature is padded using PKCS #1 v1.5, but verification process didn't check plaintext size, thus any plaintext starts with desired prefix will unlock bootloader, effectively reducing the complexity of brute force.
2 any value outside of base64's 64 characters table is treated as 'A', this reduce brute force complexity further.
3 base64 decode will not terminate until '=' is encountered, this create opportunity for buffer overrun, though input(RSA verification result) is hard to control.
4 base64 decode is skipped if first byte of PKCS #1 v1.5 payload is zero, this resulting in comparison of uninitialized stack value to cpuid and maybe exploitable to unlock phone.
I'm shocked that one can write so many bugs in such short function.
xaacnz said:
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
Click to expand...
Click to collapse
Bro! we have been using the build you uploaded on android file host on may 16 2018. The build you uploaded has all bugs fixed in lineage OS 15.1. Some developers of Redmi 5a(RIVA) has been trying to contact you. They need the source of your ROM and kernel you uploaded on 16 may. Please reply.
xaacnz said:
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
Click to expand...
Click to collapse
Would you mind sharing your device and kernel sources which you are using? We all have issues with audio which are related to kernel.
It would be great for development on Redmi 5A in general if you could share your sources with the community.
If you don't want to share them for any reason, you could maybe help us fixing the speaker bug on our sources: https://github.com/redmidevs/android_kernel_xiaomi_msm8917
boyrobbie said:
Can you share your own rom base on LOS 15.1? Please
Click to expand...
Click to collapse
LordShenron said:
Bro! we have been using the build you uploaded on android file host on may 16 2018. The build you uploaded has all bugs fixed in lineage OS 15.1. Some developers of Redmi 5a(RIVA) has been trying to contact you. They need the source of your ROM and kernel you uploaded on 16 may. Please reply.
Click to expand...
Click to collapse
33bca said:
Would you mind sharing your device and kernel sources which you are using? We all have issues with audio which are related to kernel.
It would be great for development on Redmi 5A in general if you could share your sources with the community.
If you don't want to share them for any reason, you could maybe help us fixing the speaker bug on our sources: https://github.com/redmidevs/android_kernel_xiaomi_msm8917
Click to expand...
Click to collapse
Here it is: lineage-15.1-20180515-UNOFFICIAL-riva.zip
Kernel source: https://github.com/xaacnz/android_kernel_xiaomi_msm8917
I tried to post this ROM on https://forum.xda-developers.com/xiaomi-redmi-5a/development , but my account don't have permission to do that, so I have to post it here in case anyone is interested.
xaacnz said:
Here it is: lineage-15.1-20180515-UNOFFICIAL-riva.zip
Kernel source: https://github.com/xaacnz/android_kernel_xiaomi_msm8917
I tried to post this ROM on https://forum.xda-developers.com/xiaomi-redmi-5a/development , but my account don't have permission to do that, so I have to post it here in case anyone is interested.
Click to expand...
Click to collapse
We have been trying to get around a bug in our builds. Your sources will be a great help for whole riva community Thank you so much.
Thanks
xaacnz said:
Here it is: lineage-15.1-20180515-UNOFFICIAL-riva.zip
Kernel source: https://github.com/xaacnz/android_kernel_xiaomi_msm8917
I tried to post this ROM on https://forum.xda-developers.com/xiaomi-redmi-5a/development , but my account don't have permission to do that, so I have to post it here in case anyone is interested.
Click to expand...
Click to collapse
Thanks again.
xaacnz said:
5 append a 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64 to twrp-3.2.1-0-riva.img then put the resulting file to "tmp" and rename it to "recovery.img"
If you want flash custom ROM, you just need to append[NOTE1] boot.img
NOTE1: append should work in most case, but not always. the corrected place to write 0x30, 0x83, 0x19, 0x89, 0x64 is calculate from image header, it's defined as:
Code:
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned dt_size; /* device_tree in bytes */
unsigned unused; /* future expansion: should be 0 */
....
};
and then calculate:
Code:
if (hdr->page_size && (hdr->page_size != page_size)) {
page_size = hdr->page_size;
page_mask = page_size - 1;
}
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask);
second_actual = ROUND_TO_PAGE(hdr->second_size, page_mask);
dt_size = hdr->dt_size;
dt_actual = ROUND_TO_PAGE(dt_size, page_mask);
imagesize_actual = (page_size + kernel_actual + ramdisk_actual + second_actual + dt_actual);
imagesize_actual is the place to write
NOTE2: There may be a easier way to enter EDL considering there are so many bug(eg. uninitialized stack variable, buffer overrun, missing bound check) in Xiaomi's modification, but I haven't bothered to check since my goal is achieved.
NOTE3: I suspect other model from Xiaomi may have similar bugs that bootloader lock can be bypassed using this method, but I don't have other phones to confirm my belief.
Click to expand...
Click to collapse
Hello!
I am not very familliar with programming or ROM development.
Could you please explain a bit more specific about NOTE1, how to append 4K block?
I don't quite understand where should I add it. At the beginning of the image, at the end or at the specific place in that file?
And 4k block means 4 kilobytes? Like 4096 bytes?
And if I need to flash custom room should I change something in xml files to? Or just append will be sufficient?
Please help, I need to flash that Riva finally!

Categories

Resources