Am 22.11.2015 um 09:47 schrieb Matwey V. Kornilov:
> 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 пишет:
>>>> 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.
Right, that's my dtb-source case above, and as long as that is a branch
in your home only, it remains your own problem...
The easiest solution then is to patch the one .dts for the board if you
always use that cape (see below), then nothing needs to be done on the
perl-bootloader side. Otherwise if it's multiple files or even new
subpackages, please give concrete examples (package URLs), so that we
can either adapt them or use them as test cases for perl-bootloader.
E.g., I found some instructions for TI PRU Cape, but for downstream SDK:
http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#Modify_Device_Tree_Files_to_Account_for_PRU_Cape
Someone would need to maintain such .dtsi files and patches for our
kernel versions. Today there is no Contrib project for TI, and if you
submitted any extra dtb packages to Base:System or wherever then I am
not aware...
There is a binary (and questionably labeled GPL-2.0) .dtb file for Moonshot:
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:m400/dtb-m400
And .dts and .dtsi files for Efika MX:
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:EFIKAMX/dtb-imx51-efikamx
In all other Contrib cases they seem to be from some kernel-source.
Anyway, in particular I had in mind that it's quite possible that
someone removes a cape before powering on the device and thus before
being able to install a different dtb package. Therefore elsewhere I
suggested having the core board plus some cape in the menu, which would
mean either a) having new subpackages per cape with special %post
handling adding that one cape to the menu or b) having packages any way
the packagers see fit but letting the user configure which ones to show
in the menu, which also requires having a way to regenerate
extlinux.conf after updating /etc/sysconfig/bootloader without needing
to reinstall all kernel and dtb packages.
One concern I have with naming the board filename in a config is that
.dtb names can change over time. My ODROID-XU .dts is still not accepted
upstream, meaning exynos5410-smdk5410.dtb needs to be used until
exynos5410-odroidxu.dtb is available, and for the Parallella we were
discussing splitting zynq-parallella.dts into zynq-parallella1-*.dts for
handling models with and without USB.
One solution might be to allow for kernel-version-specific
/etc/sysconfig/bootloader options to override the generic one. Another
would be integrating scripts in some extlinux.d dir that dtb-zynq etc.
could install. No perfect idea yet.
FPGAs also pose further problems for .dtb handling, i.e. the physical
board with or without extension boards plus software-defined hardware.
Not yet sure whether the new FPGA Manager drivers in 4.4 interact with
DT somehow...
Do you see a way to configure the location of extlinux.conf maybe?
U-Boot only searches in extlinux/extlinux.conf, so if we could
optionally tweak that in /etc/sysconfig/bootloader then we could have
U-Boot auto-load /boot/boot.scr and load /boot/extlinux.conf (instead of
/boot/extlinux/extlinux.conf) from there after doing any env tweaks.
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: [email protected]
To contact the owner, e-mail: [email protected]
