Database Info

Custom partition layouts, ZERO brick risk!

This is about the coolest thing you can imagine.
DEATHSPL is OBSOLETE.
We can repartition these things -- to ANY layout we like -- withOUT changing or modifying the SPL!
This is even compatible with a STOCK SPL! I.e. 0.95.0000.
This is something I discovered while looking at the MTD drivers.
The mtd drivers accept partition table specified on the KERNEL COMMAND LINE! And this SUPERSEDES the automatic table discovery method.
This is the command line argument for STOCK partition layout:
Code:
mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)
You can boot a kernel with a modified partition table using one of two methods;
the "-c" parameter to fastboot allows you to add kernel parameters. This is good for booting RECOVERY images and applying custom layouts.
The second method is to build the custom layout into your boot.img or recovery.img.
This can be done using the "--cmdline" parameter to mkbootimg.
Notes: The smallest possible partition is 128k.
The partition sizes must be MULTIPLES of 128k and must start on an offset that is a multiple of 128k. The memory size is 256MB precisely.
Note: DO NOT modify ANYTHING before the START of the boot partition, i.e. offset 0x2bc0000. If you do, it won't boot!
***** EDIT:
We now have a BETA implementation of this concept: http://forum.xda-developers.com/showpost.php?p=6916491&postcount=39
Thanks go to Firerat, who did the actual implementation work in converting CM 5.0.8 to this process.
Also thanks to skraw at CM forums who asked a silly question that started the gears a crankin and ended up getting this as an answer.
** just goes to show that there is no such thing as a stupid question.

Sweet stuff!
Now we can finally reduce the size of that useless cache partition. And ROM devs can actually fit anything they want without a headache.
This should be leaps and bounds more useful on the phones with more ROMs space like the 32A Magic, where the cache is absurdly large.

xaueious said:
Sweet stuff!
Now we can finally reduce the size of that useless cache partition. And ROM devs can actually fit anything they want without a headache.
This should be leaps and bounds more useful on the phones with more ROMs space like the 32A Magic, where the cache is absurdly large.
Click to expand...
Click to collapse
I'll ask a silly question, and full intent not to derail the thread.. why have partitions at all? (do they accomplish some level of protection that simple unix privs do not if /system, /data, /cache, etc were all on the same partition?) Hopefully not a super stupid question (I understand their use on my home linux box, but fail to see what value they add here)

I already pointed this out months ago.. but no one ever tried to make a use out of it.

sweeeeeet! good ****, someone make sure cyanogen knows about this.

mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?

mattv888 said:
mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?
Click to expand...
Click to collapse
Yeah Im curious about that too

mattv888 said:
mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?
Click to expand...
Click to collapse
Yes, in theory.. I'm not sure how usable it would be, but purely theoretically you should be able to drop cache and userdata to 128k, mount them both on the sdcard instead and flash a 200mb+ system image.
With a bit of modification to the way we flash images at the moment, there's no reason devs can't include a custom partition layout to fit the requirements of every release.
This is an awesome find by both lbcoder and maxisma, who seem to have discovered it independently.. I totally missed maxisma's annoucement though
Whoever found it first, this rules.

This would be really awesome to see can't wait

Macrophage001 said:
This would be really awesome to see can't wait
Click to expand...
Click to collapse
Wait for what?
This is something that everyone can do for themselves!
All you need is a calculator (to calculate memory offsets and sizes), the first post of this thread, and this:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
unpack your boot.img, mkbootimg it back with the specified kernel command line, shove it into your update.zip (or fastboot it into the phone), and you're done-ish.
Take the most recent CM for example:
1) extract boot.img, unpack it, repack it with the kernel command line specified (modified to your specifications), put it back in the update.zip, resign, and put it on your sdcard.
2) Phone in fastboot mode, fastboot -c "same kernel command line as boot.img is packed with" boot recovery.img, flash your update.zip, done.
And then every time the phone boots up, it'll have the customized partition table since it is built into the boot.img.

with this custom partition layouts, do we also need to do something to the recovery to make nandroid/bart recognize the new layout?

haozheng91 said:
with this custom partition layouts, do we also need to do something to the recovery to make nandroid/bart recognize the new layout?
Click to expand...
Click to collapse
Same steps as the rom, just ensure you *never* flash *any* spl or radio for any reason from a re-partitioned recovery with a cache partition that does not match the spl's actual cache start location. Or you will be in the market for a jtag adapter to fix your brick.
Making this user friendly will need some configuration work.

ezterry said:
Same steps as the rom, just ensure you *never* flash *any* spl or radio for any reason from a re-partitioned recovery with a cache partition that does not match the spl's actual cache start location. Or you will be in the market for a jtag adapter to fix your brick.
Making this user friendly will need some configuration work.
Click to expand...
Click to collapse
There's security built in to that process....
the cache partition has to get a special header applied in order for the update to be taken, and if the spl or radio partition was mapped differently, this header will be badly broken. I believe that there are also checksums on the spl and radio images that should be checked by the SPL prior to actually installing them. Part of the reason for this is to ensure that the image was actually written correctly to the cache partition.

Another good find.
maxisma said:
I already pointed this out months ago.. but no one ever tried to make a use out of it.
Click to expand...
Click to collapse
Don't see why. Hopefully people will be able to understand how to do this, get rid of the deathspl along with all the spam topics that come from the resulting bricks.

