Develop Bugs

[REF] Investigation Into PIT Files

There is very little technical information on PIT files , so this thread is an attempt to find out some real details about PIT files, and perhaps eventually be able to create our own PIT files (by modifying Samsung ones, probably).
First, what we think we know PIT files do:
- PIT files only affect the 'STL' devices. That is, it affects the OneNAND and not the MoviNAND.
- PIT files appear to control the sizing (and maybe number) of STL devices that appear in Linux.
- PIT files appear to be used by Odin to map filenames inside .tar archives to STL partitions.
STL files are quite small, at under 2KB in size. Most of the file is made up of 0s. I have tried to compare the differences between the 512 513 and 803 PIT files we have available.
All the PIT files start with 76 98 34 12 0D - probably a signature to show it is a PIT file.
[Unimportant]
The 803 PIT file then has 00s all the way to the next common point. The 512 and 513 both have common data till the next common point - but this can't be too important as the 803 just has 00s.
The next common bit seems to read the following:
"oft IBL+PBL Server\90\To boot.bin inn; C:\Program Files\ESTsof
This probably indicates something to Odin. Strange that it has C:\Program Files\ - build path for the PIT file?
Next we have some 0s with common 1s inside them, followed by the word PIT, then more 0s, and then ries.pit. All common from here on with the words 'EFS' and 'efs.rfs'. Probably telling odin to map the efs.rfs file to the 'EFS' token. Tokens probably defined either in the kernel, or in the closed source STL library. More of the same of this, with 'SBL' 'sbl.bin', 'SBL2' 'sbl.bin' -- Both SBL and SBL2 map to the same sbl.bin file?
'PARAM' to 'param.lfs'
'KERNEL' to 'zImage'
'RECOVERY' to 'zImage' (this one is interesting - could we have seperate zImage and recovery? Could save some RAM here!)
[/Unimportant]
And now we'r onto the actual changes between the PIT files. 'FACTORYFS' maps to 'factoryfs.rfs'. However, before the FACTORYFS token, there are some bytes that likely control the partition sizes.
FACTORYFS
803 : A2 04 : 41476
512 : 7A 04 : 31236
513 : CA 04 : 51716
DBDATA
803 : F0 01 : 61441
512 : 18 02 : 6146
513 : C8 01 : 51201
CACHE
803 : 8C
512 : 8C
513 : 8C
MODEM
803 : 32
512 : 32
513 : 32
So there we have it. The only real changes between the PIT files are some seemingly garbage header information in 512/513 that is missing from 803, and FACTORYFS and DBDATA have different numbers -- probably sizes.
So assuming FACTORYFS maps onto /system, we can see that the only differences in the PIT files is moving space back and forwards between /dbdata and /system. The numbers themselves don't mean anything to me - can anybody work it out?

The numbers are little-endian, so you need to read them backwards per bytes. So instead of A12 it's actually 120A, etc. If you do so, you can see that the difference between 803 and 512 are actually minor, 40 "units" are shifted between probably DBDATA and SYSTEM.
Btw: doesn't the heimdal project klnow something about the pit files?

Nice, that gives us
FACTORYFS
803 : 04 A2 : 1186
512 : 04 7A : 1146
513 : 04 CA : 1226
DBDATA
803 : 01 F0 : 496
512 : 02 18 : 536
513 : 01 C8 : 456
1186+496=1682
1146+536=1682
1226+456=1682
So we have a match.
Now to work out why the fat.format can work with 536, but not with 496
EDIT: Also, need to determine why some roms require certain PIT files. Only possibility I can see is that junk in the header - could be some type of allow list for firmwares. The 803 PIT should therefore work on all firmwares, since it just has 00s. Maybe.

In 803.pit (compared to the .512 one) the system partition size has been increased by 10MB, while DBDATA partition size has been decreased the same amount (10MB).
PS: Dump the BML2 partition. The dump contains current partition mapping.
Hope this helps

RyanZA said:
Nice, that gives us
FACTORYFS
803 : 04 A2 : 1186
512 : 04 7A : 1146
513 : 04 CA : 1226
DBDATA
803 : 01 F0 : 496
512 : 02 18 : 536
513 : 01 C8 : 456
1186+496=1682
1146+536=1682
1226+456=1682
So we have a match.
Now to work out why the fat.format can work with 536, but not with 496
EDIT: Also, need to determine why some roms require certain PIT files. Only possibility I can see is that junk in the header - could be some type of allow list for firmwares. The 803 PIT should therefore work on all firmwares, since it just has 00s. Maybe.
Click to expand...
Click to collapse
I think the main cause is that some firmwares simply don't fit in the space reserved for them. Some of the m have larger system, some of them have larger dbdata partitions. Only a guess though, I think I start flashing pit files just for fun...

RazvanG said:
In 803.pit (compared to the .512 one) the system partition size has been increased by 10MB, while DBDATA partition size has been decreased the same amount (10MB).
Hope this helps
Click to expand...
Click to collapse
10MB = 40 units... That would give us 1 unit = 256kbyte. Nice.

So this means:
BOOT (bml01) = 01 = 1 = 0.25 MB (bootloader)
PIT (bml02) = 01 = 1 = 0,25 MB (the partition table)
EFS (bml03) = 28 = 40 = 10 MB (imei data and such)
SBL (bml04) = 05 = 5 = 1,25 MB (secondary bootloader)
SBL2 (bml05) = 05 = 5 = 1,25 MB (secondary bootloader backup)
PARAM (bml06) = 14 = 20 = 5 MB (the images shown when something is wrong)
KERNEL (bml07) = 1E = 30 = 7,5 MB (kernel image)
RECOVERY (bml08) = 1E = 30 = 7,5 MB (kernel image backup)
FACTORYFS (bml09) = 47A = 1146 = 286,5 MB (/system)
DBDATA (bml10) = 218 = 536 = 134 MB (/dbdata)
CACHE (bml11) = 8C = 140 = 35 MB (/cache)
MODEM (bml12) = 32 = 50 = 12,5 MB (software for wireless)
total: 501 MB

sztupy said:
I think the main cause is that some firmwares simply don't fit in the space reserved for them. Some of the m have larger system, some of them have larger dbdata partitions. Only a guess though, I think I start flashing pit files just for fun...
Click to expand...
Click to collapse
Not sure how true this can be -- Take 512 vs 513 for example. Newer Eclair roms stopped working on 513, and required 512. However, 513 has a smaller dbdata and larger system than 512. Since we know that a clean rom when flashed has a /dbdata of around 2mb, or 1% or so of available space, it can't be space related.
Must be more to than simple space allocations.
EDIT: And 501MB means we have space left over. Where is it hiding?

