30.07.2015 20:56, Brüns, Stefan пишет:
On Thursday, July 30, 2015 11:04:21 Matwey V. Kornilov wrote:
Hello Andreas and Stefan,
That is correct. But you tell about bootloader, I am not sure why does
a bootloader need device tree overlay support in kernel. I mean it can
merge device tree before actual kernel loaded and run.
Thats how it is currently implemented in Raspbian.
The proprietary bootloader loads the board specific DTB and applies all the
overlays specified in config.txt (dtoverlay=...) on top.
The modified DTB is then provided for the kernel.
I see some possible approaches, all with cons and pros:
1. Take the DTB from the RaspBerryPI start.elf bootloader
Pros:
a) Upstream mechanisms like dtoverlay=... work. Users may be confused why
they can specify overlays in config.txt on Raspbian, but not openSUSE
b) Early availability of hardware, e.g. SPI connected TFTs, usable before
userland is available.
Cons:
a) only works for RPI
b) may affect the "U-Boot as safety net" approach.
AFAIU, basic openSUSE ARM paradigm is that we follow upstream kernel and
bootloader. So, If you rely on specific Raspbian behavior it is better
to consider using Raspbian. As far as the problem you highlight here is
common to vast majority of ARM boards, I think it is better to try to
find hardware agnostic solution.
2. Add overlay support to U-Boot
Pros:
a) may be tweakable even for network boots and other enhanced u-boot
capabilities
b) hardware from overlays available early (even for u-boot?)
c) cross platform
Cons:
a) not implemented
Do you feel that you can implement it for u-boot? I think It would
require lot of spare time for the project.
b) different to Raspbian, raspberrypi.org documentation
Actually that would be great to implement, but there is another obstacle:
c) DTBs are carried inside linux Kernel and they are not split into
overlays yet, so user will have to write his own DTO and compile it
d) bootloader have to be somehow auto-configured allowing installation
of needed overlay from RPM package to mass-deploy use-cases.
3. Use kernel overlay support (á la capemanager)
Pros:
a) runtime overlay changes possible
b) CONFIGFS overlay support available as patch
Cons:
a) different to Raspbian
b) CONFIGFS approach needs action from userspace
This is also must-have feature, but it does have slightly different
use-case when you need to modify device tree without reboot (when you
have FPGA and change its firmware, for instance). Consider the case when
you just attached SPI/UART to your board then #2 would be sufficient to you.
Problem here that I am not sure that CONFIGFS patches will ever be
accepted into upstream. Actually, we could try to apply these patches to
openSUSE kernel, but this would require argumentation to SUSE Kernel
team why we really need to do that.
I think that user-space action may be integrated into systemd to make
consistent syntax
# systemctl enable [email protected]
and so on
Currently the only possibility to get e.g. SPI running on the RPI is to patch
the DTS (set status=okay), recompile to DTB, put it into the /boot partion,
and either overwrite the original dtb file or set the fdtfile uboot env var.
Thats just to complicated.
The same is with BeagleBone Black, I am agree.
What I want is a plan to get this working.
Kind regards,
Stefan
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
