I have done an extended analysis of the FFU file of Windows Mobile 10 for Xiaomi Mi4.
The partition layout is not the same from Android and Windows Phone. But, some partitions have the same starting LBA, ending LBA and size so they are at the same location and have the same size in both partition layouts. Because the FFU doesn't contain data blocks to write in these partitions, we can assume they stay intact during the update from Android to Windows Mobile.
This way I found out that 5 partitions are kept from Android, 13 are written with data and 6 are nulled (content is all zeroes):
Code:
+-----+-----------+-----------+--------+-----------------+---------+-------------------+
+ # | Start LBA | End LBA | Size | Name | In FFU | Status |
+-----+-----------+-----------+--------+-----------------+---------+-------------------+
| 0| 1024| 2047| 1024|SBL1 | Yes | Written |
| 1| 2048| 2559| 512|UEFI_BS_NV | Yes | Nulled |
| 2| 3072| 3583| 512|UEFI_RT_NV | Yes | Nulled |
| 3| 4096| 8191| 4096|UEFI | Yes | Written |
| 4| 8192| 10239| 2048|DDR | | Kept from Android |
| 5| 10240| 12287| 2048|SSD | | Kept from Android |
| 6| 12288| 14335| 2048|PADDING0 | Yes | Nulled |
| 7| 14336| 30719| 16384|DPP | Yes | Written |
| 8| 30720| 30783| 64|DBI | Yes | Written |
| 9| 31744| 32743| 1000|RPM | Yes | Written |
| 10| 32768| 33767| 1000|TZ | Yes | Written |
| 11| 33792| 34815| 1024|WINSECAPP | Yes | Written |
| 12| 34816| 67583| 32768|TZAPPS | Yes | Written |
| 13| 67584| 68607| 1024|BACKUP_SBL1 | | |
| 14| 68608| 68671| 64|BACKUP_DBI | | |
| 15| 69632| 73727| 4096|BACKUP_UEFI | | |
| 16| 73728| 74727| 1000|BACKUP_RPM | | |
| 17| 74752| 75751| 1000|BACKUP_TZ | | |
| 18| 75776| 76799| 1024|BACKUP_WINSECAPP | | |
| 19| 76800| 109567| 32768|BACKUP_TZAPPS | Yes | Nulled |
| 20| 109568| 117759| 8192|MMOS | Yes | Written |
| 21| 117760| 131071| 13312|PADDING1 | | |
| 22| 131072| 134143| 3072|MODEM_FS1 | | Kept from Android |
| 23| 134144| 137215| 3072|MODEM_FS2 | Yes | Nulled |
| 24| 137216| 137247| 32|MODEM_FSC | Yes | Nulled |
| 25| 138240| 154623| 16384|PLAT | Yes | Written |
| 26| 154624| 220159| 65536|EFIESP | Yes | Written |
| 27| 220160| 262143| 41984|PADDING2 | | |
| 28| 262144| 265215| 3072|MODEM_FSG | | Kept from Android |
| 29| 265216| 491519| 226304|PADDING3 | | |
| 30| 491520| 524287| 32768|PERSIST | | Kept from Android |
| 31| 524288| 5537791| 5013504|MainOS | Yes | Written |
| 32| 5537792| 20967423|15429632|Data | Yes | Written |
+-----+-----------+-----------+--------------------------+---------+-------------------+
Regarding the partitions which are in the FFU file, here are all the information I gathered about them:
"SBL1" is a SBL (Secondary Boot Loader) file with a 80 bytes header
The file is not signed (no signature and no certificate chain).
Codeword[4]: d1dc4b84
Magic[4]: 3410d773
Image ID[4]: 15000000 (SBL1_IMG)
Reserved 1[4]: ffffffff
Reserved 2[4]: ffffffff
Image source[4]: 50000000
Image destination pointer[4]: 00c000f8 (4160798720)
Image size[4]: f8480400
Code size[4]: f8480400
Signature pointer[4]: f80805f8 (4161079544)
Signature size[4]: 00000000 (0)
Certificate chain pointer[4]: f80805f8 (4161079544)
Certificate chain size[4]: 00000000 (0)
OEM root certificate selelected[4]: 01000000
OEM number of root certificates[4]: 01000000
Booting image config[4]: ffffffff
Reserved 6[4]: ffffffff
Reserved 7[4]: ffffffff
Reserved 8[4]: ffffffff
Reserved 9[4]: ffffffff
"UEFI_BS_NV" is an empty partition
"UEFI_RT_NV" is an empty partition
"UEFI" is probably an ARM binary file with a 40 bytes header
The file is not signed (no signature and no certificate chain).
Image ID[4]: 05000000 (APPSBL_IMG)
Flash partition version[4]: 03000000
Image source[4]: 00000000
Image destination pointer[4]: 00002000 (2097152)
Image size[4]: 00800d00
Code size[4]: 00800d00
Signature pointer[4]: 00802d00 (2981888)
Signature size[4]: 00000000 (0)
Certificate chain pointer[4]: 00802d00 (2981888)
Certificate chain size[4]: 00000000 (0)
"PADDING0" is an empty partition
"DPP" is a FAT partition
"DBI" is probably an ARM binary file with a 40 bytes header
The file is not signed (no signature and no certificate chain).
Image ID[4]: 1e000000
Flash partition version[4]: 03000000
Image source[4]: 00000000
Image destination pointer[4]: 000080fe (4269801472)
Image size[4]: 982d0000
Code size[4]: 982d0000
Signature pointer[4]: 982d80fe (4269813144)
Signature size[4]: 00000000 (0)
Certificate chain pointer[4]: 982d80fe (4269813144)
Certificate chain size[4]: 00000000 (0)
"RPM" is an ARM ELF (Executable and Linkable Format) file
Class: ELF32
Magic[16]: 7f454c46010101000000000000000000
Type[2]: 0200 (ET_EXEC [Executable file])
Machine[2]: 2800 (EM_ARM [Advanced RISC Machines ARM])
Version[4]: 01000000
Entry point address[4]: 91001000
Start of program headers[4]: 34000000
Start of section headers[4]: 00000000
Flags[4]: 02000005
Size of this header[2]: 3400
Size of program headers[2]: 2000
Number of program headers[2]: 0400
Size of section headers[2]: 2800
Number of section headers[2]: 0000
Section header string table index[2]: 0000
"TZ" is an ARM ELF (Executable and Linkable Format) file
Class: ELF32
Magic[16]: 7f454c46010101000000000000000000
Type[2]: 0200 (ET_EXEC [Executable file])
Machine[2]: 2800 (EM_ARM [Advanced RISC Machines ARM])
Version[4]: 01000000
Entry point address[4]: 000081fe
Start of program headers[4]: 34000000
Start of section headers[4]: 00000000
Flags[4]: 02000005
Size of this header[2]: 3400
Size of program headers[2]: 2000
Number of program headers[2]: 1000
Size of section headers[2]: 2800
Number of section headers[2]: 0000
Section header string table index[2]: 0000
"WINSECAPP" is an ARM ELF (Executable and Linkable Format) file
Class: ELF32
Magic[16]: 7f454c46010101000000000000000000
Type[2]: 0200 (ET_EXEC [Executable file])
Machine[2]: 2800 (EM_ARM [Advanced RISC Machines ARM])
Version[4]: 01000000
Entry point address[4]: 0090fe07
Start of program headers[4]: 34000000
Start of section headers[4]: 00000000
Flags[4]: 02000005
Size of this header[2]: 3400
Size of program headers[2]: 2000
Number of program headers[2]: 0400
Size of section headers[2]: 2800
Number of section headers[2]: 0000
Section header string table index[2]: 0000
"TZAPPS" is a FAT partition
"BACKUP_TZAPPS" is an empty partition
"MODEM_FS2" is an empty partition
"MODEM_FSC" is an empty partition
"PLAT" is a FAT partition
"EFIESP" is a FAT partition
"MMOS" is a FAT partition
"MainOS" is a NTFS partition
-> Boot sector backup at offset 2566913536 match the boot sector from sector 0
"Data" is a NTFS partition
-> Boot sector backup at offset 7899971072 match the boot sector from sector 0
Regarding the FFU file itself (10586.1102.3063.Retail.FFU): the image embedded catalog is not signed. I attached it to this post. I also attached the extracted hash table. Indeed, the cat file only contains a SHA1 of the hashtable: it's enough to ensure the data is fine.
All the informations:
"_SECURITY_HEADER" position: 0
_SECURITY_HEADER
----------------
cbSize[4]: 20000000 (32)
Signature[12]: 5369676e6564496d61676520 (SignedImage )
dwChunkSizeInKb[4]: 80000000 (128)
dwAlgId[4]: 0c800000 (32780)
dwCatalogSize[4]: 48010000 (328)
dwHashTableSize[4]: 00a50600 (435456)
"Signed Catalog" position: 32
"Hash table data" position: 360 (+328)
"Padding" position: 435816 (+435456)
"_IMAGE_HEADER" position: 524288 (+88472)
Image Integrity Validation
--------------------------
Verify SHA-1 hash (91b4b4d9944bd90e36891b26c6ecded90190fcd5) of the hash table against the one from the embedded catalog
-> SHA-1 hash of the hash table match the hash from the catalog
Verify 1783627776 bytes of data per chunk of 128 kilobytes using 13608 SHA256 hashes (32 bytes)
-> Done successfully!
_IMAGE_HEADER
-------------
cbSize[4]: 18000000 (24)
Signature[12]: 496d616765466c6173682020 (ImageFlash )
ManifestLength[4]: f41a0000 (6900)
dwChunkSize[4]: 80000000 (128)
"Manifest" position: 524312
"Padding" position: 531212 (+6900)
"_STORE_HEADER" position: 655360 (+124148)
_STORE_HEADER
-------------
dwUpdateType[4]: 00000000 (0)
MajorVersion[2]: 0100 (1)
MinorVersion[2]: 0000 (0)
FullFlashMajorVersion[2]: 0200 (2)
FullFlashMinorVersion[2]: 0000 (0)
szPlatformId[192]: 5849414f4d49544553542e5869616f6d69383937342e4d49340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (XIAOMITEST.Xiaomi8974.MI4)
dwBlockSizeInBytes[4]: 00000200 (131072)
dwWriteDescriptorCount[4]: 25350000 (13605)
dwWriteDescriptorLength[4]: 58520300 (217688)
dwValidateDescriptorCount[4]: 00000000 (0)
dwValidateDescriptorLength[4]: 00000000 (0)
dwInitialTableIndex[4]: 00000000 (0)
dwInitialTableCount[4]: 01000000 (1)
dwFlashOnlyTableIndex[4]: d1000000 (209)
dwFlashOnlyTableCount[4]: 01000000 (1)
dwFinalTableIndex[4]: 23350000 (13603)
dwFinalTableCount[4]: 02000000 (2)
NumOfStores[2]: Skipped because field is only for version 2 FFU image
StoreIndex[2]: Skipped because field is only for version 2 FFU image
StorePayloadSize[8]: Skipped because field is only for version 2 FFU image
DevicePathLength[2]: Skipped because field is only for version 2 FFU image
DevicePath[2]: Skipped because field is only for version 2 FFU image
"_VALIDATION_ENTRY" position: 655608
"_VALIDATION_ENTRY" size: 0
"_BLOCK_DATA_ENTRY" position: 655608
"_BLOCK_DATA_ENTRY" size: 217688
"_IMAGE_PAYLOAD" position: 917504
_VALIDATION_ENTRY
-----------------
Skipped because there is no validation entries
_BLOCK_DATA_ENTRY
-----------------
(Removed because it's really long !)
"Padding" position: 873296
"_IMAGE_PAYLOAD" position: 917504
GUID Partition Table Layouts
----------------------------
GUID Partition Table from data block #0
Code:
+-----+-----------+-----------+--------+------------------------------------+
+ # | Start LBA | End LBA | Size | Name |
+-----+-----------+-----------+--------+------------------------------------+
+-----+-----------+-----------+--------+------------------------------------+
GUID Partition Table from data block #209
Code:
+-----+-----------+-----------+--------+------------------------------------+
+ # | Start LBA | End LBA | Size | Name |
+-----+-----------+-----------+--------+------------------------------------+
| 0| 1024| 2047| 1024|SBL1 |
| 1| 2048| 2559| 512|UEFI_BS_NV |
| 2| 3072| 3583| 512|UEFI_RT_NV |
| 3| 4096| 8191| 4096|UEFI |
| 4| 8192| 10239| 2048|DDR |
| 5| 10240| 12287| 2048|SSD |
| 6| 12288| 14335| 2048|PADDING0 |
| 7| 14336| 30719| 16384|DPP |
| 8| 30720| 30783| 64|DBI |
| 9| 31744| 32743| 1000|RPM |
| 10| 32768| 33767| 1000|TZ |
| 11| 33792| 34815| 1024|WINSECAPP |
| 12| 34816| 67583| 32768|TZAPPS |
| 13| 67584| 68607| 1024|BACKUP_SBL1 |
| 14| 68608| 68671| 64|BACKUP_DBI |
| 15| 69632| 73727| 4096|BACKUP_UEFI |
| 16| 73728| 74727| 1000|BACKUP_RPM |
| 17| 74752| 75751| 1000|BACKUP_TZ |
| 18| 75776| 76799| 1024|BACKUP_WINSECAPP |
| 19| 76800| 109567| 32768|BACKUP_TZAPPS |
| 21| 117760| 131071| 13312|PADDING1 |
| 22| 131072| 134143| 3072|MODEM_FS1 |
| 23| 134144| 137215| 3072|MODEM_FS2 |
| 24| 137216| 137247| 32|MODEM_FSC |
| 25| 138240| 154623| 16384|PLAT |
| 26| 154624| 220159| 65536|EFIESP |
| 27| 220160| 262143| 41984|PADDING2 |
| 28| 262144| 265215| 3072|MODEM_FSG |
| 29| 265216| 491519| 226304|PADDING3 |
| 30| 491520| 524287| 32768|PERSIST |
+-----+-----------+-----------+--------+------------------------------------+
GUID Partition Table from data block #13603
Code:
+-----+-----------+-----------+--------+------------------------------------+
+ # | Start LBA | End LBA | Size | Name |
+-----+-----------+-----------+--------+------------------------------------+
| 0| 1024| 2047| 1024|SBL1 |
| 1| 2048| 2559| 512|UEFI_BS_NV |
| 2| 3072| 3583| 512|UEFI_RT_NV |
| 3| 4096| 8191| 4096|UEFI |
| 4| 8192| 10239| 2048|DDR |
| 5| 10240| 12287| 2048|SSD |
| 6| 12288| 14335| 2048|PADDING0 |
| 7| 14336| 30719| 16384|DPP |
| 8| 30720| 30783| 64|DBI |
| 9| 31744| 32743| 1000|RPM |
| 10| 32768| 33767| 1000|TZ |
| 11| 33792| 34815| 1024|WINSECAPP |
| 12| 34816| 67583| 32768|TZAPPS |
| 13| 67584| 68607| 1024|BACKUP_SBL1 |
| 14| 68608| 68671| 64|BACKUP_DBI |
| 15| 69632| 73727| 4096|BACKUP_UEFI |
| 16| 73728| 74727| 1000|BACKUP_RPM |
| 17| 74752| 75751| 1000|BACKUP_TZ |
| 18| 75776| 76799| 1024|BACKUP_WINSECAPP |
| 19| 76800| 109567| 32768|BACKUP_TZAPPS |
| 20| 109568| 117759| 8192|MMOS |
| 21| 117760| 131071| 13312|PADDING1 |
| 22| 131072| 134143| 3072|MODEM_FS1 |
| 23| 134144| 137215| 3072|MODEM_FS2 |
| 24| 137216| 137247| 32|MODEM_FSC |
| 25| 138240| 154623| 16384|PLAT |
| 26| 154624| 220159| 65536|EFIESP |
| 27| 220160| 262143| 41984|PADDING2 |
| 28| 262144| 265215| 3072|MODEM_FSG |
| 29| 265216| 491519| 226304|PADDING3 |
| 30| 491520| 524287| 32768|PERSIST |
| 31| 524288| 5537791| 5013504|MainOS |
| 32| 5537792| 20967423|15429632|Data |
+-----+-----------+-----------+--------+------------------------------------+
Data Blocks to Partitions
-------------------------
Data Block #0-0: -> GPT
Data Block #0-1: -> GPT
Data Block #1-0: -> SBL1
to
Data Block #4-0: -> SBL1
Data Block #5-0: -> UEFI_BS_NV
to
Data Block #8-0: -> UEFI_RT_NV
Data Block #9-0: -> UEFI
to
Data Block #24-0: -> UEFI
Data Block #25-0: -> PADDING0
to
Data Block #32-0: -> PADDING0
Data Block #33-0: -> DPP
Data Block #34-0: -> DBI
Data Block #35-0: -> RPM
to
Data Block #38-0: -> RPM
Data Block #39-0: -> TZ
to
Data Block #42-0: -> TZ
Data Block #43-0: -> WINSECAPP
to
Data Block #46-0: -> WINSECAPP
Data Block #47-0: -> TZAPPS
to
Data Block #48-0: -> TZAPPS
Data Block #49-0: -> BACKUP_TZAPPS
to
Data Block #60-0: -> BACKUP_TZAPPS
Data Block #61-0: -> MODEM_FS2
to
Data Block #68-0: -> MODEM_FS2
Data Block #69-0: -> MODEM_FSC
Data Block #70-0: -> PLAT
to
Data Block #127-0: -> PLAT
Data Block #128-0: -> EFIESP
to
Data Block #208-0: -> EFIESP
Data Block #209-0: -> GPT
Data Block #210-0: -> MMOS
to
Data Block #211-0: -> MMOS
Data Block #212-0: -> MainOS
to
Data Block #12925-0: -> MainOS
Data Block #12926-0: -> Data
to
Data Block #13602-0: -> Data
Data Block #13603-0: -> GPT
Data Block #13604-0: -> GPT
Regarding the Firehose flasher:
".\prog_emmc_firehose_8974.mbn" is a SBL (Secondary Boot Loader) file with a 80 bytes header
The file is not signed (no signature and no certificate chain).
Codeword[4]: d1dc4b84
Magic[4]: 3410d773
Image ID[4]: 0d000000
Reserved 1[4]: ffffffff
Reserved 2[4]: ffffffff
Image source[4]: 50000000
Image destination pointer[4]: 50c000f8 (4160798800)
Image size[4]: 90480100
Code size[4]: 90480100
Signature pointer[4]: e00802f8 (4160882912)
Signature size[4]: 00000000 (0)
Certificate chain pointer[4]: e00802f8 (4160882912)
Certificate chain size[4]: 00000000 (0)
OEM root certificate selelected[4]: 01000000
OEM number of root certificates[4]: 01000000
Booting image config[4]: ffffffff
Reserved 6[4]: ffffffff
Reserved 7[4]: ffffffff
Reserved 8[4]: ffffffff
Reserved 9[4]: ffffffff
Finally, the packages installed in this ROM:
Part of the Windows Mobile Adaptation Kit (AK):
C:\Program Files (x86)\Windows Kits\10\MSPackages\Merged\arm\fre
Probably untouched.
Microsoft.MS_RETAILDEMOCONTENT_NEUTRAL.Data.cab
Microsoft.MS_RETAILDEMOCONTENT_ZH-CN.Data.cab
Microsoft.EFIESP.Production.cab
Microsoft.MS_BOOTSEQUENCE_RETAIL.EFIESP.cab
Microsoft.RELEASE_PRODUCTION.EFIESP.cab
Microsoft.MainOS.Production.cab
Microsoft.MainOS.Production_Lang_en-US.cab
Microsoft.MainOS.Production_Lang_zh-CN.cab
Microsoft.MainOS.Production_Res_1080x1920.cab
Microsoft.MS_BOOTSEQUENCE_RETAIL.MainOS.cab
Microsoft.MS_COMMSENHANCEMENTCHINA.MainOS.cab
Microsoft.MS_COMMSMESSAGINGGLOBAL.MainOS.cab
Microsoft.MS_FACEBOOK.MainOS.cab
Microsoft.MS_OPTIMIZED_BOOT.MainOS.cab
Microsoft.MS_RETAILDEMOCONTENT_NEUTRAL.MainOS.cab
Microsoft.MS_RETAILDEMOCONTENT_ZH-CN.MainOS.cab
Microsoft.MS_SKYPE.MainOS.cab
Microsoft.MS_STANDARD_FEATURE_1.MainOS.cab
Microsoft.PhoneFM.cab
Microsoft.PRERELEASE_PROTECTED.MainOS.cab
Microsoft.PRERELEASE_PROTECTED.MainOS_Lang_en-US.cab
Microsoft.PRERELEASE_PROTECTED.MainOS_Lang_zh-CN.cab
Microsoft.PRERELEASE_PROTECTED.MainOS_Res_1080x1920.cab
Microsoft.RELEASE_PRODUCTION.MainOS.cab
Microsoft.RELEASE_PRODUCTION.UpdateOS.cab
Microsoft.UpdateOS.Production.cab
C:\Program Files (x86)\Windows Kits\10\MSPackages\mobilecore\ARM\fre
Probably untouched.
microsoft.mobilecore.prod.efiesp.cab
microsoft.mobilecore.prod.mainos.cab
microsoft.mobilecore.updateos.cab
C:\Program Files (x86)\Windows Kits\10\MSPackages\retail\ARM\fre
Probably untouched.
Microsoft.Input.mtf_Lang_en-US.cab
Microsoft.Input.mtf_Lang_zh-CN.cab
Microsoft.Speech.Data_Lang_en-US.cab
Microsoft.Speech.Data_Lang_zh-CN.cab
Part of the Qualcomm Board Support Package:
E:\MI4\BSP\prebuilt.3063.RTF\spkg
ODM-made packages:
Qualcomm.MI4.Customizations.MainOS.spkg
Qualcomm.MI4.Customizations.StartLayout.spkg
Qualcomm.MI4.Customizations.StaticApps.MainOS.spkg
Qualcomm.MI4.Customizations.EFIESP.spkg
Qualcomm.QC8974.OEMAutobrightness.spkg
Qualcomm.QC8974.OEMDevicePlatform.spkg
Qualcomm.Xiaomi.DeviceLayout.spkg
Qualcomm MSM8974 drivers:
Can ODM recompile these packages? Or are they untouched?
OEM.HalExtensions.UpdateOS.spkg
OEM.Service.ProvisionService.spkg
Qualcomm.QC8974.BattProv.spkg
Qualcomm.QC8974.FlightToken.spkg
Qualcomm.QC8974.startupnsh.spkg
Qualcomm.QC8974.ABD.spkg
Qualcomm.QC8974.AccLSM330.spkg
Qualcomm.QC8974.ADCM.spkg
Qualcomm.QC8974.adsprpc.spkg
Qualcomm.QC8974.AlsPrxTMD27723.spkg
Qualcomm.QC8974.AMSSPeriImage_8974DI4.spkg
Qualcomm.QC8974.AtmelTouch.spkg
Qualcomm.QC8974.AudioDeviceDriver.spkg
Qualcomm.QC8974.bam_dmux.spkg
Qualcomm.QC8974.BCryptCipher_KM.spkg
Qualcomm.QC8974.BT_MainOS.spkg
Qualcomm.QC8974.DataDaemon.spkg
Qualcomm.QC8974.DiagBridge.spkg
Qualcomm.QC8974.DiagCSI.spkg
Qualcomm.QC8974.DiagRouter.spkg
Qualcomm.QC8974.direct3dum11.spkg
Qualcomm.QC8974.DisableSaverF800Bugcheck.spkg
Qualcomm.QC8974.DSPPeriImage.spkg
Qualcomm.QC8974.FveEnable.HardwareCrypto.spkg
Qualcomm.QC8974.GyroLsm330.spkg
Qualcomm.QC8974.HalExtQCTimer.spkg
Qualcomm.QC8974.HalExtQCWdogTimer.spkg
Qualcomm.QC8974.hwnhaptics.spkg
Qualcomm.QC8974.hwnled.spkg
Qualcomm.QC8974.ipc_router.spkg
Qualcomm.QC8974.libadsprpc.spkg
Qualcomm.QC8974.linklocal.spkg
Qualcomm.QC8974.MagAKM8963.spkg
Qualcomm.QC8974.mbb.spkg
Qualcomm.QC8974.mbbuio.spkg
Qualcomm.QC8974.mbrg.spkg
Qualcomm.QC8974.ocmem.spkg
Qualcomm.QC8974.PageFile.UserData.256.spkg
Qualcomm.QC8974.Pep_ROT.spkg
Qualcomm.QC8974.PEPLED.spkg
Qualcomm.QC8974.PEPProxy.spkg
Qualcomm.QC8974.PhoneRadioRevision_8974DI4.spkg
Qualcomm.QC8974.pil.spkg
Qualcomm.QC8974.powerkeygpiodriver.spkg
Qualcomm.QC8974.PPMSettings.spkg
Qualcomm.QC8974.QC_PEP.spkg
Qualcomm.QC8974.qcadc.spkg
Qualcomm.QC8974.qcaud.spkg
Qualcomm.QC8974.QcBattMiniclass.spkg
Qualcomm.QC8974.QcBattMngr.spkg
Qualcomm.QC8974.qcbluetooth.spkg
Qualcomm.QC8974.QcBms.spkg
Qualcomm.QC8974.qccamavs.spkg
Qualcomm.QC8974.qccamflash.spkg
Qualcomm.QC8974.qccamfrontsensor_imx219_8m_bayer.spkg
Qualcomm.QC8974.qccamisp.spkg
Qualcomm.QC8974.QCCamJpegE.spkg
Qualcomm.QC8974.qccamplatform.spkg
Qualcomm.QC8974.qccamrearsensor_imx214_13m_bayer.spkg
Qualcomm.QC8974.qccamsettings.spkg
Qualcomm.QC8974.qccamtuningdata.spkg
Qualcomm.QC8974.qccdi.spkg
Qualcomm.QC8974.QCCI.spkg
Qualcomm.QC8974.qccomposite.spkg
Qualcomm.QC8974.QCDiagLogging.spkg
Qualcomm.QC8974.qcdx11compiler.spkg
Qualcomm.QC8974.qcdxdriver.spkg
Qualcomm.QC8974.qcepmadc.spkg
Qualcomm.QC8974.qcfmminiport.spkg
Qualcomm.QC8974.qcfmtransport.spkg
Qualcomm.QC8974.qcgnss.spkg
Qualcomm.QC8974.QcGnssSvc.spkg
Qualcomm.QC8974.qcgpio.spkg
Qualcomm.QC8974.QcGsiffSvc.spkg
Qualcomm.QC8974.qci2c.spkg
Qualcomm.QC8974.qcimssink.spkg
Qualcomm.QC8974.qcimssrc.spkg
Qualcomm.QC8974.QCJpegEncoderMFT.spkg
Qualcomm.QC8974.QcKmdBam.spkg
Qualcomm.QC8974.qclistensoundmodellib.spkg
Qualcomm.QC8974.QcLTECoexMgr.spkg
Qualcomm.QC8974.qcmchdcpuml.spkg
Qualcomm.QC8974.qcmcumd.spkg
Qualcomm.QC8974.QcMipiBif.spkg
Qualcomm.QC8974.QcPmic.spkg
Qualcomm.QC8974.QcPmicApps.spkg
Qualcomm.QC8974.QcPmicGpio.spkg
Qualcomm.QC8974.QCPowerLog.spkg
Qualcomm.QC8974.qcqdss.spkg
Qualcomm.QC8974.QcRCSPresSvc.spkg
Qualcomm.QC8974.qcSensor1UM.spkg
Qualcomm.QC8974.qcSensors.spkg
Qualcomm.QC8974.qcSensorsConfig.spkg
Qualcomm.QC8974.QcShutdownSvc.spkg
Qualcomm.QC8974.QCSI.spkg
Qualcomm.QC8974.qcslimbus.spkg
Qualcomm.QC8974.qcspi.spkg
Qualcomm.QC8974.qcspmi.spkg
Qualcomm.QC8974.QcUsbFnSsFilter.spkg
Qualcomm.QC8974.qcviddecmft.spkg
Qualcomm.QC8974.QcVidEncmftH263.spkg
Qualcomm.QC8974.QcVidEncmftH264.spkg
Qualcomm.QC8974.QcVidEncMftMPEG4.spkg
Qualcomm.QC8974.qcvidencum.spkg
Qualcomm.QC8974.qcvss.spkg
Qualcomm.QC8974.QcWicEncoder8974.spkg
Qualcomm.QC8974.QmiDaemon.spkg
Qualcomm.QC8974.qmux.spkg
Qualcomm.QC8974.QNFC.spkg
Qualcomm.QC8974.qualcomm_uart.spkg
Qualcomm.QC8974.RegCustomization.spkg
Qualcomm.QC8974.remoteat.spkg
Qualcomm.QC8974.RemoteAtSrvc.spkg
Qualcomm.QC8974.remotefs.spkg
Qualcomm.QC8974.revrmnet.spkg
Qualcomm.QC8974.rmnetbridge.spkg
Qualcomm.QC8974.RPEN.spkg
Qualcomm.QC8974.scm.spkg
Qualcomm.QC8974.ShowVideoCallingSwitch_8974DI4.spkg
Qualcomm.QC8974.smd.spkg
Qualcomm.QC8974.smmu.spkg
Qualcomm.QC8974.SOCProdTest.spkg
Qualcomm.QC8974.ssd.spkg
Qualcomm.QC8974.ssm.spkg
Qualcomm.QC8974.subsys.spkg
Qualcomm.QC8974.TouchDetectionDriver.spkg
Qualcomm.QC8974.UsbFnFilter.spkg
Qualcomm.QC8974.WCNSSPeriImage.spkg
Qualcomm.QC8974.WDFHelper.spkg
Qualcomm.QC8974.WifiNotifierSrvc.spkg
Qualcomm.QC8974.wlan.spkg
Qualcomm.QC8974.wlan_ihv.spkg
Qualcomm.QC8974.WMIms.spkg
Qualcomm.QC8974.WMRil.spkg
Qualcomm.QC8974_MTP.ACSP.spkg
Qualcomm.M8X74SOC_MTP.acpi.spkg
Qualcomm.QC8974.smbios_cfg.spkg
Partitions:
Qualcomm.QC8974.dbi.spkg
Qualcomm.QC8974.rpm.spkg
Qualcomm.QC8974.sbl1.spkg
Qualcomm.QC8974.tz.spkg
Qualcomm.QC8974.tzapps.spkg
Qualcomm.QC8974.uefi.spkg
Qualcomm.QC8974.winsecapp.spkg
Do not forget, you can still install android on it without digging
djtonka said:
Do not forget, you can still install android on it without digging
Click to expand...
Click to collapse
Yes, I know you can flip from Android and Windows Mobile as you wish
I shared these information to understand how they ported Windows Mobile to an Android phone: it seems you need to keep some partition.
TristanLeBoss said:
Yes, I know you can flip from Android and Windows Mobile as you wish
I shared these information to understand how they ported Windows Mobile to an Android phone: it seems you need to keep some partition.
Click to expand...
Click to collapse
Kept partitions must be related to flash mode .
I think if you remove them you will not be able to go back to android
Can it be ported to other phones.
@TristanLeBoss i just wanna know what's the magic that differentiates an ARM windows to an ARM Android? Basic instruction set is the same. So it can be ported to other ARM devices right?
@katsuga & @iamsubhranil
Windows Mobile 10 can theoretically work on all ARM phones. But that's the theory...
For example, Secure Boot will be a problem because if the bootloader of your phone is not signed by your manufacturer, your phone won't boot. Some phones like the Google Nexus offer a way to disable Secure Boot...
The next problem I see is with the drivers. I am unsure if they can be customized by manufacturers or if they are generic.
TristanLeBoss said:
For example, Secure Boot will be a problem because if the bootloader of your phone is not signed by your manufacturer, your phone won't boot. Some phones like the Google Nexus offer a way to disable Secure Boot...
The next problem I see is with the drivers. I am unsure if they can be customized by manufacturers or if they are generic.
Click to expand...
Click to collapse
SecureBoot can be disabled by OEM unlocking AFAIK. And regarding the .spkg drivers, I already made some searches and found that they are UWD(Universal Windows Drivers). VS15 itself provides some generic drivers for UWP. Any low level customisations have to be made by the devolper. This is an one time effort as only UWD will reside in any future version of Windows. Being Linux based OpenSource OS, we already have our device sources, bases and all low level components in the source code state. I don't think porting them in UWD won't be any problem. Will it?
With these discoveries, what could be considered the most optimal candidate phone to test a port on? Be it not all ducks will line up in a row, but if only 1 or 2 are standing out of line, then it seems there are workarounds that can be implemented...hence the disabling of secure boot. The other difficulty is how to flash, or what method can be used both ways...from Android to WM10 and vice versa. Something similar to the miflash tool looks ideal or possibly other qualcomm tools. Maybe I am thinking too far ahead here...
nate0 said:
With these discoveries, what could be considered the most optimal candidate phone to test a port on? Be it not all ducks will line up in a row, but if only 1 or 2 are standing out of line, then it seems there are workarounds that can be implemented...hence the disabling of secure boot. The other difficulty is how to flash, or what method can be used both ways...from Android to WM10 and vice versa. Something similar to the miflash tool looks ideal or possibly other qualcomm tools. Maybe I am thinking too far ahead here...
Click to expand...
Click to collapse
Well at first I think a 100% similar spec-ed Android device with a Windows one could be the target because there'll be much less chance of missing and/or conflicting drivers and other components.
nate0 said:
With these discoveries, what could be considered the most optimal candidate phone to test a port on? Be it not all ducks will line up in a row, but if only 1 or 2 are standing out of line, then it seems there are workarounds that can be implemented...hence the disabling of secure boot. The other difficulty is how to flash, or what method can be used both ways...from Android to WM10 and vice versa. Something similar to the miflash tool looks ideal or possibly other qualcomm tools. Maybe I am thinking too far ahead here...
Click to expand...
Click to collapse
You figured them
1) Ability to disable Secure Boot or to boot an untrusted boot loader
2) Ability to flash in 9008 mode
2a) A file to flash to restore the original OS
2b) Sahara programmer to restore GPT & need boot partitions (MPRGXXXX.hex & XXXX_msimage.mbn) in case we soft brick it
2b) Firehose programmer (prog_XXXX_firehose.mbn) to flash new partitions once fastboot is gone
3) A SoC supported by one of the Windows Mobile 10 FFU we have (Xiaomi Mi4, Lumia 950, Lumia 950XL...)
TristanLeBoss said:
You figured them
1) Ability to disable Secure Boot or to boot an untrusted boot loader
2) Ability to flash in 9008 mode
2a) A file to flash to restore the original OS
2b) Sahara programmer to restore GPT & need boot partitions (MPRGXXXX.hex & XXXX_msimage.mbn) in case we soft brick it
2b) Firehose programmer (prog_XXXX_firehose.mbn) to flash new partitions once fastboot is gone
3) A SoC supported by one of the Windows Mobile 10 FFU we have (Xiaomi Mi4, Lumia 950, Lumia 950XL...)
Click to expand...
Click to collapse
EDIT: Has anyone documented successfully disabling secure-boot on a Nexus or accomplished this? Is this the same as unlocking the boot loader? I have been thinking along the lines of UEFI/EFI secure boot. Similar to disabling secure boot on a surface so you can install Android... Wondering if there are any repercussions or if it can be reversed...
TristanLeBoss said:
Regarding the Firehose flasher:
".\prog_emmc_firehose_8974.mbn" is a SBL (Secondary Boot Loader) file with a 80 bytes header
The file is not signed (no signature and no certificate chain).
Codeword[4]: d1dc4b84
Magic[4]: 3410d773
Image ID[4]: 0d000000
Reserved 1[4]: ffffffff
Reserved 2[4]: ffffffff
Image source[4]: 50000000
Image destination pointer[4]: 50c000f8 (4160798800)
Image size[4]: 90480100
Code size[4]: 90480100
Signature pointer[4]: e00802f8 (4160882912)
Signature size[4]: 00000000 (0)
Certificate chain pointer[4]: e00802f8 (4160882912)
Certificate chain size[4]: 00000000 (0)
OEM root certificate selelected[4]: 01000000
OEM number of root certificates[4]: 01000000
Booting image config[4]: ffffffff
Reserved 6[4]: ffffffff
Reserved 7[4]: ffffffff
Reserved 8[4]: ffffffff
Reserved 9[4]: ffffffff
Click to expand...
Click to collapse
@TristanLeBoss
What else do you know about this programmer or others you may be able to analyze, was it supplied through the OEM to use with their tool? Can it be used on other ARM QC 8974 chip phones? Maybe it can be used on another phone with same partition layout/size? If not I am curious if there is a way to extract or build the mbn/programmer files needed from another phone via jtag setup or something.
I ask this since the OnePlus 2 (A2001 Chinese model) there are mbn/flash partitions/programmer files available for unbricking. Maybe those would come in handy...
This sounds like your theory would also work with an OTG cable and a thumb drive. But what do you mean get a uefi image file to pack in the boot image though. This would be a signed file?
feherneoh said:
If you tell me the exact device you are using (and optionally give me a boot.img for it) I can try to build one image for you (first LK, to make sure drivers are okay, if they work, then EFIDroid)
Click to expand...
Click to collapse
Only for same specs device's for now or for all android devices?
feherneoh said:
I should be able to build UEFI for almost any SnapDragon device, but in some cases LCD does not work with it
And you still have to mess around with W10M to make it work
Click to expand...
Click to collapse
Your method uses an SD card to build/boot the separate OS correct? Can this be done with a OTG connection as well? Would this work for the OnePlus3? I currently own one. If not I would be willing to purchase a cheap used OnePlus 2 device seeing how folks are trying to get rid of them now, but not sure how easily available that boot.img is.....
Actually it seems a OP2 device has no SD card slot either, if I am able to get a cheap used test device that will work then seems OnePlus X does have a slot. Have you successfully accomplished a boot of W10M off an SD card from an Android phone? What's your test device, and do you have separate thread on this as some this is off topic from the thread Subj... @TristanLeBoss apologies.
feherneoh said:
BTW, I know people who started porting it, but it is extremely hard
Click to expand...
Click to collapse
Yes from my small experience digging into it, it is not easy to get all things to line up the way they are needed.
Related
Hi All,
For the curious here's a diffstat between the EG30 and EK02 kernels. From my first look the changes to dpram (recovery functions) and the wimax drivers are the most interesting. I've pastebin'd the driver files diff at pastebin dot com slash 3eskK04d (I'm a new user so I can't post links yet sorry!)
My first post, I hope it's useful!
Code:
arch/arm/Kconfig | 15
arch/arm/configs/c1_fips_rev02_defconfig | 1
arch/arm/configs/c1_rev00_defconfig | 1
arch/arm/configs/c1_rev00_na_spr_epic2_defconfig | 1
arch/arm/configs/c1_rev00_q1_defconfig | 1
arch/arm/configs/c1_rev01_defconfig | 1
arch/arm/configs/c1_rev01_jpn_ntt_defconfig | 1
arch/arm/configs/c1_rev01_kor_skt_defconfig | 1
arch/arm/configs/c1_rev02_c1q1_defconfig | 1
arch/arm/configs/c1_rev02_chn_defconfig | 1
arch/arm/configs/c1_rev02_defconfig | 1
arch/arm/configs/c1_rev02_jpn_ntt_defconfig | 1
arch/arm/configs/c1_rev02_kor_skt_defconfig | 1
arch/arm/configs/c1_rev02_na_spr_defconfig | 6
arch/arm/configs/c1_rev02_q1_defconfig | 1
arch/arm/configs/c1_rev02_talbot_defconfig | 1
arch/arm/configs/c1_rev02_usa_att_defconfig | 1
arch/arm/configs/c1_rev05_na_spr_defconfig | 11
arch/arm/include/asm/cacheflush.h | 9
arch/arm/include/asm/hardware/cache-l2x0.h | 1
arch/arm/include/asm/pgtable.h | 26
arch/arm/include/asm/smp_plat.h | 4
arch/arm/include/asm/tlbflush.h | 12
arch/arm/mach-s5pv310/c1-wimax.c | 11
arch/arm/mach-s5pv310/mach-c1.c | 31
arch/arm/mach-s5pv310/tmu.c | 316
arch/arm/mm/cache-l2x0.c | 6
arch/arm/mm/copypage-v4mc.c | 2
arch/arm/mm/copypage-v6.c | 2
arch/arm/mm/copypage-xscale.c | 2
arch/arm/mm/dma-mapping.c | 6
arch/arm/mm/fault-armv.c | 8
arch/arm/mm/flush.c | 46
drivers/bluetooth/bthid/bthid.c | 10
drivers/dpram/raffaello/dpram.c | 124
drivers/dpram/raffaello/dpram_recovery.c | 381
drivers/dpram/raffaello/dpram_recovery.h | 12
drivers/input/misc/cm3663.c | 9
drivers/input/touchscreen/mxt224_u1.c | 265
drivers/misc/sec_jack_spr.c | 2
drivers/mmc/card/block.c | 132
drivers/mmc/core/sdio.c | 83
drivers/mmc/core/sdio_ops.c | 34
drivers/mmc/core/sdio_ops.h | 3
drivers/net/wimax_cmc/hardware.c | 66
drivers/net/wimax_cmc/receive.c | 1
drivers/net/wimax_cmc/wimax_i2c.c | 1539
drivers/net/wimax_cmc/wimax_i2c.h | 88
drivers/net/wimax_cmc/wimax_sdio.c | 104
drivers/net/wireless/bcm4330/src/wl/sys/wl_iw.c | 1
drivers/serial/samsung.c | 2
drivers/staging/westbridge/astoria/api/src/cyaslowlevel.c | 7
drivers/staging/westbridge/astoria/device/cyasdevice.c | 20
drivers/staging/westbridge/astoria/device/cyasdiagnostics.h | 1
drivers/staging/westbridge/astoria/include/linux/westbridge/cyanch9.h | 8
drivers/staging/westbridge/astoria/include/linux/westbridge/cyasch9.h | 5
include/config/auto.conf | 893
include/config/auto.conf.cmd | 640
include/config/kernel.release | 1
include/config/tristate.conf | 310
include/generated/autoconf.h | 894
include/generated/mach-types.h |38179 ----------
include/generated/utsrelease.h | 1
include/linux/i2c/mxt224_u1.h | 21
include/linux/version.h | 2
include/linux/wimax/samsung/wimax732.h | 4
scripts/basic/docproc | 44
scripts/basic/fixdep | 41
scripts/basic/hash | 12
scripts/conmakehash | 39
scripts/genksyms/genksyms | 135
scripts/genksyms/keywords.c | 220
scripts/genksyms/lex.c | 2709
scripts/genksyms/parse.c | 2353
scripts/genksyms/parse.h | 139
scripts/kallsyms | 65
scripts/kconfig/conf | 298
scripts/kconfig/lex.zconf.c | 2429
scripts/kconfig/zconf.hash.c | 239
scripts/kconfig/zconf.tab.c | 2468
scripts/mod/elfconfig.h | 4
scripts/mod/mk_elfconfig | 28
scripts/mod/modpost | 165
This is what I have been asking about and I can't understand it..lol. I have never seen such a performance boost between stock kernels. Hopefully someone will explain what exactly has changed in simpler terms but thank you nonetheless.
Sent from my SPH-D710 using xda premium
so does this update us to 2.3.6?
delfin12 said:
so does this update us to 2.3.6?
Click to expand...
Click to collapse
This is just the kernel source diff. The full EK02 update includes an update to Android 2.3.6
I would guess a performance increase is related to the CPU cache fixes.
As in the workaround for erratum 753970 PL310 (r3p0) config ARM_ERRATA_753970
Under some condition the effect of cache sync operation on
the store buffer still remains when the operation completes.
This means that the store buffer is always asked to drain and
this prevents it from merging any further writes. The workaround
is to replace the normal offset of cache sync operation (0x730)
by another offset targeting an unmapped PL310 register 0x740.
This has the same effect as the cache sync operation: store buffer
drain and waiting for all buffers empty.
Click to expand...
Click to collapse
This woudl probably get more attention in the dev section I think it would be fitting for that area... correct me if I'm wrong.
mauricehall said:
This woudl probably get more attention in the dev section I think it would be fitting for that area... correct me if I'm wrong.
Click to expand...
Click to collapse
yeah, but i can't post there yet as a n00b.
JohnCorleone said:
This is what I have been asking about and I can't understand it..lol. I have never seen such a performance boost between stock kernels. Hopefully someone will explain what exactly has changed in simpler terms but thank you nonetheless.
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
So if I flash the EK02 rom/kernel and I'm on EG31 radio, would I still see the speed benefits?
mauricehall said:
This woudl probably get more attention in the dev section I think it would be fitting for that area... correct me if I'm wrong.
Click to expand...
Click to collapse
Chris already posted the diff in the Dev forum.
My primary goal is to get to the point where we can unbrick a Glide using download mode and heimdall, no matter what the rest of the MMC looks like. A secondary goal is to learn enough about the boot process and bootloader to be able to arbitrarily change the partition table without bricking the phone.
So, this is currently our best guess as to the stock partition layout on the Glide:
Code:
DM ID | offset | DM Name | DM filename | Device file | filesystem
======|=============|=========|=================|==============|===========
2 | Special | BCT | bct.bin | |
3 | 0x200000 | PT | | |
4 | 0x280000 | EBT | bootloader.bin | |
5 | 0x480000 | EB2 | | |
6 | 0x680000 | GP1 | fusetrigger.bin | |
7 | 0xa80000 | EFS | efs.img | mmcblk0p1 | ext4
8 | 0x1680000 | APP | factoryfs.img | mmcblk0p2 | ext4
9 | 0x26e80000 | CAC | cache.img | mmcblk0p3 | ext4
10 | 0x3a680000 | IMS | | mmcblk0p4 | FAT32
11 | 0x12a700000 | MSC | | mmcblk0p5 |
12 | 0x12a900000 | UDA | data.img | mmcblk0p6 | ext4
13 | 0x1aa900000 | MDM | modem.bin | mmcblk0p7 |
14 | 0x1ab900000 | SOS | recovery.img | mmcblk0p8 |
15 | 0x1abe00000 | LNX | boot.img | mmcblk0p9 |
16 | 0x1ac600000 | OTA | | mmcblk0p10 |
17 | 0x1ace00000 | HID | hidden.img | mmcblk0p11 | ext4
18 | 0x1cce00000 | GPT | | |
I do not presently know how mmcblk0boot0 and mmcblk0boot1 factor into things. I DO know that whatever mmcblk0boot0 is, it's not accessible through mmcblk0, meaning there's something a bit weird going on in the kernel MMC driver... see the hypotheses below. The contents of mmcblk0boot1 occur THIRTEEN times in the beginning of mmcblk0, including right at 0x0. boot1 could point to any one of those, or, again, a different location entirely that's obscured by the kernel driver.
A PIT is NOT a partition table. It's a descriptor of expected partitions and their sizes. There's no offsets or anything that could describe partition locations. So when you feed Odin or Heimdall a PIT, either Odin/Heimdall or the phone itself is making up a partition table on the fly to fit the PIT. Needless to say, flashing a PIT without a bootloader and recovery is risky, even if you're flashing the same PIT twice! it appears the partition table is created in a predictable way; that's how we got the new offsets. But, I'm still way too paranoid to flash a PIT without reflashing BCT, bootloader, and either recovery or download mode in the same go.
Download mode is DEFINITELY in the MMC. Check out the strings around 0x572400. So much for the "separate ROM" theory. There's strings from the bootloader nearby as well (note to self: HOW nearby? That could be crucial...).
BCT is a special something used only by Tegra SoCs: http://http.download.nvidia.com/tegra-public-appnotes/bct-overview.html It's a safe bet there's a BCT somewhere in MMC. The BCT should, in theory, give us the precise location of the bootloader, and then some proper disassembly can happen. Assuming our offsets are correct, we now theoretically know the location of everything. Let the dumping begin! Still, picking apart a BCT sounds absolutely smashing so I'll probably do it at some point anyway.
Hypotheses that need testing:
boot0 and boot1 contain BCTs, not bootloaders. (That would explain their size.)
mmcblk0 actually begins exactly 1MB into the MMC. boot0 and boot1 are two halves of that first 1MB.
Alternately, boot0 points to the copy of the BCT that is in RAM; a leftover of the boot process. boot1 is the actual BCT from the MMC.
There are 13 (or 15) copies of the BCT at the beginning of MMC. (In the BCT partition, of course!) Is this necessary? Probably not, but I'm not gonna possibly brick a phone to gain a few KB.
Download mode is built into the bootloader, not a separate binary. Both live in EBT. The newly found offsets put the Odin strings in EB2, so BUSTED.
EBT is the bootloader and EB2 is the Odin code.
In my opinion this topic can and should stay in the development section.
However there are no downloadable file as a result of the development, the topic holds information valuable mostly for developers, debuggers or power users, and average end users obviously has no or minimal idea what to do with the information provided here.
By the way, shall i ask a request? I'd like to see the default mounting points of those partitions witch has any. For the everyday Glide users it may be obvious, but quite often i fix broken partition tables of different phones for example, where such information can be valuable for people with no device specific routine.
Necc86 said:
By the way, shall i ask a request? I'd like to see the default mounting points of those partitions witch has any. For the everyday Glide users it may be obvious, but quite often i fix broken partition tables of different phones for example, where such information can be valuable for people with no device specific routine.
Click to expand...
Click to collapse
It's kinda beyond the scope of this project; you can get this from the volds.fstab of any ROM. Frankly, though, it should be somewhat obvious from the Odin filenames.
Bump because update.
Can anyone help me figure out how to get this to work? Im very new at porting, Please as soon as possible get back to me! Thanks in advaned!
-- Install /sdcard/AAA/touchwizzport.zip ...
Finding update package...
I:Update location: /sdcard/AAA/touchwizzport.zip
Opening update package...
Installing update...
line 2 col 43: syntax error, unexpected STRING, expecting ',' or ')'
line 279 col 40: syntax error, unexpected STRING, expecting ',' or ')'
line 306 col 1: syntax error, unexpected $end, expecting ',' or ')'
3 parse errors
E:Error in /sdcard/AAA/touchwizzport.zip
(Status 6)
* Verifying filesystems...
I:=> Let's update filesystem types via verifyFst aka blkid.
* Verifying partition sizes...
+----------+-----------------------------+--------+----------+----------+---+---+
| Mount | Block Device | fst | Size(KB) | Used(KB) | M | B |
+----------+-----------------------------+--------+----------+----------+---+---+
| | | | 0 | 0 | 0 | u |
| system | /dev/block/mmcblk0p25 | ext4 | 817151 | 17192 | 1 | f |
| data | /dev/block/mmcblk0p26 | ext4 | 999423 | 17608 | 1 | f |
| boot | /dev/block/mmcblk0p22 | emmc | 4096 | 4096 | 0 | i |
| recovery | /dev/block/mmcblk0p21 | emmc | 8701 | 8701 | 0 | i |
| cache | /dev/block/mmcblk0p28 | ext4 | 178175 | 16488 | 1 | f |
| sdcard | /dev/block/mmcblk1p1 | vfat | 7757824 | 4163200 | 1 | n |
| | | | 0 | 0 | 0 | n |
| andsec | /sdcard | vfat | 32 | 32 | 0 | f |
| sd-ext | /dev/block/mmcblk1p2 | vfat | 7761920 | 0 | 1 | f |
| | | | 0 | 0 | 0 | n |
| | | | 0 | 0 | 0 | n |
| | | | 0 | 0 | 0 | n |
+----------+-----------------------------+--------+----------+----------+---+---+
Error flashing zip '/sdcard/AAA/touchwizzport.zip'
I:Set page: 'flash_done'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Set page: 'advanced'
I:Set page: 'confirm_action'
I:Set page: 'action_page'
Click to expand...
Click to collapse
EpicLordPhone said:
Can anyone help me figure out how to get this to work? Im very new at porting, Please as soon as possible get back to me! Thanks in advaned!
Click to expand...
Click to collapse
what phone are you porting from? Send me the zip I can look at it.
MameTozhio said:
what phone are you porting from? Send me the zip I can look at it.
Click to expand...
Click to collapse
Im porting from the mytouch 4g. I know that its GSM and has a FFC but I still want to try to get it to work! Im uploading the rom to google drive so ill give you the link in afew
MameTozhio said:
what phone are you porting from? Send me the zip I can look at it.
Click to expand...
Click to collapse
Heres the link! HERE
EpicLordPhone said:
Heres the link! HERE
Click to expand...
Click to collapse
are you using CM9 as a base? also be sure to get permission to actually post it as a ROM.
MameTozhio said:
are you using CM9 as a base? also be sure to get permission to actually post it as a ROM.
Click to expand...
Click to collapse
Yes its CM9 and I know this is just a test that wont even boot and after i can get it to boot i will get permission. this is the cm9 base
And this is what i would like to port
Any luck with finding out the problem?
Sent from my HTC One V using xda app-developers app
Hi,
I've tried to search galaxy y bml map on google but all efforts led to nothing,
so i worked on myself .
If we take a look at the totoro.pit file, if the above blocks are in right order
then we can base on to map all other blocks.
bcm_boot
loke
loke_bk
systemdata -> 4
modem -> 5
param_lfs -> 6
boot -> 7
boot_backup
system -> 9
cache -> 10
userdata -> 11
efs
sysparam_dep
umts_cal_file
cal -> 15
Then finally we have all the blocks :
bml1 | bcm_boot | BcmBoot.img
bml2 | loke | sbl.bin
bml3 | loke_bk | bl.bin
bml4 | systemdata | totoro.pit
bml5 | modem | BcmCP.img
bml6 | param_lfs | param.lfs
bml7 | boot | boot.img
bml8 | boot_backup | <empty>
bml9 | system | system.img
bml10 | cache | csc.rfs
bml11 | userdata | userdata.img
bml12 | efs | <empty>
bml13 | sysparam_dep | sysparam_dep.img
bml14 | umts_cal_file | HEDGE_NVRAM8_RF_LE.bin
bml15 | cal | <empty>
So we can make a full backup of the galaxy young :good:
first and thanks.
Hello,
I need help with a quit old device:
device: Lenovo IdeaTab A2109A ("cl2n") (actually "medion Lifetab 59714" but seems to be compatible)
recovery: cwm 6.0.5.1
rom: unlegacy-android (Android 7.1.2 )
issue: I'm not able to list the partition table.
I tried to install open_gapps-arm-7.1-pico-20210502.zip, but it fails due to lack of system storage:
Code:
# Begin Open GApps Install Log
------------------------------------------------------------------
ROM Android version | 7.1.2
ROM Build ID | ua_a2109-userdebug 7.1.2 N2G48H 3026 test-keys
ROM Version increment | 3026
ROM SDK version | 25
ROM/Recovery modversion | 11-20160217-UNOFFICIAL-kai
Device Recovery | CWM-based Recovery 6.0.5.1
Device Name | a2109
Device Model | A2109A
Device Type | tablet
Device CPU | armeabi-v7a,armeabi
Device A/B-partitions | false
Installer Platform | arm
ROM Platform | arm
Display Density Used | 160
Install Type | Dirty[Data NOT Wiped]
Google Camera already installed | false
VRMode Compatible | false
Google Camera Compatible | true
New Camera API Compatible | false
Google Pixel Features | false
Current GApps Version | No GApps Installed
Google Camera version | Legacy
Installing GApps Zipfile | /data/media/open_gapps-arm-7.1-pico-20210502.zip
Installing GApps Version | 20210502
Installing GApps Type | pico
Config Type |
Using gapps-config | Not Used
Remove Stock/AOSP Browser | false[NO_Chrome]
Remove Stock/AOSP Camera | false[NO_CameraGoogle]
Remove Stock/AOSP Dialer | false[NO_DialerGoogle]
Remove Stock/AOSP Email | false[NO_Gmail]
Remove Stock/AOSP Gallery | false[NO_Photos]
Remove Stock/AOSP Launcher | false[NO_GoogleNow/PixelLauncher]
Remove Stock/AOSP MMS App | false[NO_Messenger]
Remove Stock/AOSP Pico TTS | false[default]
Ignore Google Contacts | false
Ignore Google Dialer | true[NoRemove]
Ignore Google Keyboard | false
Ignore Google Package Installer | false
Ignore Google NFC Tag | true[NoRemove]
Ignore Google WebView | false
Total System Size (KB) | 645056
Used System Space (KB) | 460820
Current Free Space (KB) | 184236
Additional Space Required (KB) | 80600 << See Calculations Below
------------------------------------------------------------------
# End Open GApps Install Log
INSTALLATION FAILURE: Your device does not have sufficient space available in
the system partition to install this GApps package as currently configured.
You will need to switch to a smaller GApps package or use gapps-config to
reduce the installed size.
NOTE: The Stock/AOSP NFC Tag is not available on your
ROM (anymore), the Google equivalent will not be removed.
NOTE: The Stock/AOSP Dialer is not available on your
ROM (anymore), the Google equivalent will not be removed.
# Begin GApps Size Calculations
------------------------------------------------------------------
TYPE | DESCRIPTION | SIZE | TOTAL
| Current Free Space | 184236 | 184236
Remove | Existing GApps | + 0 | 184236
Remove | Obsolete Files | + 0 | 184236
Remove | extservicesstock | + 16 | 184252
Remove | extsharedstock | + 12 | 184264
Remove | provision | + 12 | 184276
Install | Core | - 221656 | -37380
Install | calsync | - 2548 | -39928
Install | googletts | - 31456 | -71384
| Buffer Space | - 9216 | -80600
------------------------------------------------------------------
Additional Space Required | 80600
------------------------------------------------------------------
Now I want to repartition /system , but I don't know how the partition table need to look like and I'm not able to list it:
Code:
~$ adb shell
~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 495972 128 495844 0% /dev
tmpfs 495972 8 495964 0% /tmp
tmpfs 495972 736 495236 0% /storage
tmpfs 495972 0 495972 0% /mnt/secure
tmpfs 495972 0 495972 0% /mnt/fuse
/dev/block/platform/sdhci-tegra.3/by-name/CAC
806288 13904 792384 2% /cache
~ # cat /proc/partitions
major minor #blocks name
179 0 30539776 mmcblk0
179 1 8192 mmcblk0p1
179 2 8192 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 921600 mmcblk0p4
179 5 819200 mmcblk0p5
179 6 2048 mmcblk0p6
179 7 32768 mmcblk0p7
179 8 28731392 mmcblk0p8
179 32 2048 mmcblk0boot1
179 16 2048 mmcblk0boot0
~ # blkid
/dev/block/mmcblk0p8: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p5: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p4: LABEL="system" UUID="da594c53-9beb-f85c-85c5-cedf76546f7a" TYPE="ext4"
~ # ./parted /dev/block/mmcblk0
GNU Parted 3.3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: /dev/block/mmcblk0: unrecognised disk label
Model: MMC HBG4e (sd/mmc)
Disk /dev/block/mmcblk0: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
(parted) q
I also tried
Code:
~ # /partprobe -s
/dev/block/mmcblk0: msdos partitions
/dev/block/mmcblk0boot1: msdos partitions
/dev/block/mmcblk0boot0: msdos partitions
and
Code:
~ # /partprobe -s /dev/block/mmcblk0
Error: Partition(s) 5 on /dev/block/mmcblk0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.
As a result, the old partition(s) will remain in use. You should reboot now before making further changes.
..but I always get the same error when I try to list the partition table with parted:
Error: /dev/block/mmcblk0: unrecognised disk label
I also tried fdisk:
Code:
~ # fdisk /dev/block/mmcblk0
Device contains neither a valid DOS partition table, nor Sun, SGI, OSF or GPT disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that the previous content
won't be recoverable.
The number of cylinders for this disk is set to 954368.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): help
h: unknown command
Command Action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
Command (m for help): v
61079551 unallocated sectors
What can I do?
I could just repartion it If I knew how it needs to look like. But I'm not an expert and don't know exactly if the partition table is rom and/or device related? I'm pretty sure it is and I can't just do a kind of "standard" partitioning - right?
Thank you!
P.S. Lenovo provides a "Open Source Code - IdeaTab A2109A Tablet" - does this contain the partition table??