06-14-2020, 08:46 PM
(This post was last modified: 06-14-2020, 10:00 PM by wdt.
Edit Reason: trying to make sense out of a very confused situation
)
OK,, the boot0 and boot1 are artifacts from android, fdisk does not show them,,
so they can be ignored
blk2p1 is where idbloader is located
blk2p2 is where uboot and trust are, but I doubt that is a valid fat filesystem
Just because there is a partition listing, that says nothing about what is on the disk,,
despite the name /boot/efi
Itis odd that it starts at 4M, maybe it is an efi booted system
I suppose it could be the very 1st efi booted arm64 distro, but I doubt it
If it was an ESP, efi system partition, it will have a fat filesystem
Try mounting it, and show a directory listing, it almost certainly will fail to mount
(a fat fs needs a PBR/VBR, 2 fat tables and a / directory, this takes space,
so uboot won't be where the bootrom expects to find it. For that matter,
i doubt that rk3399 can boot in efi mode, not capable of that)
If it was an efi booted system, that should have been noted
Or maybe it's just screwed up, but you say it boots
If I understand right, you did the dd commands in post 3, so that put everything
where it is supposed to be, the bootrom cares nothing about partitions or filesystems
It's just a raw load from locations defined by bootrom
Thinking some more,, it's a screwed-up partition table, that's all
To repeat, just because a partition is defined, that says nothing about what it contains,
can be all zeros, can be random data, can be anything, most often is a filesystem,
but that has to be specifically made, not just defined in fdisk/gdisk
A partition just defines a label to refer to a specific area of the disk
--edit--
This piqued my curiosity, went and checked packages txt
^f returned nothing for efi, there was a uboot package
So, since the bootrom controls where the initialization code is loaded from,
it's just a erroneous partition table
There is experimental efi for u-boot, I don't think this is what is happening here
so they can be ignored
blk2p1 is where idbloader is located
blk2p2 is where uboot and trust are, but I doubt that is a valid fat filesystem
Just because there is a partition listing, that says nothing about what is on the disk,,
despite the name /boot/efi
Itis odd that it starts at 4M, maybe it is an efi booted system
I suppose it could be the very 1st efi booted arm64 distro, but I doubt it
If it was an ESP, efi system partition, it will have a fat filesystem
Try mounting it, and show a directory listing, it almost certainly will fail to mount
(a fat fs needs a PBR/VBR, 2 fat tables and a / directory, this takes space,
so uboot won't be where the bootrom expects to find it. For that matter,
i doubt that rk3399 can boot in efi mode, not capable of that)
If it was an efi booted system, that should have been noted
Or maybe it's just screwed up, but you say it boots
If I understand right, you did the dd commands in post 3, so that put everything
where it is supposed to be, the bootrom cares nothing about partitions or filesystems
It's just a raw load from locations defined by bootrom
Thinking some more,, it's a screwed-up partition table, that's all
To repeat, just because a partition is defined, that says nothing about what it contains,
can be all zeros, can be random data, can be anything, most often is a filesystem,
but that has to be specifically made, not just defined in fdisk/gdisk
A partition just defines a label to refer to a specific area of the disk
--edit--
This piqued my curiosity, went and checked packages txt
^f returned nothing for efi, there was a uboot package
So, since the bootrom controls where the initialization code is loaded from,
it's just a erroneous partition table
There is experimental efi for u-boot, I don't think this is what is happening here
