Database Info

eMMC sudden death research

Update from Feb 17th:
Samsung has started to upgrade eMMC firmwares on the field - only for GT-I9100 for now.
See post #79 for additional details.
Update from Feb 13th:
If you want to dump the eMMC's RAM yourself, go ahead to post #72.
I'm looking for a dump of firmware revision 0xf7 if you've got one.
-----------------------
Since it's very likely that the recent eMMC firmware patch by Samsung is their patch for the "sudden death" issue, it would be very nice to understand what is really going on there.
According to a leaked moviNAND datasheet, it seems that MMC CMD62 is vendor-specific command that moviNAND implements.
If you issue CMD62(0xEFAC62EC), then CMD62(0xCCEE) - you can read a "Smart report". To exit this mode, issue CMD62(0xEFAC62EC), then CMD62(0xDECCEE).
So what are they doing in their patch?
1. Whenever an MMC is attached:a. If it is "VTU00M", revision 0xf1, they read a Smart report.
b. The DWORD at Smart[324:328] represents a date (little-endian); if it is not 0x20120413, they don't patch the firmware. (Maybe only chips from 2012/04/13 are buggy?)​2. If the chip is buggy, whenever an MMC is attached or the device is resumed:a. Issue CMD62(0xEFAC62EC) CMD62(0x10210000) to enter RAM write mode. Now you can write to RAM by issuing MMC_ERASE_GROUP_START(Address to write) MMC_ERASE_GROUP_END(Value to be written) MMC_ERASE(0).
b. *(0x40300) = 10 B5 03 4A 90 47 00 28 00 D1 FE E7 10 BD 00 00 73 9D 05 00
c. *(0x5C7EA) = E3 F7 89 FD
d. Exit RAM write mode by issuing CMD62(0xEFAC62EC) CMD62(0xDECCEE).​10 B5 looks like a common Thumb push (in ARM architecture). Disassembling the bytes that they write to 0x40300 yields the following code:
Code:
ROM:00040300 PUSH {R4,LR}
ROM:00040302 LDR R2, =0x59D73
ROM:00040304 BLX R2
ROM:00040306 CMP R0, #0
ROM:00040308 BNE locret_4030C
ROM:0004030A
ROM:0004030A loc_4030A ; CODE XREF: ROM:loc_4030Aj
ROM:0004030A B loc_4030A
ROM:0004030C ; ---------------------------------------------------------------------------
ROM:0004030C
ROM:0004030C locret_4030C ; CODE XREF: ROM:00040308j
ROM:0004030C POP {R4,PC}
ROM:0004030C ; ---------------------------------------------------------------------
Disassembling what they write to 0x5C7EA yields this:
Code:
ROM:0005C7EA BL 0x40300
Looks like it is indeed Thumb code.
If we could dump the eMMC RAM, we would understand what has been changed.
By inspecting some code, it seems that we know how to dump the eMMC RAM:
Look at the function mmc_set_wearlevel_page in line 206. It patches the RAM (using the method mentioned before), then it validates what it has written (in lines 255-290). Seems that the procedure to read the RAM is as following:
1. CMD62(0xEFAC62EC) CMD62(0x10210002) to enter RAM reading mode
2. MMC_ERASE_GROUP_START(Address to read) MMC_ERASE_GROUP_END(Length to read) MMC_ERASE(0)
3. MMC_READ_SINGLE_BLOCK to read the data
4. CMD62(0xEFAC62EC) CMD62(0xDECCEE) to exit RAM reading mode
I don't want to run this on my device, because I'm afraid - messing with the eMMC doesn't sound like a very good idea on my device (I don't have a spare one).
Does someone have a development device which he doesn't mind to risk, and want to dump the eMMC firmware from it?

Oranav said:
Since it's very likely that the recent eMMC firmware patch by Samsung is their patch for the "sudden death" issue, it would be very nice to understand what is really going on there.
According to a leaked moviNAND datasheet, it seems that MMC CMD62 is vendor-specific command that moviNAND implements.
If you issue CMD62(0xEFAC62EC), then CMD62(0xCCEE) - you can read a "Smart report". To exit this mode, issue CMD62(0xEFAC62EC), then CMD62(0xDECCEE).
So what are they doing in their patch?
1. Whenever an MMC is attached:a. If it is "VTU00M", revision 0xf1, they read a Smart report.
b. The DWORD at Smart[324:328] represents a date (little-endian); if it is not 0x20120413, they don't patch the firmware. (Maybe only chips from 2012/04/13 are buggy?)​2. If the chip is buggy, whenever an MMC is attached or the device is resumed:a. Issue CMD62(0xEFAC62EC) CMD62(0x10210000) to enter RAM write mode. Now you can write to RAM by issuing MMC_ERASE_GROUP_START(Address to write) MMC_ERASE_GROUP_END(Value to be written) MMC_ERASE(0).
b. *(0x40300) = 10 B5 03 4A 90 47 00 28 00 D1 FE E7 10 BD 00 00 73 9D 05 00
c. *(0x5C7EA) = E3 F7 89 FD
d. Exit RAM write mode by issuing CMD62(0xEFAC62EC) CMD62(0xDECCEE).​10 B5 looks like a common Thumb push (in ARM architecture). Disassembling the bytes that they write to 0x40300 yields the following code:
Code:
ROM:00040300 PUSH {R4,LR}
ROM:00040302 LDR R2, =0x59D73
ROM:00040304 BLX R2
ROM:00040306 CMP R0, #0
ROM:00040308 BNE locret_4030C
ROM:0004030A
ROM:0004030A loc_4030A ; CODE XREF: ROM:loc_4030Aj
ROM:0004030A B loc_4030A
ROM:0004030C ; ---------------------------------------------------------------------------
ROM:0004030C
ROM:0004030C locret_4030C ; CODE XREF: ROM:00040308j
ROM:0004030C POP {R4,PC}
ROM:0004030C ; ---------------------------------------------------------------------
Disassembling what they write to 0x5C7EA yields this:
Code:
ROM:0005C7EA BL 0x40300
Looks like it is indeed Thumb code.
If we could dump the eMMC RAM, we would understand what has been changed.
By inspecting some code, it seems that we know how to dump the eMMC RAM:
Look at the function mmc_set_wearlevel_page in line 206. It patches the RAM (using the method mentioned before), then it validates what it has written (in lines 255-290). Seems that the procedure to read the RAM is as following:
1. CMD62(0xEFAC62EC) CMD62(0x10210002) to enter RAM reading mode
2. MMC_ERASE_GROUP_START(Address to read) MMC_ERASE_GROUP_END(Length to read) MMC_ERASE(0)
3. MMC_READ_SINGLE_BLOCK to read the data
4. CMD62(0xEFAC62EC) CMD62(0xDECCEE) to exit RAM reading mode
I don't want to run this on my device, because I'm afraid - messing with the eMMC doesn't sound like a very good idea on my device (I don't have a spare one).
Does someone have a development device which he doesn't mind to risk, and want to dump the eMMC firmware from it?
Click to expand...
Click to collapse
:crying: --> **Ultimate GS3 sudden death thread** :crying:
Just wanted to link to a prior thread with some information/testing that as been done. Completely understand if you nuke it because it doesn't meet the proper criteria or is way to noobish to be posted here. Anyway, just though it _might_ help, so giving it a shot..

