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.
>> 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...
>> 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".
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
