Related
Hi.
I've played short with amss.bin and changed 1 Byte somewhere in "useless" Text.
Multiloader seems to check this manipulation...
Any idea where in file is CRC, Hash or something like that?
Also any idea if RSA 2048 is activated for Bootloader or AMSS?
Best Regards
i have heard that in bada 1.2 roms its activated but the old ones...
Some packages include more then 2 files:
dbl.mbn
boot_loader.mbn
In T-Mobile Firmware I found also few ELF files...
decrypted_boot_loader.bin is decrypted with PSAS.
Best Regards
I think there are 3 Boot Loader.
We know only 2 files:
dbl.mbn----------------> human readable (find Text like Qualcomm)
boot_loader.mbn--------> encrypted (decrypt with PSAS for instance)
DBL------> Device Boot Loader
FSBL-----> Fail Safe Boot Loader
OSBL-----> OS Boot Loader
Check out Qualcomm manual in QPST... see Screenshots.
Check out above post from me... there are ELFs included...
Maybe start with:
BL3_univ_s.elf
If you wish Android porting.
If I'm wrong, please correct me.
Best Regards
And if wwe would dual-boot android then wich loader would we need to edit. and how would we disassemble it?
And if wwe would dual-boot android then wich loader would we need to edit. and how would we disassemble it?
Click to expand...
Click to collapse
As I saw on S8000 project it seems they "only" change boot_loader.mbn.
But it seems it was not encrypted.
This time on S8500 it is encrypted...
As we can not encrypt them, decrypt is not problem... also enough ELF files are floating around.
First Question is. How write not encrypted boot_loader.mbn to S8500 without killing the handset.
This is the very, very basic Question. Long time before """IDA"""...
So again.
RIFF Box JTAG could help to understand, if Security is low enough to write modified Bootloader back to handset.
All other things are dreams.
Best Regards
Edit 1.
But it could be, that dbl.mbn prevent modification of boot_loader.mbn.
Or other Checks are integrated to prevent easy Bootloader change.
For JTAG user... Is it possible to erase NAND from 0 to 20000 (first 2 MB).
Attention! Not best idea as much harder to write then... also with JTAG.
But is this area protected by something? RSA Keys?
Nand write protection?
Edit 2.
S8500 is 5 x bigger then S8000 boot_loader.mbn
300 KB against 1600 KB
So I'm pretty sure Samsung integrated more Security...
Hi All.
Now i playing with porting android to my s8500.
I see that the Korean m130k very similar to our S8500(shw-m120s),
see pics files from FCC site.
and now I'm looking for bootloader files for m130k.
Also, I have Riff box
@ oleg_k
Thank you very much for these interessting infos.
I will contact you later via PM as I have several Questions...
I found this:
http://www.gadgetfolder.com/samsung-galaxy-k-shw-m130k-android-smartphone.html
Best Regards
Adfree,
will be interesting to talk with you.
Regards
I've investigated JTAG dump...
First 4 MB in 2 GByte moviNAND looks like that:
Code:
000000-16BB0E Boot boot_loader.mbn (not encrypted)
16BB10-1BFF7F 337 KB 0000 (empty) part of Boot
1BFF80-1BFFFF ??? 128 Bytes (RSA ???)
1C0000-1FFFFF 256 KB FFFF (empty)
200000-244B27 DBL dbl.mbn
244B28-3FFFFF 1,7 MB FFFF (empty)
400000 AMSS amss.bin
Now I spent some time to find used boot_loader.mbn and dbl.mbn to be sure that not additional Data is written... this takes some time...
Edit:
In this Dump Version S8500+XX+JD9 is used. I hope I will find Firmware with Bootfiles for compare...
Edit 2.
S8500XXJD2.zip no Bootfiles
S8500XXJD3.zip no Bootfiles
S8500XXJD4.zip no Bootfiles
S8500XXJDA.zip no Bootfiles
S8500XXJDB.zip no Bootfiles
I found 4-5 packages with XXJDx in name... now I will download them all. Hopefully I find Bootfiles that matches S8500+XX+JD9
Edit 3.
Found only XXJDx without Bootfiles...
Last try for today is S8500XXJDZ.zip, but I have download problems... need more then 2 hours...
Good work adfree. You are great.
This seems more interesting than anothers ports.
Okay, I found in S8500XXJDZ.rar
S8500+XX+JD9
dbl from JTAG Dump is 100 % identical.
Last 1024 Bytes are not written into memory...
dumped DBL = dbl.mbn
But dumped boot_loader(.mbn) is with Changes... later more.
0-1FFFF identical
20000-??? long, long empty... FFFFFF
More infos will come later.
Best Regards
It seems much easier as I thought.
No private Data like IMEI... if not removed from JTAG Dump (first 4 MB before AMSS).
In Bootloader part is only once written Block with FF (empty). So
128 KB Block is empty.
boot_loader.mbn is split into 2 parts...
I will make JTAG template for XXJL2 as example.
This I can upload.
Best Regards
adfree said:
It seems much easier as I thought.
No private Data like IMEI... if not removed from JTAG Dump (first 4 MB before AMSS).
In Bootloader part is only once written Block with FF (empty). So
128 KB Block is empty.
boot_loader.mbn is split into 2 parts...
I will make JTAG template for XXJL2 as example.
This I can upload.
Best Regards
Click to expand...
Click to collapse
keep it up buddy.
Okay. Based on my knowledge and JTAG dump...
I have prepared template for JTAG based on XXJL BOOTFILES.
Last 1024 Bytes of decrypted files are NOT written into moviNAND, I cut them:
boot_loader.mbn_part2.bin
dbl.mbn_part2.bin
boot_loader.mbn_PART1 is filled with 1 Block FF (128 KB) at 0x20000
Result is 4 MB file... 0 - 0x400000... Bootarea before AMSS.
Position 1BFF80-1BFFFF looks really like RSA 1024...
Check first 16 Bytes of boot_loader.mbn_part2.bin
Maybe this is the MD5 Hash which should be in the Signature?
Maybe someone knows the Cert or public Key to decrypt the Signature...
XXJB6 has no Sigs...
Anyway.
Without Test if 0 - 0x400000 can replaced via JTAG, we have no progress.
Best Regards
ATTENTION! Please NOT use these files to flash with Multiloader!
You will brick your handset.
Edit.
Added S8500 XXJB6...
Added S8530 XXJK2
Hi adfree good work here!!
Sorry I can't help you, it's over my knowledge
Keep going dude
adfree said:
Last 1024 Bytes of decrypted files are NOT written into moviNAND
Click to expand...
Click to collapse
Just a correction here - the last 1024 are not encrypted in the same way as the rest of the file and they are in fact written, but to a different location
adfree said:
Position 1BFF80-1BFFFF looks really like RSA 1024...
Click to expand...
Click to collapse
I stand corrected if I'm looking at the wrong place, but it doesn't look much like a RSA key to me - it's not odd, so it's not a private exponent and MSB is not set, so it's not a modulus.
is there any easy task in this
i want to help but i am not a programmer
so what can i do????
Just a correction here - the last 1024 are not encrypted in the same way as the rest of the file and they are in fact written, but to a different location
Click to expand...
Click to collapse
Yes, interesting. Like an Log file/Flash history... if I search for tktoolver...
This is far after 500 MB...
I hope this is not relevant for Boot.
Position 1BFF80-1BFFFF looks really like RSA 1024...
Click to expand...
Click to collapse
I think this is the Signature... maybe. So boot_loader.mbn is signed by RSA 1024.
Only an idea, but I could be wrong. XXJB6 has not such 128 Byte Block.
There are also more different boot_loader.mbn possible.
Ehm, JE7 has different... called XX+JEE
I will compare few, but between JL2 and JDZ whole 128 Bytes differs...
I know this only from RSA 2048, where 256 Byte Signature for BenQ Qualcomm handsets...
Best Regards
At the moment I try to find matching Bootloader from S8530... for S8500+XX+JL2
Or other matching combination.
S8530XEJL2
S8530+XX+JK9
S8530XEJL4
S8530+XX+JK9
Maybe with S8530+XX+JL1 more luck...
I hope I will find combo, in same month. Maybe minor differences...
Best Regards
Edit.
Hmmmm, strange S8530 Bootloader most older then S8500...
S8530+XX+JK2
S8530+DD+JK3
S8530+XX+JK9
S8530+XX+JL1
This post will evolve over time as more info is found:
Latest Updates
6/24 Custom PIT repartition workaround posted by Jaymoon.
You lose 8GB (some of which might be further recoverable with extra work) and restores using the original PIT will lockup your phone again (a scenario that could happen if you brought your phone back to Sprint for some unrelated problem) so if you have the opportunity to get your phone replaced with little to no cost, IMO that should be your primary option.
http://forum.xda-developers.com/showthread.php?p=27852689#post27852689
E4GT specific PIT file here (theoretically instead of losing 8GB, you'll only lose 2GB):
http://forum.xda-developers.com/showpost.php?p=28070569&postcount=654
6/8 Update for other platforms waiting for fix
Codeworkx's contact with Samsung got following response [discussion]
Update 14:56 CEST:
Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time.
Click to expand...
Click to collapse
6/7 Update
Test plan posted - see bottom of post for results so far (esoteric68, krazy_smokezalot report success)
BIG THANKS to Esoteric68 (and robertm2011 before her) who took the plunge to benefit everyone else. She has completed the test plan and more. 6 flashes of CM9, 3 flashes of AOKP, 3 wipe data/factory resets, and 3 nandroid restores, 1 stock FF02 flash, all successful. We are ready to have more testers try out the test ROM installs. We are getting more confident the code analysis was correct.
6/2 Update
Less technical summary and preparation for new round of testing
5/31 Lots of discussion on the code path detailing how the problem occurs and where to put the workaround, select posts below
Call trace for CWM Recovery - wipe data/factory reset
Call trace for CWM Recovery - restore
Section of update-binary afflicted by same issue as wipe data/factory reset
Recap of where workarounds can be placed
MD5s of various update-binary executables
Pros/Cons of placing workaround in kernel vs libext4_utils.a
Are ICS nandroid backup/restores safe?
Are ICS recoveries safe?
Why do CM9/AOKP installs often brick in ICS but not in GB?
5/24 Update pretty much ties up all the loose ends - Thanks Mr. Sumrall, Garwynn, Entropy, and everyone else who pitched in!
http://forum.xda-developers.com/showthread.php?p=26521643#post26521643
Potentially very GOOD NEWS
It appears Sprint/Samsung tested the EMMC brick issue, confirmed the problem, and tested a fix that appears to resolve the problem:
http://forum.xda-developers.com/showthread.php?p=26465085#post26465085
thirdcoastraised said:
To clarify this...in testing done over the weekend, there was a small "subtest" group which consisted of 20 devices. This group was put together STRICTLY for the propose of testing the emmc bug and fix. The devices were all programmed with the data known to have cause bricks when wiping. Of those 20, all but 6 also had the code patch to resolve that issue, so there was a possibility for 6 hard bricks, only 4 actually bricked, therefore, on the build currently being tested, the "emmc break issue" has been deemed "resolved"
Click to expand...
Click to collapse
We now have an update on why this bug is happening and which PRV/fwrevs are affected. PRV/fwrev 0x19 are susceptible to the EMMC /data corruption issue (which should now be referred to as EMMC lockup issue). PRV/fwrev 0x25 has the fix for the lockup issue but has a separate 32KB of zeros data corruption issue, which is being patched in the kernel (our kernels don't have that patch). All these problems are in the EMMC firmware. It can potentially be updated, but nothing is publicly available. EMMC lockup issue is triggered on erasing the EMMC. The only piece we have not been able to explain is why GB-based kernels seem immune to the EMMC lockup problem whereas ICS seems more susceptible to the problem. Presumably both are doing ERASE commands, but possibly in slightly different ways. See these posts for more details [#1 / #2]
To get your PRV/fwrev, you can use this (if you have busybox installed):
[email protected]:/ $ su
[email protected]:/ # cd /sys/class/block/mmcblk0/device
[email protected]:/sys/class/block/mmcblk0/device # cat cid | cut -b 19,20
19
Click to expand...
Click to collapse
If you don't have busybox installed just visually parse the line, match the serial # (0xd3f24fe6 - example only - yours will be different) with the cid, and look at the 2 numbers before the serial #.
[email protected]:/ $ su
[email protected]:/ # cd /sys/class/block/mmcblk0/device
[email protected]:/sys/class/block/mmcblk0/device # cat serial cid
0xd3f24fe6
1501004d414734464119d3f24fe68e8b
Click to expand...
Click to collapse
It appears after looking at the code more closely and examining the results of the card info dumps, we do not have this fix in our kernel. It isn't clear whether the fix would resolve our /data EMMC brick issues, but the point is moot right now because we don't have the fix.
Possible BRICK here. Please do NOT do any more testing until further notice. Please do NOT use Wipe Data/Factory Reset. It is the main difference between first and 2nd round of testing and is the current suspect
FE10 repacks added to Resource section
Esoteric68, azyouthinkeyeiz, and robertm2011 are testing flashing different ROMs with FE07/FE10 repacked with unlocked recovery. We all owe them our thanks for risking their phones to help the community (taking one for the team) No bricks so far.
Separately we are still discussing whether the fix Samsung checked in will get applied to our phone. No firm conclusions yet. Even if it doesn't apply, the hope is the data we get from testing will help us produce more flexible "safe" flashing practices.
Please do NOT test CWM Touch for now. We want to isolate just the FE07 kernel and unlocked stock recovery before introducing new variables.
Executive Summary
Garwynn has found a recent checkin from Samsung in the kernel code handling EMMC memory that fixes a data corruption problem. It is possible this might fix the /data EMMC corruption we have been seeing, but we aren't sure if it is fixing the same problem. The first release to include that checked in code is FE07. There has been some communication with the developers in charge of that area to gather further info.
This thread's purpose is to foster discussion on the issue and to determine if the potential fix actually does fix our issue. Even if the fix doesn't address the issue, it is hoped in the process we are able to gather more info into specific "safe" and "unsafe" scenarios.
Please do NOT jump ahead and think it is fixed. It is TOO EARLY to make that claim.
Background
As many of you are aware since ICS has come out, there has been a nagging issue where in some situations flashing ROMs with an ICS-based kernel and custom recovery has left the phone with EMMC corruption. This EMMC corruption is so far non-recoverable, even with JTAG bit blasting, which should bypass all but hardware issues.
This problem is NOT limited to the Epic 4G Touch. Other GS2 models as well as Galaxy Note are experiencing the same thing as can be seen by this Public Service Announcement in the Galaxy Note section.
The problem first cropped up when people used ROM Manager to temporary "fake" flash CWM Touch onto an ICS-based kernel to do their flashing needs. In particular wipe data/factory reset seemed to often trigger the /data EMMC corruption. However later we found it wasn't limited to just CWM Touch and temporary flashing as CWM repacks with the ICS-based kernel also exhibited that behavior, albeit not as often.
Even more frustrating is that this bug is not always deterministic, in that you could do some operation 3 times and have it work fine, then on the 4th, trigger the /data EMMC corruption.
Complicating the testing/debugging is the issue that once the problem is triggered, your phone is basically not recoverable. You can try and ODIN a stock ROM on top which will basically work for all the components except the /data partition. Once it reaches the /data partition, ODIN will hang. Similarly if you try and wipe data/factory reset, it will hang or timeout after a while. Attempts to repartition and reformat using ODIN have not changed this behavior. Attempts to edit the partition info manually have not been successful. JTAG bit blasting has not been successful.
You can read about the past experiences in the Stuck at "Data.img" thru odin thread. By the time you get to ODIN, the damage to /data EMMC is already done. ODIN is NOT causing the damage. ODIN is hanging on data.img because the hardware won't let it write successfully to that area of EMMC.
This has led to many custom ROMs giving special procedures to go back to a GB-based kernel repacked with CWM recovery to do all your flashing (EL26+CWM). It is also the motivation for the How Not To Brick Your E4GT thread.
Details
The code checkin that has piqued our interest is in regards to data corruption caused by problem in the wear-level firmware code of the emmc. This is low-level code that runs on a processor in the emmc module. It basically tries to spread out the data writes so you get an even distribution of writes so as any one section of emmc memory does not get worn out prematurely. This code apparently can corrupt data by writing 32KB of incorrect data under some situations.
https://bitbucket.org/franciscofranco/android-tuna-omap/changeset/cea631bdac53
The code appears to restrict the firmware fix to only certain "affected" emmc modules. Also it is not able to persistently/permanently patch the firmware so this code must run at each startup. The following modules were identified in the code:
Name: VYL00M
HwRev: 0x0
FwRev: 0x25
Name: KYL00M
HwRev: 0x0
FwRev: 0x25
Name: MAG4FA
HwRev: 0x0
FwRev: 0x25
Unfortunately during ad-hoc polling we have found a case of an EMMC /data bricked phone with fwrev 0x0, so either we are not understanding what Samsung's fix is doing or they may not have addressed the full scope of the problem. Do NOT assume if your fwrev is 0x0 you are safe.
At this point, this does NOT mean the fix is not applicable. We might be looking at the wrong data. The kernel might not be exporting the data to us. The fix might need to be expanded to more modules. The fix could be for something else entirely but we might be able to avoid the bug anyway using stock recovery.
To determine what version you have (keep in mind we are at the preliminary stage, so this info might not be the right info to collect or could be meaningless for the /data EMMC corruption issue)
[email protected]:/ $ su
[email protected]:/ # cd /sys/class/block/mmcblk0/device
[email protected]:/sys/class/block/mmcblk0/device # cat name hwrev fwrev manfid oemid date type serial cid
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
0xd3f24fe6
1501004d414734464119d3f24fe68e8b
Click to expand...
Click to collapse
The comments for the code checkin give the following info:
/*
* There is a bug in some Samsung emmc chips where the wear leveling
* code can insert 32 Kbytes of zeros into the storage. We can patch
* the firmware in such chips each time they are powered on to prevent
* the bug from occurring. Only apply this patch to a particular
* revision of the firmware of the specified chips. Date doesn't
* matter, so include all possible dates in min and max fields.
*/
Click to expand...
Click to collapse
The critical piece of code appears to be the following:
Code:
/* set value 0x000000FF : It's hidden data
* When in vendor command mode, the erase command is used to
* patch the firmware in the internal sram.
*/
err = mmc_movi_erase_cmd(card, 0x0004DD9C, 0x000000FF);
if (err) {
pr_err("Fail to Set WL value1\n");
goto err_set_wl;
}
/* set value 0xD20228FF : It's hidden data */
err = mmc_movi_erase_cmd(card, 0x000379A4, 0xD20228FF);
if (err) {
pr_err("Fail to Set WL value2\n");
goto err_set_wl;
}
Action items
At this point we would like to
1) gather more info on which emmc modules folks have and see if we can detect any patterns, so if you could post your EMMC info and optionally include whether you have the ability to do testing (presumably because you have a way to replace your phone if it is damaged)
2) solicit one volunteer to try different flashing scenarios using the unlocked stock recovery and FE07 kernel repack (bigpeng indicated earlier he would be willing to do this for the community, but that was before the fwrev info, so he might have had a false sense of security, so no pressure on him if he changed his mind)
If we find that the volunteer does not see any corruption despite trying to do so, then we can expand testing to a few more people and also work on getting CWM repacks.
If the volunteer hits the bug, then we will know the issue is still there even with stock recovery and FE07 kernel.
Keep in mind, at some point someone will need to take one for the team or we will be forever in fear of bricking our phones using ICS-based kernels.
Resources
1) FE07-based repacks
Unlocked Recovery Only [update.zip / tar]
Plus (unlocked recovery, init.d, adb-root) [update.zip / tar]
2) FE10-based repacks
Unlocked Recovery Only [update.zip / tar]
Plus (unlocked recovery, init.d, adb-root) [update.zip / tar]
3) JEDEC eMMC documentation
Related threads
Galaxy Note CID investigation thread
Good job sfhub. I am learning new stuff everyday
Sent from my SPH-D710 using xda premium
This is mine. I can try to help but not till weekend when my other phone gets here.
MAG4FA
0x0
0x0
0x000015
0x0100
11/2011
MMC
Sent from my SPH-D710 using Tapatalk 2
Sorry I don't have anything majorly different than the normal, but I have this on my phone:
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
Mine is also the same,
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
I am not available to test. Sorry.
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
Also unable to risk the brick. Good luck guys.
MAG4FA
0x0
0x0
0x000015
0x0100
10/2011
MMC
I'll take one for the team if needed. I've been eyeballing the 720p Evo.
Full readings from my /data bricked device. Let me know if you want me to check anything else out:
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
I can risk a brick to save future ones. I can help test.
/*
MAG4FA
0x0
0x000015
0x0100
12/2011
MMC*/
Sent from my SPH-D710 using Tapatalk 2
Sorry for the delay on giving more details. I've got info that I'll be passing along soon, just want to read up on something a little more before I post it out here.
Regardless whether this fix turns out to be related to the issue we've been looking at, I want to throw this in now before getting into the weeds:
Big thanks to Ken Sumrall from the Android team as he's been good enough to share info with us about this bugfix. As the person who signed off on the change commit he's one of the best resources on this issue. Also want to give credit to Mr. Min of Samsung who developed the fix in question.
I'll be posting more shortly. Those with dev experience, particularly with C++ and/or Assembly may be able to help us as well.
MAG4FA
0x0
0x0
0x000015
0x0100
11/2011
MMC
If need be, will test.
Source Notes - Part 1
Source Notes - Part 1
(Please feel free to skip if you're not interested in the programming)
This section is just to document what models and versions are affected.
I'm posting this in rather lengthy detail in part for peer review and also as I misread this the first time.
If you want to see the results of this documentation you can skip to the bottom.
Again, you'll need the link to the change:
https://bitbucket.org/franciscofranco/android-tuna-omap/changeset/cea631bdac53
If I look at this part of code alone:
Code:
cid_rev(0, 0x25, 1997, 1)
...this tells me to look for a definition of cid_rev. So I do and get here:
Code:
#define cid_rev(hwrev, fwrev, year, month) \
(((u64) hwrev) << 40 | \
((u64) fwrev) << 32 | \
((u64) year) << 16 | \
((u64) month))
It's not included in this change as this was introduced previously.
But you can see the definition here:
https://bitbucket.org/franciscofranco/android-tuna-omap/src/388ae9aa9b26/include/linux/mmc/card.h
OK, so I should look for HW revision 0x0, FW revision 0x25, right?
Nope. This was nested in another function and I didn't look at that right:
Code:
MMC_FIXUP_REV("VYL00M", 0x15, CID_OEMID_ANY,
cid_rev(0, 0x25, 1997, 1), cid_rev(0, 0x25, 2012, 12),
add_quirk_mmc, MMC_QUIRK_SAMSUNG_WL_PATCH),
MMC_FIXUP_REV("KYL00M", 0x15, CID_OEMID_ANY,
cid_rev(0, 0x25, 1997, 1), cid_rev(0, 0x25, 2012, 12),
add_quirk_mmc, MMC_QUIRK_SAMSUNG_WL_PATCH),
MMC_FIXUP_REV("MAG4FA", 0x15, CID_OEMID_ANY,
cid_rev(0, 0x25, 1997, 1), cid_rev(0, 0x25, 2012, 12),
add_quirk_mmc, MMC_QUIRK_SAMSUNG_WL_PATCH),
OK, so back to the card.h file to get my definition of MMC_FIXUP_REV:
Code:
#define MMC_FIXUP_REV(_name, _manfid, _oemid, _rev_start, _rev_end, \
_fixup, _data) \
_FIXUP_EXT(_name, _manfid, \
_oemid, _rev_start, _rev_end, \
SDIO_ANY_ID, SDIO_ANY_ID, \
_fixup, _data) \
I also want to look at _FIXUP_EXT next:
Code:
#define _FIXUP_EXT(_name, _manfid, _oemid, _rev_start, _rev_end, \
_cis_vendor, _cis_device, \
_fixup, _data) \
{ \
.name = (_name), \
.manfid = (_manfid), \
.oemid = (_oemid), \
.rev_start = (_rev_start), \
.rev_end = (_rev_end), \
.cis_vendor = (_cis_vendor), \
.cis_device = (_cis_device), \
.vendor_fixup = (_fixup), \
.data = (_data), \
}
So to properly identify what is affected:
Model Name (.name) -> VYL00M, KYL00M or MAG4FA
Manu. Firwmare ID Manufacturer ID: --> 0x15
OEM ID: Any ID (easy extrapolation of CID_OEMID_ANY)
Revision Start (Range): The result of cid_rev(0, 0x25, 1997, 1). The date indicates a low limit value.
Revision End (Range: The result of cid_rev(0, 0x25, 2012, 12). The date indicates a high limit value.
Fixup: Function to call to add the fixup - in this case, add_quirk_mmc (data.h linked above)
Data: MMC_QUIRK_SAMSUNG_WL_PATH (Not 100% but looks like a label to me. Can't find a definition in change.)
Note:
The fix mentioned right above the models affected in a note: "Date doesn't matter, so include all possible dates in min and max fields." I misread how they were getting the low and high limits of the range.
The corrected eMMCs affected involve VYL00M, KYL00M or MAG4FA at Manufacturer Firmware ID 0x15.
I would like to apologize for providing inaccurate info the first time; after going through the code another time I'm fairly certain the correction to the affected model list is accurate.
This also confirms that those who have posted are in the affected list, which we knew but couldn't confirm until now.
So does this mean the new code in the kernel is to help this problem and what would be the steps to testing it?
Sorry if dumb questions, just trying to learn.
Sent from my SPH-D710 using Tapatalk 2
So theoretically, those of us who have posted are able to make full use of the ability to flash, backup, etc. with the proper modification to our kernels? (Hope I got this right.)
Sent from my SPH-D710 using Tapatalk 2
Azrael.arach said:
So does this mean the new code in the kernel is to help this problem and what would be the steps to testing it?
Sorry if dumb questions, just trying to learn.
Click to expand...
Click to collapse
I'm of the thought that 99% of all questions are never dumb. And that 1% is extremely rare.
The thread is somewhat of peer review and discussion about what we've found and as a community possibly confirm whether this is both the bug causing the bricks (and by doing so confirming that this is the fix.)
robertm2011 said:
So theoretically, those of us who have posted are able to make full use of the ability to flash, backup, etc. with the proper modification to our kernels? (Hope I got this right.)
Click to expand...
Click to collapse
It means that the fix applies to those devices. What still isn't closed is whether the bug that this squishes is *the* bug (causing the ICS based bricks). I'm going to be posting more about that part here shortly for feedback and discussion.
Very interesting but so far over my head....
/* Missed the first paragraph of the details section. Low level corruption would do what I was questioning. Nvm
Sent from my SPH-D710 using Tapatalk 2
Discussion with Android Team
OK, now on to the bug that this fixes. This post will only contain the discussions between myself and Mr. Sumrall of the Android team.
Initial inquiry to Mr. Sumrall:
Garwynn said:
1) Was the bug that this patched causing the eMMC failures on Samsung devices using an 3.0+ kernel?
2) If #1 is yes, is it known if this correct the I/O errors already experienced? Or is this perhaps preventative in nature?
Click to expand...
Click to collapse
Initial Response:
Ken Sumrall - Android Team said:
The bug was in the emmc firmware which ran on a small microprocessor inside the emmc chip, and it didn't matter what kernel was running on the device to which it was attached. However, it may be the case that a particular kernel version was more likely to trigger the bug.
With this patch, the bug is worked around, and the emmc chip should no longer corrupt data.
Click to expand...
Click to collapse
We also knew this from the code:
Code:
* There is a bug in some Samsung emmc chips where the wear leveling
* code can insert 32 Kbytes of zeros into the storage. We can patch
* the firmware in such chips each time they are powered on to prevent
* the bug from occurring.
Note: Snipped last part of comment as it is already covered.
OK, so it's putting potentially zeros in the storage; but it doesn't give us any clues as to where the possible storage was or how this could corrupt the filesystem. So I sent some follow-up questions and got the following responses. (Regular is question to Mr. Sumrall, bold is response.
1)*Can this release fix a device where the bug has already been triggered (resulting in I/O error)?
No. *The 32 Kbytes of zeros have already been inserted into the filesystem (usually in a particularly bad place, like the inode or block bitmaps, or the inode table) and the filesystem is now corrupt.
2) What would happen if a device is rolled back to a previous kernel - one without this fix? Would it be exposed again to the bug?
Yes, the corruption could happen on older kernels. *The fix doesn't permanently fix the firmware, it patches the firmware every time the device is powered on (initial power-on, wakeup from sleep).
The next question was one that has been bugging me so I figured it wouldn't hurt to learn more about this bug. Sorry if this rubs some people the wrong way.
3) The explanation in the bugfix mentions 32 Kb of zeros being added to storage. But I can't see this causing an I/O error unless it was doing this in the storage containing the instruction set. Was this somehow corrupting the I/O instruction set contained within the firmware?*I have spent several weeks defending the opinion that this was not a hardware failure but software-based.
When the ext4 filesystem detects an error, and the filesystem is set to panic or re-mount read-only on error, the function ext4_handle_error() will record an EIO *in the journal:
Code:
static void ext4_handle_error(struct super_block *sb)
{
if (sb->s_flags & MS_RDONLY)
return;
if (!test_opt(sb, ERRORS_CONT)) {
journal_t *journal = EXT4_SB(sb)->s_journal;
EXT4_SB(sb)->s_mount_flags |= EXT4_MF_FS_ABORTED;
if (journal)
jbd2_journal_abort(journal, -EIO);
}
.
.
.
.
}
So it doesn't have to be an actual low-level IO error to cause EIO to be recorded in the journal.
As for hardware vs. software failure, it is a bug in the firmware of the emmc chip, and this kernel patch enables a work-around to prevent the problem from happening.
Click to expand...
Click to collapse
Thanks again to Mr. Sumrall for this information. More soon.
Here's what I have - hope it helps. I would help test, but not until after the weekend. Thanks for all the work and info.
MAG4FA
0x0
0x0
0x000015
0x0100
10/2011
MMC
Hello,
I have a problem with the MC7090 version with imager but broken motherboard.
Someone told me to buy a laser version of this scanner and replace the motherboard to my and had to work.
Unfortunately does not work, you might need to change something in the registry. I do not know what, and whether a change in the registry will remain after a hard reset?
The system is both devices WM 5.0 Pro.
This thread is to document MCUs found to be cross-compatible between MTCD units, which includes PX3 and PX5 variants, which share identical mainboard hardware and MCU Chip STM32F091.
The following MTCD & MTCE (as of v2.56) MCUs have been validated as cross compatible on 1024x600 units:
- MLT - 01/07/17 - caution - has resulted in issues for some @leonkernan
- JY
- KBT - 08/12/2017 - thanks @abagos
- KD (v2.40_2 - enables bluetooth hands free in both front speakers)
- KGL
- KSP thanks @Overmann
- GS - Note "version unmatch" error and fix below No issue experienced on MTCE going from JY 2.80 to GS 2.78 and back to HA 2.80 - March 2018
- GS compatible on MX (see post #513)
- HA (v2.56 06/07/17 - note v2.52 on enables "shutdown delay when acc off" menu) HA MTCE (30/09/17) V2.65 https://www.sendspace.com/pro/dl/ufie8k
See this thread for pics where MCU HA and KD has been applied on JY. https://forum.xda-developers.com/showpost.php?p=72737797&postcount=640
I initially upgraded to KD 2.40, then HA v2.52 after first exporting the MCU settings.
Note that I had to reapply MCU settings in [factory sertings] to configure radio, LED, bluetooth, hardware keys, volume levels between radio, bluetooth, system etc.
MCUs were previously thought to be manufacturer specific - e.g. HA, JY, GS, KD, however I have found that they are compatible and of interest where there is either a specific issue with your MCU (e.g. bluetooth out of one speaker, to enable PX5 sleep mode control) or the vendor has long ceased to support & release updates - such as JY.
MCU cross-compatibility became of interest to me when I upgraded my JY [MCU v2.06_2] PX3 with a HCT PX5 SOM and wanted to enable the MCU specific menu item [shutdown delay when ACC off] to control sleep as found on HA/Dasaita.
I first noted that from an XDA post listing JY an KD v2.06_2 being identical and on that assumption, upgraded to KDv2.40_2, which successfully applied - but had to reconfigure factory settings.
Following on, I found a post which has an image of a GS board & MCU chip - noted it was identical to the MTCD JY MCU chip [STM32F091] - then came across a post where a user had inadvertently applied a MTCD GS MCU to a MTCD JY without bricking it.
I then started comparing same version number firmware files from various manufacturer MCUs with a text compare tool. From this work, I had enough info to compare the latest HA v2.52 and conclude it 'should' be compatible. Indeed it is.
As always, check first (suggest confirming MTCD, MCU Chip part number, view/compare the fw files, ensure you have original MCU FW, backup MCU settings or document the settings to ensure your hardware controls, volume control, bluetooth, radio, canbus etc are setup correctly). Apply at your own risk.
Please post your results and I will update this thread.
Updates:
UPDATE: 26/06/2017 Users of 800x480 Users must also apply file[dmcu.ext], a text file containing:
For PX3 --> screen:3
For PX5 --> screen:1
01/07/17 - MLT
06/07/17 - KGL confirmed and new HA v2.56
30/09/17 - MTCE MCU confimed compatible
08/03/18 - MTCE JY/GS/HA compatible - No issue experienced on MTCE going from JY 2.80 to GS 2.78 and back to HA 2.80
GS Specific Notes:
Oberbergler said:
For all those with a GS: Our unit is compatible with the MTCE MCU but you have to restore your settings and maybe to manually reconfigure your touchscreen and buttons. There is a simple function to do this in the factory settings (126) which is called key study. My touchscreen was also swapped by the x axis. I had to go with the swapped touchscreen into the settings, configure it, reboot the unit and everything was fine. For the buttons you have also the possibility to use short press and long press buttons, which is great because our units (at least mine) has only five buttons and no return button. So I use now the power off button as return in short press mode and power off in long press
Click to expand...
Click to collapse
Version unmatch see this post where user resolved by reapplying MCU AND Software APK Fix Here
- Attached Version Unmatch APK fix to this post, thanks @Wadzio
GS Configuration Settings file:
Bose321 said:
Here it is: https://gerbenbol.com/android/dmcu.cfg.
Click to expand...
Click to collapse
Do not dilute this thread by posting "how-to" questions such as - how do I update the MCU, what unit do I have, can I do it, how do I find factory settings, etc. This thread is to document cross-compatible MCUs and the fixes they apply.
Hi! Confirmed, I've upgraded to PX5 (JY UL135). Flashed KD2.40 over JY 2.06_2 then flashed HA 2.52 and everything is working as it should be. Thanks for your work.
I can confirm a cross compatibility as well.
My Unit is a xtrons device with die MCU firmware GS 2.43 and yesterday i did flash the HA 2.52. But be sure to save your mcu config first. Otherwise the hardware buttons won't do what they were supposed to do. But after flashing the firmware and restoring the config, everything is back to normal.
To make it easier to re-apply the settings, you can use the mcu.cfg function and flash it with the MCU, just in case anyone didnt know.
Some time ago I tried to investigate what actually those abbrevations mean. In my understanding GS, JY, HA is related to the canbus profiles, not directly to the reseller. It seems to be reasonable because MCU has really tiny flash capacity and add all canbus configurations to one chip would be impossible.
f1x said:
Some time ago I tried to investigate what actually those abbrevations mean. In my understanding GS, JY, HA is related to the canbus profiles, not directly to the reseller. It seems to be reasonable because MCU has really tiny flash capacity and add all canbus configurations to one chip would be impossible.
Click to expand...
Click to collapse
No, you are wrong there - the letters very definitely relate to the manufacturer, NOT the CAN Bus profiles KLD = "Klyde" KGL, = "Kai Ge Le", JY = "Joyous" etc, this has been established for years.
The seller has NOTHING to do with the software at all.
The CAN Bus profiles are named in factory settings
On MTCB/C headunits there was a slight difference in the code between MCU types so they were not interchangeable (apart from BN and HA), it would seem that on MTCD units there is no such variation in the code.
Does this also apply to LM_ (Erisin) MCUs?
I have a Erisin 5048 HU with MCU 2.41_1. Does anyone have any experience in flashing a different MCU to a LM_ type MCU? I´m worried to brick my HU if a flash a higher HA_ version.
Any info would be highly appreciated.
Greetings
Speedycarv
SpeedyCarv said:
I have a Erisin 5048 HU with MCU 2.41_1. Does anyone have any experience in flashing a different MCU to a LM_ type MCU? I´m worried to brick my HU if a flash a higher HA_ version.
Any info would be highly appreciated.
Greetings
Speedycarv
Click to expand...
Click to collapse
There are no "Erisin" MCUs - Erisin are a seller only, they sell units made by several manufacturers. You have an "LM" unit.
I would stick to what @marchnz has tested already, although having said that, on the MTCB/C units if you flash the wrong MCU you can simply flash the correct MCU to correct it, cant say if its the same for MTCD units, up to you if you want to risk it.
typos1 said:
There are no "Erisin" MCUs - Erisin are a seller only, they sell units made by several manufacturers. You have an "LM" unit.
I would stick to what @marchnz has tested already, although having said that, on the MTCB/C units if you flash the wrong MCU you can simply flash the correct MCU to correct it, cant say if its the same for MTCD units, up to you if you want to risk it.
Click to expand...
Click to collapse
My level of knowledge has not grown in any way after reading your post.
Thank you anyway..
SpeedyCarv said:
My level of knowledge has not grown in any way after reading your post.
Thank you anyway..
Click to expand...
Click to collapse
Maybe read it again ?
Basically, you could risk trying it - MTCB/C units can be restored if the wrong MCU is flashed, maybe MTCD units could be restored if the wrong MCU is flashed also ? But maybe not, so that is your decision whether to try or not.
Otherwise stick to what @marchnz has said and do not try it.
And your unit is NOT an "Erisin" unit, they are sellers and sell units from many manufacturers, you have an LM MTCD unit.
Cant make it any clearer than that.
typos1 said:
Maybe read it again ?
And your unit is NOT an "Erisin" unit, they are sellers and sell units from many manufacturers, you have an LM MTCD unit.
Click to expand...
Click to collapse
Not necessary to read again. I already knew that. That's what i tried to express in typing "my level of knowledge has not grown" Sorry if i write misunderstandable, i'm not a native speaker (German).
Thank you again for your time and patience
typos1 said:
To make it easier to re-apply the settings, you can use the mcu.cfg function and flash it with the MCU, just in case anyone didnt know.
Click to expand...
Click to collapse
Can you explain me how ? Do I put the mcu.cfg file with the new mcu in the root of gps SD ?
In factory settings I see only the option to export, not to import. Or did I miss something ?
Wout2426 said:
Can you explain me how ? Do I put the mcu.cfg file with the new mcu in the root of gps SD ?
In factory settings I see only the option to export, not to import. Or did I miss something ?
Click to expand...
Click to collapse
Thats correct, just put the mcu.cfg file on the SD card with the mcu.img.
typos1 said:
Thats correct, just put the mcu.cfg file on the SD card with the mcu.img.
Click to expand...
Click to collapse
Or, once mcu has been upgraded, you can remove the mcu update (.img) from the root of the gps card and apply the config (.cfg) on the root of the gps card separately - by running the 'upgrade MCU', it will see .cfg file and apply it.
Update for 800x480 users who update to the latest MCU - you must also apply a dmcu.ext
DMCU.EXT details
DMCU.EXT & screen resolution setting/howto/details
dmcu.ext details for PX5 800x480
That said - why is anyone purchasing a PX5 unit with 800x480?!?!
KD --> HA for 800x480 Screen
I have had quite an experience over the weekend, but am able to report successfully updating a PX3 MTCD_KD unit to a PX5 with the HA2.52 MCU Code.
For those of us with 800x480 screen sizes, as now noted in the main thread, we need to create the dmcu.ext file with the appropriate screen size to be flashed with the dmcu.img file.
Just a note that if you run across the issue of not having the appropriate resolution; don't freak out.
One interesting note I hadn't mentioned before is that after the PX5 started thinking it was 1024, I replaced it with the PX3. The PX3 booted thinking it was 1024 also. After reverting the PX3 to 800 (flashing with screen:3), I replaced the PX5. The PX5 however, did not revert back to 800, but remained at 1024. The PX5 did not revert back to 800 until after I reflashed the MCU, specifically stating it was to be 800 (screen:1).
So I tried HA 2.52 on Xtrons TB706APL
I get the following error on reboot.
After I update from dmcu.cfg it goes away but if you go into factory settings and change anything it comes back.
I also didnt see the option for the shutdown that this mcu is supposed to have.
typos1 said:
Thats correct, just put the mcu.cfg file on the SD card with the mcu.img.
Click to expand...
Click to collapse
I assume you mean "dmcu.img" and "dmcu.cfg"? That's how my downloaded img and backup cfg are called.
Bose321 said:
I assume you mean "dmcu.img" and "dmcu.cfg"? That's how my downloaded img and backup cfg are called.
Click to expand...
Click to collapse
Yeah, thats right - the "d" is just there to show its an MTCD MCU not an MTCB or MTCC one.
1-2-Hak said:
So I tried HA 2.52 on Xtrons TB706APL
I get the following error on reboot.
After I update from dmcu.cfg it goes away but if you go into factory settings and change anything it comes back.
I also didnt see the option for the shutdown that this mcu is supposed to have.
Click to expand...
Click to collapse
The shutdown option is under System Settings --> extra settings. You wont find it in the factory settings. Just FYI.
Which dmcu.cfg did you use? I might be wrong, but it seems to me it might be dangerous to use different dmcu.cfg files with different versions of the MCU Code.
Hello
Request the dump emmc file For cool1 dual c106 phone
Request for these files
boot1.bin
boot2.bin
main.bin (user data main.bin)
Does anyone have ?
If your phone is rooted
Learn through this video
https://www.youtube.com/watch?v=aWgJdwn0-4M
Generate these files for me
Please
I do not have these files and my mobile is brick
The only way to fix the use of the box is "easy jtag box"
Does anyone have ?
or
Or it can produce it Via Video Tutorial
I really need help :crying:
Unfortunately, these files do not exist on the Internet
hello?
After 2 years...
Is your phone still brick?
Lineage can dump SysUI(I don't know is it emmc or other things), if you need that , I maybe can help you.