msm8916-mainline / lk2nd

Custom bootloader for Qualcomm MSM8916/MSM8226/MSM8974/... devices
Other
393 stars 335 forks source link

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

Open jenneron opened 8 months ago

jenneron commented 8 months ago

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 commented 8 months ago

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

jenneron commented 8 months ago

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 commented 8 months ago

I've already implemented it in -next:

https://github.com/msm8916-mainline/lk2nd/blob/6461706bb92978923474ac670ef38249dbba4e95/lk2nd/version/version.c#L29-L39

jenneron commented 8 months ago

@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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

jenneron commented 8 months ago

maybe something like this would be better for us:

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