Here we have a collection of development tools I've either created/painstakingly compiled or scavenged from other developers that I've found useful for this device. All of these files can be run directly from the device (via adb) without the need for external tools. Obviously this goes without saying, but you need to run a lot of this stuff as root for it to be useful. Theoretically they should work on any device with the aarch64 architecture.
bash
Good old BASH interpreter. Pretty sure I compiled this one myself. I think I statically linked it too so it should work in TWRP.
busybox
Self explanatory. Scavenged from elsewhere (probably cyanogenmod).
patchboot script
Made this myself; you have to edit the script to your own purposes prior to using it. Place the script in its own directory with the busybox and bash binaries. Basically what this does is take a boot.img file in the same directory as the script, splits it up into its components, decompresses the ramdisk, recompresses the ramdisk, and reconstitutes it into newboot.img. The whole purpose of this is to allow you to modify the ramdisk contents live on the device. Needs to be run with bash interpreter (./bash patchboot), and depends on busybox binary in the same directory. I've added some useful ### comments with an example of how to pull the current boot.img, how to add binary services to the boot image to run as as root at startup, and how to flash the new boot image back to the device.
dbserver script
Script to start an SSH server via the dropbear binary (pulled from SSHDroid app) in public key authentication mode. I have this start up automatically on my device via patchboot script above. 4 things to be aware of:
You need a dropbear_rsa_host_key file including a pub/priv key for SSH.
You allow clients in via the .ssh/authorized_keys file
Use the 'root' user to login.
This will create a /data/data/berserker.android.apps.sshdroid/home/ directory - so you probably shouldn't use this AND have SSHDroid installed at the same time.
ssh
dropbear SSH client. Scavenged it from an unknown source on XDA. dropbear is an enormous pain in the ass to compile for aarch64 - credit to whoever made this.
nano - Compiled this one myself.
Holy crap! nano text editor! No more annoying adb push/pull for on-device script editing Only works if you're ssh'ed into the device (I couldn't get it to work via ADB). Depends on the nano_bin file and terminfo directory (should be placed in the same directory as the nano script).
rsync
Compiled this myself. I set this up using the patchboot script above to backup my device to an rsync server daily (using the ssh client above).
dropbear multibinary added in a separate zip to the first post (recompiled it myself). Tested and operational for ssh client/server purposes (so you no longer need two separate binaries). It looks for the .ssh directory (containing known_hosts and authorized_keys files) in the current working directory at the time of binary execution.
Related
Hi all,
My aim has been to compile a kernel for an Allwinner a10 F1-LY tablet (pengpod 700) that features PS3 and other gamepad support. I can upgrade my ROM to Cyanogenmod 10 to achieve this but then the hard buttons and screen rotation stop working.
After days of searching, reading and testing, I feel like I am close but need help getting over the line. I am running a virtualbox installation of Xubuntu.
Once I have this running, I will contribute a guide with screenshots back to the community.
My steps:
0. My device is running this ROM, which is JB 4.1.1 with root and CWM 5.5 installed. The image is based on a Seby build, and modified by Magica.
1. Install virtualbox and then 32 bit Ubuntu 13.0.4. Make sure you have 3D acceleration enabled and a decent amount of RAM allocated or it will run incredibly slow.
2. Install guest additions and a shared folder with the windows host machine.
3. Install some packages for later use:
Code:
sudo apt-get install gedit git ncurses5 jre-default
4. Make a folder in the home directory to work from. Open a terminal in it and then install the kernal library:
Code:
git clone https://github.com/linux-sunxi/linux-sunxi linux-sunxi
cd linux-sunxi
git checkout sunxi-3.0
5. Install the cross compile tool chain.
Download http://www.codesourcery.com/sgpp/lite/arm/portal/package7853/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi.bin
Install with:
Code:
sudo ./arm-2010.09-50-arm-none-linux-gnueabi.bin
6. Setup kernel config.
Code:
make ARCH=arm sun4i_crane_defconfig
make menuconfig ARCH=arm
The second line opens up a GUI for configuring the kernel, where I activated the following options using here as a guide::
Code:
--- Networking support <*>
Bluetooth subsystem support --->
<*> HIDP protocol support
Bluetooth device drivers --->
<*> HCI USB driver
[*] HID Devices --->
Special HID drivers --->
<*> Sony PS3 controller
<*> DragonRise Inc. game controller
[*] DragonRise Inc. force feedback
<*> Pantherlord/GreenAsia game controller
[*] Pantherlord force feedback support
<*> GreenAsia (Product ID 0x12) game controller support
[*] GreenAsia (Product ID 0x12) force feedback support
<*> SmartJoy PLUS PS2/USB adapter support
[*] SmartJoy PLUS PS2/USB adapter force feedback support
I'm not sure if my thinking is correct here, but I went through the config and changed any modular options to included, to avoid the need for additional files to be copied to the device.
7. Compile kernel:
Code:
make ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-
This runs for a long time and will eventually produce a zImage file in the linux-sunxi/arch-arm-boot/ folder.
8. Get original boot.img from device.
To do this I booted into recovery mode and used the backup feature. This made a folder on my external SD card with boot.img and other archives. I then copied boot.img to the shared folder on my windows host.
9. Split original boot.img into zImage and ramdisk, replace zImage
Make a new folder in your home directory to keep this clean. Copy the original boot.img into this folder.
I downloaded and unzipped Adi_Pat's scripts from here. into the new folder.
The boot.img file will be unpacked with:
Code:
./extract.sh
Your zImage will be in kernel/zImage
Your ramdisk will be in ramdisk folder (unpacked)
Click to expand...
Click to collapse
I then deleted the zImage in the kernel folder and replaced it with the one compiled earlier from linux-sunxi/arch/arm/boot/. The ramdisk was left alone.
10. Modify script and repack boot.img
I'm aware that Adi_pat's script is for a different device, so I modified the pack_boot.sh script to suit the a10. Line 31 becomes:
Code:
./tools/mkbootimg --kernel kernel/zImage --ramdisk ramdisk.gz -o out/boot.img --base 0x40000000 --cmdline 'console=ttyS0,115200 tw init=/init loglevel=8' --pagesize 2048
This is based on searching and the the information given when running extract.sh. The updated script can now be executed:
Code:
./pack_boot.sh
A new boot.img is created at out/boot.img.
11. Put new boot.img onto device and flash.
I copied the new boot.img into my shared folder and then onto a SD card. Using a root file explorer on the device, move the boot.img file to the /sdcard directory. Open Novo7 tools and then go to the flash boot.img option.
12. Reboot device
When the device reboots, it hangs on the first Android logo, so clearly something has been done incorrectly. Fortunately I can recover to a working device from the backup in CWM recovery in just a few minutes.
Obviously I'm doing something wrong here, and would appreciate any pointers to get it working.
I have searched and read for days, so I am sorry if I have missed a thread that answers this for me.
Many thanks in advance.
lawgic said:
Hi all,
My aim has been to compile a kernel for an Allwinner a10 F1-LY tablet (pengpod 700) that features PS3 and other gamepad support. I can upgrade my ROM to Cyanogenmod 10 to achieve this but then the hard buttons and screen rotation stop working.
After days of searching, reading and testing, I feel like I am close but need help getting over the line. I am running a virtualbox installation of Xubuntu.
Once I have this running, I will contribute a guide with screenshots back to the community.
My steps:
0. My device is running this ROM, which is JB 4.1.1 with root and CWM 5.5 installed. The image is based on a Seby build, and modified by Magica.
1. Install virtualbox and then 32 bit Ubuntu 13.0.4. Make sure you have 3D acceleration enabled and a decent amount of RAM allocated or it will run incredibly slow.
2. Install guest additions and a shared folder with the windows host machine.
3. Install some packages for later use:
Code:
sudo apt-get install gedit git ncurses5 jre-default
4. Make a folder in the home directory to work from. Open a terminal in it and then install the kernal library:
Code:
git clone https://github.com/linux-sunxi/linux-sunxi linux-sunxi
cd linux-sunxi
git checkout sunxi-3.0
5. Install the cross compile tool chain.
Download http://www.codesourcery.com/sgpp/lite/arm/portal/package7853/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi.bin
Install with:
Code:
sudo ./arm-2010.09-50-arm-none-linux-gnueabi.bin
6. Setup kernel config.
Code:
make ARCH=arm sun4i_crane_defconfig
make menuconfig ARCH=arm
The second line opens up a GUI for configuring the kernel, where I activated the following options using here as a guide::
Code:
--- Networking support <*>
Bluetooth subsystem support --->
<*> HIDP protocol support
Bluetooth device drivers --->
<*> HCI USB driver
[*] HID Devices --->
Special HID drivers --->
<*> Sony PS3 controller
<*> DragonRise Inc. game controller
[*] DragonRise Inc. force feedback
<*> Pantherlord/GreenAsia game controller
[*] Pantherlord force feedback support
<*> GreenAsia (Product ID 0x12) game controller support
[*] GreenAsia (Product ID 0x12) force feedback support
<*> SmartJoy PLUS PS2/USB adapter support
[*] SmartJoy PLUS PS2/USB adapter force feedback support
I'm not sure if my thinking is correct here, but I went through the config and changed any modular options to included, to avoid the need for additional files to be copied to the device.
7. Compile kernel:
Code:
make ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-
This runs for a long time and will eventually produce a zImage file in the linux-sunxi/arch-arm-boot/ folder.
8. Get original boot.img from device.
To do this I booted into recovery mode and used the backup feature. This made a folder on my external SD card with boot.img and other archives. I then copied boot.img to the shared folder on my windows host.
9. Split original boot.img into zImage and ramdisk, replace zImage
Make a new folder in your home directory to keep this clean. Copy the original boot.img into this folder.
I downloaded and unzipped Adi_Pat's scripts from here. into the new folder.
The boot.img file will be unpacked with:
Code:
./extract.sh
I then deleted the zImage in the kernel folder and replaced it with the one compiled earlier from linux-sunxi/arch/arm/boot/. The ramdisk was left alone.
10. Modify script and repack boot.img
I'm aware that Adi_pat's script is for a different device, so I modified the pack_boot.sh script to suit the a10. Line 31 becomes:
Code:
./tools/mkbootimg --kernel kernel/zImage --ramdisk ramdisk.gz -o out/boot.img --base 0x40000000 --cmdline 'console=ttyS0,115200 tw init=/init loglevel=8' --pagesize 2048
This is based on searching and the the information given when running extract.sh. The updated script can now be executed:
Code:
./pack_boot.sh
A new boot.img is created at out/boot.img.
11. Put new boot.img onto device and flash.
I copied the new boot.img into my shared folder and then onto a SD card. Using a root file explorer on the device, move the boot.img file to the /sdcard directory. Open Novo7 tools and then go to the flash boot.img option.
12. Reboot device
When the device reboots, it hangs on the first Android logo, so clearly something has been done incorrectly. Fortunately I can recover to a working device from the backup in CWM recovery in just a few minutes.
Obviously I'm doing something wrong here, and would appreciate any pointers to get it working.
I have searched and read for days, so I am sorry if I have missed a thread that answers this for me.
Many thanks in advance.
Click to expand...
Click to collapse
I am heavily into the allwinner tablets and would like to get CM10 install. I ran into the same issue until I build kernel 3.0.8 but you MUST put the generated NAND.KO file into the ramdisk folder and edit the init.sun4i.rc file to load it before anything else...this should get rid of the issue. I have a serial port I added to my tablet so Its a bit easier to troubleshoot and edit uboot vars when needed. If you would like to collaborate let me know.i have a 95% working android build environment that works for my tablet, only the gsensor is inverted which is a simple fix.
Michael Pizzileo
BinaryDroid
I am working with a Polaroid Tablet (pmid10c) and have been attempting to build and install a newer kernel with no success. Any help/guidance would be great. I am currently working in this thread: http://forum.xda-developers.com/showthread.php?p=46685741#post46685741 please chime in with any advice you may have.
Thanks
There's a lot of nifty tools that will automatically root my phone with pre-packaged system images (CF-Auto-Root et al). However, I'd prefer not to load my phone with firmwares from internet strangers. Also, I try to avoid apps whose code I can't see (e.g. SuperSu).
What I'd like to do is take the system preloaded on my Galaxy Note 4 by Samsung (or the recovery image) and modify it manually so that I have root access. As I understand it, this should be a fairly reproducible process. (Chainfire wrote somewhere that he has a script that automatically generates rooted images from vendor images as new versions are released.)
Please, help me do it manually. Assume I have some general Linux knowledge (your typical Ubuntu user), but no Android development skills.
bump
bump
You can't. You will have to use one of the SU binaries and SU packages. Other then that you will have to find an exploit in the base system and then code a whole new binary and app.
Yes he has a script, but that is only after years of working on the exploit for root.
Axure said:
There's a lot of nifty tools that will automatically root my phone with pre-packaged system images (CF-Auto-Root et al). However, I'd prefer not to load my phone with firmwares from internet strangers. Also, I try to avoid apps whose code I can't see (e.g. SuperSu).
What I'd like to do is take the system preloaded on my Galaxy Note 4 by Samsung (or the recovery image) and modify it manually so that I have root access. As I understand it, this should be a fairly reproducible process. (Chainfire wrote somewhere that he has a script that automatically generates rooted images from vendor images as new versions are released.)
Please, help me do it manually. Assume I have some general Linux knowledge (your typical Ubuntu user), but no Android development skills.
Click to expand...
Click to collapse
1º Download source code or unpack boot.img with unpackbootimg tool,
2º then unpack the ramdisk,
3º edit default.prop
Code:
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
4º $ cd ramdisk
5º $ find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
6º mkbootimg with the proper settings
7º ???
8º profit
What is Kexec?
"Kexec", which is short for 'Kernel Execution' is derived from the Linux Kernel call "exec". It allows the "live" booting of a new kernel "over" the currently booted kernel without taking the device down for a reboot. This is extremely useful on locked bootloader devices, as a user with root authentication can boot a custom kernel without rebooting, and undergoing the security checks enforced by the bootloader. On unlocked devices, it can be used to "multi-boot" kernels on a device without requiring the kernels to be installed to the /boot partition.
Whilst Kexec is extremely useful, it also can be extremely hard to implement, as it needs to take all devices down, and bring them back up along with the new kernel, this can lead to some serious bugs, like devices not working after soft-boot, kernel corruption, device hangs, etc. This make it very device specific, and hard to get fully working, as it requires retrieving kernel crash logs, (often) UART serial output, and a ton of debugging.
What about this whole "Hardboot" thing?
The solution to this was written (initially) by Mike Kassick, who had the idea to "Hardboot" a kernel. Which is when a kernel is loaded into memory, a flag is set, the device is taken down for a full reboot, then the flag is read out by the primary kernel very early in the boot sequence, at which point, the "primary" kernel directly loads the new "secondary" kernel/ramdisk/passes arguements/etc.
This is much easier to implement than the normal Kexec SysCall, as it jumps to the new kernel before most devices are initiated, and in doing this, we allow the secondary kernel to initialize all the devices on its own, and not have to worry about taking them down.
Many people unknowingly make use of Kexec in the form of MultiROM, so, today, I thought I would do a write up on how to use it in practice.
Necessary Components:
* Boot.img (alternatively, the zImage-dtb/ramdisk you want to use)
* Unmkbootimg
* Kexec Binary (can be found in your specific devices MultiROM zip)
* Kexec Hardboot enabled Kernel installed (most custom kernels have it)
* Root Access
Downloads:
All the Binaries I've cross compiled/found can be downloaded here: https://www.dropbox.com/sh/7g5jcofv8j2gwg9/AAA-2b-wLiHq2z0nCMIHSHooa?dl=0
All the Linux Binaries you'll want/need are here: https://www.dropbox.com/sh/qcho8bhaoi8cdkc/AACGvmIQlb_3I9OQtNMqIQwva?dl=0
If you use Windows/Mac, just find the binaries equivalents for your platform.
How to use it?
1. Take the aforementioned Kexec Binary, and place it in /system/bin using ADB or A File Explorer, granting it permissions drwxdr-xdr-x (or chmod 0755 it)
2. Over on your desktop, make sure you have Unmkbootimg in an Executable location, and that you've blessed them as executable (chmod 0755 filename). Then run
Code:
unmkbootimg /path/to/your/boot.img
This will dump a zImage (rename it to zImage-dtb now, for semantics sake), and a ramdisk, labeled initramfs.cpio.gz (Initial RAM File System, in the form of a cpio.gz archive).
Now, put the kernel and ramdisk in a folder on your SD Card via MTP/ADB Push, I called mine "kexecstuffs".
3. Now open a mobile terminal, or an ADB Shell, and run
Code:
su
cd /sdcard/PathToYourFolder/
kexec --load-hardboot zImage-dtb –initrd=initramfs.cpio.gz --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --boardname=shamu –dtb
Now, lets dissect the different arguments we are passing to Kexec:
--load-hardboot = Tells Kexec to make use of the Kexec Hardboot kernel function, and take the device down for a full reboot as opposed to soft-booting, like that used in the standard Kexec Linux SysCall
zImage-dtb = Name of your kernel file
--initrd = Points to the ramdisk to be used when booting the new kernel, if not set, the current ramdisk in the /boot partition. Most archive types are supported.
--mem-min = A reasonable value in memory where the kernel is loaded, serves as space for Kexec to do its work
--command-line = What arguments are passed to the new kernel, using "$(cat /proc/cmdline)" allows you to pass the currently booted kernel's arguments to the new kernel, which is what we want in the case of Shamu
--dtb = Defines that the board makes use of an Appended Device Tree, can be passed without a value (which will rely on Tasssdar's “boardname” value), or can have a compressed DTB image as its value
--boardname = Tasssdar's way to handle different DTB styles, we just need to pass “shamu” to it, and it'll use our DTB style
Now that we have successfully loaded the kernel into memory, lets execute it!
4. In that same Mobile Terminal/ADB Shell, run:
Code:
kexec -e
Although this guide is for the Nexus 6 (shamu), it should work all devices supported bu MultiROM, or on any device with a kernel that supports Kexec/Kexec Hardboot.
I hope this helped you to better understand what Kexec is/how to use it.
I made a little sh script that updates the native ADB and Fastboot to revision 1:7.0.0+r33-1 (The latest as of debian stretch)
The script requires chromebrew because it needs the chromebrew binutils binary to unpack debian packages.
Other requirements are: be in dev mode and have rootfs verification disabled.
If you don't have chromebrew it will try to grab it automatically for you. I would advice having a backup image on hand in case you get black screened'. I've only tested this on my chromebook pro and it works like a charm However it SHOULD work on all amd64 devices.
I'm not responsible for anything that goes wrong, use at your own risk
to run simply extract the script to your Downloads folder and
Code:
sh ~/Downloads/adbFastbootUpdater.sh
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.