lbcoder said:
There's security built in to that process....
the cache partition has to get a special header applied in order for the update to be taken, and if the spl or radio partition was mapped differently, this header will be badly broken. I believe that there are also checksums on the spl and radio images that should be checked by the SPL prior to actually installing them. Part of the reason for this is to ensure that the image was actually written correctly to the cache partition.
Click to expand...
Click to collapse
I can test it but I've seen invalid radio images trap a phone in flash radio.. I highly recommend just not tempting fate with this one and just installing 1.33.2003 or 1.33.2005 before starting custom partitions.. then you can deal with radio/alt recovery flashes from there.
Leave the recovery for android system install/uppdate/backup operations.

any success?

ezterry said:
I can test it but I've seen invalid radio images trap a phone in flash radio.. I highly recommend just not tempting fate with this one and just installing 1.33.2003 or 1.33.2005 before starting custom partitions.. then you can deal with radio/alt recovery flashes from there.
Leave the recovery for android system install/uppdate/backup operations.
Click to expand...
Click to collapse
Possibly with an invalid radio, but DEFINITELY NOT with an offset-cache partition. It simply can't possibly do anything without the right header.
And I don't see any benefit at all for installing a 1.x SPL. The ability to flash radio or SPL direct depends on fastboot, and if you have fastboot, you can break the update-x cycle simply by wiping the misc partition.
And for that matter, the 0.95.0000 SPL withOUT fastboot still could flash an nbh file in any circumstance where any of the engineering/pseudoengineering SPLs could enter fastboot.
Tempting fate is to flash a radio or spl to begin with. If you want to feel really safe, you can always build a recovery that lacks the ability to flash the radio or spl. This would, of course, force you to go back to the SPL's partition table (i.e. another recovery) to flash either of those.
Or how about this: query the kernel command line -- if the partition table is set on the kernel command line, don't allow flashing of radio or spl.