RyanZA said:
Not sure how true this can be -- Take 512 vs 513 for example. Newer Eclair roms stopped working on 513, and required 512. However, 513 has a smaller dbdata and larger system than 512. Since we know that a clean rom when flashed has a /dbdata of around 2mb, or 1% or so of available space, it can't be space related.
Must be more to than simple space allocations.
EDIT: And 501MB means we have space left over. Where is it hiding?
Click to expand...
Click to collapse
Yes, but the flashed dbdata.rfs was probably actually a large partition, that didn't fit into the allocated space.
Yes, the missing 11MB is strange, unless there is a 1MB "safety" gap between two partition (12 partitions = 11 gaps), or some other data.
EDIT: No, dumped BML0, it's only 501MB in length. The missing part might still be some space needed for the BML and STL to work.

Hi. I'm sorry for hijacking this thread but I need professional help from some geniuses (genii) and apparently you guys are firmware gurus.
Once you guys figure out how PIT files work, can you please help me figure out how to force flash Korean firmware onto an international phone without bricking it? The reason why I would like to do this, is because the Korean version has some really nice features for example native call recording (3rd party call recorders have bad quality). I made a thread for it here
Thanks a lot, köszönöm szépen!

Galaxy S I9000 PIT structure:
512.pit
PBL: 256KB (Primitive Bootloader)
PIT: 256KB
EFS: 10240KB (Non Volatile Memory)
SBL(1): 1280KB (Primary)
SBL(2): 1280KB (Backup)
PARAM: 5120KB
KERNEL(1): 7680KB (Primary)
KERNEL(2): 7680KB (Backup)
FACTORYFS: 293376KB
DBDATAFS: 137216KB
CACHE: 35840KB
MODEM: 12800KB
Total: 513024KB
513.pit
PBL: 256KB
PIT: 256KB
EFS: 10240KB
SBL(1): 1280KB
SBL(2): 1280KB
PARAM: 5120KB
KERNEL(1): 7680KB
KERNEL(2): 7680KB
FACTORYFS: 313856KB
DBDATAFS: 116736KB
CACHE: 35840KB
MODEM: 12800KB
Total: 513024KB
803.pit
PBL: 256KB
PIT: 256KB
EFS: 10240KB
SBL(1): 1280KB
SBL(2): 1280KB
PARAM: 5120KB
KERNEL(1): 7680KB
KERNEL(2): 7680KB
FACTORYFS: 303616KB
DBDATAFS: 126976KB
CACHE: 35840KB
MODEM: 12800KB
Total: 513024KB
In case there is backup blocks (e.g SBL and Kernel, Odin flashes them both while executing the flashing process).

dillovic said:
Hi. I'm sorry for hijacking this thread but I need professional help from some geniuses (genii) and apparently you guys are firmware gurus.
Once you guys figure out how PIT files work, can you please help me figure out how to force flash Korean firmware onto an international phone without bricking it? The reason why I would like to do this, is because the Korean version has some really nice features for example native call recording (3rd party call recorders have bad quality). I made a thread for it here
Thanks a lot, köszönöm szépen!
Click to expand...
Click to collapse
Galaxy S M110S is completely different hardware.
All other I9000 variants use Infineon X-Gold 616 baseband (Modem), while M110S uses Qualcomm baseband chip.

Made a try modifying the PIT file, to add more space to /dbdata and take away space from /system. I added around 25MB extra space to /dbdata.
Wasn't that hard actually, and I didn't encounter many problems (except the fact that the values are for the bare bml device, from which the stl has an extra 4-10% overhead so instead of the originally planed 35MB I could only spare 25).
If anyone's interested I can upload the modified pit and rom files.
Some remarks / questions:
- If we use the bare BML device instead of the STL I know we lose wear leveling (at least according to the rfs docs from samsung), but can't we use yaffs or similar on those devices? Or what if we (can we?) use cramfs for the /system on the BML, to gain even more space we could use for the /dbdata partition?
- The overhead the STL has seems a bit random to me. /system and /dbdata has a 4% overhead, while /cache a 10% one.

I'd be careful about resizing the partitions manually. Samsung should have aligned the partitions for best performance.
I'm not sure if its a placebo, but PIT 512 seems faster to me than PIT 803.

hardcore said:
I'd be careful about resizing the partitions manually. Samsung should have aligned the partitions for best performance.
I'm not sure if its a placebo, but PIT 512 seems faster to me than PIT 803.
Click to expand...
Click to collapse
Aligning should not be terribly hard -- we already specify using 256kb pieces instead of raw bytes. The alignment therefore is somewhere between 256kb and 4mb. If we align for 4mb, we align for everything smaller too. So as long as the numbers used are cleanly divisible by 4*4=16, it will be correctly aligned.
Flashing a PIT file with repartition checked seems to (according to docs) reset the wear leveling (the current record of what was written where, I guess), so you should not tick repartition if you are flashing many times in a row. (Many times is probably some very big number.)
I can't see why we couldn't use YAFFS or similar filesystem. Might work really well. I've got no experience setting up YAFFS though, and I don't believe it is trivial.

RyanZA said:
Aligning should not be terribly hard -- we already specify using 256kb pieces instead of raw bytes. The alignment therefore is somewhere between 256kb and 4mb. If we align for 4mb, we align for everything smaller too. So as long as the numbers used are cleanly divisible by 4*4=16, it will be correctly aligned.
Flashing a PIT file with repartition checked seems to (according to docs) reset the wear leveling (the current record of what was written where, I guess), so you should not tick repartition if you are flashing many times in a row. (Many times is probably some very big number.)
I can't see why we couldn't use YAFFS or similar filesystem. Might work really well. I've got no experience setting up YAFFS though, and I don't believe it is trivial.
Click to expand...
Click to collapse
I wonder if it is possible to make very small /system partition, and move it to mmcblk0 - since it is read only, performance will be ok. And make large dbdata partition, and keep /data/data there. That may be the ultimate lag fix
Sent from my GT-I9000 using XDA App

vitalij said:
I wonder if it is possible to make very small /system partition, and move it to mmcblk0 - since it is read only, performance will be ok. And make large dbdata partition, and keep /data/data there. That may be the ultimate lag fix
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
It is possible, but how would you flash a firmware then?
We are quickly approaching the 'throw it all away, and start from scratch with our own tools and bootloader.

