[Android Q&A, Help & Troubleshooting] mirfatif:
Continued from OP...

SECTION 3

QUERIES:

UNCERTAIN PARTITIONS

But there are no images available for these 10 partitions in factory firmware:

pad, modemst1, modemst2, fsc, ssd, DDR, keystore, config, oem & devinfo.

These seem to be very essential for OS, also containing IMEI if I'm not mistaken? I'm not sure of their contents. How system working without them? All are useless?

HOW TO COMPLETELY BOOT FROM SD CARD

In boot.img, "fstab.qcom" contains mount paths for system & userdata. While "init.target.rc" contains only mount paths for cache, persist and modem. In total 5 partitions which are mounted (checked by '

mount

').

shell@l5510:/ $ mount | grep mmcblk1

/dev/block/mmcblk1p24 /system ext4 rw,seclabel,relatime,discard,data=ordered 0 0
/dev/block/mmcblk1p32 /data ext4 rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc 0 0
/dev/block/mmcblk1p26 /cache ext4 rw,seclabel,nosuid,nodev,relatime 0 0
/dev/block/mmcblk1p25 /persist ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/mmcblk1p1 /firmware vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
shell@l5510:/ $

So the primary question is:

How to change mount source of other partitions from mmcblk0 to mmcblk1? Or how to force OS to read the essentially required partitions from mmcblk1 instead of mmcblk0?

Need to modify any other files in ramdisk or kernel-zimage or in /system or to modify init.d scripts or create new scripts? Any help?

Other than 10 partitions mentioned above, these "not mounted" partitions also include modem, sbl1, aboot, rpm, tz and hyp and fsg. Modem contains bootable code of MBR and following 5 are also executable binaries. I think these are all part of bootloader i.e. loading in initial booting process and not required by OS. But what about the fsg and ten others? Where are those used? Here is a partition detail.

Another primary issue is:

I think it's almost impossible to make Boot ROM (CPU embedded) hand over charge to bootloader at "mmcblk1". "mmcblk0" must be hardcoded in Boot ROM.

So, how to make bootloader load "kernel" and "rootfs" from mmcblk1p* instead of mmcblk0p*? Like there are switches in testing devices to optionally boot from different memories. Can we modify "aboot" (the little kernel) or "emmc_appsboot.mbn" ELF binary for this purpose? It must be complicated as bootloaders are signed by vendor (Qualcomm) and involve low-level programming as discussed here. Right?

Or in other words, how to force bootloader to read partition table from dev/mmcblk1 instead of dev/mmcblk0?

If we can't do this, system doesn't know how to boot in the absence of eMMC. That would have to be done through fastboot everytime we need to. Because boot chain will be stuck at bootloader.

Multi-booting solutions are also dependent on a fully working /boot partition on eMMC because they (one way or the other) re-flash/replace modified boot image every time a ROM is to be switched. EFIDroid is a secondary bootloader but that too replaces /boot and/or /recovery.

I have gone through this, this, this and this. But they only address partial booting from sd card e.g. dual booting in which only /system, /data and /cache are involved. None has discussed complete boot from sd. Is it really impossible? This link gives a little hope but it points to a ready made solution (bootloader) which boots kernel from SD card. But it gives no explanation how.

I have also come across a few threads discussing Samsung (and HTC too) booting from SD Card as a fix to QHSUSB_DLOAD mode or bricked-bootloaader state. They extracted "debrick" file from a working phone and flashed that to the start of SD Card. Debrick file seems to be a single bootloader file containing all bootloaders in it as explained here and here. So after flashing the bootloader(s) with its accompanying partitions to SD Card, when device was powered on, it automatically booted from SD Card. If it's that simple for all devices with Qualcomm SoC, the only thing I have to do is :laugh:

[COLOR="Red"]dd if=/dev/zero of=/dev/block/mmcblk0 bs=1m count=200[/COLOR]

Any suggestions? I believe this must be possible as they are discussing here.

Edit: Related quote from [GUIDE][9008][EDL|QDL][QUALCOMM ONLY] Unbrick via external sdcard (no QFIL!):

Some secondary questions:

HOW ARE PARTITIONS IDENTIFIED BY BOOT-ROM WITHOUT PARTITION TABLE ON eMMC

If there is no readable partition table on a bricked eMMC, how Boot ROM (primary bootloader on SoC) switches control to secondary bootloader or bootable modem partition or other partitions used by processors? Means how SoC / Processors locate modem, sbl, rpm, tz or aboot (the little kernel's offspring) on eMMC? Also, why '

parted /dev/block/mmcblk0 p

' and '

sgdisk --print /dev/block/mmcblk0

'show partitions if there is no table?

Though parted-2.2 shows warning:

[COLOR="Red"]Error: Both the primary and backup GPT tables are corrupt. Try making a fresh
table, and using Parted's rescue feature to recover partitions.[/COLOR]

Or I'm thinking in wrong direction? This link discusses the issues but I'm not clear how it works.

How is this "specific block" located by cpu ROM?

It's talking about some "low-level" and "high-level" partition tables. How they differ? How can we manipulate the former?

And finally...

HOW TO SPEED UP SD CARD

Other than using a UHS-III or the most recent and expensive App Performance Class (A1) sd card, what changes we can make to kernel to boost read/write speed? Otherwise, it's almost useless with too slow speed, frequent ANRs, hangs and laggings.

Default I/O scheduler being used on QMobile Z8 is cfq with default tune-able settings. I think it's one of best schedulers for higher throughput. Na? Try other? Details here:

root@l5510:/ # cat /sys/block/mmcblk0/queue/scheduler
noop deadline row [cfq]

root@l5510:/ # for fyle in $(find /sys/block/mmcblk0/queue/iosched/ -type f); do echo $fyle; cat $fyle; done;
/sys/block/mmcblk0/queue/iosched/fifo_expire_async
50
/sys/block/mmcblk0/queue/iosched/group_idle
0
/sys/block/mmcblk0/queue/iosched/quantum
20
/sys/block/mmcblk0/queue/iosched/slice_async
40
/sys/block/mmcblk0/queue/iosched/slice_idle
10
/sys/block/mmcblk0/queue/iosched/slice_sync
100
/sys/block/mmcblk0/queue/iosched/low_latency
0
/sys/block/mmcblk0/queue/iosched/fifo_expire_sync
50
/sys/block/mmcblk0/queue/iosched/back_seek_max
16384
/sys/block/mmcblk0/queue/iosched/target_latency
300
/sys/block/mmcblk0/queue/iosched/back_seek_penalty
2
/sys/block/mmcblk0/queue/iosched/slice_async_rq
2

root@l5510:/ # cat /sys/block/mmcblk1/queue/scheduler
noop deadline row [cfq]

root@l5510:/ # for fyle in $(find /sys/block/mmcblk1/queue/iosched/ -type f); do echo $fyle; cat $fyle; done;
/sys/block/mmcblk1/queue/iosched/fifo_expire_async
50
/sys/block/mmcblk1/queue/iosched/group_idle
0
/sys/block/mmcblk1/queue/iosched/quantum
20
/sys/block/mmcblk1/queue/iosched/slice_async
40
/sys/block/mmcblk1/queue/iosched/slice_idle
10
/sys/block/mmcblk1/queue/iosched/slice_sync
100
/sys/block/mmcblk1/queue/iosched/low_latency
0
/sys/block/mmcblk1/queue/iosched/fifo_expire_sync
50
/sys/block/mmcblk1/queue/iosched/back_seek_max
16384
/sys/block/mmcblk1/queue/iosched/target_latency
300
/sys/block/mmcblk1/queue/iosched/back_seek_penalty
2
/sys/block/mmcblk1/queue/iosched/slice_async_rq
2
root@l5510:/ #

Tried different cache values (read_ahead_kb) from 64 to 4048. Makes no difference apparently.

Also disabled jounalling using '

tune2fs -O ^has_journal

' and e2fsck checks using '

tune2fs -c -1

'.

Changed mount options to for /data and /cache:

root@l5510:/ # mount | grep -E "/cache|/data"

/dev/block/mmcblk1p32 /data ext4 rw,seclabel,[B]noatime,discard,nobarrier,noauto_da_alloc,commit=60[/B] 0 0
/dev/block/mmcblk1p26 /cache ext4 rw,seclabel,noatime,discard,nobarrier,noauto_da_alloc,commit=60 0 0

root@l5510:/ #

Seems useless so far. Any ideas? Or it's a hardware limitation of device?

Is there a way to get rid of FUSE and use ext4 in true sense for whole /data (only possible if someone is willing to quit using MTP), though it doesn't matter much for Android's internal operations? But it's a real pain for I/O operations on external media.

Edit: Speed much improved by using a more certain branded SD Card; Sandisk C-10.

[MENTION=6787237]yoAeroA00[/MENTION] Sir need your special attention for kernel part. You have a good history with kernel tweaking and multibooting.