21.11.2015 22:40, Andreas Färber пишет:
Am 21.11.2015 um 18:33 schrieb Matwey V. Kornilov:
21.11.2015 15:59, Andreas Färber пишет:
Am 21.11.2015 um 12:48 schrieb Stefan Bruens:
On Saturday 21 November 2015 08:49:47 Matwey V. Kornilov wrote:
> 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.
One possibility instead of choosing a different filename, use a different directory name, e.g.: /boot/dtb-4.3.0-geiger-cape/*dtb or /boot/dtb-4.3.0/geiger-cape/*dtb
I would like to keep %{version} for directory name and %{ftd_flavour} for file name.
Where are you taking those variables from? It's %{kernel_version} and %{kernel_release} in dtb-source, and $ftdfile in U-Boot.
I used to emphasize that they are variables. They are not come from somewhere.
That still leaves the question of how to get that directory into extlinux.conf - it can no longer be inferred from the kernel then.
If the answer is hand-editing FDTDIR, then on the perl-bootloader side we only need to assure that on add/remove operations it does not override such local changes.
This is hard to achieve. Sure, entry may be marked as 'manual' and keep untouched but I am not sure how this Yast-magic works in real life.
Where would we need to mark it? Reinstalling my kernel-lpae package did not modify my extlinux.conf at all...
I don't know, but lines line '###Don't change this comment - YaST2 identifier: Original name: linux Handled by: user###' can do magic. Please note, that with my current patch RPM kernel %post and %pre don't work, because bootloader_entry script has to be adjusted also.
Do we have any actual example of such a cape dtb package that's not self-made? I encountered and dropped some binary .dtb files in raspberrypi-firmware package, other than that I am not aware of any. And when self-made, doesn't that involve having a modified kernel-source package?
Not necessary. I may enable UART number N or change pin multiplexing for BBB just editing (patching) .dts file, and this operation is safe. I don't need recompile the kernel.
My point was that .dts files are in kernel-source. So either you need a patch in kernel-source, which leads to a differing %{kernel_release}, or you have a patch in a dtb-source. If you locally patch a .dts file that's what I meant with "self-made".
Nothing can prevent me from branching dtb-source and do the following: cp /usr/src/linux/COPYING . cp -r /usr/src/linux/ . chmod -R ug+rw linux %patch0 %patch1 And introduce a couple of new subpackages.
Regards, Andreas
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org