Warning! TL/DR - stop here!
https://forum.xda-developers.com/sho....php?t=2450045
Within a root shell the concatenation of these commands and multiplying the blocks by 1024 was:
BoardConfig.mk
https://www.cnx-software.com/2016/11...ogic-tv-boxes/
Using that to build the .img extractor as "amlxtract" I uncompress original image file flashed to device.
_aml_dtb.PARTITION and meson1.dtb are identical so renamed one of them to "dtb" and placed it in device/amlogic/p212_N/ overwriting the existing.
Extract recovery.img (recovery.PARTITION) then initrd.img.
initrd.img:
Rename zImage to kernel and move to device/amlogic/p212_N/ .
Could take contents of initrd.img and place in device/amlogic/p212_N/recovery/root
This is where things complicate. Essentially anything in device/amlogic/p212_N/ is an override. In other words, whatever kernel the TWRP build process creates will be ignored in favor of the override kernel provided. Overwriting the entire contents of device/amlogic/p212_N/recovery/root would negate the entire build process. It'd be the same as rebuilding stock recovery.
I figure first step (in Linux) is to do "rmdir *" to remove empty folders, then delete any symbolic links. Of course we'd want to retain init-recovery.amlogic.rc and etc twrp.fstab. Theoretically it makes sense to override only those files absolutely necessary and let TWRP build what it requires. The more overrides, the more conflicts.
Not sure if twrp.fstab should be edited with the initial filesystem information gleaned. If so it looks more like this:
https://github.com/minimal-manifest-...fest_twrp_omni
Pull Magendanz repo directly into twrp-5.1 tree
device/amlogic/p212_N/vendorsetup.sh
Now build
Build is successful and I use android app named "rashr" to flash custom recovery then reboot into it. Hasn't worked so far [success! see next post] whether I build against twrp-5.1 or twrp-7.1.
From my observation, the choice of twrp tree has a major impact on cross-compilation, with included tool-chain. Since we're going to use the kernel from stock recovery (which matches that found in stock boot.img (boot.PARTITION)) it's important that the build process outputs software compatible with the provided kernel.
Pretty sure everything is correct. I don't edit the dtb or kernel but may use too many overrides. Will keep at it no matter how long it takes to figure this out.
https://forum.xda-developers.com/sho....php?t=2450045
Within a root shell the concatenation of these commands and multiplying the blocks by 1024 was:
Code:
cat /proc/partitions ls -al /dev/block/platform/*.emmc/by-num ls -al /dev/block/platform/*.emmc/ ls -al /dev/block/platform/*.sd/by-num ls -al /dev/block/platform/*.emmc/ major minor #blocks name mount blks*1024 7 0 65536 loop0 67108864 253 0 512000 zram0 524288000 179 0 15155200 mmcblk0 15518924800 179 1 4096 mmcblk0p1 -> /dev/block/bootloader 4194304 179 2 65536 mmcblk0p2 -> /dev/block/reserved 67108864 179 3 524288 mmcblk0p3 -> /dev/block/cache 536870912 179 4 8192 mmcblk0p4 -> /dev/block/env 8388608 179 5 32768 mmcblk0p5 -> /dev/block/logo 33554432 179 6 32768 mmcblk0p6 -> /dev/block/recovery 33554432 179 7 8192 mmcblk0p7 -> /dev/block/rsv 8388608 179 8 8192 mmcblk0p8 -> /dev/block/tee 8388608 179 9 32768 mmcblk0p9 -> /dev/block/crypt 33554432 179 10 32768 mmcblk0p10 -> /dev/block/misc 33554432 179 11 32768 mmcblk0p11 -> /dev/block/boot 33554432 179 12 2097152 mmcblk0p12 -> /dev/block/system 2147483648 179 13 12152832 mmcblk0p13 -> /dev/block/data 12444499968 179 32 4096 mmcblk0boot0 -> /dev/block/mmcblk0boot0 4194304 179 64 4096 mmcblk0boot1 -> /dev/block/mmcblk0boot1 4194304 179 96 128 mmcblk0rpmb -> /dev/block/mmcblk0rpmb 131072
Code:
# Partitions BOARD_RECOVERYIMAGE_PARTITION_SIZE := 33554432 BOARD_BOOTIMAGE_PARTITION_SIZE := 33554432 BOARD_SYSTEMIMAGE_PARTITION_SIZE := 2147483648 BOARD_USERDATAIMAGE_PARTITION_SIZE:= 12444499968 BOARD_CACHEIMAGE_PARTITION_SIZE := 536870912 BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := ext4 BOARD_FLASH_BLOCK_SIZE := 131072
Using that to build the .img extractor as "amlxtract" I uncompress original image file flashed to device.
Code:
_aml_dtb.PARTITION _aml_dtb.VERIFY aml_sdc_burn.ini aml_sdc_burn.UBOOT bootloader.PARTITION bootloader.VERIFY boot.PARTITION boot.VERIFY DDR.USB logo.PARTITION logo.VERIFY meson1.dtb platform.conf recovery.PARTITION recovery.VERIFY system.PARTITION system.VERIFY UBOOT.USB
Extract recovery.img (recovery.PARTITION) then initrd.img.
Code:
bootimg.cfg initrd.img zImage
Code:
acct boot bugreports -> /data/user_de/0/com.android.shell/files/bugreports cache charger -> /sbin/healthd config d -> /sys/kernel/debug data default.prop dev etc file_contexts.bin fstab.amlogic init init.rc init.recovery.amlogic.rc mnt oem proc property_contexts res sbin sdcard seapp_contexts selinux_version sepolicy service_contexts storage sys system tmp ueventd.amlogic.rc ueventd.rc vendor -> /system/vendor
Could take contents of initrd.img and place in device/amlogic/p212_N/recovery/root
This is where things complicate. Essentially anything in device/amlogic/p212_N/ is an override. In other words, whatever kernel the TWRP build process creates will be ignored in favor of the override kernel provided. Overwriting the entire contents of device/amlogic/p212_N/recovery/root would negate the entire build process. It'd be the same as rebuilding stock recovery.
I figure first step (in Linux) is to do "rmdir *" to remove empty folders, then delete any symbolic links. Of course we'd want to retain init-recovery.amlogic.rc and etc twrp.fstab. Theoretically it makes sense to override only those files absolutely necessary and let TWRP build what it requires. The more overrides, the more conflicts.
Not sure if twrp.fstab should be edited with the initial filesystem information gleaned. If so it looks more like this:
Code:
/cache ext4 /dev/block/cache /dev/block/mmcblk0p3 flags=backup=1;display=Cache /system ext4 /dev/block/system /dev/block/mmcblk0p12 flags=backup=1;display=System /data ext4 /dev/block/data /dev/block/mmcblk0p13 flags=backup=1 /boot emmc /dev/block/boot /dev/block/mmcblk0p11 flags=backup=1;display=Boot /recovery emmc /dev/block/recovery /dev/block/mmcblk0p6 flags=backup=1;display=Recovery /logo emmc /dev/block/logo /dev/block/mmcblk0p5 flags=backup=1;display=Logo;flashimg /misc emmc /dev/block/misc /dev/block/mmcblk0p10 /external_sd auto /dev/block/mmcblk1p1 flags=wipeingui;storage;removable;display="External SD" /usb-otg auto /dev/block/sda1 flags=display="USB OTG";removable;storage
https://github.com/minimal-manifest-...fest_twrp_omni
Code:
To initialize a shallow clone, which will save even more space, use a command like this: repo init --depth=1 -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-5.1 Then to sync up: repo sync Then to build: cd <source-dir>; . build/envsetup.sh; lunch omni_<device>-eng; mka recoveryimage
Code:
cd <source-dir> git clone https://github.com/Magendanz/android_device_amlogic.git --depth 1 --branch master device/amlogic
Code:
add_lunch_combo omni_p212_N-userdebug add_lunch_combo omni_p212_N-user add_lunch_combo omni_p212_N-eng
Code:
cd <source-dir> . build/envsetup.sh lunch omni_p212_N-userdebug mka recoveryimage
From my observation, the choice of twrp tree has a major impact on cross-compilation, with included tool-chain. Since we're going to use the kernel from stock recovery (which matches that found in stock boot.img (boot.PARTITION)) it's important that the build process outputs software compatible with the provided kernel.
Pretty sure everything is correct. I don't edit the dtb or kernel but may use too many overrides. Will keep at it no matter how long it takes to figure this out.
..gif "Peace Man"){kind=icon}
Comment