So I decided to do a small RAM dump after all.
Before the patch, 0x5C7EA reads FD F7 C2 FA, which is "BL 0x59D72".
As I thought, they replace a function call to the new one.
I will dump function 0x59D72 later this week.

Oranav said:
So I decided to do a small RAM dump after all.
Before the patch, 0x5C7EA reads FD F7 C2 FA, which is "BL 0x59D72".
As I thought, they replace a function call to the new one.
I will dump function 0x59D72 later this week.
Click to expand...
Click to collapse
So it looks like the new function calls the old function, and then if it returns ZERO then in goes into an INFINITE loop?!?
Seems like an odd fix, maybe self presevation?
Oli

odewdney said:
So it looks like the new function calls the old function, and then if it returns ZERO then in goes into an INFINITE loop?!?
Seems like an odd fix, maybe self presevation?
Oli
Click to expand...
Click to collapse
WELL... after I changed to XXELLA stock firmware and stock kernel in 01/13 my 06/12 SGS3 had the _first freeze ever_ on XXELLA. Maybe its completely unrelated and was only a random thing.
But, could it be, that this fix temporary (until reboot) locks the eMMC in a bad situation to avoid damaging internal data structures?
But then in this cases you get a phone freeze, cause the eMMC is temporary unaviable so the phone crashes until you reboot it. But it avoided eMMC data structure damage.
Sounds not very logical, but when you have to fix a problem and only have a few bytes to patch it (cause it must be run on every emmc-start), and the problem only occurs on a hand full devices (out of millions) then it is maybe acceptable to have a freeze instead of a dead eMMC in that rare cases that it occurs.
But this is only a idea... don't now if it is like that.
BR
Rob
PS: Oranav, thank you very much for your effort.

odewdney said:
So it looks like the new function calls the old function, and then if it returns ZERO then in goes into an INFINITE loop?!?
Seems like an odd fix, maybe self presevation?
Oli
Click to expand...
Click to collapse
Right, haven't spotted this. Thanks for the observation.
Self preservation sounds possible.
Rob2222 said:
WELL... after I changed to XXELLA stock firmware and stock kernel in 01/13 my 06/12 SGS3 had the _first freeze ever_ on XXELLA. Maybe its completely unrelated and was only a random thing.
But, could it be, that this fix temporary (until reboot) locks the eMMC in a bad situation to avoid damaging internal data structures?
But then in this cases you get a phone freeze, cause the eMMC is temporary unaviable so the phone crashes until you reboot it. But it avoided eMMC data structure damage.
Sounds not very logical, but when you have to fix a problem and only have a few bytes to patch it (cause it must be run on every emmc-start), and the problem only occurs on a hand full devices (out of millions) then it is maybe acceptable to have a freeze instead of a dead eMMC in that rare cases that it occurs.
But this is only a idea... don't now if it is like that.
BR
Rob
PS: Oranav, thank you very much for your effort.
Click to expand...
Click to collapse
This could be possible - this patch looks like a quick and dirty fix, so maybe they didn't have the time to properly fix this. Instead, they just avoid the bug absolutely (with the cost of data corruption).
But I don't think this would cause lockups - I believe the chip has a watchdog...
All in all, I think the best thing we can do right now is to dump the whole firmware out of it. I will do it soon.

there is also a chance that this is just a temporary workaround to prevent further bricking - until there is a final fix.
As of now we asume that this is the fix as it directly adresses the eMMC in concern, but all this is just based on asumptions.

Rob2222 said:
WELL... after I changed to XXELLA stock firmware and stock kernel in 01/13 my 06/12 SGS3 had the _first freeze ever_ on XXELLA. Maybe its completely unrelated and was only a random thing.
But, could it be, that this fix temporary (until reboot) locks the eMMC in a bad situation to avoid damaging internal data structures?
But then in this cases you get a phone freeze, cause the eMMC is temporary unaviable so the phone crashes until you reboot it. But it avoided eMMC data structure damage.
Sounds not very logical, but when you have to fix a problem and only have a few bytes to patch it (cause it must be run on every emmc-start), and the problem only occurs on a hand full devices (out of millions) then it is maybe acceptable to have a freeze instead of a dead eMMC in that rare cases that it occurs.
But this is only a idea... don't now if it is like that.
BR
Rob
PS: Oranav, thank you very much for your effort.
Click to expand...
Click to collapse
I think we can prove that the fix is actualy locking into loop ,but you must risk your phone :/ . If you are in ->
1) Flash back to older version without the fix
2) Wait and pray
a) If your phone dies --> the guys were right about the fix and the loop
b) If it stays alive ,then ...
We wont know for sure ,but your phone is maybe in the "perfect" condition for the test :/ .
(Sorry if this makes no sence)

@ivan:
Sorry, can't do that. Cause of high air humidity my humidity indicator is already a little soaked. Cause of the warranty-repair reports in out local forums I am not sure if I would get warranty. I think theres a fair chance, that they would deny my warranty. Cause of that I don't want to take any extra risk. I am on unrooted stock at the moment, cause of that.
@Oranav:
In our local forum we get some reports about a rising count of locks and restarts on S3's in the last time. Some like my freeze.
It also seems that after a while this problems gets better and even disappear completely.
Cause of that I am thinking, if it could be, that the fix maybe locks the eMMC if it finds a bad data structure, then this locks maybe could bring a phone-freeze (already stated that), and in the same time it repairs the data structure in this block with the bad data structure.
At least this would explain some rising count of freezes with the fix and the point, that the freezes become less and less over time.
I have no idea if it's that way, I just wanted to post it as theory to think about.
BTW, do you think when the watchdog restarts the eMMC that it goes that fast that the phone isn't affected?
BR
Robert

