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 spi@1.overlay 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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org