lbcoder said:
This is the command line argument for STOCK partition layout:
Code:
mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)
Notes: The smallest possible partition is 128k.
The partition sizes must be MULTIPLES of 128k and must start on an offset that is a multiple of 128k. The memory size is 256MB precisely.
Note: DO NOT modify ANYTHING before the START of the boot partition, i.e. offset 0x2bc0000. If you do, it won't boot!
Click to expand...
Click to collapse
I'm working my way thru the math.. I set up an OpenOffice spreadsheet (alas its fairly inept at working with hex #'s, so I have to do all the match in decimal and convert it to hex (couldn't find a way to make it add in hex, and it can't seem to convert big hex numbers back to dec.. even tho it can convert that same dec # into hex... grr...) anyway... this is the table I came up with (using D and H to denote Decimal and Hex versions of the same #s)
Code:
Block k M bytes(D) bytes(H) StartD EndD StartH EndH
misc 256 0.25 262144 40000 38535168 38797312 24C0000 2500000
recover 5120 5 5242880 500000 40632320 45875200 26C0000 2BC0000
boot 2560 2.5 2621440 280000 45875200 48496640 2BC0000 2E40000
system 69120 67.5 70778880 4380000 48496640 119275520 2E40000 71C0000
cache 69120 67.5 70778880 4380000 119275520 190054400 71C0000 B540000
userdat 76544 74.75 78381056 4AC0000 190054400 268435456 B540000 10000000
size 229900288 219.25
The only "gap" I saw was after misc.. ie. there was space between the end of misc and the beginning of recovery (1792k by my calculations).. is that correct, or did I fudge my math up? Any idea what is in that gap?
Also by taking the final addr and subtracting the start addr, it looks like 219.25M (out of the 256M you mention) are being used? (actually that does not take the "gap" memory into account). Any idea what is using the other 256-219.25=36.75M?
Note: not trying to poke any holes here.. I'm trying to get a good understanding of this, so I can give it a try.
EDIT: added M column to table

Yes.. there are some internal partitions after misc.
If you have 1.33.2005 or 1.33.2003 spls ask it the partition layout yourself: fastboot oem listpartition

zim2dive said:
I'm working my way thru the math.. I set up an OpenOffice spreadsheet (alas its fairly inept at working with hex #'s, so I have to do all the match in decimal and convert it to hex (couldn't find a way to make it add in hex, and it can't seem to convert big hex numbers back to dec.. even tho it can convert that same dec # into hex... grr...) anyway... this is the table I came up with (using D and H to denote Decimal and Hex versions of the same #s)
Code:
Block k M bytes(D) bytes(H) StartD EndD StartH EndH
misc 256 0.25 262144 40000 38535168 38797312 24C0000 2500000
recover 5120 5 5242880 500000 40632320 45875200 26C0000 2BC0000
boot 2560 2.5 2621440 280000 45875200 48496640 2BC0000 2E40000
system 69120 67.5 70778880 4380000 48496640 119275520 2E40000 71C0000
cache 69120 67.5 70778880 4380000 119275520 190054400 71C0000 B540000
userdat 76544 74.75 78381056 4AC0000 190054400 268435456 B540000 10000000
size 229900288 219.25
The only "gap" I saw was after misc.. ie. there was space between the end of misc and the beginning of recovery (1792k by my calculations).. is that correct, or did I fudge my math up? Any idea what is in that gap?
Also by taking the final addr and subtracting the start addr, it looks like 219.25M (out of the 256M you mention) are being used? (actually that does not take the "gap" memory into account). Any idea what is using the other 256-219.25=36.75M?
Note: not trying to poke any holes here.. I'm trying to get a good understanding of this, so I can give it a try.
EDIT: added M column to table
Click to expand...
Click to collapse
You don't need to do any subtraction. The start address is itself the size of the "gap" before it. I.e. look at startD column: 38535168 -- that would be ~38.5 MB or (divide by 1024x1024) 36.75 MiB, the same as the number you got through your subtraction.
That gap is for the radio and SPL, and some proprietary data, like IMEI, radio lock, security, etc.
Of course, you could just ASK someone who has a deathSPL for the numbers....
Not about the gap between misc and recovery: I believe that the splash images go there.
In any case, you don't need to worry about any of those....
The only partitions you need to map are the ones that *are* mapped.
misc, recovery, and boot should be left alone. As should the STARTING address of system.
You should start by adjusting the SIZE of system,
Adjust the OFFSET of cache by the SAME AMOUNT as you adjusted the SIZE of system.
Adjust the SIZE of cache by whatever you feel is appropriate,
Adjust the OFFSET of userdata to (OFFSET+SIZE) of cache.
And according to the mtd documentation, you should be able to set the SIZE of userdata to "-" in order for it to fill all of the remaining space. Either that, or hardcode it to 0x10000000-OFFSET.

make kexec guestable kernels

hi all,
i'm going to support multiple android roms loading in my kernel_chooser + root_chooser project.
in few words it will be a powerful bootloader for android.
this is what it will be able to do ( many points are yet working ):
kernel loading thought kexec
boot from external devices
boot from subfolders
custom background
change android /sytem partition
change android /data partition
wipe android /cache partition
what i'm asking to you it's to make your android rom's kernel kexec-ready, applying them a kexec guest patch.
thus to make them ready to load for me.
if not i have to patch your kernel every time you modify it.
kernel_chooser and root_chooser are hosted here: https://github.com/tux-mind/tf201-dev
they are made for the asus transformer prime ( TF201 ), but they can run on any android device with your help.
i will add you to the github collaborators if you want to help.
now we are working on multiple android roms support.
thanks in advance for your time.
-- tux_mind

@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work

HTCDreamOn said:
@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work
Click to expand...
Click to collapse
thanks
yes, this should work for all devices, except for a little tuning of the partition with the configuration data ( /data ).
i have to make it to self-detect the /data partition.
let's say for example that you want to use it on your HTC Vision.
i have to build an host kernel by the stock one applying the host kexec patch.
than i have to build an android boot image which contains kernel_chooser as initrd and the above kernel.
this android boot image will be written to your current one though fastboot.
after that kernel_chooser will be able to load any kernel patched with the guest patch.
obviously the loaded kernel must be made for that device
it can also load a custom initrd and use a custom kernel CMDLINE.
so, after i made a HTC Vision kernel_chooser, your rom it's ready to load if you applied the guest patch to you kernel.
i can't explain well how to make you rom "bootable" because we are developing this
but if your kernel is kexec-loadable it will be supported by kernel_chooser.
i will update you in the next days
bye!

Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4

@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?

dtrail1 said:
how different are the methods to use kexec?
Click to expand...
Click to collapse
kexec it's a syscall, so it's the same on every arm device.
HTCDreamOn said:
@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?
Click to expand...
Click to collapse
there is a good explaination here:
http://forum.xda-developers.com/showthread.php?t=2104706
look at the "Compatibility patch".
for my tf201 the guest patch is this: http://git.lilstevie.geek.nz/?p=ubu...ch;h=54c2e480682afb0629f3854dfea4154f528421e5
which is almost the same...
i hope that almost all kernels have the same host/guest patch, in order to save us a lot of work.
the patch isn't need for kexec, but for hardboot kexec, thus to physically shutdown and restart the device with your kernel, from 0.
the standard kexec it's a assembly jump to 0 ( jmp 0x0 ) with the new kernel loaded in the .text section.
but the standard method don't reinitialize the devices and many other things that could rest in a undefined state.
btw, i have almost done my work.....i'm fighting the android udev which is overwriting my symlinks..
see you!

i got it!
my initial target was to remove devices created by ueventd and replace them with symlink to loop devices.
but android respawn ueventd and replaces my symlinks...
i tried to start the android ueventd, leave it running, and replace the /sbin/ueventd with a infinite sleep static program
but android dont' start at all..i can't even access via adb.
so, the "final" solution is to edit the /fstab.$hardware, which should be in any andoird boot image ( right ? ).
please feel free to suggest any other way to hack the mount process.
you can find the sources here: https://github.com/tux-mind/tf201-dev/tree/master/android_chooser
the program read the paths from kernel cmdline.
the syntax is that:
Code:
newandroid=blkdev:initrd_path:fstab_path
where
blkdev is the linux name of the blockdevice containing the next args ( e.g. /dev/mmcblk0p8 )
initrd_path is the path on the previous blockdevice of the android initrd ( gzipped or not )
fstab_path is the path on the previous blockdevice of the fstab file
the fstab file have this syntax:
Code:
/android/mountpoint /path/to/image/file
where
/android/mountpoint is the android mountpoint to overwrite ( e.g. /system )
/path/to/image/file is the path to the filesystem image file ( on blkdev ) ( e.g. /boot/unrooted.img )
i don't make any documentation until i will be sure that there is no better way to do this.
thanks in advance for your testing
ah, some other useful info.
because we are in testing the program write a log file with some debug info in the root of your blkdev.
so you will find /android_chooser.log on your blkdev with these info in case of errors.
tux_mind

Please
dtrail1 said:
Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4
Click to expand...
Click to collapse
Dtrail could you explain me kexec and its components required for loading new kernel because my device(electrify 2) is similar to droid razr. Using bmm kexec is boot able because I had checked by flashing droid razr's kernel which gave a boot loop.
I would be pleased and thankful to you if you help me.

Porting Tips

This thread covers what I have learned about porting. When possible, I'll include links.
This post primarily applies to Samsung devices, although parts can also be used by other manufacturer's devices.
Get the stock firmware for your devices. This step is very important. Besides needing it to reset your device, you will need the boot and recovery images that should be in the archive file.
Follow Cyanogenmod's Porting page.
Use Heimdall to get the partition table
Get the block size by taking the number of blocks from the pit file, and then dividing the size of the storage card by that. Round to the nearest power of 2. (E.g., 524 -> 512).
Use unpackbootimg to get the files in the boot and recovery images
Get the kernel building
Use PRODUCT_COPY_FILES to copy files to specific locations. It needs to be in a device_*.mk file. Use this for the initrc's, and anything else that needs to be in the recovery (e.g., kernel modules). Keep in mind that the only variables the mk file knows about are the ones you tell it about.
At this point, you may or may not have a booting recovery. In the event that you cannot boot into the recovery (e..g, it reboots immediately upon attempting to enter the recovery), try looking at the stock recovery files (especially the ramdisk files), and see what the differences are between it and your recovery image. Again, unpackbootimg is helpful.
As a side note, I'm trying to port Cyanogenmod to the Tab 3 7.0 without using anyone else's source. Right now, I'm stuck on (6), which I'm still going through. I'll try to remember to update this post as I learn new things.

Build Environment
I'm currently using Fedora Rawhide -- which doesn't have java 1.6 or 1.7. For building the recoveries, it does not seem to matter.
That said, building using just the "mka" command will error out, as Cyanogenmod 11 is not able to be built under java 1.8.
As such, my recommendation is to use an arch installation and the systemd-nspawn command for java 1.7 (also, see the AUR for older java packages).

[TOOL]TWRP/AROMA SPFlash | MediaTek

AROMA/TWRP version of SPFlash Tools.
This tool is for MTK devices with a GPT layout - (MT6732, MT6752 and their variants).
With some testing it may be possible to add some some support for the older devices using an MBR.
Requirements:Copy SPFlash contents to /sdcard/SPFlash
Rename *scatter.txt to scatter.txt
Run .zip from TWRP​MTK-64bit_SoCs-v*.zip:During testing there will only be info displayed on screen, nothing should be modified. (Unless otherwise stated)​SPFlash-v*.zip:This will install all .img/.bin in SPFlash folder if partition is large enough​Downloads:GDrive Folder​Changelogs:SPFlash
v10 - Readded internal sd - fixed aroma exit/about screen - (a few cosmetic issues introduced).
v8 - Aroma menus updated
v7 - Create 'flashable' zip from backed up partitions.
v6 - Zipped backups added
v4 - Backup + Install fixed -- Aroma "Quit Installation" stalls
v3 - Backup function added - untested -- backup works / install from v2 broken
v2 - Menu Select Added
v1 - Initial Release
MTK-64bit_SoCs
v8 - attempts to fix unrelated menu/alert
v7 - calculations done quicker
v6 - script rewrite/reorder
v1 - v5: Initial test builds​
Only follow menu Partition Related -> Scatter Information
Other menus/option are broken/dead ends...
Other things in the MTK folder:simg2img/img2simg are arm source compiled binaries to handle sparse files
file/magic were taken from @osm0sis's AIK (I can't seem to get file to compile)
MTKsplit is used to split boot/recovery images into it's individual parts. Normal images will split into 3; 1 = img ANDROID! header, 3 = kernel (zImage) and 5 = ramdisk (ramdisk). MTK images split into 5; 1,3,5 as before with 2 and 4 being additional headers.​
XDA:DevDB Information
TWRP/AROMA SPFlasher, Tool/Utility for all devices (see above for details)
Contributors
HypoTurtle
Source Code: https://drive.google.com/open?id=0B8WPOq9wZyKxfktHVWgxbW9nYmtJd1ZWc2RIM1NXUU5pSXpramg0bVBYYUdyRDhid3hwM3c
Version Information
Status: Testing
Current Stable Version: V8
Stable Release Date: 2015-09-03
Created 2015-09-03
Last Updated 2015-09-03

Current StatusMTK-64bit_SoCs-v8 .zip will output the partitions that it deems are incorrectly sized in the scatter.txt and will also check the .img/.bins in the SPFlash folder and determine what should go where and will determine if the partition is large enough for the respective .img/.bin
SPFlash-v1.zip will flash the entire contents of /sdcard/SPFlash folder
SPFlash-v3.zip allows selection of files /sdcard/SPFlash folder to install and has a backup option​
Improvements NeededFor SPFlash-v2 will add a basic menu select option for what you want to flash...
In future versions will add backup option and partition resize
Will start to look at resize...​

Derivative Work - using scatt and part from #1
ScatterfixGenerating a fixed scatter from a 'broken one'
Code:
[size=1]#!/sbin/sh
ldr=`pwd`
scatterfix(){
scatt \${b} \${c} \${d}
part \${p} \${q} \${r}
scttrbfr=`cat "${scatterloc:-$ldr}/scatter.txt"`
while IFS=" " read -r a b c && read -r d e f <&3; do
if [ $a = $d ]; then
if [[ ! ${b} = "DONT_USE" && ${b} != ${e} ]]; then
scttrafter="${scttrbfr//${b}/${e}}"
scttrbfr=`echo "${scttrafter}"`
fi
if [[ ! ${c} = "DONT_USE" && ${c} != ${f} ]]; then
scttrafter="${scttrbfr//${c}/${f}}"
scttrbfr=`echo "${scttrafter}"`
fi
fi
echo "${scttrbfr}" > ${scatterloc:-$ldr}/scatter-new.txt
done </tmp/scatter 3</tmp/parted-new
}
scatterfix
diff ${scatterloc:-$ldr}/scatter.txt ${scatterloc:-$ldr}/scatter-new.txt[/size]
Problems to fixThe code will change any hex value deemed wrong to a new calculated value - there is a chance that 4 values are the same but only one/two are wrong - to fix will need to add a loop through scatterfix until the scatter-new.txt generated is actually correct.​​Resize Userdata/IntsdMore of a precursor - bugs fixed and maintained by @odigitech
Thread located here​

Some Dev. QuestionsBefore adding the resizing partitions (Firmware Upgrade) option:
1. Is the preloader header custom or generic; and does it change when flashing the proloader?
2. Is there an actual function to the BPLGU/APDB files other than some sort of device/system check?​

For v7 trying to add a backup + make installable zip option:
Have done it with basic dd backups; would prefer to use sparse/simg2img but simgimg can't seem to use zipped .img's; have looked into using dat/sdat2img but that would require getting python to run in recovery (unless I'm mistaken).

Have added the simplistic option as v7...

odigitech said:
@HypoTurtle I have made a modified version of MTKsplit with more human-friendly names, its in my Drive folder, if it's any use.
Click to expand...
Click to collapse
Thanks, I have updated mine to support non-MTK header-ed boot/recovery.imgs -- can't hurt to make it human readable I suppose.
MTKsplit will be used in the next uploaded version (v8) in the form of a simplistic porting tool...
Should be uploaded on Monday/Tuesday

odigitech said:
You made it work for non-MTK also? Nice one, is it on your Drive?
Sent from my thl 2015 using XDA Free mobile app
Click to expand...
Click to collapse
Should be... but I'll update it with the human-readable version now.
It's not vigorously tested; and not as robust as the (un)mkbootimg binaries out there but it seems to do the job.

@HypoTurtle: on my Jiayu s3, the Germans have been working on android 5.1.1 for it and so far it is great. I installed beta 3 and the next day they released beta 4. Rather then getting out the laptop, I thought I'd use your script, so I got the files needed, I got your script and set it up as the instructions. But when I ran the script, it didn't find the system.img file, and didn't give it to me as an option. I verified that the file was there on disk, but I was never given a check box to select it for flashing. Any logs I can send you to try and figure out why?
Sent from my KFTHWI using XDA Premium 4 mobile app

AlexZap said:
@HypoTurtle: on my Jiayu s3, the Germans have been working on android 5.1.1 for it and so far it is great. I installed beta 3 and the next day they released beta 4. Rather then getting out the laptop, I thought I'd use your script, so I got the files needed, I got your script and set it up as the instructions. But when I ran the script, it didn't find the system.img file, and didn't give it to me as an option. I verified that the file was there on disk, but I was never given a check box to select it for flashing. Any logs I can send you to try and figure out why?
Sent from my KFTHWI using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Is it just the system.img that doesn't appear? And are you using internal or external SD?

HypoTurtle said:
Is it just the system.img that doesn't appear? And are you using internal or external SD?
Click to expand...
Click to collapse
Just system.img, and external_sd
Sent from my KFTHWI using XDA Premium 4 mobile app

AlexZap said:
Just system.img, and external_sd
Sent from my KFTHWI using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Can you post the scatter; the menu items are just an existence check.
[ if *.img/*.bin from scatter exists in SPFlash folder then you are given the option to flash it ]
(Just noticed that it will stall if you try and install and there are no valid img/bin files present)

HypoTurtle said:
Can you post the scatter; the menu items are just an existence check.
[ if *.img/*.bin from scatter exists in SPFlash folder then you are given the option to flash it ]
(Just noticed that it will stall if you try and install and there are no valid img/bin files present)
Click to expand...
Click to collapse
Screenshot of the folder, and the scatter. I checked it and it looked fine.

AlexZap said:
Screenshot of the folder, and the scatter. I checked it and it looked fine.
Click to expand...
Click to collapse
Ah yes - this problem is caused by the amount of items shown - I have it set to show 3, 5 or 12. It will only show 12 (more than 5) if there are 12 things to flash. From your screenshot you have 7 items to be flashed (trustzone gets flashed twice), so you will miss two items - the second flash of trustzone.bin and system.img.
Hope that makes sense; I can alter it to work with 6+; but you should be able to adjust it to work as described above. the reason I did it this way was that otherwise it would look a bit messy - I suppose I could add a 7 option.

HypoTurtle said:
Ah yes - this problem is caused by the amount of items shown - I have it set to show 3, 5 or 12. It will only show 12 (more than 5) if there are 12 things to flash. From your screenshot you have 7 items to be flashed (trustzone gets flashed twice), so you will miss two items - the second flash of trustzone.bin and system.img.
Hope that makes sense; I can alter it to work with 6+; but you should be able to adjust it to work as described above. the reason I did it this way was that otherwise it would look a bit messy - I suppose I could add a 7 option.
Click to expand...
Click to collapse
Ahhh... Not a. Problem then. I don't really need to flash anything besides system and boot. I just included the rest for completness. I'll take one out and let you know how it goes.
On a side note, any reason for these (3, 5, and 12)? An not just everything that is there?
Sent from my JY-S3 using XDA Premium 4 mobile app

HypoTurtle said:
Some Dev. QuestionsBefore adding the resizing partitions (Firmware Upgrade) option:
Q1. Is the preloader header custom or generic; and does it change when flashing the proloader?
Q2. Is there an actual function to the BPLGU/APDB files other than some sort of device/system check?​
Click to expand...
Click to collapse
A1 - Generic, MTK preloader has been the same since armv7 to armv8. Yes, dd backup copy needs to be clean up of the header & footer, more info then checkout with AlexZap... :good:
A2 - Not all MTK firmware include it, it contains the IMEI refer to here for more info or a single link that explained everything... :good:

AlexZap said:
Ahhh... Not a. Problem then. I don't really need to flash anything besides system and boot. I just included the rest for completness. I'll take one out and let you know how it goes.
On a side note, any reason for these (3, 5, and 12)? An not just everything that is there?
Sent from my JY-S3 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Not sure if you missed the edit. It was more for cosmetic reasons - I could have had say 12 files being displayed but if there's only one file to flash you would have a screen with a lot of blank entries. 3, 5 and 12 seemed the most appropriate without going down the route of creating a menu for all possible entries.
3 being typical install (system/boot and perhaps blank cache/userdata to wipe); 5 as 3 but with custom etc.
I figured that anyone with more than 5 flashable items in there would have dumped the entire SPFlash ROM which I calculated as ~12 items.
yuweng said:
A1 - Generic, MTK preloader has been the same since armv7 to armv8. Yes, dd backup copy needs to be clean up of the header & footer, more info then checkout with AlexZap... :good:
A2 - Not all MTK firmware include it, it contains the IMEI refer to here for more info or a single link that explained everything... :good:
Click to expand...
Click to collapse
A2. I don't thing it contains the IMEI - but it is the database that the IMEI is coded against; I'm not aware of any devices (other than the P6000) suggesting that you recode the IMEI on an upgrade from KK to LP so there is probably not an issue here.

i never use it myself, typically MDRT is able to recover it on mine, feedbacks from fellow XDA member is that, that is the only way that they manage to recover IMEI on their MTK...
On 2nd thought, BTW, i'm using intel nowadays :laugh: IMEI & calibration info is at a hidden partition, same as Samsung & Qualcomm devices that reside at /efs partition, how did MTK IMEI survive Factory Reset since it is at /data/nvram, i wonder, never really thought about it...

yuweng said:
i never use it myself, typically MDRT is able to recover it on mine, feedbacks from fellow XDA member is that, that is the only way that they manage to recover IMEI on their MTK...
On 2nd thought, BTW, i'm using intel nowadays :laugh: IMEI & calibration info is at a hidden partition, same as Samsung & Qualcomm devices that reside at /efs partition, how did MTK IMEI survive Factory Reset since it is at /data/nvram, i wonder, never really thought about it...
Click to expand...
Click to collapse
On the 64bits at least it is also on a hidden partition (nvram) - and it just gets copied to /data/nvram or something (ie. its not mounted but it's files are there). The DB files etc are present in /system as well as in the full SPFlash ROM so I guess things like MTKEng and apps like chamelephon use that when setting/'fixing' the IMEI.
What are the file formats used by intel stock ROMS? This tool isn't really MTK dependant - it's GPT partition dependant (with a scatter for validity check- I'll post a bear minimum of what a 'scatter.txt' needs to have).
Anyway v8 added - so that files to flash aren't hidden (max. 12 files).

Hmm, further digging seems MTK IMEI is at /dev/nvram, same thing happening on intel, users just never spell out everything, they use the format/ erase flash/ emmc that wipes out the IMEI partition but never tell...
i think on the X3, its not possible as its NOT an Android image file but proprietary fls file which they got it when they acquire infineon i think...
Manual fastboot/ dd backup/ restore & you'll end up with a brick device, ATM, no custom recoveries that boot on the x3, i haven't figure out how to repack its recovery that has three separate different region that requires three proprietary download file that packs it together into a fls file & only their FlashTool_E2 is able to download it correctly...
Can't really understand infineon/ intel for developing such cheap device but with such high end software tools...

[PX5][Android 10] Patched recovery

This is the Android 10 recovery image by HCT (version 10.3.1) patched to skip signature checking on .zip files
Tested on MTCE_LM (Eunavi). Use at your own risk
It can be flashed from a root shell (either adb or via terminal emulator) by performing the following steps
1. upload recovery via adb
Code:
adb push hct_recovery_patched.img /sdcard/
2. flash recovery
Code:
# backup current recovery
dd if=/dev/block/by-name/recovery of=/sdcard/recovery_backup.img
# write new recovery
dd if=/sdcard/hct_recovery_patched.img of=/dev/block/by-name/recovery
NOTE: If you do not disable the "flash_recovery" service in /init.rc, AND you have a stock kernel, recovery will be restored to the original version after rebooting.
There are 3 ways to avoid this:
- Flash magisk (or a modified kernel) while in recovery. The patch will then fail to apply and recovery won't be overwritten
- Disable "flash_recovery" by doing "adb remount" and editing /init.rc (comment out the following)
Code:
service flash_recovery /system/bin/install-recovery.sh
class main
oneshot
- Neuter the service by either:
- removing /system/bin/install-recovery.sh​- replacing /system/bin/install-recovery.sh with a dummy script​- removing /system/recovery-from-boot.p​

Woo-hoo, after hundreds of rubbish posts in the MTCD forums, we have a real development post!
Great work and thanks for sharing this, these forums need more like you.

Thanks for the kind comment!
I have to admit that it was frustrating to see the lack of information sharing on this forum, and the pervasive pay-per-use model.
I spent a lot of time just getting Android 10 installed (starting from Android 9), and i had to bring the head unit to my desk as working in the car was rather hard and all i achieved was a brick.
I unfortunately had to bring it back in the car now (can't sit on my desk forever) but, now that i figured out how to make bootable recoveries, i was wondering how hard it could be to have TWRP or at least a hassle-free recovery to install Android 10 from Android 9.
As a first step, this recovery makes it possible to install Magisk or other zip files without doing it manually within adb.
Cheers!

Your work is really good!
Thanks a lot for it.
Now you can also modify ROM's without signatur errors when installing.
Wouldn't it be good if we had an app like the ModInstaller ?
So a one click installation of the recovery without shell or adb.

I have now built an app.
And now need help.
Namely, in the app is the recovery and the script.
Unfortunately, the flash process is not started.
It always comes only the first message from the script.
The app is open source and the script and the recovery are in res/raw.
In the attach you will find the finished app and pictures.
If someone has a solution, he can write me or make a pull request on Github.
Source code:
GitHub - jamal2362/RK33XX-Custom-Recovery-Installer: Application for flashing custom recovery on Rockchip Android Head-Units.
Application for flashing custom recovery on Rockchip Android Head-Units. - GitHub - jamal2362/RK33XX-Custom-Recovery-Installer: Application for flashing custom recovery on Rockchip Android Head-Units.
github.com
The script:
RK33XX-Custom-Recovery-Installer/script at master · jamal2362/RK33XX-Custom-Recovery-Installer
Application for flashing custom recovery on Rockchip Android Head-Units. - RK33XX-Custom-Recovery-Installer/script at master · jamal2362/RK33XX-Custom-Recovery-Installer
github.com

First of all, congrats for the work!
DISCLAIMER:
I don't own ModInstaller, i have never bought a copy of it and i don't intend to do so.
Analysis is purely done from Youtube videos, open source code analysis and existing and openly available binary images.
I was working to figure out how to make a FLOSS alternative to ModInstaller.
The issues i found in all my attempts are the following:
- A6 recovery is the only one that can boot from SD Card (which can then be used to flash A9 -> A10 with the 2SD trick)
- (it took me a long time to pull these information together and unbrick my unit)​- The A6 recovery is unable to directly flash A10 RKAF/RKFW images (sdupdate.img) due to the code being too old
- a failure will be observed while writing super.img. This happens because the device needs to be repartitioned, and the A6 recovery is not doing it correctly​- A9 recovery is buggy. Booting it with no system installed will result in a black screen.
- it will only boot succesfully after being written by the A6 flash tool, which writes the "misc" partition with the recovery commands to run (the "hint" i get from this is that the misc partition is important)​- A10 recovery can't be loaded by the A6 recovery. I always got a black screen after flash. Is it a flash issue? is it an issue with the recovery itself? hard to know
Theory: maybe the recovery could be written over the kernel partition? ("boot")
This way, the recovery will always run after being flashed instead of requiring an explicit "enter recovery" trigger (buttons, misc partition, etc.)
Besides these experiments, in parallel, i did some bug fixing to this repository: https://github.com/liftoff-sr/rockchip-tool/commits/master (i'm "smx-smx")
That allows me to unpack nad repack "sdupdate.img" , "reduced recovery images" and "full IMG files".
With those tools. i tried to swap "recovery.img" in the A6 image, but i always got the black screen upon booting from SD.
Either A9/A10 breaks sdboot or the bootloader crashes before it gets there.
Since this also happens when being flashed, this could either be a bug in the flashing program or a bug in the boot stack (which fails to run recovery perhaps due to a dirty state of the internal flash). It's hard to know for sure without having a UART connection with the board.
BUT, we have an alternative, in the form of the recovery built-in ISP flash tool.
This is the code that reads "sdupdate.img" from the SD Card and flashes it
After reading the recovery source code, i realised that this code can only be triggered correctly when booting from the SD card.
It detects this state by reading /proc/cmdline and probing for specific values (https://github.com/rockchip-android...6f72b7d3123dab27135ac41d55029/sdboot.cpp#L206)
This means the bootloader can (and will) pass those arguments under specific conditions (https://github.com/rockchip-linux/u...c873f178c/arch/arm/mach-rockchip/board.c#L358)
If you check here https://github.com/rockchip-linux/u...3f178c/arch/arm/mach-rockchip/boot_mode.c#L47 you can see the magic word that needs to be written to the "misc" partition in order to trigger that code.
Note that, besides the well known "sdboot", "usbboot" is also possible.
I'm not sure if the ROM can physically boot from USB, but the bootloader and recovery do support (according to code) passing the flag to enable flashing from USB.
So, recapping, there are these ways we can try:
a - try to overwrite "boot" with "recovery" (but it might not work due to the partitioning layout, e.g. jumping from A6 -> A10)
- note: uboot might also need to be written when doing this.
b - making a modified "sdupdate.img" that flashes recovery on top of boot, and all the other core partitions like "misc", "uboot", "trust", "vbmeta"
c - writing "misc" from android in order to triggers the "rkfwupdate" mode
d - taking a dump of the first portion of the flash in various states (A6, A8, A9, A10), and having a "dd" that writes it back to the beginning of the flash (i suspect this is how ModInstaller does it)
Considering cases "b" and "c" depend on a recovery that can write them correctly (and the A6 one is buggy), this leaves us with "a" and "d"
Considering that ModInstaller does it in one shot, and doesn't seem to matter about the partitioning layout, i believe "d" might be the most viable option...
Using the "rockchip-tool" repository i linked from github, the partition table can be dumped from any .img file
You can observe "Image/parameter.txt" from the extracted firmware
This is the partition table from A6's recovery:
[email protected](uboot)
[email protected](trust)
[email protected](misc)
[email protected](resource)
[email protected](kernel)
[email protected](dtb)
[email protected](dtbo)
[email protected](vbmeta)
[email protected](boot)
[email protected](recovery)
[email protected](backup)
[email protected](security)
[email protected](cache)
[email protected](system)
[email protected](metadata)
[email protected](vendor)
[email protected](oem)
[email protected](frp)
[email protected](userdata)
And this is the partition table from A9's recovery
[email protected](uboot)
[email protected](trust)
[email protected](misc)
[email protected](resource)
[email protected](kernel)
[email protected](dtb)
[email protected](dtbo)
[email protected](vbmeta)
[email protected](boot)
[email protected](recovery)
[email protected](backup)
[email protected](security)
[email protected](cache)
[email protected](system)
[email protected](metadata)
[email protected](vendor)
[email protected](oem)
[email protected](frp)
[email protected](userdata)
Notice how uboot, trust, misc, resource, kernel, dtb, and others live in the same space. (2000, 4000, 6000, 8000, 10000, ...)
What we could do is create a raw blob that spans that address range, and "dd" it directly to /dev/mmcblk0 at the right offset.
So i would focus on converting recovery images to raw blobs, with recovery-as-kernel so it boots straight away on the first try.

Bump a real thread.

Is it possible to convert it to a file installed by SDDiskTool?

marchnz said:
Bump a real thread.
Click to expand...
Click to collapse
I created a flashing tool to flash recovery within Android, using Rockchip's own code: https://forum.xda-developers.com/t/...chip-firmware-flash-tool-for-android.4458299/

blala said:
I created a flashing tool to flash recovery within Android, using Rockchip's own code: https://forum.xda-developers.com/t/...chip-firmware-flash-tool-for-android.4458299/
Click to expand...
Click to collapse
This file hct_recovery.patched.img does not appear to be installed via rkupdate

sadaghiani said:
Is it possible to convert it to a file installed by SDDiskTool?
Click to expand...
Click to collapse
It needs to be converted, yes
I'll take a look this afternoon

blala said:
It needs to be converted, yes
I'll take a look this afternoon
Click to expand...
Click to collapse
Is it possible to create a boot image that includes moded recovery & magisk and moded kernel ?

If by image you mean firmware image then yes, it can be done with https://github.com/liftoff-sr/rockchip-tool
But what i would recommend is the modded recovery only, with the magisk .zip to use in Recovery
Otherwise you risk flashing a kernel that doesn't match with kernel modules or is otherwise not fully compatible with the installed system

blala said:
If by image you mean firmware image then yes, it can be done with https://github.com/liftoff-sr/rockchip-tool
But what i would recommend is the modded recovery only, with the magisk .zip to use in Recovery
Otherwise you risk flashing a kernel that doesn't match with kernel modules or is otherwise not fully compatible with the installed system
Click to expand...
Click to collapse
boot.img file included recovery+magisk+kernel

Flashing a boot.img (Kernel, for example) in an Android mobile phone via adb shell
Flashing a boot.img (Kernel, for example) in an Android mobile phone via adb shell - script.sh
gist.github.com

MTCD has separate boot and recovery partitions.
Perhaps you can adapt both recovery/kernel to be in the same image but the bootloader won't know about that (and will always boot from "recovery" partition)