Rob2222 said:
I have no idea if it's that way, I just wanted to post it as theory to think about.
Click to expand...
Click to collapse
The problem is that there are too many theories imaginable, but I can't think of no way to prove them but to reverse engineer the MoviNAND firmware.
Rob2222 said:
BTW, do you think when the watchdog restarts the eMMC that it goes that fast that the phone isn't affected?
Click to expand...
Click to collapse
Certainly not. Watchdogs are slow, drivers running on a Cortex-A9 are blazing fast.
But I do think Linux's MMC driver can handle device restarts during an MMC operation.

Rob2222 said:
@ivan:
Sorry, can't do that. Cause of high air humidity my humidity indicator is already a little soaked. Cause of the warranty-repair reports in out local forums I am not sure if I would get warranty. I think theres a fair chance, that they would deny my warranty. Cause of that I don't want to take any extra risk. I am on unrooted stock at the moment, cause of that.
@Oranav:
In our local forum we get some reports about a rising count of locks and restarts on S3's in the last time. Some like my freeze.
It also seems that after a while this problems gets better and even disappear completely.
Cause of that I am thinking, if it could be, that the fix maybe locks the eMMC if it finds a bad data structure, then this locks maybe could bring a phone-freeze (already stated that), and in the same time it repairs the data structure in this block with the bad data structure.
At least this would explain some rising count of freezes with the fix and the point, that the freezes become less and less over time.
I have no idea if it's that way, I just wanted to post it as theory to think about.
BTW, do you think when the watchdog restarts the eMMC that it goes that fast that the phone isn't affected?
BR
Robert
Click to expand...
Click to collapse
if those freezes are really caused by the firmware fix, I don't see how the would disappear over time...
I mean if it really is the case that the fix trades data corruption for eMMC survival, it would make sense to see freezes... but depending on what data is affected, they should only be treatable by reinstalling the affected app or deleting its data/cache.
updated theory:
for all we know the error condition where the eMMC dies is quite rare, since most devices have been used for month before they passed away. So under the assumption that the error condition appears randomly and that there is a chance of data corruption every time the condition appears with fixed kernel, we could expect to see freezes and other problems some time after the fix was applied. So that would explain the raising number of freezes reported. Furthermore I'd assume that people getting freezes would try to do something about it, like reinstalling/deleting apps wiping caches and/or data... or even reflashing, thus repairing the corrupted data. So freezes would disappear.
Wait, doesn't most evidence point to the fact that the error condition does NOT appear in a random fashion, since there were no cases in the beginning, and then a lot all of a sudden? Well, it might be that this is just the way we perceive the issue. Maybe there were cases before, but they weren't reported... phones died, people sent them in, got new ones and went on with their lives. But after some time the issue got known... bloggers wrote about it... and so on... people realized their phones died because of a wider problem... voila, steep raise in reported cases. Also the number of dying S3s would simply rise by a rising number of overall S3s, I mean Samsung kept selling phones, right?
But even under the assumption the bug is related to wear-levelling and not random, here is another idea: I have no clue how the algorithms work, but maybe it uses some sort of pseudo-random data to do whatever, with the same seed on all eMMCs... and thus all of them go through the same series of numbers. And now imagine the error condition is only triggered by a specific number or number set (say someone screwed up a boundary condition). Under this theory the error condition wouldn't appear randomly, but after a certain amount of write ops (or something).
Another question I asked myself is: shouldn't there be cases were data corruption does damage beyond all repair except for reflashing?
Well, it might be, but it seems reasonable to assume that it is a lot less likely than user-data corruption, since most critical files on the phone shouldn't be opened writeable (or are on a read-only mounted partition in the first place), hence shouldn't be affected by ****-ups during writes.
Like the previous poster I want to add that this is most likely all bull****... but it is what came to my mind looking for a theory that supports the data we got.

Okay, got a RAM dump
I won't post it here (or anywhere else for that matter) because I don't want to get sued by Samsung.
I might release a kernel which allows you to dump the RAM yourself if there's enough demand, but I don't want to right now, because:
1. The code is ugly as hell, not implemented as a kernel module, not thread-safe etc.
2. It is highly dangerous (messing with the eMMC chip - I really don't know how much stable this thing is), so if you want to do it on your device, you should be an expert. In that case, you can write the code yourself (with little effort)
Anyway, I hope the FTL is Whimory, since I'm familiar with it. Would be easier.
I'll let you know if I find anything interesting.
PS I've attached a little teaser. (Yes, this is the patched function. 0x40300 is red because I've opened a partial RAM dump.)
EDIT - Some initial results:
0. The CPU is a Cortex-M3.
1. No strings at all Just some uninteresting release asserts ("REL_ASSERT")
2. Found the Smart Report generator function -> found the MMC command handlers.
3. Most MMC commands handlers are stored in a function table. There are 3 special commands: MMC60, MMC62, MMC64. Depends on the arguments these special commands are provided, they modify the function table (this is the so called "vendor mode").
4. There are a lot of possible arguments for MMC62, not the only ones we know.
5. If you trace back the function they patch all the way up the call stack, you get to MMC24 and MMC25 handler. These commands are MMC_WRITE_BLOCK and MMC_WRITE_MULTIPLE_BLOCK. Since the function they patch is deep down the call stack, it's very likely that it is the wear level.
Anyway, because of the lack of strings I guess it would be very hard to truly understand the SDS bug we're facing

Odp: eMMC sudden death research
i cant say i have an idea whats going on inside emmc but usually in this case of mistakes/failures debug or diagnostics code is used for release.
maybe some debug info repeatedly written triggers wear levelling failure
so fix has to simply disable it

Awesome research.
So we're dealing with bug in exactly the same eMMC subsystem as in faulty SGS2 eMMC chips, but in device that was released after proving SGS2 eMMCs to be faulty.
Oranav, for some reason I cannot send you PMs. Could you send me your dump? Does your eMMC come from faulty serie?

Hi all, after reading this thread, I am now scared....
I have a Note 2 N7100 which is running ARHD V8.0 with Perseus Kernel V31.2 and TWRP recovery 3.2.2.3
The above all include the fix for SDS and Exynos hole.
I have been running the device for nearly 1 week I think. Last night I fully charged my phone, used it for 3 minutes surfing the forum (chrome) via wifi connection. After 3 minutes, I left the phone on the table for 3 hours. The only running app is Viber... when I tried to wake the phone up, it did wake up but it froze... no button worked, I tried for about 2 minutes... nothing worked except the power button which booted the device.
This is weird, never experienced this before... I am now scared the phone will die unexpectedly.