RyanZA said:
It is possible, but how would you flash a firmware then?
We are quickly approaching the 'throw it all away, and start from scratch with our own tools and bootloader.
Click to expand...
Click to collapse
So are u guys planning to release the new galaxy s series phone??
You should rename it to galaxy-xda

So, from the info you have gathered, is there any point in using a PIT file when repartition is not checked?

huxflux2003 said:
So, from the info you have gathered, is there any point in using a PIT file when repartition is not checked?
Click to expand...
Click to collapse
I don't really see much point, but than again PIT file will tell odin (if your flashing pda) explicitly where the kernel should be flashed.
Also, I noticed that kernel partition is only 7.5-6 mb. Doest it mean that we cant use larger kernels (cos I think voodoo might me larger - hence the screen tear on boot).

[Tool] sin2raw v0.2 - new tool to extract sin files *updated*

As you know, we were unable to extract ext4 from Sony ICS firmwares. I took a look at the problem and found out that Sony changed the way sin are generated.
I wrote a quick and (very) dirty command line tool to extract sin properly, it's now possible to extract a working system.ext4.
Usage:
sin2raw <sin file> <output file> [size[K|M|G]]
Usage examples:
sin2raw system.sin system.ext4
sin2raw userdata.sin userdata.ext4
sin2raw kernel.sin kernel.elf
Note:
For linux, there are two versions, sin2raw for 64 bits and sin2raw32 for 32 bits. I strongly recommend using the 64 bits one, 2 gig+ ext4 files are safer with this one.
Release history:
v 0.2:
new: partition size is extracted to generate file, specifying file size is not needed anymore.
new: loader.sin is detected and handled properly.
fix: block header sizes are int, not short.
fix: win32 compatibility.
fix: various size fixes for 32 bits cpu.
code cleanup.
v 0.1 :
Initial release
FAQ
*obsolete* What is size param / 1G ?
When extracting ext4, you have to specify the original partition size on phone. For instance, on xperia S, system is exactly 1 gig, so you have to add 1G. Userdata partition is almost 2 gig, you have to add 2097120K instead of 1G
(Ugly) source code is there, pre-built binaries for windows and linux are attached to this post.
More details to come soon on sin format in second post.

Background:
So, here is the deal: basically, new ext4 sins are using something that was in sin format but that we didn't dig into.
Sin is like this:
Code:
-----------------------
| Sin Header (15 bytes) |
-----------------------
| Block descriptors |
-----------------------
| File Header |
-----------------------
| File Data |
-----------------------
Block descriptors are like this:
Code:
---------------
| target_offset |
---------------
| block_count |
---------------
| block_length |
---------------
| payload_size |
---------------
| payload |
---------------
I presume payload is block signature. A block descriptor is working like this: takes "block_length" bytes from sin "data" and put them at "target_offset" on target device/file.
Up to ics, all block target_offsets were contiguous and that's why sin2img was working. With ics, they are not, explaining why sin2img doesn't work anymore.
History:
2012/08/16 18:00: new analysis, used in 0.2
2012/08/16 11:00: pdfs with more detailed information

it works, thx.
but with only this option 1G added.
Code:
sin2raw system.sin system.ext4 1G

:good:Great job! Thank you very much, i just got extract problem on new *.sin files.
Let me test this tool,I will give some feedback soon.
---------- Post added at 01:50 PM ---------- Previous post was at 01:44 PM ----------
DearTanker said:
:good:Great job! Thank you very much, i just got extract problem on new *.sin files.
Let me test this tool,I will give some feedback soon.
Click to expand...
Click to collapse
It works now,:laugh:,but what is "1G" means?
It seems output file system.ext4 size is 1G?
sorry for my pool english.
---------- Post added at 02:00 PM ---------- Previous post was at 01:50 PM ----------
can extract userdata.sin too,but when extract userdata.sin it will run out space of disk..

Thanks for the info..I will try it.

1G is output file size, 1 gigabyte, you can also use 1024M.
When extracting ext4, you have to specify the phone system partition size if you want to be able to mount it. System partition is 1 gig on Xperia S, I don't know about the other xperias.
If you extract other files like kernel.sin, you don't need to specify output file size.

can extract userdata.sin too,but when extract userdata.sin it will run out space of disk..
Click to expand...
Click to collapse
userdata.sin is almost 2GB, use this:
sin2raw userdata.sin userdata.ext4 2097120K
it will mount properly.

letama said:
userdata.sin is almost 2GB, use this:
sin2raw userdata.sin userdata.ext4 2097120K
it will mount properly.
Click to expand...
Click to collapse
thx, it works on userdata now
but why 2G does not work?

matchung said:
thx, it works on userdata now
but why 2G does not work?
Click to expand...
Click to collapse
Because partition is not exactly 2gig, more 1.999

Why is the system folder not available after converting sin to ext4?

Sharaz22, what do you mean by not available after converting ? This tool extracts a .ext4 image file, you have to mount it to see files. For instance:
mkdir system
sudo mount -o loop -t ext4 system.ext4 system
On windows, I don't know, I know there are some options but never looked at them.

I have mounted the system.ext4 image but there is no system folder in there all the other folder are available e.g. apps xbin etc.

Ah, got it. Well, system.ext4 is the system folder content. In android, system directory is coming from a partition that is mounted to an empty system directory. This is exactly this partition you have there.

Just want to confirm that this tool works fine. I can create pre-rooted image much easier. Don't need to create it from Nandroid anymore. Thanks
Sent from my LT26i using xda premium

Thanks for the feedback!
I'm working on a new release, 0.1 has issues with kernel extracts and hopefully I should be able to compute ext4 size automatically.
And a special thanks to Androxyde for his help!

Thanks,
It's work fine!

New version 0.2 is out, extract is much better now (previous one has few bugs) and size parameter is not needed anymore.
Check first post for details.

its working very fast and without bugs, thats nice, thanks!

I'm using Windows 7 Ultimate 32bit. About sin2raw, how do I open & use it You know, when I left-clicked on "sin2raw.exe", a command windows did appear in just one second, then it disappeared...

banking.amateur said:
I'm using Windows 7 Ultimate 32bit. About sin2raw, how do I open & use it You know, when I left-clicked on "sin2raw.exe", a command windows did appear in just one second, then it disappeared...
Click to expand...
Click to collapse
Sin2raw is a command line tool. You have to use it in a cmd.exe window. Or you could use last FlashTool as Androxyde added the same algorithm in his tool.

[DEV]Redmi 1s partition Table

