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