owl74 said:
Hi all, after reading this thread, I am now scared....
I have a Note 2 N7100 which is running ARHD V8.0 with Perseus Kernel V31.2 and TWRP recovery 3.2.2.3
The above all include the fix for SDS and Exynos hole.
I have been running the device for nearly 1 week I think. Last night I fully charged my phone, used it for 3 minutes surfing the forum (chrome) via wifi connection. After 3 minutes, I left the phone on the table for 3 hours. The only running app is Viber... when I tried to wake the phone up, it did wake up but it froze... no button worked, I tried for about 2 minutes... nothing worked except the power button which booted the device.
This is weird, never experienced this before... I am now scared the phone will die unexpectedly.
Click to expand...
Click to collapse
How long were you using the system before you had updated to the 'fix'? None the less, it does not necessarily mean that the phone is getting near to the SDS. I have had a few android phones which would sometimes reboot or hang for other reasons.

I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.
Rebellos, I enabled the private messaging system for me. I do have the faulty chip.
Sent from my GT-I9300 using xda app-developers app

Oranav said:
I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.
Click to expand...
Click to collapse
Damn Oranav, nice work!
So does it mean you get a total screen freeze? Every time?
BR
Robert

thealgorithm said:
How long were you using the system before you had updated to the 'fix'? None the less, it does not necessarily mean that the phone is getting near to the SDS. I have had a few android phones which would sometimes reboot or hang for other reasons.
Click to expand...
Click to collapse
About 2 weeks. Forgot to mention i reebooted the phone before I charged it. I will return this phone before it dies on me.... I think I will get an S3 but I will check if it has a new chip... otherwise I will return again and stick to my desire hd which is already running S3 rom....
---------- Post added at 02:24 PM ---------- Previous post was at 02:22 PM ----------
Oranav said:
I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.
Rebellos, I enabled the private messaging system for me. I do have the faulty chip.
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
So everyone's speculation is right about thw fix causing the freeze...

AW: eMMC sudden death research
Suppose this fix addresses wear leveling. If firmwares without this fix wear out the eMMC would then not the device still boot and then crash? As far as I know flash is still readable but not writable any more when worn out. Could it be that the wear leveling algorithm has a problem so that after some time it replaces cells from the bootloader and that causes the death?
In short: I want to know if it had a negative effect using the old firmware for some time because that old software caused extreme aging for the eMMC.

[Completed] e-Reader Pandigital Novel Black / Model R70E200 -- sh does not run due libs problem

Hello,
I have "Pandigital Novel Black / Model R70E200 / which supposedly runs Android 1.5" which went through SD card update which did not finished correctly.
My knowledge is limited at this moment about android internals but I am coming from PC Linux world which could help in resolution of following situation.
Yesterday I decided to read some documentation on the e-Reader but found that touch screen did not respond (buttons and orientation worked fine). I did attempted to restart the e-Reader a few times but without any success -- touch screen did not respond (the e-Reader was not used for prolonged period of time).
And it seems that by accident I "hit" a combination of buttons which supposedly initiated some unknown process at boot time. After this incident I had no option as to attempt to re-flash firmware.
For some inexplicable reason the flash process did not went as I would expect. Now it does not matter what I do process verification of firmware never ends.
I've attempted to get into "hard reset" but no success so far -- I always end up in re-flash situation.
To get at least some information for debugging of the situation I installed "adb" and was able to retrieve a log message which states following
link_image[1714]: 1760 could not load needed library 'libm.so' for '/system/bin
/sh' (link_image[1703]: 1760 missing essential tables)CANNOT LINK EXECUTABLE
and similar message about libstdc++
These two messages could explain why re-flash never ends -- I am not sure what happened but some libraries or damaged or missing and I am not able to get "sh" run.
I was able to pull "sh" binary on my computer but in Linux "ldd" could not "decipher" location of missing libraries so that I could attempt to push them in proper location in the e-Reader.
I would be happy to hear any suggestions how the situation can be corrected.
I still keep some hope that the situation can be corrected as "RDU" is still running and e-Reader still "has some breath in it".
RDU Version 2.8.9a (current boot count: 0)
Firmware version S6410_PPP2_BBB_2010_11_18
At normal boot the e-Reader has following behavior:
1. Please be patient while system starts
2. On the screen "Pandigital novel image with Contains Reader(R) Mobile Technology by Adobe System Incorporated" strangely shifted about 1/5 of the screen toward right side
It is quite difficult to establish a connection between adb and e-Reader.
Thank you,
Andromeda

andromeda_2010 said:
Hello,
I have "Pandigital Novel Black / Model R70E200 / which supposedly runs Android 1.5" which went through SD card update which did not finished correctly.
My knowledge is limited at this moment about android internals but I am coming from PC Linux world which could help in resolution of following situation.
Yesterday I decided to read some documentation on the e-Reader but found that touch screen did not respond (buttons and orientation worked fine). I did attempted to restart the e-Reader a few times but without any success -- touch screen did not respond (the e-Reader was not used for prolonged period of time).
And it seems that by accident I "hit" a combination of buttons which supposedly initiated some unknown process at boot time. After this incident I had no option as to attempt to re-flash firmware.
For some inexplicable reason the flash process did not went as I would expect. Now it does not matter what I do process verification of firmware never ends.
I've attempted to get into "hard reset" but no success so far -- I always end up in re-flash situation.
To get at least some information for debugging of the situation I installed "adb" and was able to retrieve a log message which states following
link_image[1714]: 1760 could not load needed library 'libm.so' for '/system/bin
/sh' (link_image[1703]: 1760 missing essential tables)CANNOT LINK EXECUTABLE
and similar message about libstdc++
These two messages could explain why re-flash never ends -- I am not sure what happened but some libraries or damaged or missing and I am not able to get "sh" run.
I was able to pull "sh" binary on my computer but in Linux "ldd" could not "decipher" location of missing libraries so that I could attempt to push them in proper location in the e-Reader.
I would be happy to hear any suggestions how the situation can be corrected.
I still keep some hope that the situation can be corrected as "RDU" is still running and e-Reader still "has some breath in it".
RDU Version 2.8.9a (current boot count: 0)
Firmware version S6410_PPP2_BBB_2010_11_18
At normal boot the e-Reader has following behavior:
1. Please be patient while system starts
2. On the screen "Pandigital novel image with Contains Reader(R) Mobile Technology by Adobe System Incorporated" strangely shifted about 1/5 of the screen toward right side
It is quite difficult to establish a connection between adb and e-Reader.
Thank you,
Andromeda
Click to expand...
Click to collapse
Hello,
Thanks for using XDA Assist.
There's no dedicated forum for your device here in XDA.You can post your query in Android Q&A,Help and Troubleshooting.Experts there may be able to help you
___
v7
XDA Assist

Modifying the bootloader - for power on during charge ?

