What's interesting to me is that, even with a Magisk-patched boot.img, the flash process is still able to boot into userspace fastboot (new with Android 10), and the rest of the flash seems to go by totally fine.
# when installed with a full factory image, will boot, and Magisk will be active # Result: The same patched boot image as before, that caused a boot failure # Result: The image will flash, and the device will boot without Magisk # Verify that rezipping the image did not cause the issue: # Result: The image will successfully flash, but fail to boot # Overwrite the boot.img in the factory image # (Do this manually, save to patched_boot.img) Steps to reproduce (using Google factory image as an example): If I were to flash an unpatched factory image, boot it once, and then boot the exact same boot.img I attempted to embed in the factory image, it will work just fine, and Magisk will be active.
The bootloader won't say anything surrounding having issues with "boot.img," it will just say "no valid slot to boot." Since you can actually reach the "G" logo, I don't think anything is necessarily "wrong" with the patched boot.img, but it seems the rest of the install doesn't complete successfully when it is in place. It will reach the "G" logo on a stock Google image (or the "android" logo on an AOSP build), then abruptly reboot, try the next boot slot, then ultimately fail and go back to the bootloader. I have (what I believe is) a very good reason for doing so, but there seems to be an issue with how the patched boot.img behaves during a typical flash.īasically, when you send a Magisk-patched boot.img as part of a factory image flash (via flash-all.sh present in a full factory image), the flash will succeed, but the device will not be able to boot after that. Hope above description is helpful to you.To keep things brief, I would like to flash Magisk as part of a full factory image flash. In addition, it is very simple to flash u-boot, only one command you need: If you like, you can seperate it to 3 scripts for your purpose. # if you don't want to write u-boot.imx to eMMC here, comment below line, please!įB: ucmd if env exists emmc_ack then else setenv emmc_ack 0 fi įB: ucmd setenv emmc_cmd mmc partconf $Ībove commands can ensure OS Firmware to run in DDR, then begin to write kernel dtb / zImage and rootfs to eMMC. # you can use kernel to do that for specific boards # becaue difference chip, offset is difference SDPU: write -f u-boot.imx -offset 0x57c00 # These commands will be run when use SPL and will be skipped if no spl # This command will be run when ROM support stream mode # | optee image, put dummy _uTee.tar file here if platform is not MX6/MX7* # | kernel image, arm64 is Image, arm32 it is zImage # Please Replace below items with actually file names Pay attention to this: each script should have these commands at begining: Then using these commands to flash them to eMMC: for example, u-boot-script.uuu, zImage-dtb.uuu & rootfs-script.uuu. So if you understand how the script is working, you can seperate 3 script: flashing u-boot, flashing dtb & zImage, flashing rootfs. If you don't want u-boot to do it, you can commment the line.
In the script, u-boot can write itself to eMMC. (2) writing u-boot-imx / kernel dtb / zImage & rootfs to eMMC or other flash on board.
(1) Loading u-boot-imx / kernel dtb / zImage / ramfs to DDR, then run it.
#FBK: ucmd tar -xf /tmp/op.tar -C /mnt/fat Name should be changed to beįsl-image-mfgtool-initramfs-imx_.u-bootĬomment these 2 lines if there is no optee. In our demo image, the ramfs has been provided, you don't need to recompile it. (4) _.uboot - >Using the one provided in Demo Image. (3) _board.dtb - > your dtb's name in linux kernel Other lines including _flash.bin should be changed by u-boot.imx SDP: boot -f _flash.bin (Here _flash.bin should be replaced with u-boot.imx) # This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ so you should modify the script for yours. I.MX6/7 are the same as that of i.MX8MM & I.MX8MQ.