Related
With the advent of Blackrose custom HBOOT which gives us S-OFF, we can now resize the MTD partitions of our N1. This method is the one used by lbcoder in the Desire thread where you patch the recovery and boot in order to pass modified MTD partition information which supersedes the one provided by the SPL. Using this, I've managed to increase my userdata partition by ~50 MB by taking ~50 MB from the cache partition.
These instructions are for advanced users only. This will involve hex calculations and command line instructions that are not for the faint of heart. I don't believe it's dangerous though so anyone could still try since I will try to make these instructions as detailed as I possibly can.
What you need:
N1 with Blackrose HBOOT (I'm not sure this is needed though after I read more in-depth about the patch)
hex calculator (or a pencil & paper if you want to do it manually)
adb
fastboot
unpack-bootimg.pl
mkbootimg
recovery.img <- in my case I used ClockWorkMod 5.0.2 from here
boot.img <- taken from CM zip (in my case my KANG)
Partition Layout:
0x000003ee0000-0x000003fc0000 : "misc"
0x000004240000-0x000004640000 : "recovery"
0x000004640000-0x0000049c0000 : "boot"
0x0000049c0000-0x00000dac0000 : "system"
0x00000dac0000-0x0000139c0000 : "cache"
0x0000139c0000-0x00001fe00000 : "userdata"
Partition Sizes in Hex:
0x0000000e0000 : "misc"
0x000000400000 : "recovery"
0x000000380000 : "boot"
0x000009100000 : "system"
0x000005f00000 : "cache"
0x00000c440000 : "userdata"
Step-by-step Instructions:
A>Backup your current system: (OPTIONAL)
*I'm assuming you're using CWM 5.0.2 for the backup step since I tried using 3.X and the restore didn't work
1.) Boot your N1 into recovery using either adb reboot recovery or through the bootloader
2.) Backup your current system (I'm going to assume you know how to use your recovery for this)
B>Calculate new MTD parameter values:
*For this example I'm going to transfer ~50MB of cache space to my userdata partition:
1.) Since I know the cache partition is ~100MB in size, I'll just divide the hex size in 2:
0x5f00000 / 2 = 0x2f80000 <= this will be our new cache size
**Note that there is a minimum of 0x20000 (128k) for a partition and the size must be divisible by it which is why I'm playing safe and just dividing the original number in order to get an easier value for this example.
2.) Add the new cache partition size to the original cache partition starting address to get the new starting address of the userdata partition:
0xdac0000 + 0x2f80000 = 0x10a40000 <= this will be the new starting address for userdata
3.) Get the new userdata size by subtracting the new starting address of userdata with the ending address:
0x1fe00000 - 0x10a40000 = 0xf3c0000 <= this will be the new userdata size
C>Create a new recovery.img file which uses the new values:
1.) Breakdown the recovery.img file into it's kernel and ramdisk components using unpack-bootimg.pl:
.\unpack-bootimg.pl recovery.img
*This will yield 2 files and 1 directory. You can delete the directory since we only need the files.
2.) Rename the kernel from the recovery.img-kernel.gz made from unpack-bootimg.pl to recovery.img-kernel.
3.) Create the recovery-new.img file using mkbootimg with the new MTD command embedded:
mkbootimg --cmdline 'no_console_suspend=1 console=null mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)' --kernel recovery.img-kernel --ramdisk recovery.img-ramdisk.cpio.gz -o recovery-new.img --base 0x20000000
*Note that the values for cache starting address, userdata starting address and userdata size have been changed to the newly calculated values in the previous step.
**This will yield recovery-new.img which will be used in the next steps.
D>Create a new boot.img file which uses the new values:
1.) Breakdown the boot.img file into it's kernel and ramdisk components using unpack-bootimg.pl:
.\unpack-bootimg.pl boot.img
*This will yield 2 files and 1 directory. You can delete the directory since we only need the files.
2.) Rename the kernel from the boot.img-kernel.gz made from unpack-bootimg.pl to boot.img-kernel.
3.) Create the boot-new.img file using mkbootimg with the new MTD command embedded:
mkbootimg --cmdline 'no_console_suspend=1 wire.search_count=5 mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)' --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz -o boot-new.img --base 0x20000000
*Note that the values for cache starting address, userdata starting address and userdata size have been changed to the newly calculated values in the previous step.
**This will yield boot-new.img which will be used in the next steps.
E>Flash the recovery-new.img:
1.) Boot into bootloader and use fastboot command to flash the new recovery:
fastboot flash recovery recovery-new.img
F>Make system operational:
1.) Boot into recovery mode.
2.) Erase everything (factory reset)
3.) Either:
- Flash the ROM you took the original boot.img from OR
- Restore the backup you made previously (this only works (or has been tested) on CWM 5.0.2)
4.) DO NOT REBOOT YET!!!
G>Flash modified boot.img:
1.) Use adb to reboot to bootloader directly from recovery: (this is for safety since if you boot from an unmodified boot.img you'll have to start from F again.
adb reboot bootloader
2.) Use fastboot to flash the new boot image:
fastboot flash boot boot-new.img
3.) You may restart normally.
For those who've read this far, everything above has been rendered obsolete! Here's an editor for the SPL itself for the partition sizes:
http://intersectraven.euroskank.com/tools/SPLHexEditor.exe
*Instructions are in dla5244's thread 2nd post.
Try it at your own risk though!
Credits:
dla5244 - for bringing S-OFF to our N1 even after a looong time since its release
Firerat - for the original patch idea
Lbcoder - for coming up with the idea in the Desire thread
Reserved!
(I'm learning to reserve now... )
2 Questions:
Is the userdata space where downloaded apps go?
why didn't you choose any other partition to transfer empty space from?
drzplaya1121 said:
2 Questions:
Is the userdata space where downloaded apps go?
why didn't you choose any other partition to transfer empty space from?
Click to expand...
Click to collapse
1.) Yes.
2.) This is a sample. If you want to transfer from system or to system from cache, this example will show you how to do so.
thank U. Now I have no need to buy a new phone because of constantly running out of memory
Does it mean that every time I flash a new kernel, the whole effort will go waste?
Also, can I use the same procedure for Amon RA recovery??
rjmohit said:
Does it mean that every time I flash a new rom (which obviously has a different boot.img), the whole effort will go waste?
Also, can I use the same procedure for Amon RA recovery??
Click to expand...
Click to collapse
For that you need to do only steps D, F and G. If you flash only a kernel which uses koush's anykernel updater, you don't need to do anything.
intersectRaven said:
For that you need to do only steps D, F and G. If you flash only a kernel which uses koush's anykernel updater, you don't need to do anything.
Click to expand...
Click to collapse
Thanks.
One more silly question
Will the following procedure work.
1. Flash any ROM.
2. Then flash the modified boot.img (which may not belong to that ROM).
3. Then optionally flash the desired kernel.
rjmohit said:
Thanks.
One more silly question
Will the following procedure work.
1. Flash any ROM.
2. Then flash the modified boot.img (which may not belong to that ROM).
3. Then optionally flash the desired kernel.
Click to expand...
Click to collapse
Yeah. That would work since you're replacing the kernel anyways. What's important is that the kernel is compatible with the ROM.
Well done IR cannot wait to resize my data partition..
Okay, I extracted the recovery.img file, now when I try to extract recovery.img-kernel.gz, it gives the following error: not in gzip format. Exactly same happens for boot.img. I tried extracting it with different extractors on windows and ubuntu, nothing worked. Pls help.
I don't like using MTD because over time you will notice lag. If your already using sd-ext then your data is basically not being used. And I believe that cache never gets past 50% usage. Just putting in my two cents
rjmohit said:
Okay, I extracted the recovery.img file, now when I try to extract recovery.img-kernel.gz, it gives the following error: not in gzip format. Exactly same happens for boot.img. I tried extracting it with different extractors on windows and ubuntu, nothing worked. Pls help.
Click to expand...
Click to collapse
That's odd. In my installation, it worked flawlessly. Were there no errors during the run of unpack?
blahbl4hblah said:
I don't like using MTD because over time you will notice lag. If your already using sd-ext then your data is basically not being used. And I believe that cache never gets past 50% usage. Just putting in my two cents
Click to expand...
Click to collapse
intersectRaven said:
That's odd. In my installation, it worked flawlessly. Were there no errors during the run of unpack?
Click to expand...
Click to collapse
Nope. No errors. :-/
rjmohit said:
Nope. No errors. :-/
Click to expand...
Click to collapse
Found the problem. It seems it was never compressed in the first place. Ark sees this and just copies the file without the .gz extension.
*Instructions edited accordingly.
I may sound a bit noobish, but I'm facing one more hindrance:
How exactly do I run the mkbootimg file in the ubuntu terminal? I mean, can you give me the exact syntax?
I was facing a similar problem with the perl script, but then I found a solution on google, but didnt find anything for the mkbootimg. Can I run it under windows cmd?
rjmohit said:
I may sound a bit noobish, but I'm facing one more hindrance:
How exactly do I run the mkbootimg file in the ubuntu terminal? I mean, can you give me the exact syntax?
I was facing a similar problem with the perl script, but then I found a solution on google, but didnt find anything for the mkbootimg. Can I run it under windows cmd?
Click to expand...
Click to collapse
I already posted the syntax in the instructions. You just need to make sure the mkbootimg file has execute permissions in order for it to run.
Updated OP with SPL editor program.
intersectRaven said:
Updated OP with SPL editor program.
Click to expand...
Click to collapse
I tried your program. Everything worked fine. Just that my /cache now shows 290 MB free, while I had resized it to 20 MB!! Is that a bug? /system & /data show proper sizes though. thanks.
rjmohit said:
I tried your program. Everything worked fine. Just that my /cache now shows 290 MB free, while I had resized it to 20 MB!! Is that a bug? /system & /data show proper sizes though. thanks.
Click to expand...
Click to collapse
Is it the display on the program or display on the Android device when booted?
Wait, I found it. It's a bug. Thanks! I'll edit it when I get home. For now, please double check the values by reopening the made file before flashing. If the values are incorrect, please DON'T FLASH!!!
is there a possibility, both the stock Archos firmware to root and also with a boot menu such as OpenAOS to use.
Need to control both the floor on my A70H firmware with root right and as a second OS Debian Linux to the possibility of the software with a panoramic head Papywizard.
The Debian Linux I've done and it works flawlessly under OpenAOS, but unfortunately I have no right under Android Root.
Have also been tested UrukDroid, unfortunately, it works with the boot of an Alternative OS will not therefore have already contacted the developer of UrukDroid, unfortunately without positive result.
Sorry for my bad English.
Best regards
kwalter
Multiboot for OpenAOS works the same as Chulris Root but not for the last FW.
So if you want Root and Linux you have to downgrade the Archos to 2.3.81.
Ich you then boot through the Multiboot menu and select Android, you have root.
fzelle said:
Ich you then boot through the Multiboot menu and select Android, you have root.
Click to expand...
Click to collapse
Doesn't this also work with the latest firmware, because openaos multiboot uses unionfs to create an overlay over the archos firmware to give you read write access, su and superuser.apk.
I didn't upgrade, because of lack of time, it is still on my todo list.
Maurice
Do you think that your Kernel and InitRam is 100% compatible with the new FW?
P.S.: Any news on cm7?
Well there are only minor changes in the kernel from the latest firmware, so I guess it would be no problem to boot the new firmware with the openaos kernel.
However like I said I didn't try it myself yet, so that is why I asked if there are problems.
PS CM7:
For CM7 we have made good progress. However we have to wait until bubu has some time to finish the new unified multiboot menu for gen7 and gen8. In the mean time we are still improving CM7.
To get an impression on the progress just look at closed tickets and the commits on our git.
Maurice
openAOS A70H
hi,
can anyone help me?
i've created a ext4 partition on my A70H 250GB Harddisk with 50GB space.
On this partition i've put the Imagefiles for debian etc., what is the correct entry in menu.lst
to boot debian or other os from openAOS Bootmenu.
On Android over openAOS, fdisk say it is sda2.
When i put the following entry on Menu.lst it will not boot Debian etc. only Android boots correct:
Archos|ARCHOS|ARCHOS|/init|0
Debian|/dev/sda2|/rootfs.debian|/sbin/init|1
Angstrom|/dev/sda2|/rootfs.angstrom|/sbin/init|1
Gingerbread|/dev/sda2|/gingerbread.img|/init|0
or
Archos|ARCHOS|ARCHOS|/init|0
Debian|/dev/block/sda2|/rootfs.debian|/sbin/init|1
Angstrom|/dev/block/sda2|/rootfs.angstrom|/sbin/init|1
Gingerbread|/dev/block/sda2|/gingerbread.img|/init|0
What is the correct path to the second partition on openAOS Boottime??????
Sorry for my bad english.
Best regards
kwalter
It depends how your partition shows up in initramfs. To find out you could try serial debugging.
You can enable serial debugging in the boot menu by going to advanced menu and select Debugging then choose serial.
When your device is connected to your pc you can use minicom to get a shell on initramfs.
This is all explained http://dev.openaos.org/wiki/SettingUpMultiRootGen8#Debugging
In the initramfs shell you can see how your partition shows up by using "df" or looking at /dev etc.
However the way you want it doesn't work, you have to create a partition for each image file and unpack that image file on that partition. Partition booting is meant to get rid of image files.
Maurice
openAOS A70H
Hi,
sorry, but I do not understand.
If the image files I in the storage directory and the menu.lst like this I can change the whole boot without problems:
Archos | Archos | Archos | / init | 0
Debian | | / rootfs.img | / sbin / init | 1
Angstrom | | / angstrom.img | / sbin / init | 1
Gingerbread | | / gingerbread.img | / init | 0
Whether floor Archos firmware, Gingerbread, Angstrom or Debian, everything works 100%.
Unfortunately, I have 4GB but only for my Debian image since FAT file system.
Best Reagards
kwalter
You could change internal storage to ext3 to overcome the filesize problem.
However when you want to boot your image file from a different partition then you don't copy the image file to that partition, but you copy the contents of the image file to that partition. That is why you need a different partition for each image file.
In the multiboot menu we only loop mount image files from internal storage and not from other partitions. From other partitions they will be directly "booted" and not loop mounted first.
So what you can do is on your pc create a folder say /temp/mount/debian
Then you do the following:
Code:
$ sudo mount -o loop (path_to_where_your_archos_is_mounted)/rootfs.img /temp/mount/debian
This will mount your image file on the folder /temp/mount/debian
Then copy everything to your created partition on your archos using -rp option for recursive and preserve rights on the files.
Code:
$ sudo cp -rp /temp/mount/debian/* /(partition_on_your_archos)
After that adjust the menu.lst like you did before.
Maurice
Multiboot and root for A70H - Bluetooth
Hello at all,
so now I've finally managed to boot the Debian from a separate partition with openAOS.
But now comes the next problem, Bluetooth works
not more.
In the image it has worked reasonably clean, but once I
openAOS've installed boot menu does not work anymore.
Both the image and also on the partition, when I try to connect a Bluetooth device, gets out Blutooth.
(Only the devices, thats need a PIN for connection, all other devices are OK.)
Is there a solution?
Hope that someone can help me.
Best regards
kwalter
I did look at suggested threads and nothing seemed to be answered not using just ADB with root provided by TWRP, everything was using TWRP recovery UI
I have a LeEco Le S3 (X522) running stock
Code:
Android Version: 6.0.1
EUI Version: 5.8.018S (Stable)
Build: IFXNAOP5801810091S release-keys
but I feel this is irrelevant as this is a general question.
What I have done so far.
Code:
cat proc/partitions
and backed up the output using just
Code:
> sdcard/<name_of_command_&_args>
same for
Code:
df
and
Code:
mount
and finally
Code:
ls dev/block/xxx/byname
you can see the output of those here /anonymous/5a2bb0a231a58b8842036bb5c82d016a gist on github
and then I used DD to backup partitions to IMGs on sdcard/ for aboot, boot, misc, sbl1, recovery and system (I also used TWRP to do the same to just cover it)
then copied those images and backups off using adb pull, is that all I need to do to recover to stock,
aka am I missing anything? partition table perhaps in case that gets stuffed up too?
Hello guys,
I have a Ulefone Be Touch 2 (with a MT6752 cpu) that only boot and stay on the ulefone logo, and I can't install any ROM (official or custom ones)...
In fact, the tools (latest SPFlashTool v5.1628 and the one provided by ulephone I used successfully earlier) do the download process until 100% without error message, but the only thing that seems to be on the phone (and working) is the recovery.
With this two softwares I am able to install the official recovery or TWRP (2.8.7.0 from needrom), and they both are usable.
But when I try to do something in recovery mod, it tells me that cache or system partitions (and others) are not mounted (or found).
In SPFlashTool, I tryed many features without success but I have (NAND and UFS) errors when doing memory tests :
#External RAM:
#
# Type = DRAM
#
# Size = 0x80000000 (2048MB/16384Mb)
#
#NAND Flash:
#
# ERROR: NAND Flash was not detected!
#
#EMMC:
#
# EMMC_PART_BOOT1 Size = 0x0000000000400000(4MB)
# EMMC_PART_BOOT2 Size = 0x0000000000400000(4MB)
# EMMC_PART_RPMB Size = 0x0000000000400000(4MB)
# EMMC_PART_GP1 Size = 0x0000000000000000(0MB)
# EMMC_PART_GP2 Size = 0x0000000000000000(0MB)
# EMMC_PART_GP3 Size = 0x0000000000000000(0MB)
# EMMC_PART_GP4 Size = 0x0000000000000000(0MB)
# EMMC_PART_USER Size = 0x00000003a3e00000(14910MB)
#
#UFS:
#
# ERROR: UFS was not detected!
I don't understand what it meens and how can I change the recovery if the NAND is gone? Are system partitions and recovery stored in different places/memory (types)?
I searched and read on differents thread (the UBT2 review, mtk6755 ERROR: NAND Flash was not detected by split52 , [GUIDE] How to 'unbrick' your Mediatek MT65xx...) and googled and watched related videos but didn't find anything than matches and can really help me.
So, if someone can help me I would really be grateful.
Thank you in advance.
I'm sorry if I post this thread in the wrong section (I think it's the first I creat).
sylkyls
I had a problem like your's when I walked all over my partition layout because of a botched flash. Didn't have UFS errors tho. No info anywhere. Had to verify my scatter file and recovery fstab layout agreed with each other. Ended up modifying my scatter file. Took it one partition at a time using the fstab until the recovery recognized all partitions then backed up my files, reformatted and flashed the stock rom using SPF Tools. Took a while to boot. After that, the original scatter file worked. Still don't make sense why it worked that way but it got me back working.
smith901 said:
I had a problem like your's when I walked all over my partition layout because of a botched flash. Didn't have UFS errors tho. No info anywhere. Had to verify my scatter file and recovery fstab layout agreed with each other. Ended up modifying my scatter file. Took it one partition at a time using the fstab until the recovery recognized all partitions then backed up my files, reformatted and flashed the stock rom using SPF Tools. Took a while to boot. After that, the original scatter file worked. Still don't make sense why it worked that way but it got me back working.
Click to expand...
Click to collapse
Thank you smith901,
I don't know how to do this: I can run a terminal into the recovery but if I do cat /etc/fstab or less /etc/fstab , I only have :
/system ext4 rw
/cache ext4 rw
/data ext4 rw
/external_sd auto rw
I think I'm doing the wrong way.
Could you tell me (or redirect me to) a method please?
Have a nice day
sylkyls
sylkyls said:
Thank you smith901,
I don't know how to do this: I can run a terminal into the recovery but if I do cat /etc/fstab or less /etc/fstab , I only have :
/system ext4 rw
/cache ext4 rw
/data ext4 rw
/external_sd auto rw
I think I'm doing the wrong way.
Could you tell me (or redirect me to) a method please?
sylkyls
Click to expand...
Click to collapse
Seems to be fstab problems.
Use whatever unpacking tool you are comfortable with to unpack the stock recovery and TWRP. Then replace your fstab files in the root and /etc directories after changing what you want, rw to /system or whatever. Modify the twrp.fstab file in /etc using the values from stock fstab. You might have to add in or replace your rc and mt6735 files also. Repack then flash. The log screen in TWRP will let you know what partitions can't be read. Choosing the correct encryption partition took some trial & error.
Once you get it all to read, the modified twrp.fstab, files in the unpacked stock recovery folder plus a device tree, and the TWRP building thread will get a recovery built by yourself as soon as you can sync from git.
smith901 said:
Seems to be fstab problems.
Use whatever unpacking tool you are comfortable with to unpack the stock recovery and TWRP. Then replace your fstab files in the root and /etc directories after changing what you want, rw to /system or whatever. Modify the twrp.fstab file in /etc using the values from stock fstab. You might have to add in or replace your rc and mt6735 files also. Repack then flash. The log screen in TWRP will let you know what partitions can't be read. Choosing the correct encryption partition took some trial & error.
Once you get it all to read, the modified twrp.fstab, files in the unpacked stock recovery folder plus a device tree, and the TWRP building thread will get a recovery built by yourself as soon as you can sync from git.
Click to expand...
Click to collapse
Thank you again, but I'm really sorry that I can't apply your instructions... ( unpacking with 7-zip does not give me any fstab file )
Could you try to do it with the official rom please? ( download link is in the bottom of this page: http://ulefone.com/download/betouch2.html , at the next step my phone needs the "option 2" rar file).
With custom roms (zip files flashable with a custom recovery or rar archive), I can unpack thems and obtain/open a fstab file ( recovery.fstab ) but not with things flashable with SPFlashTool.
sylkyls
sylkyls said:
Thank you again, but I'm really sorry that I can't apply your instructions... ( unpacking with 7-zip does not give me any fstab file )
Could you try to do it with the official rom please? ( download link is in the bottom of this page: http://ulefone.com/download/betouch2.html , at the next step my phone needs the "option 2" rar file).
With custom roms (zip files flashable with a custom recovery or rar archive), I can unpack thems and obtain/open a fstab file ( recovery.fstab ) but not with things flashable with SPFlashTool.
sylkyls
Click to expand...
Click to collapse
I meant an unpacking tool like Carliv Image Kitchen or Android Image Kitchen. I'm rarely this helpful so once I finish cleaning the carpet I'll have a look.
The recovery.fstab file look slim in this recovery but that is what they made.
Download Aindroid Image Kitchen.
Follow the instructions to unpack your stock recovery and TWRP recovery.
Make the changes you want. Copy needed files, /etc/recovery.fstab, fstab.mt6752 and probably the *.rc files from stock to TWRP. Just check everything to be sure.
Repack TWRP then flash.
I don't use Windows so I couldn't use the program provided in the archive.
sylkyls,
did you solve the issue? I have the same problem.
cmarqz said:
sylkyls,
did you solve the issue? I have the same problem.
Click to expand...
Click to collapse
Hello,
Sorry every one but I forgot to follow this thread as I had a lot of work and someone giave me another phone ( a samsung note 4 N910F) that I repared (and am using now) and then I did let my ulefone away from my priorities.
Sorry cmarqz but I didn't try the solution proposed by smith901 on my MTK6752 device.
Maybe I'll try it later.
Did you find a solution for your device?
Best regards XDA users.
What is the Touchpad Toolbox?
https://forum.xda-developers.com/showthread.php?t=2756314
A set of Scripts (programs) that allows:
Easily manage LVM, one of the greatest features of the TP.
https://wiki.archlinux.org/index.php/LVM
Create Android, WebOS volumens, or total reset.
It can make a fresh /boot directory installation adding moboot.
Reflash the battery Firmware
Install specific, older version of recovery and Rom.
How is done?
https://webos-internals.org/wiki/Angstrom_on_Touchpad
A small Linux OS is built into an img (ext2) file system and is loaded into memory as a RAMDisk.
Angstrom v2015.01
Built from branch: master
Revision: 038d832
Target system: arm-angstrom-linux-gnueabi
This information is from the file angstrom-version located in the /etc folder of the RAMDisk.
Following this instructions will unpack the RAMDisk and Kernel, then can be repack as it would with any Android system.
All this is done on Linux ubuntu 18.04 x64 system. If you have any other OS you can install Linux as a virtual machine.
1 .Create a directory
hptoolbox
2. Unzip TPToolbox-2015-01-08-v42.zip to the directory hptoolbox (http://downloads.codefi.re/jcsullins/cmtouchpad/tptoolbox/TPToolbox-2015-01-08-v42.zip
3. Open terminal in the hptoolbox directoty and paste the following commands.
Code:
dumpimage -i TPToolbox-2015-01-08-v42.bin uImage.kernel
dumpimage -i TPToolbox-2015-01-08-v42.bin -p 1 RAMDisk_Compress
dd if=RAMDisk_Compress of=RAMDisk.xz bs=64 skip=1
xz -d RAMDisk.xz
## The RAMDisk which is 67.1MB is a Linux rev 0.0 ext2 filesystem data img file.
4. Creat a loop disk to have read and write access of the RAMDisk
Code:
sudo udisksctl loop-setup -f RAMDisk
## Mapped file RAMDisk as /dev/loop16 (this is only on my system and it will be different on others)
5. Mount the 67 MB Loop Device, it can easly be done using Disks
6. Open your file manager as sudo in (my system is nautilus, it can be different on other Linux)
Code:
[email protected]:~$ sudo nautilus
[sudo] password for ubuntu:
7. The settings for the ToolBox are in /usr/tptoolbox.
You have complete control on all the files, but read what each script says on top:
Code:
# This script is Copyright (c) 2014 James Sullins, All rights reserved.
# James (JC) Sullins, aka jcsullins
# No modifications or distribution without permission
To repack the Kernel and RAMDisk
1. Unmount the RAMDisk img and Detach the loop device
2 Open terminal in the hptoolbox directory and paste the following commands.
Code:
mkimage -A arm -T ramdisk -C none -n RAMDisk -d RAMDisk uImage.RAMDisk
mkimage -A arm -T multi -C none -n "Tenderloin ToolBOX Modified" -d uImage.kernel:uImage.RAMDisk uImage.ToolBox_Modified
In my system I can not make RAMDisk using xz compression but it works uncompress is just a 70MB file.
If the RAMDisk is compress using (( xz -9 RAMDisk )) then the file size will be as the original but it will not be recognized by the kernel at boot.
3. To load using the novacom driver:
Code:
novacom boot mem:// <uImage.ToolBox_Modified
Many thanks to jcsullins for creating the ToolBox ,which allowed many users to easily transition to Android from WebOS and gave new life to a device that could have been in landfills many years ago. In my opinion this has been the greatest Tool for the TP and finding out how it works made it even more amazing!
HP_TOUCHPAD said:
What is the Touchpad Toolbox?
--SNIP--
Click to expand...
Click to collapse
You've done a great job figuring that out HP_TOUCHPAD! As a result, if Sullins agreed (assuming he would even answer the request), the TPToolbox could be modified fairly easily to handle the latest ROMS, GAPPS, and RECOVERIES. For example, it turns out that there is an unused parameter that would allow TPToolbox to install the zipfiles without any checks. Additionally, it is simple to bypass having to install a GAPPS with the ROM, or to keep all checks but the one that checks for a compatible GAPPS..
shumash said:
You've done a great job figuring that out HP_TOUCHPAD! As a result, if Sullins agreed (assuming he would even answer the request), the TPToolbox could be modified fairly easily to handle the latest ROMS, GAPPS, and RECOVERIES. For example, it turns out that there is an unused parameter that would allow TPToolbox to install the zipfiles without any checks. Additionally, it is simple to bypass having to install a GAPPS with the ROM, or to keep all checks but the one that checks for a compatible GAPPS..
Click to expand...
Click to collapse
Thank you, and yes the ToolBox can be modified very easily only if JSullins agreed.
But there is only one section that needs to be modified to update the toolbox and make compatible with all ROMS now and forever. In my opinion there is no need for the Toolbox to install any ROMS as that is the work of TWRP to do and it does it well.
This is the only modification that needs to be done to update the toolbox and make it useful forever!
In the folder toolbox/bin/make_boot (open the script)
add the following under this line : (do_run cp /usr/tptoolbox/data/moboot /mnt/boot/uImage.moboot)
Code:
do_run cp /usr/tptoolbox/data/uImage.TWRP /mnt/boot/uImage.TWRP
do_run cp /usr/tptoolbox/data/android.default.recovery /mnt/boot/android.default.recovery
do_run cp /usr/tptoolbox/data/moboot.default /mnt/boot/moboot.default
do_run cp /usr/tptoolbox/data/uImage.ToolBOX /mnt/boot/uImage.ToolBOX
copy the files to /usr/tptoolbox/data/
uImage.TWRP
android.default.recovery
moboot.default
uImage.ToolBOX (this is the toolbox.bin, renamed it to be loadable from the moboot menu.
save the script.
I do not need to tell you "the Linux Guru" what is going on, but just for the record.
When recreating the boot it will install TWRP into boot and also the ToolBOX.
Reboot and now you have TWRP and also the ToolBOX in the moboot menu and you can install any ROM using TWRP.
This will make it super easy for all users to start fresh!
Complete reset (it will install TWRP, recovery by default) nothing extra for the user to do!
Reflash battery firmare
Resize Android volumens
Reboot and install ROM
I do not think it can be any easier for anyone than this and the change is minimal!
HP_TOUCHPAD said:
Thank you, and yes the ToolBox can be modified very easily only if JSullins agreed.
But there is only one section that needs to be modified to update the toolbox and make compatible with all ROMS now and forever. In my opinion there is no need for the Toolbox to install any ROMS as that is the work of TWRP to do and it does it well.
--SNIP--
I do not think it can be any easier for anyone than this and the change is minimal!
Click to expand...
Click to collapse
I like what you're suggesting, but it's not that easy. I think you're creating a different application. The python scripts need to be modified to remove the "Install Android" option. Making users decide how to (re)install non-datamedia (DM) or DM ROMS by themselves was one of the things HPToolbox solved. I think that a better way is just to prevent all the checks that are done for three zips, gapp/rom capatibility, etc. and let users install the gapps themselves, although I can see a way to expand the allowable gapps dictionary to include the latest versions
Additionally, unless you resize /boot (which is fixed in one of the python scripts and may require lots of other changes), users who want to retain WebOS (there may be one or two left.) won't be able to install Android because there won't be enough room having uImage.TPToolbox there.
shumash said:
I like what you're suggesting, but it's not that easy. I think you're creating a different application.
There is no changes to the menu is only adding uImage.TWRP to be copy to boot.
In the Toolbox MAIN MENU
The option: Complete Data Reset
Call the script: toolbox/bin/make_boot
It will completely erase and format boot then copy files located in (/usr/tptoolbox/data/) over to /boot
It is part of the toolbox option and how it works. Nothing needs to be added or the main script modified.
By adding this code to the already (toolbox/bin/make_boot) script
Code:
do_run cp /usr/tptoolbox/data/uImage.TWRP /mnt/boot/uImage.TWRP
do_run cp /usr/tptoolbox/data/android.default.recovery /mnt/boot/android.default.recovery
do_run cp /usr/tptoolbox/data/moboot.default /mnt/boot/moboot.default
And copy those files to (/usr/tptoolbox/data/).
When the user select the option in the MENU to Complete Data Reset, it will do as always the only difference is, it will install TWRP automatically, which in my opinion it needs to be there to install and back up.
The python scripts need to be modified to remove the "Install Android" option. Making users decide how to (re)install non-datamedia (DM) or DM ROMS by themselves was one of the things HPToolbox solved.
The Install Android can be there as is and do as you are suggesting which is to remove the limitation and be able to install any recovery or gapps
I think that a better way is just to prevent all the checks that are done for three zips, gapp/rom capatibility, etc. and let users install the gapps themselves, although I can see a way to expand the allowable gapps dictionary to include the latest versions.
Yes that is perfect and the way it should have been from the beginning, to allow installation of any ROM. There is nothing malicious that anybody can do to brick the device. Reloading the toolbox (novacom boot mem:// < uImage.Toolbox) will recreate everything even if /boot is destroy.
Additionally, unless you resize /boot (which is fixed in one of the python scripts and may require lots of other changes), users who want to retain WebOS (there may be one or two left.) won't be able to install Android because there won't be enough room having uImage.TPToolbox there.
Click to expand...
Click to collapse
Correct if uImage.Toolbox ( 11 MB ) file is copy to boot and TWRP there will be 8 MB left for one uImage boot file, only one OS will be able to boot.
That could be an option and does not need to be copy to boot, but it could make it easier for "Android only users" to have it handy and no PC will be required to load it again.
Here is another simple quick modification to avoid confusion and make it easier.
When you select Install Android, the USB media is mounted and a directory /ttinstall is created. At the same time the directory is created a shortcut (link) can be place of a landing web page where the links to all ROM and Recovery can be download from, that the user can click and download the correct Recovery, ROM and gapps.
Make it super easy and avoid confusion of what to install and where to get it from. It could be a landing page any where that can be updated.
This is another issue to think about. To load any uImage to fix a problematic TP, a PC is need it with novacom drivers install.
This is the command that will fix any TP:
novacom boot mem:// <
If novacom is not install in the user PC or not working properly nothing can be done.
Idea.
Create a basic Linux OS, bare minimum that will run anywhere. Have the novacom install and the toolbox in it, with a basic browser to get the files.
The Linux OS can be distributed as a Live CD (.iso) that can be booted on any PC. This will guarantee that the novacom driver will work and load the toolbox or any other uImage into the TP.
I made my own live CD of Ubuntu 18.04 ( is a 2GB file ) that has everything set up and do any kind of work on the TP and be able to use it on any PC.
HP_TOUCHPAD said:
__SNIP__
Click to expand...
Click to collapse
All good ideas, but this is much easier.
shumash said:
All good ideas, but this is much easier.
Click to expand...
Click to collapse
Crazy complicated !
Take a very close look at the steps.
" 1) complete data reset"
Before this happens the novacom driver needs to be install. It used to be an easy one to do, but with new OS, windows or Linux it can get complicated. Nothing can be done unless this driver is properly install and the environment is properly set to load the uImage. This can easily create errors and frustration and not a successful install.
The universal Java installer used to work, not any more. It will be great to have a portable novacom driver, but I do not know if that is even possible to load and work in different OS.
But anyways doing the first steps is to load the Toolbox to do a complete data reset.
Well if the toolbox is modified, once the complete data reset is done uImage.TWRP will be already copy into boot.
The only thing you have to do is reboot the device select TWRP and do the installation as regular.
No more steps need it, and nothing else to download or install.
One step and done!
But now you need to run:
TWRP_TmpLoad_v03_win.bat
Then install TWRP, because is temporally loaded in memory.
What it does is loading uImage.TWRP using:
novacom boot mem:// <uImage.TWRP
The same way the Toolbox gets loaded in the first place.
If the Toolbox restriction gets remove then it will install TWRP, and then reboot.
Like I said the magic command is:
novacom boot mem://
Any boot uImage can be load it that way, but the only thing that will reset everything is the Toolbox.