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.
I flashed the Note 8.0 by PA 5.1. Next I flashed Open-Gapps (nano/micro) and there are errors.
Begin Open GApps Install Log
-----------------------------------------------------------------------------
ROM Android Version | 5.1.1
ROM ID | LVY48C test-keys
ROM Version | 5.1-20150822
Device Recovery |
Using Bundled XZdec | true
Device Name | konawifi
Device Model | GT-N5110
Device Type | tablet
Device CPU | armeabi-v7a,armeabi
getprop Density | 213
default.prop Density | 213
build.prop Density | 213
Display Density Used | 213dpi
Install Type | Dirty[Data NOT Wiped]
Google Camera Installed¹ | false
FaceUnlock Compatible | true
Google Camera Compatible | true
Current GApps Version | No GApps Installed
Installing GApps Version | 20160109
Installing GApps Type | pico
Config Type | exclude
Using gapps-config | Not Used
Remove Stock/AOSP Browser | false[NO_Chrome]
Remove Stock/AOSP Calculator |
Remove Stock/AOSP Clock | false[default]
Remove Stock/AOSP Contacts |
Remove Stock/AOSP Email | false[NO_Gmail]
Remove Stock/AOSP Gallery | false[NO_Photos]
Remove Stock/AOSP Launcher | false[NO_GoogleNow]
Remove Stock/AOSP MMS App | false[NO_Hangouts]
Remove Stock/AOSP Pico TTS | false[NO_GoogleTTS]
Remove Stock/AOSP NFC Tag | false[default]
Remove Stock/AOSP WebView | false[default]
Ignore Google Contacts | false
Ignore Google Keyboard | false
Ignore Google Package Installer | false
Ignore Google NFC Tag | true[NoRemove]
Ignore Google WebView | false
Total System Size (KB) | 1548144
Used System Space (KB) | 338148
Current Free Space (KB) | 1209996
Post Install Free Space (KB) | 1120292 << See Calculations Below
-----------------------------------------------------------------------------
¹ Previously installed with Open GApps
# End Open GApps Install Log
!!! WARNING !!! - Duplicate files were found between your ROM and this GApps
package. This is likely due to your ROM's dev including Google proprietary
files in the ROM. The duplicate files are shown in the log portion below.
# Begin GApps <> ROM Duplicate File List
/system/lib/libjni_latinimegoogle.so
# End GApps <> ROM Duplicate File List
# Begin GApps Size Calculations
-----------------------------------------------------------------------------
TYPE | DESCRIPTION | SIZE | TOTAL
| Current Free Space | 1209996 | 1209996
Remove | Existing GApps | + 664 | 1210660
Remove | Obsolete Files | + 696 | 1211356
Install | Core² | - 80604 | 1130752
Install | calsync³ | - 1244 | 1129508
| Buffer Space² | - 9216 | 1120292
-----------------------------------------------------------------------------
Post Install Free Space | 1120292
-----------------------------------------------------------------------------
² Required (ALWAYS Installed)
³ Optional (may be removed)
# End GApps Size Calculations
# Begin User's gapps-config
# End User's gapps-config
I do not know what I must do.
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.