Hi, "Diederik de Haas" <didi.deb...@cknow.org> wrote (Sun, 20 Oct 2024 16:28:41 +0200): > The 'cs21' device is a (different) Rock64 (rk3328): > > ``` > diederik@cs21:~$ ls -lh /boot/ > total 242M > ... > -rw-r--r-- 1 root root 285K sep 30 21:08 config-6.1.0-26-arm64 > drwxr-xr-x 4 root root 16K jan 1 1970 efi > drwxr-xr-x 2 root root 4,0K okt 9 18:02 extlinux > drwxr-xr-x 5 root root 4,0K okt 9 18:03 grub > -rw-r--r-- 1 root root 30M okt 9 18:02 initrd.img-6.1.0-26-arm64 > -rw-r--r-- 1 root root 83 sep 30 21:08 System.map-6.1.0-26-arm64 > -rw-r--r-- 1 root root 32M sep 30 21:08 vmlinuz-6.1.0-26-arm64 > ``` > > I have 4 kernels installed, but listing them all isn't useful. > > And now the partition stuff: > > ``` > root@cs21:~# parted -s /dev/mmcblk1 print > Model: MMC NCard (sd/mmc) > Disk /dev/mmcblk1: 61.9GB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: > > Number Start End Size File system Name Flags > 1 32.8kB 16.8MB 16.7MB primary > 2 16.8MB 256MB 239MB fat16 primary boot, esp > 3 256MB 61.9GB 61.6GB ext4 primary > > root@cs21:~# lsblk -o +PARTFLAGS,FSTYPE /dev/mmcblk1 > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS PARTFLAGS FSTYPE > mmcblk1 179:0 0 57.6G 0 disk > ├─mmcblk1p1 179:1 0 16M 0 part > ├─mmcblk1p2 179:2 0 228M 0 part /boot/efi vfat > └─mmcblk1p3 179:3 0 57.4G 0 part / ext4 > ``` > > And 'quartz64a' is a Pine64 Quartz64 Model A (rk3566): > > ``` > root@quartz64a:~# parted -s /dev/mmcblk1 print > Model: MMC A3A562 (sd/mmc) > Disk /dev/mmcblk1: 124GB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: > > Number Start End Size File system Name Flags > 1 32.8kB 3670kB 3637kB loader1_part > 2 8389kB 12.6MB 4194kB loader2_part > 3 12.6MB 16.8MB 4194kB trust_part > 4 16.8MB 134MB 117MB efi_part > 5 134MB 124GB 124GB ext4 root_part legacy_boot > > root@quartz64a:~# lsblk -o +PARTFLAGS,FSTYPE /dev/mmcblk1 > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS PARTFLAGS FSTYPE > mmcblk1 179:0 0 115.2G 0 disk > ├─mmcblk1p1 179:1 0 3.5M 0 part > ├─mmcblk1p2 179:2 0 4M 0 part > ├─mmcblk1p3 179:3 0 4M 0 part > ├─mmcblk1p4 179:4 0 112M 0 part > └─mmcblk1p5 179:5 0 115.1G 0 part / 0x4 ext4 > ``` > > FTR: I cannot think of any reason why the device type would matter. > And the Quartz64-A has those other partitions, but doesn't use them. > Just some other experiment with the 'official' Rockchip partition > layout. > > And I just changed the 'legacy_boot' flag to 'boot' on the SDcard with > which I did my test, which then (apparently) also triggers the 'esp' > flag and it booted with that too. > So it looks like it just needs some indication (flag) of what the boot > device is, but it doesn't (seem to) matter which one.
Hmm, I'm irritated now: here you have a device|installation, which has the legacy_boot flag installed, but it did not work|boot despite of this. And you changed that legacy_boot flag into a boot flag, and that made the problem go away? (so the device boots fine). So, why should we then do some work to implement the setting of the legacy_boot flag on arm64? And here, from another mail: "Diederik de Haas" <didi.deb...@cknow.org> wrote (Mon, 21 Oct 2024 10:26:28 +0200): > On Sun Oct 20, 2024 at 8:49 PM CEST, Pascal Hambourg wrote: > > > So it looks like it just needs some indication (flag) of what the boot > > > device is, but it doesn't (seem to) matter which one. > > > > Weird. Does it have to be on the boot/root partition or can it be on any > > other partition ? > > It appears to not matter if it's 'boot' or 'legacy_boot', but it (ofc?) > needs to be set on the partition with the kernel as that needs to be > started for the rest of the boot process. > My guess is that on the tested system it tried to do something with TFTP > as it couldn't find a kernel as the '[legacy_]boot' flag was not set, > thus couldn't find a kernel thus tried another option (tftp). Here you also imply, that both boot or legacy_boot flag do the job. So, can I understand this, as there is no need to set the legacy_boot flag, but just adjust the situations, where the 'boot' flag is being set? Or do we explicitely want to support both the legacy_boot and the boot flag, because we know that some systems are buggy and one needs the first and other need the latter flag? Sorry, or did I lost track somewhere? (I was some days offline lately) Holger -- Holger Wansing <hwans...@mailbox.org> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