Device Name: Xiaome Redmi 1s
Redmi 1S partition table
Fdisk
Code:
fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 7818 MB, 7818182656 bytes
256 heads, 63 sectors/track, 946 cylinders
Units = cylinders of 16128 * 512 = 8257536 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 266306 2147483647+ ee EFI GPT
Partition 1 has different physical/logical beginnings (non-Linux?):
phys=(0, 0, 1) logical=(0, 0, 2)
Partition 1 has different physical/logical endings:
phys=(1023, 255, 63) logical=(266305, 4, 4)
Parted
Code:
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)
p
Model: MMC M8G1GC (sd/mmc)
Disk /dev/block/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 2097kB 2080kB sbl1
2 2097kB 4177kB 2080kB sbl1bak
3 4177kB 5225kB 1049kB rpm
4 5225kB 6274kB 1049kB rpmbak
5 6274kB 7323kB 1049kB tz
6 7323kB 8371kB 1049kB tzbak
7 8371kB 8379kB 8192B ssd
8 8379kB 9428kB 1049kB sdi
9 9428kB 10.5MB 1049kB DDR
10 10.5MB 14.7MB 4194kB aboot
11 14.7MB 18.9MB 4194kB abootbak
12 18.9MB 24.1MB 5243kB bk1
13 24.1MB 28.3MB 4194kB misc
14 28.3MB 36.7MB 8389kB logo
15 36.7MB 67.1MB 30.4MB bk2
16 67.1MB 68.7MB 1573kB modemst1
17 68.7MB 70.2MB 1573kB modemst2
18 70.2MB 70.3MB 1024B fsc
19 70.3MB 134MB 64.0MB bk3
20 134MB 136MB 1573kB fsg
21 136MB 168MB 32.0MB bk4
22 168MB 201MB 33.6MB bk5
23 201MB 268MB 67.1MB fat16 modem
24 268MB 285MB 16.8MB boot
25 285MB 302MB 16.8MB recovery
26 302MB 336MB 33.6MB ext4 persist
27 336MB 1174MB 839MB ext4 system
28 1174MB 1577MB 403MB ext4 cache
29 1577MB 7818MB 6241MB ext4 userdata
(parted)
gdisk
Code:
gdisk -l /dev/block/mmcblk0
GPT fdisk (gdisk) version 0.8.4
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk /dev/block/mmcblk0: 15269888 sectors, 7.3 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 98101B32-BBE2-4BF2-A06E-2BB33D000C20
Partition table holds up to 32 entries
First usable sector is 34, last usable sector is 15269854
Partitions will be aligned on 2-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
1 34 4095 2.0 MiB FFFF sbl1
2 4096 8157 2.0 MiB 0700 sbl1bak
3 8158 10205 1024.0 KiB FFFF rpm
4 10206 12253 1024.0 KiB 0700 rpmbak
5 12254 14301 1024.0 KiB FFFF tz
6 14302 16349 1024.0 KiB 0700 tzbak
7 16350 16365 8.0 KiB FFFF ssd
8 16366 18413 1024.0 KiB FFFF sdi
9 18414 20461 1024.0 KiB FFFF DDR
10 20462 28653 4.0 MiB FFFF aboot
11 28654 36845 4.0 MiB 0700 abootbak
12 36846 47085 5.0 MiB 8300 bk1
13 47086 55277 4.0 MiB FFFF misc
14 55278 71661 8.0 MiB 8300 logo
15 71662 131061 29.0 MiB 8300 bk2
16 131062 134133 1.5 MiB FFFF modemst1
17 134134 137205 1.5 MiB FFFF modemst2
18 137206 137207 1024 bytes FFFF fsc
19 137208 262133 61.0 MiB 8300 bk3
20 262134 265205 1.5 MiB FFFF fsg
21 265206 327669 30.5 MiB 8300 bk4
22 327670 393205 32.0 MiB 8300 bk5
23 393206 524277 64.0 MiB 0700 modem
24 524278 557045 16.0 MiB FFFF boot
25 557046 589813 16.0 MiB FFFF recovery
26 589814 655349 32.0 MiB 0700 persist
27 655350 2293749 800.0 MiB 0700 system
28 2293750 3080181 384.0 MiB 0700 cache
29 3080182 15269854 5.8 GiB 0700 userdata

planning to make changes with this Partition table :-]
but thinking what to expand.......
Userdata or System by shrinking /Cache
:-]
will make thread soon with all info and guide .

OH NO!!!
I accidentally erased tz partition. So will 'dd'ing tz.mbn to /dev/sdb5(here) work? Please help, my phone is completely dead, not even fastboot. X|

generex144 said:
I accidentally erased tz partition. So will 'dd'ing tz.mbn to /dev/sdb5(here) work? Please help, my phone is completely dead, not even fastboot. X|
Click to expand...
Click to collapse
dnt wrry, i have gone through this..
this will help you..
http://en.miui.com/thread-54139-1-1.html
NOTE- donwload ,install usb 9006 & 9008 drivers properly and before start charge battery with external charger or with spare phone... battery should b in phone else it wont switch 9006 to 9008 mode...

