GPT header is always at LBA 1 and spans only one sector. Partition Array on the other hand is not fixed.
I don't know how Rockchip does, but with GPT, having huge number of partitions, it would be better to rely on them instead of hadrcoded locations for uboot. except the ROM code wouldn't find uboot then. even though it's trivial to add GPT parsing for finding the needed partitions, they wouldn't want to change it.
By the way, I know, that most of available builds (armbian being an exception) keep using rockchip disk layout and the latter does use GPT scheme, Did you know, that with GPT, you cannot just use dd (alone) for putting an image onto the target medium. you need at least to have some process (installation is its proper name, ideally) in addition, that would regenerate GUIDs on every partition and disk and CRC, in both GPT zones - main and backup. this is something that I see is totally neglected now and violated (and what bugs me honestly). having the same GUIDs on entities, intended to have them unique, is a standard violation and might have unpleasant practical consequenses. GPT aware utilities might get confused and corrupt your data. and as we see, with people constantly copying from SD to eMMC, USB storage, HDD, SSD and running them both, this scenario is not something unreal.
Overall, GPT requires more careful handling during flashing, than plain copying, at the service utilities side. for example GPT mandates putting the backup GPT header at the last block of the device. apparently this means that flashing by copying would shrink the target medium to the size of the source medium. resizing here is more than writing somewhere, that this disk is 256GB instead of 8GB - you need to generate backup GPT header and Partition Array at right places, adjust fields everywhere and recalculate CRC. this should be done in a strict sequence to guarantee consistence. It has been seen on this forum not once, when people complained about their storages got irreversibly shrunk, and this was reported on many machines they tried without possibilities to fix. this might have something to do with messing up GPT. It was intended to use one, real size, - you generate GPT structures for a new device, not create them by silly copying another device as a whole and then "resizing" it. the latter might go wrong, resulting in a device lacking most of its payload space. maybe some utilities think, it's wrong to move backup GPT header. but without this, resizing is impossible - your fatty eMMC would turn into slim eMMC for everything, that takes disk size by thoroughly analyzing corresponding GPT header fields. neglecting GUID uniqness requirement could be even worse (confusing one disk with another, when writing, what else could be worse).
I don't know how Rockchip does, but with GPT, having huge number of partitions, it would be better to rely on them instead of hadrcoded locations for uboot. except the ROM code wouldn't find uboot then. even though it's trivial to add GPT parsing for finding the needed partitions, they wouldn't want to change it.
By the way, I know, that most of available builds (armbian being an exception) keep using rockchip disk layout and the latter does use GPT scheme, Did you know, that with GPT, you cannot just use dd (alone) for putting an image onto the target medium. you need at least to have some process (installation is its proper name, ideally) in addition, that would regenerate GUIDs on every partition and disk and CRC, in both GPT zones - main and backup. this is something that I see is totally neglected now and violated (and what bugs me honestly). having the same GUIDs on entities, intended to have them unique, is a standard violation and might have unpleasant practical consequenses. GPT aware utilities might get confused and corrupt your data. and as we see, with people constantly copying from SD to eMMC, USB storage, HDD, SSD and running them both, this scenario is not something unreal.
Overall, GPT requires more careful handling during flashing, than plain copying, at the service utilities side. for example GPT mandates putting the backup GPT header at the last block of the device. apparently this means that flashing by copying would shrink the target medium to the size of the source medium. resizing here is more than writing somewhere, that this disk is 256GB instead of 8GB - you need to generate backup GPT header and Partition Array at right places, adjust fields everywhere and recalculate CRC. this should be done in a strict sequence to guarantee consistence. It has been seen on this forum not once, when people complained about their storages got irreversibly shrunk, and this was reported on many machines they tried without possibilities to fix. this might have something to do with messing up GPT. It was intended to use one, real size, - you generate GPT structures for a new device, not create them by silly copying another device as a whole and then "resizing" it. the latter might go wrong, resulting in a device lacking most of its payload space. maybe some utilities think, it's wrong to move backup GPT header. but without this, resizing is impossible - your fatty eMMC would turn into slim eMMC for everything, that takes disk size by thoroughly analyzing corresponding GPT header fields. neglecting GUID uniqness requirement could be even worse (confusing one disk with another, when writing, what else could be worse).
ANT - my hobby OS for x86 and ARM.
