[next] Pass bootloader information in the dtb using a generic namespace

[jenneron]

I suggest to attach to fdt something like:

bootloader,name = "lk2nd"
bootloader,type = "msm8916-secondary";
bootloader,version = "0.15.0";

Then this information can be read from /proc/device-tree by userspace.

Once we have something like this we can propose fwupd to read these values to identify the bootloader. If we get this functionality to fwupd we will be able to implement upgrades for lk2nd through fwupd.

Note that I suggest having some generic prefix like bootloader, instead of lk2nd,, so we can use this approach in other bootloaders, e.g. U-Boot + extlinux

[jenneron]

If we get the whole idea going I could help you with pushing binaries to fwupd repo automatically using GitHub Actions

[jenneron]

Also, I hope we can stop maintaining lk2nd packages in pmaports, but I'm not sure why these are there in the first place

[TravMurav]

I've already implemented it in -next:

lk2nd/lk2nd/version/version.c

Lines 29 to 39 in 6461706

	offset = fdt_path_offset(dtb, "/chosen");
	if (offset < 0)
	return 0;
	ret = fdt_setprop_string(dtb, offset, "lk2nd,project", xstr(BOARD));
	if (ret < 0)
	return 0;
	ret = fdt_setprop_string(dtb, offset, "lk2nd,version", LK2ND_VERSION);
	if (ret < 0)
	return 0;

[jenneron]

@TravMurav nice, lol. But I would still like to point this:

Note that I suggest having some generic prefix like bootloader, instead of lk2nd,, so we can use this approach in other bootloaders, e.g. U-Boot + extlinux

We have been thinking about the same thing for tegra devices using u-boot, so it would be nice to have common fwupd solution

[TravMurav]

hm, interesting, if we can get wide-ish support for those properties, then it would be really nice, not sure if we have any upstream to give us guidance on that though, but bootloader, sounds sad as a vendor prefix, in which case I'd do

&{/chosen} {
    bootloader {
        name = "lk2nd";
        version = "18.0"
        lk2nd,project = "lk2nd-msm8916"
    };
};

or something like that, not exactly sure what would be a nice, scalable solution here

(...) i.e. I'm not sure if "subtype" would be generic enough to apply to everyone.

[jenneron]

if you have this for lk2nd:

&{/chosen} {
    bootloader {
        name = "lk2nd";
        type = "lk2nd-msm8916";
        version = "18.0";
    };
};

we would have this for u-boot on tegra:

&{/chosen} {
    bootloader {
        name = "U-Boot (grate-drivers)"; // the name is U-Boot, but we use it in the fork, so let's specify fork here as well to distinguish them
        type = "asus-grouper"; // u-boot builds are per-device, so let's do it here
        version = "2024.01";
    };
};

(just to give you an idea what i want from U-Boot side)

[jenneron]

it would be also nice to have stage = "primary" or stage = "secondary" under bootloader node

[jenneron]

maybe something like this would be better for us:

&{/chosen} {
    bootloader {
        name = "U-Boot";
        type = "grate-drivers"
        device = "asus-grouper";
        version = "2024.01";
    };
};