First of all I have the desire to boot on charging -- for an in-dash car-puter like so:
http://forum.xda-developers.com/shield-tablet/help/nvidia-shield-boot-charge-carputer-t3280530
I've performed all the common attempts you find out there. I've deleted the binary responsible for putting the battery capacity image on an "off" tablet. Replace the binary with a shell script is also common.
I hacked on the ramdisk to try to make init.rc's "charger" entry not start the charge service but boot. Then it occurred to me -- none of this is being used it's all a red herring and the @FliiFe was right -- it's all in the bootloader. (I had not read his post yet) You can deduce this by replacing the battery images in /system/res/ and nothing visible changes during the "charge mode" boot.
It's interesting that the Android source (and K1 releases) have all the cruft laying around looking like "charge mode" is running off the system boot/ramdisk and system partitions. A lot of wasted time looking at that.
So here I am looking at modifying the bootloader - probably the most risky thing you can do. Does anyone know if it's possible? On first pass, I'm not able to see where it would be in the K1 Android source tree. Any Ideas?
Thanks!

I doubt there is any source for the bootlaoder. Usually, manufacturers don't open-source them for obvious reasons (avoid oem relock, bunch of other things). The only solution might be to somehow unpack, modify and repack the bootloader.
Anyway, good luck, that is not going to be an easy journey.

Why not removing the battery and replace it with a cable?

Niii4 said:
Why not removing the battery and replace it with a cable?
Click to expand...
Click to collapse
I'm curious, have you done this? Some electronics will not work on charger/PS without an operating battery.

No, I haven't done this myself. But someone on this site did.
Search for battery replacement..

Oukitel WP10 - General development and hacking.

I bought the Oukitel WP10 as my replacement for my previous phone, an AGM X2, which is was getting on in age. Reasons for purchase: 5g, ruggedized phone, giant battery, POGO pins on the backside for connecting ???
The phone, physically, is fine, It's giant brick with a big battery, a decent camera and all the usual sensors are there. It as the potential to be a really neat phone....and then you boot it up. Something was and is.....not right. The developers lobotomized their rom. Why? Who knows. Will they fix it? {edit: they did sorta}. The app drawer is missing so the phone dumps all your apps out on the home pages. 3rd party widgets don't work : you can set them up but if you reboot the phone, they don't update. The recent apps tab works with gestures and 3 button navigation but only with the stock launcher, which appears to be launcher 3 but is named quickstep? 3rd party launchers load, but can not access the recent apps tab. Some 3rd party apps refuse to load producing various error codes. The user interface feels like someone had an iphone and tried to model it's interface to this phone. This person did not succeed.
I have emailed the company my complaints and reasonably expect nothing to happen as I am sure the person who did this to this phone did it on purpose. May they be cursed with pubic lice and hemorrhoids.
That being said, if the phone's UI could be fixed, it would be a really nice phone and I have plans to mate those POGO pins with an Arduino or a PI because, let's face it, they aren't gonna make any accessories, are they? But I can make some really neat ones out of an Arduino and a 3d printed cover that fits over those POGO pins.
So the plan will be: 1. Root the phone - accomplished. 2. Compile TWRP against it. 3. Modify the stock rom so it it is fully functional. 4. Begin development of a customizable Android 10 rom. 5. Begin development of an Android 11 rom.
At this time, I can confirm that the bootlooder can be unlocked, you can sideload things with ADB, and a stock rom apparently exists and can be accessed through the Oukitel website. There is some kind of flashing tool too, but everything is in chinese. I downloaded the stock rom and it appears to be the same build as on the phone. I tried flashing just for giggles but kept getting signature errors. There was something in the chinese instructions about coping and renaming some files prior to flashing but I have not had time to figure it out yet as it is all in chinese.
I will be trying to extract the boot img as it appears that Magisk would work if I can patch the boot img and reflash. If/when I am successful, I will post it here. Any help is welcome.

**** 02/03/2021: Well wouldn't you know it, they released an update....so maybe not do this right away*******
Guide to rooting the Oukitel WP10.
disclaimer: I have tried to make the steps straightforward yet detailed. This is a high-risk activity with a high probability of failure.​
Prologue: This guide assumes basic familiarity with ADB, fastboot, sideloading, and booting into your recovery. Please note ADB, fastboot commands will vary slightly depending on your installation, and whether you are a PC, a Mac or a Linux box.
Preplanning: inevitability screwing up your phone.
i. Back up, copy over and otherwise remove any valuable data from your phone. This process will delete all your old data.
ii. Obtain a copy of the stock rom. At the time of writing it is: OUKITEL_WP10_EEA_V10-R11 .zip which is hosted on Mega. You can find it at the Oukitel site -> Downloads.
iii. To reflash the stock rom you apparently need a tool called SPMDT. I am not familiar this tool and the instructions from Oukitel are all in Chinese so this will not be covered here at this time. It may be easier to do all of this using SPMDT. Review chinese Oukitel instructions on how to swap checksums and how to use SPMDT to restore your phone.
1. Install Magisk Manager - this is the tool we will use to root this phone. A more detailed explanation about how it works is here. Download directly on your phone and install or download to your computer and sideload using ADB.
Code:
adb install MagiskManager-v8.0.7.apk
2. Open Magisk Manager and verify that you can install Magisk. This phone does have a ramdisk, is encrypted but does not have a/b partitioning. There are 3 options: At this time, I can't find a TWRP custom recovery and do not yet know how to make one so downloading a zip to load with TWRP is not possible. A direct install seems to be for updating a previous Magisk installation? I am not sure and available information seems ambiguous. This leaves option 2: patch the stock boot image.
-2a. On your computer, open the stock rom and extract the boot.img file. Using ADB, upload it to your phone:
Code:
adb push boot.img /sdcard
This should send it to the users default directory. The /sdcard part may vary.
-2b. Open Magisk Manager on your phone and select option 2. Choose the boot.img file and Magisk will give it the clap.
-2c. Download the file to your desktop. Can probably open "Android Storage" in your file system and copy it over or use the following ADB command:
Code:
adb pull /sdcard/Download/magisk_patched_mzhsO.img ~/Desktop
Again, the *.img name and your preferred directory may vary and adjust command syntax for your OS.
3. Unlock the bootloader. You must first enable developer tools on your phone and then go to Settings ->System ->Advanced ->Developer Options -> OEM unlocking (turn slider on). This does not unlock the bootloader. It just allows you to unlock the bootloader. To unlock the bootloader, plug your phone into your computer using the USBc cable, make sure USB debugging is on and reboot your phone into fastboot by holding down the vol up and power buttons as the phone reboots. In the bootloader menu, choose fastboot by using the volume up to cycle through the menu options and then the volume down key to start fastboot. When all is ready:
Code:
fastboot flashing unlock
and a teeny-tiny prompt will pop up asking if you really want to do that. Use volume keys to navigate.
To relock the bootloader later (not now):
Code:
fastboot flashing lock
will button it up again. You might not need this ever.
4. I can't remember if it forces you to reboot at this point but if it does, just boot into fastboot again. Do not try to install the modified boot img file yet. If you do, you will send it into a fastboot bootloop (soft bricking your phone). This happened to me. I then learned that this phone, and I assume, most android phones past Android 8 are protected by Android Verified Boot which is part of a system that verifies that the firmware you are running is legit. In this case, it causes the bootloader to verify the boot and recovery partitions. We have to disable it to install the modified boot img. I borrowed the following commands from these threads here and here and here
-4a. vbmeta.img apparently contains checksums of the boot, recovery and maybe system partitions. The guy from the first link installed a custom vbmeta.img using the command below. I do not know whether this is generic vbmeta, whether it is vendor specific so I did not use the custom vbmeta he created.
-4a. Since I didn't know whether to use a vbmeta.img from another phone, I poked around until I found the 3rd link above which stated that I could just use a dummy vbmeta.img generated by using a python script AVBtool
I cloned it into Pycharm (or your preferred IDE...or you can rawdog it from the command line) from Google's github and ran the script as below:
Python:
avbtool make_vbmeta_image --flags 2 --padding_size 4096 --output vbmeta_disabled.img
-4b. I installed the vbmeta_disabled.img using fastboot.
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta_disabled.img
-4c. I then installed the modified boot.img (as discussed above):
Code:
fastboot flash boot magisk_patched_mzhsO.img
-4d. and rebooted: fastboot reboot
5. The system rebooted into the modified stock rom and I reinstalled everything I had backed up earlier. I confirmed Magisk had given me root access. HOWEVER: SafetyNet failed the ctsProfile check! There seems to be a fix for it here but since I don't know what it means or what it does and since the phone appears to be working, it will have to wait for later.
Epilogue. I am happy to report, that, after a bit of fiddling around, Magisk's Quickswitch module coupled with a very dodgy alpha Lawnchair2 apk I got from APKmirror through their Telegram group has resulted in a mostly functional rom! I now have an app drawer and gestures mostly works with the Lawnchair 2 launcher. Widgets still need to be reinstalled if you reboot. So...it now sucks a lot less.
Gentle reminder: this guide is rough and the result of only 1 pass through. And I screwed it up.

