Related
During my time hacking on android I've discovered some nice easter eggs deep in the android platform. One such easter egg is the mounting of ext4 images directly in the init.rc script. This is a feature I have never seen used by any oems and only by one custom rom [ EDIT: and by letama in his Sony Xperia Boot Manager ]! looking at the git logs this functionality has been present since September 2010 [ commit 49b8124a1759cb8b27e0c21a1a5a54b8a81bdb19 ]. What this effectively gives us is the ability to overlay a pseudo partition layout over the top over the existing layout, thus avoiding any "Danger" of accidental bricking the device by reformatting the SDCard. This is very similar to the way archos mount the stock file system and a variation/extension on the existing methods we use for the SDE Roms.
Although the explanation assumes the use of the SD models it should be fairly straightforward to apply the the HDD models.
THE METHOD:
PART 1 - Prepare a recovery ext4 image file
1. Build CWM6 from the CM10 source.
2. Modify The Recovery's init.rc file to look something similar to this
Code:
on early-init
start ueventd
on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
mkdir /boot
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mount /tmp /tmp tmpfs
mkdir /partitions 0771 system system
mount ext4 /dev/block/mmcblk0p4 /partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount ext4 [email protected]/partitions/CAC /cache nosuid nodev
mount ext4 [email protected]/partitions/DATA /data nosuid nodev
mount ext4 [email protected]/partitions/SYS /system
mount ext4 [email protected]/partitions/SDCARD /sdcard nosuid nodev
mount ext4 [email protected]/partitions/BOOT /boot
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
# Always start adbd on userdebug and eng builds
# In recovery, always run adbd as root.
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
#write /sys/class/android_usb/android0/enable 1
write /sys/class/android_usb/android0/iManufacturer $ro.product.manufacturer
write /sys/class/android_usb/android0/iProduct $ro.product.model
write /sys/class/android_usb/android0/iSerial A101S_REC
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
3. Modify the etc/recovery.fstab to look like this
Code:
# mount point fstype device
/cache ext4 /dev/block/loop1
/data ext4 /dev/block/loop2
/system ext4 /dev/block/loop3
/sdcard ext4 /dev/block/loop4
4. Creating an empty ext4 image file name REC and mount it on your pc. [ 5MB should do it ]
5. Copy the contents of the built recovery/root directory to the root of your mounted image.
6. chmod init.rc , default.prop and ueventd.rc to 644 ( rw-r-r- )
7. umount the ext4 image and push it to the root of you data partition
That's stage 1 complete. Part 2 Will Follow Shortly.....
Part 2 - Make a dual boot initramfs.cpio.lzo
1. Change the name of the /data directory to /bootdata by modifying the etc/mountpoints file in the initramfs.cpio.lzo. This stops CWM getting confused when trying to un/mount the data partition
Code:
mount_name mount_dev mount_point mount_fs mount_opts volume_name error_code custom_opt
rawfs /dev/mmcblk0p1 /mnt/rawfs rawfs none 150
system /dev/mmcblk0p2 /mnt/system ext4 rw,noatime,noexec system 152
bootdata /dev/mmcblk0p4 /bootdata ext4 rw,noatime,noexec bootdata 154 crypt_compat
storage /dev/mmcblk1p1 /mnt/storage ext4 rw,noatime #storage_name# 155
storage_A80S /bootdata/media /mnt/storage bind bootdata none 155
storage_A101S /bootdata/media /mnt/storage bind bootdata none 155
storage_A101XS /bootdata/media /mnt/storage bind bootdata none 155
storage_LUDO /bootdata/media /mnt/storage bind bootdata none 155
storage_A80H /dev/hdd1 /mnt/storage ext4 rw,noatime #storage_name# 155
storage_A101H /dev/hdd1 /mnt/storage ext4 rw,noatime #storage_name# 155
usbhost_ehci /dev/storage_ehci1 /mnt/usbhost_ehci vfat rw,noatime,utf8,shortname=mixed none 156
usbhost_otg /dev/storage_otg1 /mnt/usbhost_otg vfat rw,noatime,utf8,shortname=mixed none 156
rfsext4 /dev/loop0 /new-root ext4 rw,noatime none 157
rfsext3 /dev/loop0 /new-root ext3 rw,noatime none 157
rootfs /dev/loop0 /new-root squashfs ro,cts_compat none 157
ramdisk /tmp/ramdisk /ramdisk vfat loop,rw,utf8,shortname=mixed #ramdisk_name# 158 ramdisk,ramdisk_size=256
2. Using sirduke989 dmenu initramfs you can modify the init script in the initramfs to mount /bootdata instead of /data and also add /bootdata/REC and /bootdata/BOOT to the list
of known locations , I see this a temporary measure as there are a number of other ways to enable dual ( Triple?!? ) booting
3. Flash the modified initramfs and your choice of kernel using either the recovery menu or kd_flasher, I used the 3.0.21 kernel extracted from the 4.0.24 aos file.
You should now be able to boot into CWM Recovery!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Clearly I'm a developer not a photographer!!
Part 3 - Create rest of the "partition" images.
You should have a /partitions directory in you device root, This is what is normally mounted as your /data ( /dev/block/mmcblk0p4) and contains normal android user data e.g installed app settings databases etc. This is where I've created the reset of my Partitions which are just more ext4 images files. I did this using "dd if=/dev/zero ...." and "mke2fs -text4 ...." on the device through adb whilst booted into CWM. This saved time in pushing large empty ext4 files from my pc.
I called my image CAC ( cache ) DATA ( data ) SYS ( system ) SDCARD ( sdcard ) BOOT ( boot ) you can obviously call them what you like and place them anywhere as long as you match up the image names with those in init.rc and make sure the loop numbers are correct in the etc/recovery.fstab everything should be fine.
You can play around with the files sizes, I have an 8gb my current file sizes at the moment are
BOOT = 25MB
CAC = 500MB
DATA = 3GB
SYS = 500MB
SDCARD = 2GB
The sdcard mount point is probably worth pointing at an external sd if you have one available. I have a 32GB Class 10 that I'll probably set up.
After you've setup your psuedo partitions you should then be able to reboot into recovery, if you've done things correctly you mount output should contain the following
Code:
/dev/block/mmcblk0p4 on /partitions type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop1 on /cache type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop2 on /data type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop3 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop4 on /sdcard type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop5 on /boot type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
Everything seems to function correctly, I have successful done a backup and restore of my system partition. I have also applied CWM-SuperSU.zip through install zip from sdcard. Mounting and Remounting works although I'm not sure if Mount USB Storage works yet, I didn't on linux and I've not tested on windows and finally wiping and formating was also successful.
Part 4 - Notes on setting up rom images.
Now you may of already realized normal archos images don't come as separate the /boot and /system images so work is require to split them up.
Also if you want to split the /system from the reset of a archos image your boot partition will need to be about 50MB as archos have they /bin /lib /usr directories which contains binary files that use /lib/libuClibc-*.so as it's libc which brings there root filesystem in at around 38MB.
There is a very strong case for ditching these binaries especially when using AOSP/CM based roms. My intial tests show this is possible.
Just like the recovery init.rc Similar changes have to be made to the roms init.rc
Moving Forward:
of course, there's a lot to do but I wanted to at least get this initial information out there for people to consider. I'm currently booting a Linaro 4.1.1 rom using the split partitions. I have also been working on better booting methods which is why I haven't given any details re the initramfs init script but It's fairly straight forward to adjust and adapt. I'll write up more details soon!
More Research!
As I mentioned, I've been further looking into different booting methods and I think I'm approaching what could be a workable solution that will make the Gen9 more like standard android devices
Here's some more of my findings
1. It turns out that we can dump the existing initramfs.cpio.lzo and we can use a standard android ramdisk layout as the android init will load instead of the init script that is currently being used, this also removes the need for switch root and other nonsense that archos have in there. There was one gotcha when had me stumped for about ten minutes, I needed to add "write /sys/class/leds/lcd-backlight/brightness 75" to the init.rc to turn the screen on.
2. It's possible to stop android either using adb shell stop or stopping each service zygote etc, and start CWM while android is booted. It's probably also feasible the manage booting between recovery and android using the persist properties system which should make switching between the 2 fairly easy to control without much tweaking to any binaries. Looking at other devices, namely samsung, they seem to do something similar with recovery being in the same boot.img as the standard files, they simply load a recovery.rc instead of the main init.rc, this might mean that we have to patch CWM to load the correct init.rc I've not looked at the code properly yet but It's not going to be an issue anyway as all the code is fully available, You've gotta love open source.
3. By mounting /dev/block/mmcblk0p1 to /mnt/rawfs we are still able to use abcbox, reboot_into writes to the params file in the partition to control boot switching, so we can maintain booting into sde while leaving the stock android partition in place. I was unable to get any immediate joy from kd_flasher, that maybe because we currently have the ramdisk we want to overwrite mounted as the rootfs. Again I can't imagine it being too difficult to jig this, It can probably be worked out by looking at the current recovery ramdisk scripts should kd_flasher style functionality be required at any point.
4. Most of the binaries that rely on uClibc can be recompiled against bionic without any issue, usb_modeswitch for example. If there are any closed source ones, then the dynamic linker ld-uclibc or whatever is called, ultimately symlinks back to uClibc and we can just grab the one file and place it in the /lib directory. I tested /usr/bin/lsdvd in this way and It seemed to work fine.
I've got all this going on while still leaving a stock android fully intact, which is a great fallback Just in case.... Keeping these modifications at a safe level is one of the primary goals to enable much wider use
I'll put together some examples within the next couple of days to demostrate what I'm talking about here.
I've got a Linaro 4.1.1 ( JRO03R ) which has working powervr drivers with a 3.0.21 kernel, although that's about all that's working on it at the minute.
It's more a proof of concept than anything else, The kernel would need recompiling to add tracefs functionality which is required by jellybean but using the same magic should leave the powervr drivers functioning still, If anyone's interested I can stick that up, I've foolishly deleted ( misplaced/can't remember ) the device files I used to build this.... Too many android source trees and not using git properly leads to school boy errors.
I'm currently working on an omapzoom 4.1.2 tree using the blaze_tablet device as a base, I think this may yield the best results for the archos.
I suppose one other thing to do is the fix up a stock rom to use these methods and give it CWM, that should be pretty simple to do. Although ICS is ooold and I'm really not a fan of some of archos' methods e.g booting 4 different devices off one firmware. Although to their credit they do demostrate just what possible with deviating android from it's normal standard structures.
Hopefully this has whetted your appetites, I'm pretty excited about what's possible here as I feel it brings these archos devices in line with most others.
Me Again!
Just a cheeky little update, I been trying the figure out the best approach to handle switching between android and recovery mode. In effect I kind of wanted to create a Stage 4 bootloader! because you can never have too many bootloaders LOL I certainly wanted to do a "proper" job on it and try to avoid changes to the android platform code.
While to doing research into this I found this patch to the linux kernel which the android team submitted for review, Reading the mailing list thread I don't think it's been accepted yet! It's true what they say about the Kernel Mailing List, You need to bring your A game and be sure of what your doing..
Anyways the patch add a boot-control-block driver to kernel which check for a boot flag, which is exactly what I need to make booting into alternative configuration nice and simple. I suppose it wouldn't be too difficult to chuck in support for the fastboot protocol on one of those configurations. So a CWM Shouldn't be too far off now!!!
As a little treat I've attached a recovery based ram disk if anyone what's to play, just flash it with you favourite kernel on to your sde partition. Then You can boot into recovery and set your self up a pseudo partition image layout through adb. You won't be able to be into android, obviously until you put your old initramfs back.......
This is totally unsupported.
Click to expand...
Click to collapse
I'm just chucking up for those who want to get a feel for to do so. If your uncomfortable playing around in this area then stand well back, It's not prime time yet!!!!
However Feel free to ask questions of a technical bent but If you can't get it to boot then tough luck I'm afraid for now! :laugh:
You shouldn't be able to do any damage with this be I wouldn't go selecting wipe/format etc until you've got some partition images sorted.
I've add abcbox to sbin and symlink reboot_into. It does not seem to fully reboot but It will set the boot flag which you then follow with a call to reboot, That will reboot back into CWM (sde).
Onward
EDIT: Here's the Init.rc and etc/recovery.fstab that It attempts to use.
Code:
on early-init
start ueventd
on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
mkdir /boot
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mkdir /mnt
mkdir /mnt/rawfs
mount /tmp /tmp tmpfs
mkdir /partitions 0771 system system
mount ext4 /dev/block/mmcblk0p4 /partitions
mount rawfs /dev/block/mmcblk0p1 /mnt/rawfs
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount ext4 [email protected]/partitions/CAC /cache nosuid nodev
mount ext4 [email protected]/partitions/DATA /data nosuid nodev
mount ext4 [email protected]/partitions/SYS /system
mount ext4 [email protected]/partitions/SDCARD /sdcard nosuid nodev
mount ext4 [email protected]/partitions/BOOT /boot
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
# Always start adbd on userdebug and eng builds
# In recovery, always run adbd as root.
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
#write /sys/class/android_usb/android0/enable 1
write /sys/class/android_usb/android0/iManufacturer $ro.product.manufacturer
write /sys/class/android_usb/android0/iProduct $ro.product.model
write /sys/class/android_usb/android0/iSerial A101S_REC
write /sys/class/leds/lcd-backlight/brightness 75
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
Recovery.fstab
Code:
# mount point fstype device
/cache ext4 /dev/block/loop0
/data ext4 /dev/block/loop1
/system ext4 /dev/block/loop2
/sdcard ext4 /dev/block/loop3
Any words about hdd versions?
DragosP2010 said:
Any words about hdd versions?
Click to expand...
Click to collapse
I all depends how you want the structure it, What it would change is the mount point of the paritions directory. After that. everything is loop mounted and sitting on top of the existing structure.
Code:
mount ext4 /dev/block/mmcblk0p4 /partitions
Great stuff!!!!
Hey trevd,
that's fantastic... i will definitely try this CWM in a few days with my custom kernel and bootloader (mountpoint will need some tweaks as well ).
I'm very busy these days, so i gess i'll leave some longer statements to the recent developments in a few days.
Just in short... it's very pleasant to see all these open developments popping up and i really, really appreciate this kind of hacking!
Keep on your great work... you rock!!
Cheers,
scholbert
Hi Trevd,
Nice job!
I've been using the same kind of trick on my Xperia S boot manager project, recovery on loops and mount [email protected] in inits. You may want to take a look at what I did there (see my sig), it may have some use for your project.
Basically, what I do is storing multiple kernels+cpios on the regular kernel partition. I use one (trimmed down to maximize space) to handle the boot logic and cwm, and I have enough space to handle two "regular" kernels. I handle kernel switch just before they load with a small assembly loader. It works very nicely on Xperia, and it's very nice to be able to dual boot with isolated cwms. I can't remember maximum size on a g9 kernel rawfs file, but I think you could have at least enough space to have two kernels to isolate recovery.
Hey letama,
nice to read you :highfive:
letama said:
I've been using the same kind of trick on my Xperia S boot manager project, recovery on loops and mount [email protected] in inits. You may want to take a look at what I did there (see my sig), it may have some use for your project.
Click to expand...
Click to collapse
Cool stuff again...
letama said:
Basically, what I do is storing multiple kernels+cpios on the regular kernel partition. I use one (trimmed down to maximize space) to handle the boot logic and cwm, and I have enough space to handle two "regular" kernels. I handle kernel switch just before they load with a small assembly loader. It works very nicely on Xperia, and it's very nice to be able to dual boot with isolated cwms. I can't remember maximum size on a g9 kernel rawfs file, but I think you could have at least enough space to have two kernels to isolate recovery.
Click to expand...
Click to collapse
AFAIK, we got around ~30MBytes in the raws partition on our tablets so would be possible to put some more kernel+cpios here easily.
Anyway, made some experiments with my latest u-boot port for the tablet this weekend.
I was able to bring up my A80S completely from MicroSD and boot into CWM by using uImage and uInitramfs (based on trevd's CWM image).
There's also some lowlevel multiboot implemented now by using the volume keys... but i know that i use a very special setup, so this is more a proof of concept and not a suitable environment for the average user
Cheers,
scholbert
Thanks Letama + Scholbert
I'll look at all this stuff this week....As a aside, I've played around with mmcblk0p3 and given myself an mmcblk0p5 / 6 of 4MB each. I found parted to be pretty useful (read:safe) for this..... I'm dubious about playing around with the rawfs too much at this point, mainly because I don't understand it fully, yet!.
Have you guy seen this https://github.com/swetland/omap4boot ( I think it's along the line of what Scholbert been working with/on )
Like I've mentioned to ultimate goal is a solution that is "safe" for the average user and also leaves the rest of the tablet in-tact, it maybe a lofty goal but worth a shot. :good:
Thanks for the input guys!
scholbert said:
AFAIK, we got around ~30MBytes in the raws partition on our tablets so would be possible to put some more kernel+cpios here easily.
Click to expand...
Click to collapse
30 for init kernel ? That's plenty indeed! Cool!
Anyway, made some experiments with my latest u-boot port for the tablet this weekend.
I was able to bring up my A80S completely from MicroSD and boot into CWM by using uImage and uInitramfs (based on trevd's CWM image).
There's also some lowlevel multiboot implemented now by using the volume keys... but i know that i use a very special setup, so this is more a proof of concept and not a suitable environment for the average user
Click to expand...
Click to collapse
Nice job! Too bad that Archos doesn't do this on their board with a small internal switch. Would be cool for people like me with big fingers and poor soldering skills
trevd said:
I'll look at all this stuff this week....As a aside, I've played around with mmcblk0p3 and given myself an mmcblk0p5 / 6 of 4MB each. I found parted to be pretty useful (read:safe) for this..... I'm dubious about playing around with the rawfs too much at this point, mainly because I don't understand it fully, yet!.
Click to expand...
Click to collapse
Hummm... You're going to end with a full re-partitioning scheme with system and data if you continue this way . Just be careful when you recreate partitions to let the empty space at the beginning of the disk untouched, instant brick ahead if you go there...
Just in case, here is what I did with my repartition script (do you have it ?): delete p3, delete p4, re-create p3 (careful with start point, leave the hole! it should start just after p2) as extended partition, big enough to hold the new partitions, recreate p4 (same thing about the hole, it should start after p3) with what remains and then you can create p5,p6,p7 with the size you want inside p3.
Last advice: rawfs, don't touch it .
Anyway, the good thing with what I did on Xperia S is that you don't mess with rawfs and re-partition, it's just like flashing a very big SDE kernel from recovery with unmodfified sde firmware, that's all. If I find some time, I'll take a look to see if we can do the same thing here.
letama said:
Just in case, here is what I did with my repartition script (do you have it ?): delete p3, delete p4, re-create p3 (careful with start point, leave the hole! it should start just after p2) as extended partition, big enough to hold the new partitions, recreate p4 (same thing about the hole, it should start after p3) with what remains and then you can create p5,p6,p7 with the size you want inside p3.
Click to expand...
Click to collapse
Hi
Yes I have read your previous threads on the subject which provided alot of the inspiration for the work currently at hand, It is also why I am being ultra careful around the partitions
I think maybe I'm just being too clever trying too pull everything back a step into the intramfs when we can just do the old switch root method method.... It's a little messy on the inside but it will get the job done!
Well, I don't like much the switch root too, it's not a very "Android way" of doing things and make some apps not very happy with it, but yes, it will get the job done, one root for recovery, one root for firmware. And Archos stock would be difficult without switch root, they did put far too much stuff outside of system.
letama said:
Well, I don't like much the switch root too, it's not a very "Android way" of doing things and make some apps not very happy with it, but yes, it will get the job done, one root for recovery, one root for firmware. And Archos stock would be difficult without switch root, they did put far too much stuff outside of system.
Click to expand...
Click to collapse
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
trevd said:
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
Click to expand...
Click to collapse
Well, it's required. It's used inside Android, it handles audio, wifi, codecs, smb...
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
Click to expand...
Click to collapse
In rawfs or initramfs ? I wouldn't add any file in rawfs, it would be difficult to do and I don't know how would behave the bootloader if it sees new files there. Initramfs you're free to do whatever you want until you reach maximum size of kernel+initramfs.
trevd said:
Have you guy seen this https://github.com/swetland/omap4boot ( I think it's along the line of what Scholbert been working with/on )
Click to expand...
Click to collapse
Well kind of... while i try to stick with the MicroSD our fellow vincencb follows the omap4boot path.
He already made a port of barebox bootloader to work with this tool and pushed it to the repos.
This way you may put anything you like on the tablet's RAM by using MicroUSB for communication and file transfer.
My way is more to get a full featured u-boot and put it into a state, where it might replace stock loader.
Last step is to put it in internal eMMC... so this is also research and development for now.
trevd said:
Like I've mentioned to ultimate goal is a solution that is "safe" for the average user and also leaves the rest of the tablet in-tact, it maybe a lofty goal but worth a shot. :good:
Click to expand...
Click to collapse
Yepp that sounds like a reasonable approach.
letama said:
30 for init kernel ? That's plenty indeed! Cool!
Click to expand...
Click to collapse
To be even more precisely, there are 32512*1K blocks for the rawfs partition.
On my device there's ~12MB left...
letama said:
Nice job! Too bad that Archos doesn't do this on their board with a small internal switch. Would be cool for people like me with big fingers and poor soldering skills
Click to expand...
Click to collapse
Yeah, a real switch would be nice indeed... there's some unused testpoints giving us additional GPIO
Need to solder though...
trevd said:
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
Click to expand...
Click to collapse
Some stuff outside of system is quite useful and gives us something like a minimal linux ecosystem.
Very useful at console level... some tools seem to be used by the Android system as well.
trevd said:
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
Click to expand...
Click to collapse
Mmmh, letama maybe right with being very careful with this part of internal storage. If it get's corrupt you'll risk a brick (could be restored though by using external boot mechanism).
Anyway the best would be to mount it RW and use the kernel driver to access it... the unknown part is still the bootcode.
There's some kind of allocation table at the beginning of rawfs partition. It is yet unknown how bootcode behaves with an additional entry
Anyway, this is a real nice project and i would really appreciate to see it pushing forward.
Take your time trevd, and again thanks a lot for contribution!!
Have a nice day,
scholbert
Not to put this down in any way, but wouldn't TWRP be better for the G9? It has a full touch tablet UI, which is better than CWM's
Sent from my Galaxy Nexus using Tapatalk 2
Quinny899 said:
Not to put this down in any way, but wouldn't TWRP be better for the G9? It has a full touch tablet UI, which is better than CWM's
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Hi Quinny
There's nothing to stop us using whatever recovery we like.... they all work the same way ( I think ) , i.e the code is compiled into a recovery binary. Unfortunately my touch screen stopped working long ago so I wouldn't really benefit
scholbert said:
To be even more precisely, there are 32512*1K blocks for the rawfs partition.
On my device there's ~12MB left...
Click to expand...
Click to collapse
Ah, yes, but there is space reserved for each file there, what I have to figure is how much is reserved for custom file (sde kernel). I don't want to have to shift the files located after custom to make room for sde kernel , it would defeat the "no-fuss/no-risk" of the method.
Anyway the best would be to mount it RW and use the kernel driver to access it... the unknown part is still the bootcode.
There's some kind of allocation table at the beginning of rawfs partition. It is yet unknown how bootcode behaves with an additional entry
Click to expand...
Click to collapse
Definitely. Re-partitioning is much safer if space is needed.
trevd said:
.... they all work the same way ( I think ) , i.e the code is compiled into a recovery binary.
Click to expand...
Click to collapse
This is a good keyword: The recovery binary itself!
Most tools inside the recovery are simply linked to busybox, which itself is a link to recovery executable.
In other words, we have some code responsable for the menu and framebuffer stuff and we have busybox.
The strings command gave me version 1.2.0. Now my question...
How to configure this part of code?
I'd like to enhance the busybox part.
Could you please provide a little to howto for a compiler run?
Will i need all that Android stuff installed...
I you have any clue, please point me in the right direction.
Lazy,
scholbert
scholbert said:
How to configure this part of code?
I'd like to enhance the busybox part.
Could you please provide a little to howto for a compiler run?
Will i need all that Android stuff installed...
Click to expand...
Click to collapse
Yes, you need full android repo. Android Build system is messy and tightly coupled, busybox is compiled with bionic (android libc), recovery is built on top of it with few android libraries links. Isolating all this "mess" would be difficult. Except disk space required, there is no big deal in getting full android repo.
I'd suggest to take a look at this, you should do the "Prepare the Build Environment" section.
I don't know how trevd built his recovery, but what I did is create a gen9 device to get proper configuration for recovery (frame buffer config, ...). You can get mine if you want, it's a little outdated (latest cwm doesn't need a specific gfx anymore, the custom one I used has been moved to upstream for instance), but it should give you a base.
To do that, you have to create an "archos" directory in cm9/device directory, then from inside it do:
Code:
git clone git://gitorious.org/archos-ics/device-g9.git gen9
Then, you need to setup the build env once. From cm9 root, you have to do that:
Code:
. build/envsetup.sh
(it setups android build environment)
then
Code:
lunch
then choose full_gen9-eng.
(it selects device target for build)
You should have something like that:
Code:
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=4.0.4
TARGET_PRODUCT=full_gen9
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=IMM76L
============================================
from this point, you can compile:
make -j4 recoveryimage (change j4 with the number of parallel build you want depending on your cpu).
whole recovery fs should be in out/target/product/gen9/recovery/root, with recovery command in sbin
Last, how do you want to extend it? If you want to add custom commands, take a look at cwm bootable/recovery/extendedcommands.c, it may be easier to add stuff there than in busybox.
Welcome. Already he was just asking about the same with the addition of some suggestions.The init.d directory has the opportunity to start up the concrete near the beginning of a comment, start the machine.One could initiate concrete partitions on the SD card to have played a role partition "mtd" for example / system / data / cachefrom what I noticed the kernel to jb has otherwise changed little these partitions (size).I do not know exactly how it looks with them, but if one could perform 2 partitions by mtd / system (small to perform the basic start-up and later redirects to / systemsd and the rest used as a framework or a particle cache?)
examples of partition
mtd / system (start-up)
mtd / ram (unless you know)
mmc / fat32
mmc / systemsd (the rest of the system)
mmc / data
mmc / .......
and so onthat was a minimum of 4 block
for it is our memory that was on the phone at the same time much bigger and faster (unless there think) than a swap sdanother thing that applications were loaded into the framework so that if they were around 500 + mb ram for the system to switch on only long landing and later had to speed up.I came up with this idea a bit strange when I have made applications to change fat32, after connecting the USB cable.for me my memory card is slightly odd partitions of personal reasons
Class10+ 32gb
fat32 / sdcard 26gb block1
ext4 / 4gb sd-ext Block2
swap ... 2gb block3
fat32 / sdcard2 2gb block4
sorry to my poor english. I hope you understand my gibberish (a lot of words I could not remember so I used google translator)
-AsA- said:
Welcome. Already he was just asking about the same with the addition of some suggestions.The init.d directory has the opportunity to start up the concrete near the beginning of a comment, start the machine.One could initiate concrete partitions on the SD card to have played a role partition "mtd" for example / system / data / cachefrom what I noticed the kernel to jb has otherwise changed little these partitions (size).I do not know exactly how it looks with them, but if one could perform 2 partitions by mtd / system (small to perform the basic start-up and later redirects to / systemsd and the rest used as a framework or a particle cache?)
examples of partition
mtd / system (start-up)
mtd / ram (unless you know)
mmc / fat32
mmc / systemsd (the rest of the system)
mmc / data
mmc / .......
and so onthat was a minimum of 4 block
for it is our memory that was on the phone at the same time much bigger and faster (unless there think) than a swap sdanother thing that applications were loaded into the framework so that if they were around 500 + mb ram for the system to switch on only long landing and later had to speed up.I came up with this idea a bit strange when I have made applications to change fat32, after connecting the USB cable.for me my memory card is slightly odd partitions of personal reasons
Class10+ 32gb
fat32 / sdcard 26gb block1
ext4 / 4gb sd-ext Block2
swap ... 2gb block3
fat32 / sdcard2 2gb block4
sorry to my poor english. I hope you understand my gibberish (a lot of words I could not remember so I used google translator)
Click to expand...
Click to collapse
I didn't get you.
But it is possible to install rom on sdcard with High read/write speed.(class 6 or higher)
all U need is a dual-boot recovery
(I don't know that u must have a Rom installed in internal memory or not(
Sent From My "ULTIMATE ROM- gb - WP8 edition" via Tapatalk
yes, but not on my mind
dual-boot umount dir and make new to port img file. mtd block is not changed
my idea if edit mtd block
Memory phone
mtdblock0 /system size 206 mb
mtdblock1 /cache size 50 mb
mtdblock3 /data size 211mb
mayby mtdblock2 is block ram1, ram2 ..... size ~200mb
all ~667mb
my idea is
mtdblock0 /system (basic start-up i don't know mayby 20mb-67mb)
and mtdblock1 is block ram 600mb
of sd card make block to /system /data etc
this is my idea but I do not know if possible
@-AsA-
Hi. I am working on a dual-boot project. I sent you an invite to our group. It would be awesome if we could work together. I have a test kernel ready, if you want to test. It's still a WIP. Everything modified is mentioned there. Please take a look. Thank you.
Looking forward to working with you.
sgt. meow
sgt. meow said:
@-AsA-
Hi. I am working on a dual-boot project. I sent you an invite to our group. It would be awesome if we could work together. I have a test kernel ready, if you want to test. It's still a WIP. Everything modified is mentioned there. Please take a look. Thank you.
Looking forward to working with you.
sgt. meow
Click to expand...
Click to collapse
im helping you on dboot project
The bootloader won't boot directly from the sdcard.
Nevertheless, you can definitely have ROM images in the sdcard and use those while booting android (basically you only have to update init.rc for that).
Check 'multiboot' in my signature for more details.
nobodyAtall said:
The bootloader won't boot directly from the sdcard.
Nevertheless, you can definitely have ROM images in the sdcard and use those while booting android (basically you only have to update init.rc for that).
Check 'multiboot' in my signature for more details.
Click to expand...
Click to collapse
Can we edit bootloader?
Sent from my XPERIA X8 using xda premium
fotak-x said:
Can we edit bootloader?
Sent from my XPERIA X8 using xda premium
Click to expand...
Click to collapse
First make it unlockable for newer devices
Then edit
sent from my W8 using client-server technology
fotak-x said:
Can we edit bootloader?
Sent from my XPERIA X8 using xda premium
Click to expand...
Click to collapse
S1loader is not open source to work with. You could hex-edit it if you had some easy way to flash it and recover from the countless hard bricks the bootloader development process has. Unfortunately this is doable via jtag only. My knowledge is limitted on that area.
Sent from my Galaxy Nexus using xda app-developers app
As for the bootloader, what could be the first real-time editor hex can perform a large change in the machine switched on.
When it comes to dual boot I can help not only the development of a test.
slightly going back bootloader to my x8 from the beginning she had unlocked (date of manufacture 10W40 surprisingly). I had not unlocked. To change the kernel or other heavy operations.Never failed to I managed to brick trying to do specifically
not worried about the phone I'm always ready to purchase a new...
The idea of a modified bootloader is nice, but it have two problem.
1. Modify the bootloader to add capability to boot directly from sdcard is basically useless because this is possible with a simple script in a modified ramdisk. Check the post from nAa, or search the thread about nBoot from feherneoh. This is easy and not need to do dangerous things.
2. The modification of the bootloader is near impossible because:
- the working of S1Boot is not documented
- this is a non-standard raw binary, hard to disassembly/decompile
- if someone can disassembly it correctly, need VERY HIGH skills in native arm assembly programming
- need special hardwares to revive the dead phone after all failed modifications (special cables, setool, etc...)
Don't forget: we had to wait more than a year to get unlocked bootloader (and this modification only skip the security verification), and this is working only with devices what older than 1-1,5 years.
I think if someone have these prerequisites, better if he/she working on valuable things instead of boot from sdcard (add fastboot support to bootloader, etc...)
I was thinking of making nBoot work with JB (it didn't). If that fails we will come up with a new method.
It's almost impossible for us to re-write the bootloader.
It would be super cool if someone added fastboot support to our bootloaders.
nobodyAtall said:
The bootloader won't boot directly from the sdcard.
Click to expand...
Click to collapse
maybe not in our device but its not impossible
http://forum.xda-developers.com/showthread.php?t=2061437
stamatis said:
maybe not in our device but its not impossible
http://forum.xda-developers.com/showthread.php?t=2061437
Click to expand...
Click to collapse
Obviously I was talking about these devices not some Samsung one...
@sgt. meow fastboot support is not something that can be added to an existing bootloader. The bootloader itself has to support this protocol. Hence the only solution would be to switch to another bootloader which would have to be ported from scratch for these devices.
The job would require a tremendous amount of effort since not even miniloader works for them!
Can we use dd to write an entire directory to a .img file? I'm thinking of something.
@nAa
I know. I was just unaware that bootloaders could be ported for our device (even if it meant no sleep for 6 months for the brave dev).
sgt. meow said:
Can we use dd to write an entire directory to a .img file? I'm thinking of something.
@nAa
I know. I was just unaware that bootloaders could be ported for our device (even if it meant no sleep for 6 months for the brave dev).
Click to expand...
Click to collapse
Mtd devices are not block devices. What are you trying to achieve?
Sent from my Galaxy Nexus using xda app-developers app
I was thinking of using feherneoh's nBoot, but in a different way. My idea was to somehow write the current ROM's /system to system.img on sdcard and the same thing with data and cache. Then install another ROM that uses the same kernel (JellySony for example). Then if XXX is present in /sdcard, it would mount system.img as /system (and the same with data and cache), thus enabling dual-boot. In a kinda stupid way.
sgt. meow said:
I was thinking of using feherneoh's nBoot, but in a different way. My idea was to somehow write the current ROM's /system to system.img on sdcard and the same thing with data and cache. Then install another ROM that uses the same kernel (JellySony for example). Then if XXX is present in /sdcard, it would mount system.img as /system (and the same with data and cache), thus enabling dual-boot. In a kinda stupid way.
Click to expand...
Click to collapse
This is how my multiboot mod worked actually - except from the fact that back in those days we couldn't flash custom kernels and the whole job was done via the chroot/hw_config.sh hack.
The bummer is you can't switch kernels so multiboot between say gb and jb is not possible.
nobodyAtall said:
S1loader is not open source to work with. You could hex-edit it if you had some easy way to flash it and recover from the countless hard bricks the bootloader development process has. Unfortunately this is doable via jtag only. My knowledge is limitted on that area.
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
...where can i find s1loader in phone? can i pull it out?just curious.....
fotak-x said:
...where can i find s1loader in phone? can i pull it out?just curious.....
Click to expand...
Click to collapse
There are two options:
- Export all the partitions (I think the file is nand_partitions.c) from kernel. The mtdump/dd it.
- Use the mtdmapper module that is in the unlocking bootloader tool to get all the partitions to map and then dump it.
Both ways basically do the same thing and they both have a pretty BIG chance of getting your device hard bricked (even when you are in read-only mode).
(I know this thread maybe should belong to Development forum, but I'm posting here since I don't have enough posts to discuss there yet)
I'm in the second year of Computer Science, being a dynamic/interpreted languages programmer for over 6 years now, C/C++ for 2 years.
I have a solid understanding on the x86 PC architecture: interrupts, buses, etc. I'm pretty good at basic x86 assembly... Been studying UEFI for over a month... Whatever.
I've lost the past couple hours searching but didn't find anything on the architecture of our device. Is the "Bootloader" here compared to a BIOS? Or is it like any PC bootloader (MS-DOS, Windows, Linux bootloaders). Is there anything like a BIOS at all or does the OS, once booted, manages all the hardware interrupts by itself? Can I use INT 10H on XT890? Is it ANYTHING close to the PC architecture?
PCI, ISA, (parallel and serial) "ports" managed by a chipset between the peripherals and the x86 core itself?
Ok, it's x86. Once the system has booted, we can call x86 instructions, ok... But what is under that? Is there any reference on this? How can I boot my own code, if it's not Linux?
I really got nowhere trying to learn about the architecture underneath Android and Motorola's Bootloader on Medfield. Found nothing on Intel nor Motorola websites. What am I doing wrong?
Thanks in advance!
I'm studying this myself but there is a lot that i need to learn. Check those to see if helps.
http://bootloader.wikidot.com/android
http://elinux.org/Android_Booting
http://www.ibm.com/developerworks/linux/library/l-linuxboot/
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Using @thiagomtl's links, I was able to understand a little more about the Boot process. XT890 seems to have basically the same mechanics of the ARM ones, but x86 tuned.
However I'm yet to understand the differences between "normal" Linux bootstrapping and the Android Bootloader's one.
On a average legacy Linux box we have GRUB/LILO on the MBR. Making a hell of a simplification here: The user turns the PC on, BIOS does the POST and then loads whatever code is on the MBR. GRUB is a very small program there, which simply loads a driver for the storage device, loads vmlinuz and the f*ing ramdisk on the memory and executes it (effectively by simply pointing the IP to the address where the kernel is on the memory).
Samuelgames said:
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Click to expand...
Click to collapse
But the Boot process is just a part of my original question. Ok, a important one, but a part.
What about the structure of the device? How it's all implemented? Is the display using plain old VESA VBE? Are the input devices PS/2? USB? Is the power implemented using ACPI standards? lol
As far as I'm concerned Atom SoC doesn't respect many industry standards for the architecture, even for those who run Windows 8, buttons on the Razr I should be naturally be defined as GPIO as the notification LED, I don't think the display respects VESA standards (SGX 540 can't even do scaling) but it should fallback to them at some extent depending on how you initialize the framebuffer.
All of this should be in the Motorola kernel, I haven't taken a look at it but I'll surely will once I get my phone
@Hazou, @YaPeL, @Omar-Avelar
you guys know anything about this?
Ok this is all i know about it by searching through the code and internet and by finding out myself (no sources included, just my memory). It's all linux, nothing like Windows.
Kernel:
We indeed are making a x86 kernel, but not for normal PC's. We use the mid-x86 implementation within the x86 code of the kernel. (arch/x86/platform/mid-x86) MID is the intel word for all the socs for mobile platforms intel is using. The normal upstream linux doesn't provide all the necessary code. And is has changed with the new android version 4.4.2 for our device.
Boot sequence:
The android devices use some sort of bootloader. Droidboot. Droidboot includes the fastboot commands and starts the bringup of the android system. You can read about it on the internet. In most devices (ARM) it is the first thing thats get called for.
Our intel device is a little different. Before the droidboot gets loaded the firmware of the device loads another OS. Also called POS (i think preprocessor OS, or something). Those gets updated with the dix and efwi(wrong name) files we got. The POS can be accessed by booting in the medfield download through the camera button, if i am correct. The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
To comment about the JB implementation.
We can build our own kernel and we can, if we want and take the time, upgrade the kernel to the newest version (for android is that 3.10, but we should be able to manage to go fully upstream 3.17). But that takes a lot of time.
I also noticed that, from what i heard, some kernel modules specific for our device has changed and now the kernel that we have can't load the new firmware files in 4.4. So we will need the next kernel from Moto to compile our own when 4.4.2 is released. Those changed are not upstream.
Hazou said:
The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
Click to expand...
Click to collapse
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Flacid Monkey said:
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Click to expand...
Click to collapse
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Hazou said:
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Click to expand...
Click to collapse
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Flacid Monkey said:
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Click to expand...
Click to collapse
I am almost certain it can be fixed as long as it is a software failure (some maybe have a hardware failure). As this seems one of them it should be fixable as long as your BL is unlocked. With a locked bootloader u don't stand any chance (nah, maybe with medfield flasher, but that one is also limited).
Take a look at the acer padphone or something. Dunno how it is called exactly. Is also uses the intel SOC and makes use of the medfield flasher.
I never had a phone thats corrupt so can't say much about it, but i can help with thinking my way through. If u have that problem can u boot in fastboot or is that even impossible? I know we can flash the POS and fastboot through xfstk. So with the right combination it should work. And if not we can try flash the modem as extra if that is possible. But do know it can hard-brick the device (modem, lowest thing of the device) of-course, aldo u don't have much choice now
Another thing, because fastboot (and even recovery) can flash the dix, ifwi and bootloader files. I 'assume' xfstk (that can also flash the ifwi, dix and bootloader) can flash the whole emmc with indeed the right parameters. We have the source code of the fastboot/recovery ifwi, dix and bootloader flasher. Also called update_osip.
So think it out, i will wait and see.
uart console
Has somebody tried to access a uart console on our razr-i? would be nice for debugging.
Intels datasheet says the board has 3 uart ports. http://ark.intel.com/products/70097
I hope one uart port can be accessed via usb or audio jack. Like on this device: http://forum.xda-developers.com/showthread.php?t=1081743
Or is it only possible with opening the phone and looking for jtag pins?
Ext4 is more TWRP friendly - boots lot more faster
How to change to ext4:
- make a nandroid backup via TWRP
- copy whole sdcard to PC
- format data with ext4 (wipe - advance wipe - change file system)
- copy sdcard back to mobile
- restore nandroid
- reboot
(- encrypt again)
Problems:
- I had the problem that sdcard was read only so apps can't save anything
SOLVED:
Code:
find /sdcard -type d -exec chmod 0775 {}
find /sdcard -type f -exec chmod 0664 {}
chown -R media_rw:media_rw /sdcard
chcon -R "u:object_r:media_rw_data_file:s0" /sdcard
(Make sure: the :o smiley means : o)
(I'm running OOS 4.0.1 and TWRP beta1)
Maybe it's faster for use with TWRP. But the phone gets a lot slower during every day use. What do you do more often - stuff in TWRP or every day tasks?
dreinulldrei said:
Maybe it's faster for use with TWRP. But the phone gets a lot slower during every day use. What do you do more often - stuff in TWRP or every day tasks?
Click to expand...
Click to collapse
Well - ext4 doesn't make phone much slower
And it boots lot faster which is important for me
Often I have to turn my phone off and boot time is nearly ½
uaiclout said:
Well - ext4 doesn't make phone much slower
And it boots lot faster which is important for me
Often I have to turn my phone off and boot time is nearly ½
Click to expand...
Click to collapse
Let's make it clear, you means boot (into TWRP) faster. I'm sure that's a small section of the minority opinion. For most people, they should leave it at F2FS. I don't know about you, but if I have to reboot into TWRP more than normal usage then I don't consider that as a smartphone, but a developing unit.
someone0 said:
Let's make it clear, you means boot (into TWRP) faster. I'm sure that's a small section of the minority opinion. For most people, they should leave it at F2FS. I don't know about you, but if I have to reboot into TWRP more than normal usage then I don't consider that as a smartphone, but a developing unit.
Click to expand...
Click to collapse
Don't forget you get more storage to use on ext4 (2-3 gigs on my 64gb OnePlus 3t) versus f2fs. The speed of doing everything from installing, uninstalling, moving files, opening apps and running apps seemed the exact same to me when I tested them.
Year I also think that f2fs and ext4 have nearly the same speed
System os does also boot bit faster with ext4 - about ¾ I would say
And of course we have more memory with ext4
This is an old post, but interesting to see nonetheless:
https://forum.xda-developers.com/showthread.php?t=2697069
It would be nice to see how much things have changed in the benchmark tests (f2fs vs Ext4) if someone would like to run an updated test with the OP3T
m0d hipp¥ said:
This is an old post, but interesting to see nonetheless:
https://forum.xda-developers.com/showthread.php?t=2697069
It would be nice to see how much things have changed in the benchmark tests (f2fs vs Ext4) if someone would like to run an updated test with the OP3T
Click to expand...
Click to collapse
f2fs uses more space for allocating certain things, but was written for flash storage. it will almost always win over ext4, if you don't see much of an improvement, then there could be many factors involved. e.g. kernel code, or processor limits on older devices.
I would like to see benchmarks too.
the main advantage of ext4, is it's age and stability, it has error checking capabilities, last i heard, f2fs does not. (similar to chkdsk in windows)
And that is why OP5 used ext4
What's the size of system, data and cache partitions for the Xiaomi Mi8?
Could you please show the sizes of its partitions, please?
I haven't bought the mobile yet.
I've had problems with older mobiles because these partitions are too small and many apps complain, specially Google services.
There are some complex tutorials to modify partition sizes with adb commands but are specific to each phone.
What's the best/easiest way to achieve it with the Xiaomi Mi8?
skanskan said:
What's the size of system, data and cache partitions for the Xiaomi Mi8?
Could you please show the sizes of its partitions, please?
I haven't bought the mobile yet.
I've had problems with older mobiles because these partitions are too small and many apps complain, specially Google services.
There are some complex tutorials to modify partition sizes with adb commands but are specific to each phone.
What's the best/easiest way to achieve it with the Xiaomi Mi8?
Click to expand...
Click to collapse
What you're talking about is issues with old budget phones.
Even the modern budget phones have partitions big enough to fit files in without issues.
And the Mi 8 is a flagship so you have nothing to worry about when it comes to partition sizes.
The Marionette said:
What you're talking about is issues with old budget phones.
Even the modern budget phones have partitions big enough to fit files in without issues.
And the Mi 8 is a flagship so you have nothing to worry about when it comes to partition sizes.
Click to expand...
Click to collapse
Anyway, could you please tell me the size of its partitions, please?
Just to know the information.
Thanks
The Marionette said:
What you're talking about is issues with old budget phones.
Even the modern budget phones have partitions big enough to fit files in without issues.
And the Mi 8 is a flagship so you have nothing to worry about when it comes to partition sizes.
Click to expand...
Click to collapse
In another forum somebody has just told me his mobile has this partitions (diskinfo):
Data 52.5 G 3.9 used 48.4GB free
System 2.9G 2.1G used 872MB free
Ram 5.5. GB 2.9GB used 1.6GB free
As you can see the System partition is quite small and almost full, even if the phone is a new model the problem is still there.
We need a method to easily enlarge that system partition, and maybe other not shown there.
skanskan said:
In another forum somebody has just told me his mobile has this partitions (diskinfo):
Data 52.5 G 3.9 used 48.4GB free
System 2.9G 2.1G used 872MB free
Ram 5.5. GB 2.9GB used 1.6GB free
As you can see the System partition is quite small and almost full, even if the phone is a new model the problem is still there.
We need a method to easily enlarge that system partition, and maybe other not shown there.
Click to expand...
Click to collapse
You're the only one who thinks that. Try repartitioning yourself but don't complain when you brick your phone.
skanskan said:
We need a method to easily enlarge that system partition, and maybe other not shown there.
Click to expand...
Click to collapse
I've done this job, in the past, with my Oppo Find 7 (see here - https://forum.xda-developers.com/fi...st-custom-storage-partitions-v1-oppo-t2930576).
I discourage all of you to repeat a job like this - unless you have a tool (usually a MS Windows tool) that recreates all the storage's internal partitions (jn the same way as done in factory) and only if you have a very high-level know-how to face and solve all possible issues and matters - be even ready to say good-bye to your phone !!!
italianquadcore said:
I've done this job, in the past, with my Oppo Find 7 (see here - https://forum.xda-developers.com/fi...st-custom-storage-partitions-v1-oppo-t2930576).
I discourage all of you to repeat a job like this - unless you have a tool (usually a MS Windows tool) that recreates all the storage's internal partitions (jn the same way as done in factory) and only if you have a very high-level know-how to face and solve all possible issues and matters - be even ready to say good-bye to your phone !!!
Click to expand...
Click to collapse
This is the kind of tutorial I've already seen before.
The problem is almost always the same, the rely on a script designed specifically for a phone model.
I could try to translate that script to my phone using generic adb and linux commands but it will be dangerous.
I've also heard that some versions of TWRP can resize the partitions easily. It would be great to get it on the Mi8.
What is the worst thing that can happen if all goes wrong?
Wouldn't I solve it by just wiping everything from a fastboot and resintalling a ROM?
Regards.
skanskan said:
This is the kind of tutorial I've already seen before.
The problem is almost always the same, the rely on a script designed specifically for a phone model.
I could try to translate that script to my phone using generic adb and linux commands but it will be dangerous.
I've also heard that some versions of TWRP can resize the partitions easily. It would be great to get it on the Mi8.
What is the worst thing that can happen if all goes wrong?
Wouldn't I solve it by just wiping everything from a fastboot and resintalling a ROM?
Regards.
Click to expand...
Click to collapse
There is no reason to touch the partitions of modern smartphones, all the most important partitions are big enough to contain all binary codes for the operating system and personal data we need.
Whenever we unlock the bootloader, we have full access of the emmc, so we can even delete/resize/create partitions. The first con is that we could not start the phone anymore, due to the fact that android, recovery and fastboot, reside in three different partitions. If we delete these partitions, there is no way to access the smartphone. In this case an external application for Windows or Linux (created by the manufacturer) must be used to rewrite all the emmc again, recreating the partitions and rewriting them, in the same way as done in factory. This application is the most important piece of software we must have if we want to mod our smartphone.