Is the partition table not resetted if I fastboot flashed a stock img onto the phone? I've tried it thrice but it stops at the cache partition giving me this error:
Code:
Unspecified error(0x80004005: FAILED (remote: size too large)

Root and Recovery (CAN-L11)

It seem impossible to find any useful root tools for the Huawei Nova (EU edition).
This thread is in hope to collect some more info on this device, in order to give people better instruction on how to Root it.
Getting the boot-loader unlocked is easy as its unlock code is given by Huawei, and described
elsewhere. (1st 6 steps.) The problem appears to be to find an easy and persistent method for
root. It is very possible that I have missed something as I have not had much time to look
around very hard. So any input and links would be greatly appreciated.
If you do find the FULL firmware, please upload it and post a new link. It seem that most links I've found are
either fake, behind a long chain of ad-walls or on Chinese hard to navigate websites.
First of all the phone (I am interested in) has the following Firmware properties:
Code:
[ro.build.cust.id]: [CAN-L11C432B100CUSTC432D004]
[ro.product.fingerprintName]: [HUAWEI-MILAN]
[ro.product.CustCVersion]: [C432]
[ro.product.CustDVersion]: [D004]
[ro.product.board]: [CAN-L11]
[ro.product.hardwareversion]: [HL1CANL01M]
The update available so far is incomplete since it's an OTA to patch and resolve some
minor issues. So don't take it. Other OTAs can be found with this tool.
The processor (MSM8953) is exactly the same as for the following devices:
Code:
Asus Zenfone 3 (ZE520KL)
Asus Zenfone 3 (ZE552KL)
Asus Zenfone 3 Deluxe 5.5"
Huawei G9 Plus
Huawei Nova
Huawei Nova plus
Lenovo Vibe P2
Motorola Moto Z Play
Oppo R9s
Qiku 360 N4S
Samsung Galaxy C7
Samsung Galaxy On7 (2016)
Vivo X9
Xiaomi Redmi 4 Prime(32GB)
ZTE Axon Max 2
ZTE Axon 7 MAX
This means, that anything root that works on these, may also have a better success on this device.
But be careful, since these are just common names of devices and not exact model numbers!
For the bootloader unlock you need to provide this info:
Code:
Product Model: [ro.product.model]:
Product Serial number* [ro.boot.serialno]:
Product IMEI || MEID: (*#06#):
Product ID: (*#*#1357946#*#*):

All it takes is for someone to compile twrp. Knowing the differences in the models is important. I am in China so looking at the 64g internal 4gb memory. It is listed as CAZ-AL10. The partitions seem different, as the twrp developed does not support other models. Build it with you partition breakdown and it will work.

wangdaning said:
All it takes is for someone to compile twrp. Knowing the differences in the models is important. I am in China so looking at the 64g internal 4gb memory. It is listed as CAZ-AL10. The partitions seem different, as the twrp developed does not support other models. Build it with you partition breakdown and it will work.
Click to expand...
Click to collapse
Yeah, I was thinking to do that since nobody else seem interested, but since I'm not rooted yet, I can't even get a proper partition layout as standard partition layout "by-name" is unreadable for non-root, at least not from simple shell. Is your device using the same processor (see my post above)? (I doubt it.) However, it was compiled with kernel debug fs, so perhaps something can be used there. I was also asking elsewhere if we can use the recent full AOS 7.0 (EMUI 5.0) update posted by @lgstoian and use it to build TWRP also for the original 6.0 (EMUI 4.1)?
By the way, where does Huawei post their sources? And who to contact to make them post it? Do they normally comply with open-source requirements?
The partition table seem to look as follows:
Code:
$ cat /proc/partitions
major minor #blocks name
254 0 524288 zram0
179 0 30535680 mmcblk0
179 1 512 mmcblk0p1
179 2 512 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 256 mmcblk0p4
179 5 8192 mmcblk0p5
179 6 256 mmcblk0p6
179 7 256 mmcblk0p7
179 8 256 mmcblk0p8
179 9 512 mmcblk0p9
179 10 512 mmcblk0p10
179 11 2048 mmcblk0p11
179 12 256 mmcblk0p12
179 13 8192 mmcblk0p13
179 14 256 mmcblk0p14
179 15 256 mmcblk0p15
179 16 256 mmcblk0p16
179 17 65536 mmcblk0p17
179 18 4096 mmcblk0p18
179 19 4096 mmcblk0p19
179 20 4096 mmcblk0p20
179 21 163840 mmcblk0p21
179 22 1 mmcblk0p22
179 23 8 mmcblk0p23
179 24 16384 mmcblk0p24
179 25 32 mmcblk0p25
179 26 16 mmcblk0p26
179 27 8192 mmcblk0p27
179 28 11264 mmcblk0p28
179 29 4096 mmcblk0p29
179 30 81920 mmcblk0p30
179 31 81920 mmcblk0p31
259 0 81920 mmcblk0p32
259 1 1024 mmcblk0p33
259 2 262144 mmcblk0p34
259 3 7168 mmcblk0p35
259 4 65536 mmcblk0p36
259 5 65536 mmcblk0p37
259 6 512 mmcblk0p38
259 7 512 mmcblk0p39
259 8 32 mmcblk0p40
259 9 512 mmcblk0p41
259 10 1024 mmcblk0p42
259 11 32768 mmcblk0p43
259 12 512 mmcblk0p44
259 13 4096 mmcblk0p45
259 14 128 mmcblk0p46
259 15 128 mmcblk0p47
259 16 256 mmcblk0p48
259 17 256 mmcblk0p49
259 18 8 mmcblk0p50
259 19 16384 mmcblk0p51
259 20 524288 mmcblk0p52
259 21 3788800 mmcblk0p53
259 22 25178095 mmcblk0p54
179 32 4096 mmcblk0rpmb
253 0 3758932 dm-0
253 1 520124 dm-1
253 2 25178079 dm-2
But we need the correct mapping to the files as given in the full update.

They usually drop their sources here for international : http://consumer.huawei.com/en/support/mobile-phones/index.htm and here for chinese : http://consumer.huawei.com/cn/support/mobile-phones/index.htm
From what I saw they pop up there 2 - 3 months after the phones launch date.

Looking forward for the root of the Huawei nova urgently. I think it needs more time for this newly device to get one great dev to compile twrp and get a root method to work.
I just switched from HTC 10 to nova and I'm very impressed. Huawei emui did so much better than HTC.
Everything is working out of the box and looks great. The only thing I really miss is root for using adblock and a network speed indicator.

Getting my popcorn bowl !! :laugh:
Nova Plus

E:V:A said:
It seem impossible to find any useful root tools for the Huawei Nova (EU edition).
This thread is in hope to collect some more info on this device, in order to give people better instruction on how to Root it.
Getting the boot-loader unlocked is easy as its unlock code is given by Huawei, and described
elsewhere. (1st 6 steps.) The problem appears to be to find an easy and persistent method for
root. It is very possible that I have missed something as I have not had much time to look
around very hard. So any input and links would be greatly appreciated.
If you do find the FULL firmware, please upload it and post a new link. It seem that most links I've found are
either fake, behind a long chain of ad-walls or on Chinese hard to navigate websites.
First of all the phone (I am interested in) has the following Firmware properties:
Code:
[ro.build.cust.id]: [CAN-L11C432B100CUSTC432D004]
[ro.product.fingerprintName]: [HUAWEI-MILAN]
[ro.product.CustCVersion]: [C432]
[ro.product.CustDVersion]: [D004]
[ro.product.board]: [CAN-L11]
[ro.product.hardwareversion]: [HL1CANL01M]
The update available so far is incomplete since it's an OTA to patch and resolve some
minor issues. So don't take it. Other OTAs can be found with this tool.
The processor (MSM8953) is exactly the same as for the following devices:
Code:
Asus Zenfone 3 (ZE520KL)
Asus Zenfone 3 (ZE552KL)
Asus Zenfone 3 Deluxe 5.5"
Huawei G9 Plus
Huawei Nova
Huawei Nova plus
Lenovo Vibe P2
Motorola Moto Z Play
Oppo R9s
Qiku 360 N4S
Samsung Galaxy C7
Samsung Galaxy On7 (2016)
Vivo X9
Xiaomi Redmi 4 Prime(32GB)
ZTE Axon Max 2
ZTE Axon 7 MAX
This means, that anything root that works on these, may also have a better success on this device.
But be careful, since these are just common names of devices and not exact model numbers!
For the bootloader unlock you need to provide this info:
Code:
Product Model: [ro.product.model]:
Product Serial number* [ro.boot.serialno]:
Product IMEI || MEID: (*#06#):
Product ID: (*#*#1357946#*#*):
Click to expand...
Click to collapse
Hi man! I bought my Nova but it didn't arrive yet. But I'm following this thread and searched a bit. It seems that there is a source for Zenfone 3 ZE520KL here. Don't know if something can be done from here.
Sadly, Huawei G9 Plus isn't even listed at the site that @lgstoian sent. For more accurated source, we will have to wait for Huawei to put the source code on the site =/
EDIT: in fact, I noticed that g9 plus isn't to be found anywhere in Huawei website. And it seems that G9 Plus has the same specs of Nova Plus, So they might be the same device.

As I stated in the bootloader thread, I'm really interested in compiling TWRP for the device, but I'm on L01. I put together some files and if everything goes well, I'll give it a try at the end of the week. This isn't a promise, but I try to..

The difference between the L-01 and the L-11 should only the modem because the dual sim.
Tell new hat you need.

That's right..but let me start with L01-Version..at the moment I've some problems to solve for compiling, but the files should be complete..

If you read with compile, send me a copy I will try it on my L-11. (I bricked it with manual flash a system img from the 7.0 Update xD )
And with a working TWRP i can flash a backup from another phone, to get it work again.

Let me guess you tried the C900 one? Have you tried to flash also recovery and boot from this package?

Vinnom said:
...And it seems that G9 Plus has the same specs of Nova Plus, So they might be the same device.
Click to expand...
Click to collapse
It probably is the same device. I would guess it is a test release device, possibly even a developer device from a very limited release.
-=MoRpH=- said:
The difference between the L-01 and the L-11 should only the modem because the dual sim.
Click to expand...
Click to collapse
Yep, I think so too, because both firmware and and ro.product.hardwareversion are often referring to L01.
What we need is a working partition table, to know what can be flashed where. ATM I can't even read the partitions, since I have no working root. I'm closely following the developments on the dirtycow thread. However, the full AOS 7 update contain all partitions, but I need to get the mappings.
Running 7zip on the UPDATE.APP give you these 61 image files:
Code:
$ ls -1
aboot.img*
abootbak.img*
apdp.img*
boot.img*
bootfail_info.img*
cache.img*
cmnlib.img*
cmnlib64.img*
cmnlib64bak.img*
cmnlibbak.img*
config.img*
cust.img*
DDR.img*
devcfg.img*
devcfgbak.img*
devinfo.img*
dip.img*
dpo.img*
dsp.img*
erecovery.img*
fsc.img*
fsg.img*
keymaster.img*
keymasterbak.img*
keystore.img*
limits.img*
lksecapp.img*
lksecappbak.img*
log.img*
mcfg.img*
mdtp.img*
misc.img*
modem.img*
modemst1.img*
modemst2.img*
mota.img*
msadp.img*
nff.img*
oeminfo.img*
pad0.img*
pad1.img*
pad2.img*
patch.img*
persist.img*
product.img*
recovery.img*
rpm.img*
rpmbak.img*
rrecord.img*
sbl1.img*
sbl1bak.img*
sec.img*
splash.img*
ssd.img*
syscfg.img*
system.img*
tz.img*
tzbak.img*
userdata.img*
vendor.img*
version.img*
However, using 7z to unpack give you an error for each, even though the names (and number of partitions) now seem correct. This is because the image packaging contain additional non-standard data. Although there are some differences, it's something like this:
Code:
1. First 92 bytes are 0x00
2. Each file are started with 55AA 5AA5
3. Then 4 bytes for Header Length
4. Then 4 bytes for Unknown1
5. Then 8 bytes for Hardware ID
6. Then 4 bytes for File Sequence
7. Then 4 bytes for File Size
8. Then 16 byts for File Date
9. Then 16 byts for File Time
10.Then 16 byts for File Type
11.Then 16 byts for Blank1
12.Then 2 bytes for Header Checksum
13.Then 2 bytes for BlockSize
14.Then 2 bytes for Blank2
15.Then ($headerLength-98) bytes for file checksum
16.Then data file length bytes for files.
17.Then padding if have
18.Then repeat 2 to 17
So you need to use a Huawei specific unpacker. Trying to use any previous and outdated split_updata.pl (or splitupdate) scripts, does not give all the partitions without modifications. There are some hope for the better maintained Huawei Updater Extractor tool by @worstenbrood.
Mapping this back to /proc/partitions, should be fairly straight forward...
What is note worthy is that the mmcblk0p54 partition is 16 bytes larger than dm-2 (verity?), and /system is mounted on dm-2.

The question here is, how got the Chinese guy the mounting point or the partition table for the 64gb version? My Chinese is to bad, so I can't ask him.
Gesendet von iPhone mit Tapatalk

@morph wich Chinese guy do you mean?

I think he is referring to this thread : http://club.huawei.com/thread-11271738-1-1.html

Yes @lgstoian That's what I mean.
The recovery boot on my L11 but can't mount the partitions.
Gesendet von iPhone mit Tapatalk

Google's translation of the link:
Code:
NovaTWRP for XiaoWang_v1.1
UPDATE:
1. Added the king su_v3.64, integrated with the recovery file
2. Perfect support sub-f2fs
3. Solved the previous version of the bug
Boot file also improved, to solve the last version of the small probability
of the collapse of the phenomenon, be sure to use the new version
Because the system can not support supersu, will not start, so the use
of the kingroot team file (kingroot program is really high, I looked
directly on the ignorant of), and by the kingroot implementation of
the root. This program needs to format the data, please make a backup
As the screenshot upload it is too slow, so do not upload, and then
pass on the following text with a very detailed description of it
Before operation, please charge the battery to 60 or more, just in
case
1. First of all, please back up good data, first of all, please back
up good data, first back up good data, I have said important three times
2. Your phone needs to unlock the OEM before follow-up operation
3. Press the power button to restart, hold down the black screen of the moment the volume down, it will enter fastboot
4. Then extract the downloaded file, click the brush into the boot,
brush into the recovery, will be prompted to brush into the general impossible to error
5. Unplug the USB, press the power button to shut down,
press and hold the volume after the black screen, until you see a
large English, and so on 3 seconds to release, entered the Nova
special TWRP latest version
6. Go to Main> Clear> Format data partition> enter yes>
7. Main interface> Restart> Recovery
8. The main interface> mount> the system hook
9. Main interface> Advanced> File management> Select su folder> Select su> Copy> system> xbin> Point to the lower right corner of the hook> Slide button to confirm >>>> Back to system / xbin / Select su file>
10. Main interface> Restart> System>
11. Restart to the system, do not set the fingerprint and account
12. Install KingRoot.apk just downloaded, be sure to this version, do not download other versions, and do not download other software will be error, will become a serious brick
13.root after he turned around and then complete the point that the blue immediately deal with
14. Do not ask me why always the middle of the night post
15. Cherish the fruits of labor, reproduced, please indicate the source
If the operation failed, please do not lose heart, I also prepared the
original document, under any circumstances, as long as BootLoader
is not formatted, you can save the brick paste is a virtue, to
download the file, please reply " My brother "file 118.92M, it is
recommended to use WiFi download
Pan.baidu.com/s/1eRTkmsi
This link was updated on November 26, 2016 at 22:37:36

Xelfmade said:
Let me guess you tried the C900 one? Have you tried to flash also recovery and boot from this package?
Click to expand...
Click to collapse
First i tried the L11 EMUI 5 Beta (Yes boot, recovery and system.img). After that i got a boot loop and tried to wipe user data... that fails at 30%.
Than i tried the full firmware for the C900 (dload and fastboot) doesn't work too. Right now i can only boot the recovery and erecovery.

@lgstoian does that mean, he has successfully rooted the nova and we only have to translate his description correct to get a working root?

Flashing curtana custom rom into joyeuse devices

Good news for joyuse devices owner, I admit that we can flashing custom rom android 10 curtana on joyuse as long as we be aware and inspected first:
It is what inside custom rom curtana only allow if inside contain: boot, system, product, and vendor, don't try to flash from curtana rom if it contain firmware update it will break your phone
You are as long as using curtana custom recovery you can flash curtana custom rom, and format data partition after flashing
You only replace folder camera on lib and lib64 on vendor from extracted vendor joyeuse in order camera working properly, use root and fx file explorer to access vendor
If you want to come back to joyeuse custom rom you need to flash joyeuse custom recovery again and flash original vendor image belongs to joyeuse again
Have enjoy flashing curtana custom rom on joyeuse devices
All are working perfecly accept bugs from custom rom itself.
Use with carefully and I am not responsible for your damage devices

hendibudi said:
Good news for joyuse devices owner, I admit that we can flashing custom rom android 10 curtana on joyuse as long as we be aware inspected first:
It is what inside custom rom curtana only allow if inside contain: boot, system, product, and vendor, don't try to flash from curtana rom if it contain firmware update it will break your phone
You are as long as using curtana recovery rom you can flash curtana custom rom
You only replace folder camera on lib and lib64 on vendor from extracted vendor joyeuse in order camera working properly
Have enjoy flashing curtana custom rom on joyeuse devices
All are working perfecly accept bugs from custom rom itself.
Click to expand...
Click to collapse
Have You Tried it?
Please attach some Screenshots:fingers-crossed:
!

OGHyperion said:
Have You Tried it?
Please attach some Screenshots:fingers-crossed:
!
Click to expand...
Click to collapse
Almost all rom working accept evolution x curtana rom

This is good news from the rom developers, to know that they would be able to quite easily adapt their versions to work on the joyeuse version.
Though I think that this way you fake all software,... to believe the phone is another version.
Which could conflict in the future.
I would rather try the following:
Start from a joyeuse rom (with correct firmware, vendor, ... data)
And only copy/overwrite the required partitions (data/system/....) with those of a curtana rom.
So keeping the correct firmware, vendor, ...
That would leave you only to adapt the build.prop file to set model, ... (check with the joyeuese rom)
Just a thought, I have not much knowledge here.
But also trying to learn and try.
Would someone be able to explain me the partition layout and where to find the system?
I am confused not to find the system partition.
How do I for example also remount the system partition on these phones to make it writable?
adb shell "su -c 'mount -o rw,remount /system'"
I'm trying to understand how this works, sorry for being noob.
C:\Users\kheno>adb shell
joyeuse:/ $ su
joyeuse:/ # ls /dev/block
bootdevice loop1 loop4 ram1 ram4 sda11 sda3 sdb2 sde1 sde18 sde26 sde34 sde42 sde50 sde9
by-name loop10 loop5 ram10 ram5 sda12 sda4 sdc sde10 sde19 sde27 sde35 sde43 sde51 sdf
dm-0 loop11 loop6 ram11 ram6 sda13 sda5 sdc1 sde11 sde2 sde28 sde36 sde44 sde52 sdf1
dm-1 loop12 loop7 ram12 ram7 sda14 sda6 sdc2 sde12 sde20 sde29 sde37 sde45 sde53 sdf2
dm-2 loop13 loop8 ram13 ram8 sda15 sda7 sdd sde13 sde21 sde3 sde38 sde46 sde54 sdf3
dm-3 loop14 loop9 ram14 ram9 sda16 sda8 sdd1 sde14 sde22 sde30 sde39 sde47 sde55 sdf4
dm-4 loop15 mapper ram15 sda sda17 sda9 sdd2 sde15 sde23 sde31 sde4 sde48 sde6 sdf5
dm-5 loop2 platform ram2 sda1 sda18 sdb sdd3 sde16 sde24 sde32 sde40 sde49 sde7 vold
loop0 loop3 ram0 ram3 sda10 sda2 sdb1 sde sde17 sde25 sde33 sde41 sde5 sde8 zram0
joyeuse:/ # ls /dev/block/by-name/
ALIGN_TO_128K_1 catecontentfv devinfo hyp mdtpsecapp qupfw spunvm vbmeta_system
ALIGN_TO_128K_2 catefv dip hypbak mdtpsecappbak qupfwbak ssd vbmeta_systembak
abl cateloader dsp imagefv metadata recovery storsec vbmetabak
ablbak cdt dspbak imagefvbak minidump recoverybak super xbl
aop cmnlib dtbo keymaster misc sda toolsfv xbl_config
aopbak cmnlib64 dtbobak keymasterbak modem sdb tz xbl_configbak
apdp cmnlib64bak exaid keystore modembak sdc tzbak xblbak
bluetooth cmnlibbak ffu limits modemst1 sdd uefisecapp
bluetoothbak cust frp logdump modemst2 sde uefisecappbak
boot ddr fsc logfs multiimgoem sdf uefivarstore
bootbak devcfg fsg mdtp multiimgqti secdata userdata
cache devcfgbak gsort mdtpbak persist splash vbmeta
joyeuse:/ # df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 2.7G 1.0M 2.7G 1% /dev
tmpfs 2.7G 0 2.7G 0% /mnt
tmpfs 2.7G 0 2.7G 0% /apex
/dev/block/sda12 11M 72K 11M 1% /metadata
tmpfs 2.7G 6.3M 2.7G 1% /sbin
/sbin/.magisk/block/system_root 2.2G 2.2G 7.2M 100% /sbin/.magisk/mirror/system_root
none 2.7G 0 2.7G 0% /sys/fs/cgroup
/dev/block/sda13 344M 940K 343M 1% /cache
/dev/block/sde4 256M 127M 128M 50% /vendor/firmware_mnt
/dev/block/sde9 27M 20M 7.3M 74% /vendor/dsp
/dev/block/sda2 27M 1.3M 26M 6% /mnt/vendor/persist
/dev/block/sde5 64M 848K 63M 2% /vendor/bt_firmware
/dev/block/sda7 976M 914M 62M 94% /cust
/dev/block/loop2 836K 808K 28K 97% /apex/[email protected]
/dev/block/loop3 5.2M 5.2M 32K 100% /apex/[email protected]
/dev/block/loop4 1.6M 1.6M 28K 99% /apex/[email protected]
/dev/block/loop5 5.0M 5.0M 32K 100% /apex/[email protected]
/dev/block/loop6 96M 96M 36K 100% /apex/[email protected]
/dev/block/loop7 232K 36K 196K 16% /apex/[email protected]
/dev/block/loop8 21M 21M 32K 100% /apex/[email protected]
/sbin/.magisk/block/product 1.0G 1.0G 3.3M 100% /sbin/.magisk/mirror/product
/sbin/.magisk/block/vendor 1.1G 1.1G 3.8M 100% /sbin/.magisk/mirror/vendor
/sbin/.magisk/block/data 105G 6.7G 98G 7% /sbin/.magisk/mirror/data
/data/media 105G 6.7G 98G 7% /mnt/runtime/default/emulated
Have no clue, still noob when it comes to these things

This seems great! Can someone else confirm that this approach works?

did you test on your own? and its success?

nickadsy said:
did you test on your own? and its success?
Click to expand...
Click to collapse
All custom rom curtana i try it working accept evolution x not working because inside rom there is no vendor image content

So it's supposed to be easy to build a patch to flash after flashing a curtana rom to bring it back to joyeuse
Going to download some ROMs and try this

ahked.ragab said:
So it's supposed to be easy to build a patch to flash after flashing a curtana rom to bring it back to joyeuse
Going to download some ROMs and try this
Click to expand...
Click to collapse
If it really works, it's possible to make patch..

eng4r said:
So it's supposed to be easy to build a patch to flash after flashing a curtana rom to bring it back to joyeuse
Going to download some ROMs and try this
Click to expand...
Click to collapse
Let us know how your patch goes

Do we need to flash curtana recovery on joyeuse? By the way can you give me joyeuse vendor I will try to make a zip that replace lib and lib64

anyone tried this if it works or not ?

Doesn't sound very reliable to me. Sorry.
Sent from my Redmi Note 9 Pro using XDA Labs

What about NFC?

Edit - I have just read your post #13 on the Havoc-OS-3.7 thread which seems to answer all my questions below, except "which Curtana recovery did you use". Thanks
@hendibudi - thank you for this post, I am really interested. I don't know enough to jump straight in and try it but hope I can get enough info to feel confident enough to have a go.
You say not to flash (on Joyeuse) if the Curtana rom contains firmware update.
So, looking inside the miui_JOYEUSEEEAGlobal_V11.0.3.0.QJZEUXM zip the first folder I see is "firmware-update". Is this the "firmware-update" you say to avoid? Would it only be in it's own folder or could there be (in different roms) firmware-updates in other folders? Does the absence of a firmware-update folder mean that I am safe to flash on my EEA joyeuse (without any further checks)?
Looking inside the Curtana Havoc-OS-v3.7-20200725-curtana-Official-GApps zip, there are 2 folders ("install" and "meta-inf") and I cannot see anything (in any of the folders) that looks (to me) like firmware-update.
Both the above zips contain folders called META-INF which both contain a folder called com\google\android. In both cases the android folder contains 2 files called "update-binary" and "updater-script". Looking through both update_binary files, they both seem to have a mention of "firmware" but it looks to me like it is mentioned in part of an error message (seems to be the same two 2 mentions in each).
Looking at the updater-script, the MIUI one really does seem to be updating about 30 objects from the "firmware-update" folder and even starts with a message saying "Patching firmware images..."
The Havoc updater script also prints a message saying "Patching firmware images..." which is followed by the last 3 lines of the script which are "package_extract_file" lines for dtbo.img , vbmeta.img and vbmeta_system.img. Would these update firmware or are they something else?
I will try looking these up in Google but I'm not confident I would understand the answer :0))
I understand that I and I alone am responsible for what I do/flash with my phone but from what I have seen in the above, it looks like I can safely use the Curtana Havoc rom on my EEA joyeuse phone. Would you agree or tell me not to try it?
Also, you mention (point 2) that we can use curtana custom recovery to flash the rom and format data partition - which curtana custom recovery have you used for this and is my EEA Joyeuse Note 9 pro different to your model (is it likely to be a problem).
I have rooted & flashed roms on several other phones in the past but all have had official TWRP's and the only thing to sort out was if they had MTK or SD cpu's – even I managed that quite easily. The Note 9 pro and all its variations seem to be in a whole new (& complicated) league.

https://forum.xda-developers.com/redmi-note-9-pro/themes/dolby-sound-mod-100-t4081933 Is this Firmware ?

mura20 said:
Let us know how your patch goes
Click to expand...
Click to collapse
Someone already did it http://forum.xda-developers.com/red...gisk-joyeuse-camera-fix-roms-curtana-t4142663

Does anyone know how I can get my Note 9 Pro Global back to the "brick" state?
Unfortunately I flashed a curtana image, because I always got Error 7 on the joyeuse image.
Now the device only boots up to the Redmi logo and restarts immediately.
I can't get into the Fastboot Mode anymore.
Can someone save my device or is there a possibility to flash it by myself?

Can i use miui 12 curtana rom for my joyeuse phone?

What? Want a brick? Lets do it!
Enviado desde mi Redmi Note 9S mediante Tapatalk