Due to an OTA update being provided from Oukitel it became necessary to learn how to use the SP Flash Tool.
Guide to reinstalling the Stock firmware for your Oukitel WP10.
(the bootloader will remain unlocked if you unlocked it as in the previous post)​I loosely borrowed from the gents at GetDroidTips This process assumes you are using a Debian based linux distro.
​1. Download the stock rom OUKITEL_WP10_EEA_V10-R11. Extract rom folder.
2. Download the latest SP Flash Tool . Extract.
3. On linux, there is an error regarding libpng12 which deprecated in newer versions of linux. For the reckless, a nice person from SO made up a custom .deb to install to fix this problem here. Otherwise you have to manually install it so that this program can find it.
4. Open your SP Flash Tool folder and run flash_tool. A nice little gui should pop up if it runs.
4a. Go to the Download tab and choose "MTK_AllInOne_DA.bin" as your download agent.
4b. Under scatter-loading file, navigate to the stock rom folder and "MT6873_Android_scatter.txt" should be the only option and choose it.
4c. Reading the windows instructions here recommended unticking the "preloader" in the payload section below these options on the Download tab as it might brick the phone, so I did. I do not know if this is necessary.
5. Turn off your phone. Then plug the USB cord in and hold the volume up key down so the flash tool will detect the device via USB. Can also try holding the volume down key down. Do not press power button like you would if you were planning to boot into fastboot.
If all goes well the flash tool will reflash the stock rom and reboot into stock rom. The bootloader will remain unlocked until you use fastboot to relock in the post above. There was an OTA update yesterday: OUKITEL WP10 EEA_V14_20210118 . The phone UI feels a little snappier but it appears that the stock rom launcher still does not have an app drawer. This might be a Google thing and not a Oukitel thing. However, 3rd party launchers with app drawers now work with 3 button navigation! The recents tab and app drawer appear to be functional. Gesture control still appears to be not functional with 3rd party launchers and some but not all not all widgets will update after a reboot. Cause to be determined. I have not tried to repeat the root procedure above.

hello, I am new and have been looking for threads about rooting c19 oukitel, but seems non exists. How could i start one?

dreadeye said:
hello, I am new...
Click to expand...
Click to collapse
....for phones that have a small user base, you can just start a thread for your phone under general like I did. Xda may be like Stack Xch where you need to have a certain number of posts before you can start your own thread. I don't recall. If so, you will have to reply to some posts first.

calfax said:
Will they fix it? {edit: they did sorta}.
Click to expand...
Click to collapse
Hey Calfax, not to hijack your thread, but I am thinking about getting this phone, would you mind explaining what the new update did and did not fix?

glitchhawk said:
Hey Calfax, not to hijack your thread, but I am thinking about getting this phone, would you mind explaining what the new update did and did not fix?
Click to expand...
Click to collapse
It fixed your ability to use a 3rd party launcher. It did not fix the widgets issue. I think this is an Android 10 issue more that Oukitel specific. Having a phone with an 8000 mAh battery has helped tremendously over the last few days.
The phone does not like to use 4g data and I do not know why.

sup op,
Just got oukitel wp10 today. I have just done a quick read through everything here and am probably going to try and get root going asap.
I have read elsewhere that treble based phones (such as this one) can basically have any treble enabled custom rom installed on them. I know very little about this but is it a concept your are familiar with?
am very glad someone has taken the intitiative here regardless. thanks for that!!
p.s. ditto on the pubic lice and hemorrhoids thing and also for whoever designed the xda app

Also, I bet the 4g issue your having is related to what bands the phone operates on. Who is your carrier?

