[opensuse-arm] DT overlays (was: Drivers for display for rpi3)
Hi Tony, Am 24.04.2017 um 19:19 schrieb Tony Su:
Hi, I'm looking for the referenced Wiki with links to dtb overlays, can't find it.
For that matter, I can't find the specific github repo (Is the Wiki associated with the github project or some other Wiki?)
Looking around, I can only find the following HCL page that lists supported HATs which is something I haven't noticed before. https://en.opensuse.org/Category:Raspberry_Pi_40-pin_connector
Look at the ArPi600 link in that category, for instance. For Chistera Pi and TLV493D there are overlay files too, but no links in the Wiki yet. The Arduino Shield, MikroBus and XBee categories should also have some. The commands can either be typed manually or placed in a boot.script that then needs to be turned into boot.scr via mkimage (u-boot-tools) and placed into the first partition (i.e., /boot/efi if it exists, /boot otherwise). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, 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
Are you using the same dtb definitions and format as what is being used in the Debian Raspbian image which does <not> use u-boot? Thx, Tony On Mon, Apr 24, 2017 at 10:33 AM, Andreas Färber <afaerber@suse.de> wrote:
Hi Tony,
Am 24.04.2017 um 19:19 schrieb Tony Su:
Hi, I'm looking for the referenced Wiki with links to dtb overlays, can't find it.
For that matter, I can't find the specific github repo (Is the Wiki associated with the github project or some other Wiki?)
Looking around, I can only find the following HCL page that lists supported HATs which is something I haven't noticed before. https://en.opensuse.org/Category:Raspberry_Pi_40-pin_connector
Look at the ArPi600 link in that category, for instance.
For Chistera Pi and TLV493D there are overlay files too, but no links in the Wiki yet.
The Arduino Shield, MikroBus and XBee categories should also have some.
The commands can either be typed manually or placed in a boot.script that then needs to be turned into boot.scr via mkimage (u-boot-tools) and placed into the first partition (i.e., /boot/efi if it exists, /boot otherwise).
Regards, Andreas
-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, 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
Additional, It's been a few months since I looked at this, Raspbian makes it very easy (?) to add definitions, you drop individual files for each definition into a directory, then boot. I didn't explore how difficult it would be to write the definitions themselves. Of course, if the dtb definitions are identical, then it would mean that just dropping the files from raspbian into the openSUSE directory would instantly enable support for the 50-plus or so HATs (last I counted) that Raspbian supports. Tony On Mon, Apr 24, 2017 at 10:35 AM, Tony Su <tonysu@su-networking.com> wrote:
Are you using the same dtb definitions and format as what is being used in the Debian Raspbian image which does <not> use u-boot?
Thx, Tony
On Mon, Apr 24, 2017 at 10:33 AM, Andreas Färber <afaerber@suse.de> wrote:
Hi Tony,
Am 24.04.2017 um 19:19 schrieb Tony Su:
Hi, I'm looking for the referenced Wiki with links to dtb overlays, can't find it.
For that matter, I can't find the specific github repo (Is the Wiki associated with the github project or some other Wiki?)
Looking around, I can only find the following HCL page that lists supported HATs which is something I haven't noticed before. https://en.opensuse.org/Category:Raspberry_Pi_40-pin_connector
Look at the ArPi600 link in that category, for instance.
For Chistera Pi and TLV493D there are overlay files too, but no links in the Wiki yet.
The Arduino Shield, MikroBus and XBee categories should also have some.
The commands can either be typed manually or placed in a boot.script that then needs to be turned into boot.scr via mkimage (u-boot-tools) and placed into the first partition (i.e., /boot/efi if it exists, /boot otherwise).
Regards, Andreas
-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, 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
Am 24.04.2017 um 19:43 schrieb Tony Su:
Additional, It's been a few months since I looked at this, Raspbian makes it very easy (?) to add definitions, you drop individual files for each definition into a directory, then boot. I didn't explore how difficult it would be to write the definitions themselves.
Of course, if the dtb definitions are identical, then it would mean that just dropping the files from raspbian into the openSUSE directory would instantly enable support for the 50-plus or so HATs (last I counted) that Raspbian supports.
Tony
On Mon, Apr 24, 2017 at 10:35 AM, Tony Su <tonysu@su-networking.com> wrote:
Are you using the same dtb definitions and format as what is being used in the Debian Raspbian image which does <not> use u-boot?
Reminder: Please don't top-post on our mailing lists; reply below. openSUSE uses U-Boot, and U-Boot does not get its Device Tree from the Raspberry Pi firmware, so their built-in overlay support (config.txt) is useless to us. Whether it would be possible to iterate over files in a directory from a U-Boot script I haven't tried, can't think of how - if you have a solution, please share. The alternative would be to do it as a systemd service from Linux, but that would require some DT merging tool AFAIU, which we don't have today. That's why reusing U-Boot's existing implementation is somewhat convenient for me, even if sub-optimal. As for reusing Raspbian .dtbo files, any .dtbo file always depends on the base .dtb file. So if they are still based off old non-mainline bcm2708/09/10 files, then reusing them with mainline bcm2835/36/37 files is unlikely to work. https://www.raspberrypi.org/documentation/configuration/device-tree.md section 2.1 also mentions differences between -overlay.dtb and .dtbo for (their?) kernel v4.4+. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, 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
Thx for looking at this, and your analysis. AFAIK based on existing systemd functionality, I'm not sure that it's quite ready to extend hardware device support, my impression is that although on the Roadmap of what systemd wants to eventually do, today udev still primarily is the subsystem that detects and implements devices. I only know of systemd services mounting devices, but only after udev has done its work. IMO and Thx again, Tony -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Am 27.04.2017 um 02:52 schrieb Tony Su:
Thx for looking at this, and your analysis.
AFAIK based on existing systemd functionality, I'm not sure that it's quite ready to extend hardware device support, my impression is that although on the Roadmap of what systemd wants to eventually do, today udev still primarily is the subsystem that detects and implements devices. I only know of systemd services mounting devices, but only after udev has done its work.
I think you misunderstood: systemd is a way to execute userspace commands on boot, as successor to, e.g., /etc/init.d/boot.local script. It is rumored to be possible to apply .dtbo files to /sys/firmware from userspace; Raspbian has some dtmerge tool (never tried it myself). You could either package a yourhat.service unit (that depends on suitable other uniquely named services if applicable), or we could have one service that iterates over an, e.g., /boot/dtboverlay.d/ directory with 10-yourhat.dtbo, achieving ordering via filename prefix. Personally I see it as a more pressing issue to make sure there are mainline drivers for the sensors etc. I run into, because that takes more time, so I have not looked into writing/packaging such tools. raspberrypi-userland is problematic, so we'd need a standalone package. Any volunteers? Once we know what exactly we need to make it work technically, we can start thinking about a new YaST module as equivalent to rpi-config. Note that as of this week Kernel:HEAD's dtb packages should be prepared for overlays (i.e., node labels can be referenced by phandle now). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, 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 2017-04-28 16:29, Andreas Färber wrote:
Hi,
Am 27.04.2017 um 02:52 schrieb Tony Su:
Thx for looking at this, and your analysis.
AFAIK based on existing systemd functionality, I'm not sure that it's quite ready to extend hardware device support, my impression is that although on the Roadmap of what systemd wants to eventually do, today udev still primarily is the subsystem that detects and implements devices. I only know of systemd services mounting devices, but only after udev has done its work.
I think you misunderstood: systemd is a way to execute userspace commands on boot, as successor to, e.g., /etc/init.d/boot.local script.
It is rumored to be possible to apply .dtbo files to /sys/firmware from userspace; Raspbian has some dtmerge tool (never tried it myself).
You could either package a yourhat.service unit (that depends on suitable other uniquely named services if applicable), or we could have one service that iterates over an, e.g., /boot/dtboverlay.d/ directory with 10-yourhat.dtbo, achieving ordering via filename prefix.
Personally I see it as a more pressing issue to make sure there are mainline drivers for the sensors etc. I run into, because that takes more time, so I have not looked into writing/packaging such tools. raspberrypi-userland is problematic, so we'd need a standalone package. Any volunteers?
Once we know what exactly we need to make it work technically, we can start thinking about a new YaST module as equivalent to rpi-config.
Note that as of this week Kernel:HEAD's dtb packages should be prepared for overlays (i.e., node labels can be referenced by phandle now).
With that you can apply a few patches (or verify they are applied) and do for i in /boot/dtboverlay.d/*.dtbo ; do cat $i > /sys/whatever/node/applies/overlays ; done I had a branch with these somewhere so I can try dusting it off and see how many are still needed. Thanks Michal -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 28.04.2017 um 20:23 schrieb Michal Suchánek:
On 2017-04-28 16:29, Andreas Färber wrote:
Am 27.04.2017 um 02:52 schrieb Tony Su:
Thx for looking at this, and your analysis.
AFAIK based on existing systemd functionality, I'm not sure that it's quite ready to extend hardware device support, my impression is that although on the Roadmap of what systemd wants to eventually do, today udev still primarily is the subsystem that detects and implements devices. I only know of systemd services mounting devices, but only after udev has done its work.
I think you misunderstood: systemd is a way to execute userspace commands on boot, as successor to, e.g., /etc/init.d/boot.local script.
It is rumored to be possible to apply .dtbo files to /sys/firmware from userspace; Raspbian has some dtmerge tool (never tried it myself).
Correction: dtoverlay seems the more relevant one - deals with Raspberry Pi specific features such as DT parameters though.
You could either package a yourhat.service unit (that depends on suitable other uniquely named services if applicable), or we could have one service that iterates over an, e.g., /boot/dtboverlay.d/ directory with 10-yourhat.dtbo, achieving ordering via filename prefix.
Personally I see it as a more pressing issue to make sure there are mainline drivers for the sensors etc. I run into, because that takes more time, so I have not looked into writing/packaging such tools. raspberrypi-userland is problematic, so we'd need a standalone package. Any volunteers?
Once we know what exactly we need to make it work technically, we can start thinking about a new YaST module as equivalent to rpi-config.
Note that as of this week Kernel:HEAD's dtb packages should be prepared for overlays (i.e., node labels can be referenced by phandle now).
With that you can apply a few patches (or verify they are applied) and do
for i in /boot/dtboverlay.d/*.dtbo ; do cat $i > /sys/whatever/node/applies/overlays ; done
I had a branch with these somewhere so I can try dusting it off and see how many are still needed.
Hmm, https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/lo... is what I've come across? I.e. /sys/kernel/config/device-tree/overlays, which is not yet in 4.11 (CONFIG_OF_CONFIGFS unavailable). Being able to just write a .dtbo into configfs would of course be easiest for us. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, 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 Fri, Apr 28, 2017 at 4:29 PM, Andreas Färber <afaerber@suse.de> wrote:
Once we know what exactly we need to make it work technically, we can start thinking about a new YaST module as equivalent to rpi-config.
rpi-config? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 02.05.2017 um 09:32 schrieb Roger Oberholtzer:
On Fri, Apr 28, 2017 at 4:29 PM, Andreas Färber <afaerber@suse.de> wrote:
Once we know what exactly we need to make it work technically, we can start thinking about a new YaST module as equivalent to rpi-config.
rpi-config?
Some Raspbian tool that you will see mentioned in many Raspberry Pi how-tos - apparently some curses interface to editing config.txt, where Raspbian enables interfaces like SPI or specific Hats. The point is, some people like me are okay with editing a boot.script and running mkimage, others want some guided approach. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, 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
participants (4)
-
Andreas Färber -
Michal Suchánek -
Roger Oberholtzer -
Tony Su