[opensuse-arm] Support for device-tree overlays
Hi everyone, as the RaspberryPI kernel is nowadays "configured" by the device tree, there are some issues for the current openSUSE images. By default the dtbs as shipped disable any optional hardware, which is a good thing. On the other hand things like SPI are no longer working. Raspbian tackles this with so called overlays and some help from the binary start.elf bootloader: 1. start.elf reads the dtb from the fat boot partition a) a file defined in config.txt, "device_tree=foo.dtb" b) a hardcoded hardware specific default file, "bcm2708-rpi-<variant>.dtb" 2. if the config.txt specifies "dtoverlay=foo-overlay" 1. the boot loader reads "overlays/foo-overlay.dtb" from the fat partition 2. the overlay is patched into the flattened device tree 3. the boot loader puts the device tree at address 0x100 (override with "device_tree_address=0xabcd1234" 4. the boot loader loads the specified kernel As openSUSE does not directly jump into the kernel, but starts u-boot, this does not work here. Issues: 1. u-boot does not have overlay support 2. u-boot loads its own dtb from storage, e.g. bcm2835-rpi-b.dtb 3. The u-boot boot.scr is loaded at address 0, and overwrites the boot loader provided dtb. The 3rd issue can be worked around with a "device_tree_address=0x1000" in config.txt. I tried to replace the "loadfdt" function in the boot.scr with a "fdt move 0x1000 0x2000000". Although the move succeeds, the kernel start crashes afterwards: ---- 4443840 bytes read in 1041 ms (4.1 MiB/s) 6946368 bytes read in 1403 ms (4.7 MiB/s) Copying FDT ... Kernel image @ 0x1000000 [ 0x000000 - 0x43cec0 ] data abort pc : [<17f63d68>] lr : [<17f644e0>] reloc pc : [<0001dd68>] lr : [<0001e4e0>] sp : 17b48a50 ip : 17b521e9 fp : 17f51c54 r10: 17f91354 r9 : 17b49ee8 r8 : 17f922bc r7 : 17f922b8 r6 : 17b521e0 r5 : 00000003 r4 : 33554432 r3 : 00000000 r2 : 00000010 r1 : 00000000 r0 : 33554432 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... ---- instead of: ---- 4443840 bytes read in 1268 ms (3.3 MiB/s) 6946368 bytes read in 1753 ms (3.8 MiB/s) 8127 bytes read in 56 ms (141.6 KiB/s) Kernel image @ 0x1000000 [ 0x000000 - 0x43cec0 ] ## Flattened Device Tree blob at 02000000 Booting using the fdt blob at 0x2000000 Using Device Tree in place at 02000000, end 02004fbe ---- So either this approach needs more work, or a completely different approach is needed to get overlays to work. Any ideas? Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Stefan, Am 29.07.2015 um 04:04 schrieb Stefan Bruens:
By default the dtbs as shipped disable any optional hardware, which is a good thing. On the other hand things like SPI are no longer working.
Raspbian tackles this with so called overlays and some help from the binary start.elf bootloader: 1. start.elf reads the dtb from the fat boot partition a) a file defined in config.txt, "device_tree=foo.dtb" b) a hardcoded hardware specific default file, "bcm2708-rpi-<variant>.dtb" 2. if the config.txt specifies "dtoverlay=foo-overlay" 1. the boot loader reads "overlays/foo-overlay.dtb" from the fat partition 2. the overlay is patched into the flattened device tree 3. the boot loader puts the device tree at address 0x100 (override with "device_tree_address=0xabcd1234" 4. the boot loader loads the specified kernel
As openSUSE does not directly jump into the kernel, but starts u-boot, this does not work here.
Matwey had enabled DT overlays in the kernel at some point. Does that still require the bootloader to take such special steps? Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wednesday 29 July 2015 15:51:45 Andreas Färber wrote:
Hi Stefan,
Am 29.07.2015 um 04:04 schrieb Stefan Bruens:
By default the dtbs as shipped disable any optional hardware, which is a good thing. On the other hand things like SPI are no longer working.
Raspbian tackles this with so called overlays and some help from the binary start.elf bootloader: 1. start.elf reads the dtb from the fat boot partition
a) a file defined in config.txt, "device_tree=foo.dtb" b) a hardcoded hardware specific default file, "bcm2708-rpi-<variant>.dtb"
2. if the config.txt specifies "dtoverlay=foo-overlay"
1. the boot loader reads "overlays/foo-overlay.dtb" from the fat partition 2. the overlay is patched into the flattened device tree
3. the boot loader puts the device tree at address 0x100 (override with "device_tree_address=0xabcd1234" 4. the boot loader loads the specified kernel
As openSUSE does not directly jump into the kernel, but starts u-boot, this does not work here.
Matwey had enabled DT overlays in the kernel at some point. Does that still require the bootloader to take such special steps?
As far as I know: Upstream kernel has support for transactional changes of device trees: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2... This is used by the beaglebone capemanager, which is *not* upstream. http://elinux.org/Capemgr#Implementation It could also be used by the dt-overlay configfs interface, which is pending due to possible security implications: http://article.gmane.org/gmane.linux.kernel/1816078 So mainline kernel has an in-Kernel API for applying DT overlays, but no user facing interface. 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
30.07.2015 01:57, Stefan Bruens пишет:
On Wednesday 29 July 2015 15:51:45 Andreas Färber wrote:
Hi Stefan,
Am 29.07.2015 um 04:04 schrieb Stefan Bruens:
By default the dtbs as shipped disable any optional hardware, which is a good thing. On the other hand things like SPI are no longer working.
Raspbian tackles this with so called overlays and some help from the binary start.elf bootloader: 1. start.elf reads the dtb from the fat boot partition
a) a file defined in config.txt, "device_tree=foo.dtb" b) a hardcoded hardware specific default file, "bcm2708-rpi-<variant>.dtb"
2. if the config.txt specifies "dtoverlay=foo-overlay"
1. the boot loader reads "overlays/foo-overlay.dtb" from the fat partition 2. the overlay is patched into the flattened device tree
3. the boot loader puts the device tree at address 0x100 (override with "device_tree_address=0xabcd1234" 4. the boot loader loads the specified kernel
As openSUSE does not directly jump into the kernel, but starts u-boot, this does not work here.
Matwey had enabled DT overlays in the kernel at some point. Does that still require the bootloader to take such special steps?
As far as I know:
Upstream kernel has support for transactional changes of device trees: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2...
This is used by the beaglebone capemanager, which is *not* upstream. http://elinux.org/Capemgr#Implementation
It could also be used by the dt-overlay configfs interface, which is pending due to possible security implications: http://article.gmane.org/gmane.linux.kernel/1816078
So mainline kernel has an in-Kernel API for applying DT overlays, but no user facing interface.
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.
Kind regards,
Stefan
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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
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
31.07.2015 11:42, Matwey V. Kornilov пишет:
2. Add overlay support to U-Boot
I know 2A option. Merge DTB and DTOs in userspace using special script and then provide the result to u-boot for the next booting. This is what update-bootloader may do. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 31.07.15 09:52, Matwey V. Kornilov wrote:
31.07.2015 11:42, Matwey V. Kornilov пишет:
2. Add overlay support to U-Boot
I know 2A option. Merge DTB and DTOs in userspace using special script and then provide the result to u-boot for the next booting. This is what update-bootloader may do.
So SPI came in as an option here. What exactly would you envision the script that makes this easy to look like? Imagine you have a SPI Flash controller on your SPI CS0 connection. Then you would need to also add the flash driver to your device tree. And because the flash chip is partitioned, you would also need to provide its partition table in the device tree. It gets incredibly complicated very quickly. That said, I do agree that we could probably do a better job at this by giving users at least the chance to take 2 dtbs and have the boot loader merge them into one - so you have one for the board and one for "custom changes". Thinking out loud here, there is another problem we have on U-Boot systems: You can only have a single kernel selected at any given time. There are 2 options out of that 1) Implement extboot support in our bootloader configuration tools 2) Use grub2 on top of u-boot I'm in favor of option 2. And I haven't looked at it, but I wouldn't be surprised if you could convince grub2 to merge dtbs for you. If it does't we should probably extend it to be able to. That's a vision that I think should get us to a more streamlined solution that the ad-hoc hacks we have today. But it's a bumpy road and some people really need to sit down and work on some code ;). So at the end of the day it boils down to "if you do the work, you get to choose how it's done". Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
2015-08-04 1:42 GMT+03:00 Alexander Graf <agraf@suse.de>:
On 31.07.15 09:52, Matwey V. Kornilov wrote:
31.07.2015 11:42, Matwey V. Kornilov пишет:
2. Add overlay support to U-Boot
I know 2A option. Merge DTB and DTOs in userspace using special script and then provide the result to u-boot for the next booting. This is what update-bootloader may do.
So SPI came in as an option here. What exactly would you envision the script that makes this easy to look like?
User brings dtbo and script merges it with base dtb. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Monday 03 August 2015 23:42:20 Alexander Graf wrote:
On 31.07.15 09:52, Matwey V. Kornilov wrote:
31.07.2015 11:42, Matwey V. Kornilov пишет:
2. Add overlay support to U-Boot
I know 2A option. Merge DTB and DTOs in userspace using special script and then provide the result to u-boot for the next booting. This is what update-bootloader may do.
So SPI came in as an option here. What exactly would you envision the script that makes this easy to look like?
Imagine you have a SPI Flash controller on your SPI CS0 connection. Then you would need to also add the flash driver to your device tree. And because the flash chip is partitioned, you would also need to provide its partition table in the device tree.
This is just a single device tree overlay. And although it can be specified completely in the device tree, I would expect the partitioning be part of the kernel command line.
It gets incredibly complicated very quickly.
That said, I do agree that we could probably do a better job at this by giving users at least the chance to take 2 dtbs and have the boot loader merge them into one - so you have one for the board and one for "custom changes".
Thinking out loud here, there is another problem we have on U-Boot systems: You can only have a single kernel selected at any given time. There are 2 options out of that
1) Implement extboot support in our bootloader configuration tools 2) Use grub2 on top of u-boot
I'm in favor of option 2. And I haven't looked at it, but I wouldn't be surprised if you could convince grub2 to merge dtbs for you. If it does't we should probably extend it to be able to.
grub2 can only merge a commandline into the /chosen/ dtb node, thats it. I think with extboot support, you mean configuration via extlinux.conf, as outlined here: http://code.metager.de/source/xref/denx/u-boot/doc/README.distro I dont like the idea of chaining bootloaders ad infinitum. The vendor supplied bootloader (start.elf for RPi) is limited (no boot menu, no network boot ...), so it makes sense to put something on top, but thats it. 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
participants (5)
-
Alexander Graf -
Andreas Färber -
Brüns, Stefan -
Matwey V. Kornilov -
Stefan Bruens