[BUG]: wrong GPT location after flashing in Win11 (not booting)

[KeiTHDani]

Version

2.0.0 (Dev_build) nigthly

Version type

uClibc (compatible)

Version hash

c01f3db

Issue description

The Miyoo logo is displayed, the brightness changes, and it restarts repeatedly but does not progress through the process.

Version 2.0.0 beta 2 works correctly.

I tried to force the detection by setting "v90" on "console.cfg" file but doesn't work too.

Steps to reproduce

Write MicroSD
Turn the device ON

What device are you using?

PowKiddy V90

Relevant log outputs

CONSOLE_PARAMETERS=lowcurrent=1
CONSOLE_VARIANT=v90
CONSOLE_VIDEO=st7789sfb.ko
FORCE_VERSION=v90
arch=arm
baudrate=115200
board=sunxi
board_name=sunxi
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_device=mmc0
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=fel mmc_auto usb0 
bootargs=console=tty0 console=ttyS1,115200 panic=5 rootwait quiet lpj=1015808 root=/dev/mmcblk0p2 ro
bootcmd=env export -t 0x81000000; fatwrite mmc 0:1 0x81000000 uEnv.txt ${filesize}; run distro_bootcmd;
bootcmd_args=setenv bootargs ${bootargs} miyoo_kbd.miyoo_ver=5 miyoo_kbd.miyoo_layout=1 miyoo.miyoo_snd=1 pwm-suniv.motor_ver=2 miyoo-video.driver='st7789sfb+lowcurrent=1'
bootcmd_fel=if test -n ${fel_booted} && test -n ${fel_scriptaddr}; then echo '(FEL boot)'; source ${fel_scriptaddr}; fi
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_mmc_auto=if test ${mmc_bootdev} -eq 1; then run bootcmd_mmc1; run bootcmd_mmc0; elif test ${mmc_bootdev} -eq 0; then run bootcmd_mmc0; run bootcmd_mmc1; fi
bootcmd_usb0=devnum=0; run usb_boot
bootdelay=0
bootm_size=0x1700000
console=ttyS0,115200
cpu=arm926ejs
dfu_alt_info_ram=kernel ram 0x80500000 0x1000000;fdt ram 0x80C00000 0x100000;ramdisk ram 0x80D50000 0x4000000
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
fdt_addr_r=0x80C00000
fdtcontroladdr=80e30890
fdtfile=suniv-f1c100s-generic.dtb
fileaddr=81000000
filesize=30
kernel_addr_r=0x80500000
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
mmc_bootdev=0
partitions=name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};name=loader2,size=984k,uuid=${uuid_gpt_loader2};name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};name=system,size=-,uuid=${uuid_gpt_system};
preboot=usb start
pxefile_addr_r=0x80D00000
ramdisk_addr_r=0x80D50000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x80C50000
silent=1
soc=sunxi
splashfile=miyoo-splash.bmp
splashimage=0x80000000
splashsource=mmc_fs
stderr=serial,vga
stdin=serial,usbkbd
stdout=serial,vga
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi
uuid_gpt_esp=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
uuid_gpt_system=69dad710-2ce4-4e3c-b16c-21a1d49abed3

Issues' terms

• I did not find any existing open/closed issue of same matter

[KeiTHDani]

Reviewing the "uEnv.txt" of version 2.0.0 Beta 2, after having started normally, I see that there are only two different lines.

fdtcontroladdr=80e57890
filesize=14

[Apaczer]

since you're stuck on Miyoo splash-logo, then it can't pass bootloader. To verify you could remove or rename miyoo-splash.bmp to enable logs console output and check for any errors.

[KeiTHDani]

Thank you. After renaming the file miyoo-splash.bmp I could see that there is an error in the GPT table.
I have re-recorded the image several times but it always seems to have the error in the GPT table (is it possible that the images were already generated with this error in the GPT table?).
I have corrected the GPT table manually with gdisk (options r, b and w) and now it has started normally, doing the first_boot as expected.

[Apaczer]

I must ask what's the flashing procedure (OS, flash-tool) u are using? This is smth I can easly repro on my Win machine but not on my Ubuntu while using pure dd cmd.
Starting location of part. table should be at default 2 but it somehow relocate itself after flashing (doesn't seem like genimage issue).

[KeiTHDani]

The OS is Windows 11 24H2, and i flash the SD card with Win32DiskImager as usual.
I can say that after flashing version 2.0.0 beta 2, and reviewing the SD with MiniTool Partition Wizard I can see the partition table without problem. On the other hand, after flashing beta 3, and reviewing it with the same software, it tells me that there is a problem and it is not able to identify the partitions.

[Apaczer]

I thought I was imagining things but that issue was not present in earlier 23H2 Win11 compilation and that I confirmed by checking microsoft VS issue tracker - additionaly I did verify GPT header hex value of PartitionEntryLBA and it is correct in raw image and when flashing with other OS'es, thus sector 2 (but not the case in Win11 where it dislocate it to 2034 sector). Considering we are operating on non-standard low Partition Entries value, you should wait for big MS to take action on mentioned issue.

FTTB you should use other system (linux, mac or older Windows) to flash image and after writing to disk in another environment the Win11 shouldn't try to "repair" your GPT on disk and corrupt PartitionEntryArray CRC-32 checksum.

[KeiTHDani]

I don't think this would have crossed my mind...
Sorry for not checking the raw image before warning of the problem and all the time consumed to find that the fault is this "bad behavior" caused by the OS.
I hope that at least it helps so that if it happens to someone else and they come to this post, they can solve it quickly with gdisk as I mentioned previously (which, by the way, I did from Windows 11 itself with a version of the program for it)
Thank you so much!

[Apaczer]

Yes it is an easy fix with gdisk as long as you know what are u doing (you could just relocate broken partition table to default sector). Generally speaking CRC cheksum changes either way when flashing to real disk (when target size differs), but other GPT header values should stay unchanged.

Let us leave it open for anyone using current Windows to be aware of the problem.