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. 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 b) different to Raspbian, raspberrypi.org documentation 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 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. What I want is a plan to get this working. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org