I have obtained root and have a few nuggets of wisdom to offer regarding OP's instructions. First off BIG THANKS TO OP ONCE AGAIN FOR TAKING THE INITIATIVE!!
1. The first problem I ran into was with creating a vbmeta dummy image at OP's #4a in his second comment on this thread. There is a link to AVB Tools in the first paragraph and what is supposed to be a link to the tool on google's github page in the second paragraph but the link in the second paragraph to the github page is not working, so I defaulted to the first link but the AVB tool on that page, for whatever reason, is not working properly, while the tool on googles github page DOES WORK AS INTENDED.
I think what OP intended to link to was the following: https://github.com/PixelExperience/external_avb
REGARDLESS, I have attached a copy of my vbmeta "dummy" image to this post, so you can just use that instead if you prefer.
2. If you update your phone after isntalling magisk, you will have to go through the fastboot process again, and yes this means YOU HAVE TO DO THE VBMETA STEP AGAIN BEFORE THE MAGISK STEP OR YOU WILL BRICK YOUR PHONE.
3. I bricked my phone and was having trouble running the SPFLASH tool, linked in OP's third comment on this thread. IF YOU ARE HAVING ANY TROUBLE RUNNING THIS TOOL JUST DOWNLOAD THE LATEST VERSION OF UBUNTU AND RUN THE SPFLASH TOOL FROM AN UBUNTU LIVE USB. I tried on a couple different linuxes with the right kernel version and still had trouble so just do it from ubuntu live if you are having trouble.
4. If you are stuck in a bootloop like I was, you can still run the SPFLASH tool. Just get the tool setup, press download, then plug in your phone and hold the volume up button as it enters the off-stage of the bootloop, the SPFLASH tool will pick it up and start the flash process if you time it right.
5. OP says he is still having trouble with third part launchers but I was able to get Nova launcher running by installing it, then when holding down on the nova launcher icon on the home screen of the default launcher, there is an option to make nova the default launcher from there. idk if every 3rd party launcher will be able to do this, but Nova was.
6. OP also mentioned having issues with gestures, and pointed to it seeming to be a Google issue, and I have confirmed that it most certainly is, as there is a message in My Nova launcher settings that says:
Android 10 gestures Navigation
Google has not yet made gesture navigation compatible with 3rd party launchers. There is nothing that Nova Launcher can do to change this until a future Android update.
Click to expand...
Click to collapse
CURSED BE TO GOOGLE. PRAISES TO OP

