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: [email protected]
To contact the owner, e-mail: [email protected]
