21.11.2015 01:08, Andreas Färber пишет:
Am 20.11.2015 um 20:09 schrieb Matwey V. Kornilov:
16.11.2015 04:05, Andreas Färber пишет:
Am 15.11.2015 um 19:50 schrieb Matwey V. Kornilov:
2015-11-15 21:34 GMT+03:00 Andreas Färber
: Am 28.10.2015 um 19:07 schrieb Matwey V. Kornilov:
I've just looked through perl-bootloader. It is not so hard to implement additional module Extlinux.pm, given there is hardware support to test. But I would say that to implement extlinux support seems to be way easier than direct u-boot anyway. Patching perl-bootloader should be sufficient for correct operation of kernel RPM post/pre scripts.
Have you looked further into implementing this?
I am testing changes to dtb-source, but I do not have a good solution for /boot/dtb symlink yet. Switching to extlinux would elegantly avoid tackling that. ;)
I've just tested that extlinux worked. I am going to start to implement initial support into perl-bootloader,
Great, then I'll leave my hands off.
I gathered that /etc/sysconfig/bootloader would need LOADER_TYPE="extlinux", and Library.pm:SetLoaderType() would need to handle "extlinux" to instantiate your new Core/Extlinux.pm. https://github.com/openSUSE/perl-bootloader
Looks promising, do you have it packaged for testing?
https://build.opensuse.org/package/show/home:matwey:branches:Base:System/per...
Now I am going to implement DTB handling. kernel and dtb-* can be installed and removed independently. Among other, additional commands for update_bootloader are required. For dtb-*-%{version} %postin we need to scan entries with kernel %{version} and set fdtdir to "/boot/dtb-%{version}"
No, my plan was to just set fdtdir on kernel installation. The idea is that you can use a dtb-tegra124-4.3.0-1 with kernel-lpae-4.3.0-1 but not randomly mix and match versions. I definitely do not want installing a new dtb package to update all my old kernels to the new version - that's likely to break, they're not fully independent of each other.
If there's any Contrib packages installing to /boot/dtb we'll need to update them, too.
I probably poorly explained, sorry. In ideal world, we want the following entries (as you said, kernel version must match dtb version): 1. /boot/vmlinuz-4.3.1 with /boot/dtb-4.3.1/tegra.tdb 2. /boot/vmlinuz-4.3.0 with /boot/dtb-4.3.0/tegra.tdb 3. /boot/vmlinuz-4.2.0 with /boot/dtb-4.2.0/tegra.tdb In real world, the kernel package does not "Requires:" appropriate dtb-%{flavor}-%{version} because the %{flavor} is user and hardware dependent. We have a race condition here, two possibilities are available: 1) kernel-default-%{version} is installed AFTER the dtb-%{flavor}-%{version}, then perl-Bootloader can check that the directory /boot/dtb-%{version} already exists and create the following new entry, not modifying anything else: 1. /boot/vmlinuz-4.3.2 with /boot/dtb-4.3.2/tegra.tdb 2) kernel-default-%{version} is installed BEFORE dtb-%{flavor}-%{version}, then perl-Bootloader can not rely on the fact that /boot/dtb-%{version} will ever exists in the future. Fortunately, perl-Bootloader seems to be able to find the most appropriate entry to copy default config from. So, the best what we can in this situation is the following: 1. /boot/vmlinuz-4.3.2 with /boot/dtb-4.3.1/tegra.tdb Sure, it may not boot in theory, but /boot/dtb-4.3.2/tegra.tdb doesn't boot surely because there is no such directory /boot/dtb-4.3.2 2A) Sure, the most probable scenario is that dtb-%{flavor}-%{version} will be installed in the near future after kernel-default-%{version} installation. Then we need to go into perl-Bootloader again and check for entries for %{version}. We will find the following: 1. /boot/vmlinuz-4.3.2 with /boot/dtb-4.3.1/tegra.tdb Which can be now safely replaced to (see dtb-4.3.2 ?) 1. /boot/vmlinuz-4.3.2 with /boot/dtb-4.3.2/tegra.tdb
For dtb-*-%{version} %preun we need to scan entries which use /boot/dtb-%{version} and set fdtdir to "/boot/dtb" fallback.
Would the new perl-Bootloader ever realistically encounter dtb packages following the old /boot/dtb scheme?
Once we have everything in place for switching to extlinux.conf, we won't even need any /boot/dtb symlink. I've seen kernel uninstallation leaving the /boot/initrd symlink dangling, so I saw no need to go through hoops for /boot/dtb either.
The flavor of dtb (dtb file) is to be specified in /etc/sysconfig/bootloader
That shouldn't be necessary, U-Boot is supposed to provide $fdtfile. In my testing I didn't need to specify a dtb file in extlinux.conf, only the dtb directory.
That is great news, but I think it is better to provide optional possibility to set the file manually. Let me describe use-case. BeagleBone Black supports the capes, and the kernel still doesn't have an user-space API for overlays. So, to enable my specific hardware I will modify am335x-beaglebone.dts and compile new version, say am335x-beaglebone-with-geiger-counter-cap.dtb. Sure, when I will deploy this to my production, I will make a package dtb-am335x-with-geiger-counter-%{version}.rpm (Please, see above, imagine, new kernel update has been issued and my build service has not rebuild this package yet, so I'll receive an updated kernel and will not receive and updated dtb package) How should u-boot guess what I want now? So, please, let the user some freedom.
Regards, Andreas
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org