Found this in the stock rom zip and translated it (was half in Chinese). Thought someone might find the info useful
Project Name: S1000D-Cloud Base-S85
Clients: Ozzie ...
Customer Configuration:
MT6873, FLASH: 128GB+8GB (Integrated UfS+DDR4X), Global GSM 4-band (2/3/5/8)+W 7-band(1/2/4/5/6/8/19, with RXD)+TD 2-band(34/39)+TDD 5-band(34/38/39/40/41)+FDD 18-band(1/3/5/8)+W 7-band(1/2/4/5/6/8/19, with RXD)+TD 2-band (34/39) + TDD 5-band (34/38/39/40/41) + FDD 18-band (1/3/5/5/6/8/19, with RXD 1/2/3/4/5/7/8/12/13/17/18/19/20/25/26/28A/28B/66) + CDMA 3-band (BC0/BC1/BC10, with RXD) + 5G 11-band (N1/3/5/8/20/28/38/41/77/78/79），Support NFC,support LCD screen (3 and backlight), support 9V2A charging, support oncell/incell TP (motherboard does not support separate TP connector), three rear camera: 4800W main rear camera+1300W wide angle camera+200W macro camera does not support thermal imaging, front camera 1600W, support fingerprint, battery built-in non-removable, does not support front flash, support secondary board SIM card, does not support T card, does not support RGB signal light (FPC), does not support HALL, support side buttons, support earpiece (connector FPC), support dual silicon wheat (main mic sub-board patch, sub-mic motherboard patch), smart amplifier, support TYPE-C headset (sub-board end), support light distance sensor (FPC), support G-Sensor, support GPS/WIFI/Bluetooth/FM, support geomagnetic, support gyroscope, support OTG, support rear camera flash (connector, FPC), support/laser distance measurement (sub-bo
ard end)/temperature measurement/night vision (plug-in) Support wireless charging (sub-board compatible）, Does not support UV / heart rate/air pressure / volatile gas detection/intercom plug-in / encryption chip/night vision fill light (FPC), antenna shrapnel (battery cover full paste&screen shrapnel full paste), support motherboard side ANT6 antenna, support motor, support power button，
Software version: //192.168.1.50/alps_q0_mp2_1/s1000_mt73_A_L/s1000d-yj-s85-a2-66-l-128G8G-fhdp-bom5-q0-cts-eu/R11
Release Date: 2020-12-17 16:08
LCD: 6.67FHD.Huaxing glass, middle perforated, cover glass Corning 3rd generation FT8756
SENSOR:
Wide Angle CAM Win-win-win-win-win I., SWAQ6925001A-VA S5K3L6XX03-FGX9
Macro Shadow Collar I., YL-YJS85-02M1-WJ 200W GC02M2
Post-secondary Shadow Collar I., YL-YJS85-02M1-WJ GC032A
Ex CAM Win-win-win-win-win I., SWAC205S100B-VA S5K3P9SP04-FGX9
Flash Model:
UFS+LPDDR4X(128GB+8GB) H9HQ16AFAMMDAR-KEM
UFS+LPDDR4X(128GB+8GB) H9HQ15AFAMADAR-KEM
UFS+LPDDR4X(128GB+8GB) KM8V8001JM-B813
Language Type: Multi-lingual
Version Download Instructions: Normal download, no need to erase
Download tool version: SP_MDT_AFterSale_20.32
Release Notes: First Archive
Click to expand...
Click to collapse

Hard bricked my wp10 with spflash. DO NOT FORGET TO UNTICK PRELOADER USING SPFLASH TOOL.
Hopefully the oukitel people can help cause I have spent hours now trying different fixes and have only managed to get a blank black screen by opening the phone, unplugging and replugging the battery (so technically some progress). But i can't justify spending any more time trying to fix.
This phone is (was) great and its nice to have no restrictions on rooting or whatever but great power/responsibility/etc, u know the drill
kinda surprised there isn't more activity around this phone on XDA though Cuz it is a sweet one.

Has anyone pursued anything further with this beast of a phone?
I have purchased one and used it several weeks now, and did find the operating system leaving a lot to be desired, and really dislike the iPhone-like swiping gestures that I initiate accidentally all the time. My company phone for my job is a newer iPhone with the same gesture motions, unlike my previous employer-provided iPhone.
This WP10 has amazing potential but really could still use a better custom ROM.
And my 6800mah Blackview BV9800 battery outlasts this 8000mah battery.
My biggest complaint so far is the GPS fixing using Locus Maps Pro or Google Maps.
I get a display of a multitude of satellites within view,but within 5 seconds, all GPS satellite fixing disappears on the Locus satellite display screen,and I can no longer get a location fix.
Same problem with Google maps, although I don't have any advanced tools to see the satellites being used as I do with Locus.
With locust, I can refresh the GPS connection and they reappear, but then still disappear immediately. This is very annoying when using a rugged outdoor smartphone for rugged outdoor navigation.
I might be replacing the faulty touch screen interface on my 1-year-old Blackview BV9800 if I cannot find an easy solution for this Oukitel WP10GPS issue.
A custom ROM or updated upgraded ROM would be very nice!
I'm not sure why the battery does not last as long as the Blackview's smaller battery, but I liked the size of the battery on this better than the current flagship Blackview models, and I also liked the more ruggedized case with far more screws securing the case halves together.
The BV9800 was the last of its kind from Blackview, the BV9900 has a slightly smaller battery and a less rugged appearing case, & the new 5G rugged version using the BL6000 is just an upgraded 5G version of the BV9900, same case design, battery still smaller than BV9800.
This is why I jumped ship after 3 Blackview rugged phones and tried out this Oukitel WP10. It has potential to be superior to the BV9800, but ROM issues are making me question switching back to the BV9800.

chuck.lambert78 said:
Has anyone pursued anything further with this beast of a phone?
I have purchased one and used it several weeks now, and did find the operating system leaving a lot to be desired, and really dislike the iPhone-like swiping gestures that I initiate accidentally all the time. My company phone for my job is a newer iPhone with the same gesture motions, unlike my previous employer-provided iPhone.
This WP10 has amazing potential but really could still use a better custom ROM.
And my 6800mah Blackview BV9800 battery outlasts this 8000mah battery.
My biggest complaint so far is the GPS fixing using Locus Maps Pro or Google Maps.
I get a display of a multitude of satellites within view,but within 5 seconds, all GPS satellite fixing disappears on the Locus satellite display screen,and I can no longer get a location fix.
Same problem with Google maps, although I don't have any advanced tools to see the satellites being used as I do with Locus.
With locust, I can refresh the GPS connection and they reappear, but then still disappear immediately. This is very annoying when using a rugged outdoor smartphone for rugged outdoor navigation.
I might be replacing the faulty touch screen interface on my 1-year-old Blackview BV9800 if I cannot find an easy solution for this Oukitel WP10GPS issue.
A custom ROM or updated upgraded ROM would be very nice!
I'm not sure why the battery does not last as long as the Blackview's smaller battery, but I liked the size of the battery on this better than the current flagship Blackview models, and I also liked the more ruggedized case with far more screws securing the case halves together.
The BV9800 was the last of its kind from Blackview, the BV9900 has a slightly smaller battery and a less rugged appearing case, & the new 5G rugged version using the BL6000 is just an upgraded 5G version of the BV9900, same case design, battery still smaller than BV9800.
This is why I jumped ship after 3 Blackview rugged phones and tried out this Oukitel WP10. It has potential to be superior to the BV9800, but ROM issues are making me question switching back to the BV9800.
Click to expand...
Click to collapse
i think the gesture issue might be an android 10 problem although i dont recall having this sort of problem b4 bricking my phone.
the gps issue i did experience and i can say that on other devices i have seen improvement to gps services from installing custom rom, walking/driving forward while trying to get directions or current location on map app, also enable wifi and bluetooth monitoring (google.says it helps but in most situations/locations i doubt it does)

É possível instalar o gsi treble rom no wp10? Notei vários erros.

Question Can someone explain how the storage works on these things?

I've been trying to troubleshoot an Atoto S8 Ultra (uis7862 based unit), and I'm having a really difficult time figuring out how the storage works.
I've noticed that when my unit resets (either on its own due to a bug or with the factory reset command), when I reboot the system seems fresh in that none of my apps are installed, but certain parameters persist. As if there's a different partition for user data that isn't where the apps/data go, and only one of them gets cleared with a factory reset.
For example, all of my paired bluetooth devices in BT1 (Atoto uses the dual bluetooth system, with BT1 being phone connections) were still there after factory resets, and using the file explorer I found folders for all of my previously installed apps as well as downloaded files and saved screenshots. No matter how many times I reset, that stuff was still there.
I used the Twipe All script from @surfer63 and it finally cleared everything, but now it appears that other settings have cleared / defaulted that I'm not aware of, which I think came a certain way from the factory. For example, there's a transparent car in my backup camera view now. It looks almost like the window for the virtual 360 camera but its not, it's just an overlay and it won't go away. This started only after the twipe command, so I feel like there were partitions wiped with settings set at the factory. Additionally, now my Bluetooth system is actually VERY peculiar. When anything plays off a paired bluetooth device, it pauses playback elsewhere. For example, a chime notification on my phone will pause spotify natively on the unit for the duration of the sound. This is not a feature the unit had by default and there is no discernible way to make it stop!
I don't even know where to begin trying to trouble shoot this! I reached out to customer support, and they said they have never heard of this working that way!
They recommended I capture a debug log as follows:
Create a folder called blinkdebug and reboot the system, it will start capturing any data. They showed me 2 videos of this working on their test bench, and I can confirm it works on another unit a user has, but on mine it does nothing. The folder is empty, whereas on other Atoto devices I saw a file created with log info there. Like the blinkdebug system doesn't exist on my unit post twipe script or something. What could this possibly be?

dishe2 said:
They recommended I capture a debug log as follows:
Create a folder called blinkdebug and reboot the system, it will start capturing any data. They showed me 2 videos of this working on their test bench, and I can confirm it works on another unit a user has, but on mine it does nothing. The folder is empty, whereas on other Atoto devices I saw a file created with log info there. Like the blinkdebug system doesn't exist on my unit post twipe script or something. What could this possibly be?
Click to expand...
Click to collapse
I don't have a clue either. What I do know is that in the Mekede units in the "/system/bin" folder there are three binaries "blink", "blink5" and "blink131". and a daemon "blinkd". These are soflinked from "/oem/bin".
These are started from the "init.rc" in the root folder /. (you can consider init.rc (actually multiple .rc files) as the startup scripts).
Code:
blink -> /system/bin/blink
blink131 -> /system/bin/blink131
blink5 -> /system/bin/blink5
brlinkd -> /system/bin/brlinkd
I can only guess that blink means something like "bluetooth link" ?? (and maybe I'm completely wrong. I can't find anything about it).
There are also bt_* files for bluetooth so again: I can be completely wrong, but do you have those "blink" binaries as well?
dishe2 said:
I've noticed that when my unit resets (either on its own due to a bug or with the factory reset command), when I reboot the system seems fresh in that none of my apps are installed, but certain parameters persist. As if there's a different partition for user data that isn't where the apps/data go, and only one of them gets cleared with a factory reset.
Click to expand...
Click to collapse
I mentioned it somewhere else, but there is also the /sys/fyt folder. This folder is also used to store settings that are FYT-only settings and fall outside the normal android partitions and might not be touched by Android resets. They "were always" touched when you do a full firmware flash with "twipe all", but you have a very exclusive device