Hello Matwey, On Tue, Oct 27, 2015 at 9:52 PM, Matwey V. Kornilov wrote:

27.10.2015 11:04, Guillaume Gardet пишет:

...

Hi,

Le 26/10/2015 19:52, Matwey V. Kornilov a écrit :

...

Hello,

Why bootmenu command is not used atm? Are there any reasons?

You mean ansi bootmenu? If yes, ac100 community member tried to enable it for our board, but extlinux.conf was proposed as better solution, here is link http://patchwork.ozlabs.org/patch/450122/ I tried to use extlinux.conf with openSUSE on Chromebook Snow, because its support already enabled there, and it work flawlessly and very flexible, take a look at README.distro in u-boot repo, also as it is same as pxe config file kiwi probably already have support for it. Here is example of my test extlinux.conf: TIMEOUT 1000 ONTIMEOUT localboot DEFAULT default MENU TITLE Boot menu PROMPT 0 LABEL default MENU LABEL Default LINUX /boot/zImage FDT /boot/dtb/exynos5250-snow.dtb INITRD /boot/initrd APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 console=ttySAC3,115200n8 console=tty LABEL failsafe MENU LABEL Failsafe LINUX /boot/zImage-4.1.5-exynos_defconfig FDT /boot/dtb/exynos5250-snow.dtb INITRD /boot/initrd-4.1.5-exynos_defconfig APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 console=ttySAC3,115200n8 console=tty LABEL localboot MENU LABEL Local boot script (boot.scr) LOCALBOOT 1

...

I think nobody worked on it until now.

Oh, I see.

But first I am going to introduce additional env variable to simplify selection of the kernel version from u-boot command line.

After then, I would highly want to have fallback possibility like the following: https://www.gnu.org/software/grub/manual/legacy/Booting-fallback-systems.htm... which can be implemented using u-boot uEnv.txt file

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 28.10.2015 um 09:31 schrieb Matwey V. Kornilov:

27.10.2015 22:43, Misha Komarovskiy пишет:

...

On Tue, Oct 27, 2015 at 9:52 PM, Matwey V. Kornilov wrote:

...

27.10.2015 11:04, Guillaume Gardet пишет:

...

Le 26/10/2015 19:52, Matwey V. Kornilov a écrit :

...

Why bootmenu command is not used atm? Are there any reasons?

You mean ansi bootmenu? If yes, ac100 community member tried to enable it for our board, but extlinux.conf was proposed as better solution, here is link http://patchwork.ozlabs.org/patch/450122/

I tried to use extlinux.conf with openSUSE on Chromebook Snow, because its support already enabled there, and it work flawlessly and very flexible, take a look at README.distro in u-boot repo, also as it is same as pxe config file kiwi probably already have support for it.

Here is example of my test extlinux.conf: [...] Nice. I cannot understand is it uboot who runs extlinux or just support of extlinux configuration file syntax inside uboot?

As far as I understand, someone would need to generate such config file into the filesystem for U-Boot to read. That's the big problem I see with it. If you want to dive into YaST, perl-bootloader or whatever is involved there, feel free to give it a try! Some solution for handling multiple kernels is bitterly needed. In YaST not even grub2 was supported on ARMv7 last time I tried - that's the alternative to extlinux. It requires CONFIG_API to be enabled, for which I have a u-boot branch. It also requires grub2 to be patched for the RAM address of some boards. 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

Hi Misha, Am 28.10.2015 um 17:18 schrieb Misha Komarovskiy:

On Wed, Oct 28, 2015 at 5:10 PM, Andreas Färber wrote:

...

Am 28.10.2015 um 09:31 schrieb Matwey V. Kornilov:

...

27.10.2015 22:43, Misha Komarovskiy пишет:

...

On Tue, Oct 27, 2015 at 9:52 PM, Matwey V. Kornilov wrote:

...

27.10.2015 11:04, Guillaume Gardet пишет:

...

Le 26/10/2015 19:52, Matwey V. Kornilov a écrit : > Why bootmenu command is not used atm? Are there any reasons?

You mean ansi bootmenu? If yes, ac100 community member tried to enable it for our board, but extlinux.conf was proposed as better solution, here is link http://patchwork.ozlabs.org/patch/450122/

I tried to use extlinux.conf with openSUSE on Chromebook Snow, because its support already enabled there, and it work flawlessly and very flexible, take a look at README.distro in u-boot repo, also as it is same as pxe config file kiwi probably already have support for it.

Here is example of my test extlinux.conf: [...] Nice. I cannot understand is it uboot who runs extlinux or just support of extlinux configuration file syntax inside uboot?

As far as I understand, someone would need to generate such config file into the filesystem for U-Boot to read. That's the big problem I see with it. If you want to dive into YaST, perl-bootloader or whatever is involved there, feel free to give it a try!

Yes we need to generate this file and put inside resulting JeOS image, same way we generate boot.scr but to /extlinux folder on boot partition and extlinux.conf is not compiled it is plain text file.

No, strong objection! This is absolutely not like boot.scr but rather like grub.cfg. It contains entries per kernel, so it needs to be regenerated on kernel package installation, not just once during JeOS build time. Therefore my pointing to whatever tools are involved there. If that gets implemented properly, the JeOS image will automatically get it through kernel package installation and needs no changes. Also, to really make multi-kernel support work for ARM, we need to fix the dtb-source package for multiversion support, installing stuff to /boot/dtb-4.2.3-1 etc. (and update a dtb symlink during %post). That way you can safely go back to a previously working kernel. Long on my TODO list to investigate, but hasn't made it to the top yet. Volunteers? 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

Hi Matwey, Am 28.10.2015 um 19:07 schrieb Matwey V. Kornilov:

I've just looked through perl-bootloader. It is not so hard to implement additional module Extlinux.pm, given there is hardware support to test. But I would say that to implement extlinux support seems to be way easier than direct u-boot anyway. Patching perl-bootloader should be sufficient for correct operation of kernel RPM post/pre scripts.

Have you looked further into implementing this? I am testing changes to dtb-source, but I do not have a good solution for /boot/dtb symlink yet. Switching to extlinux would elegantly avoid tackling that. ;) 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 15.11.2015 um 19:50 schrieb Matwey V. Kornilov:

2015-11-15 21:34 GMT+03:00 Andreas Färber :

...

Am 28.10.2015 um 19:07 schrieb Matwey V. Kornilov:

...

I've just looked through perl-bootloader. It is not so hard to implement additional module Extlinux.pm, given there is hardware support to test. But I would say that to implement extlinux support seems to be way easier than direct u-boot anyway. Patching perl-bootloader should be sufficient for correct operation of kernel RPM post/pre scripts.

Have you looked further into implementing this?

I am testing changes to dtb-source, but I do not have a good solution for /boot/dtb symlink yet. Switching to extlinux would elegantly avoid tackling that. ;)

I've just tested that extlinux worked. I am going to start to implement initial support into perl-bootloader,

Great, then I'll leave my hands off. I gathered that /etc/sysconfig/bootloader would need LOADER_TYPE="extlinux", and Library.pm:SetLoaderType() would need to handle "extlinux" to instantiate your new Core/Extlinux.pm. https://github.com/openSUSE/perl-bootloader https://github.com/yast/yast-bootloader will probably also need some love for ARM, to allow selecting (grub2 and) extlinux. Meanwhile, this is what I've cooked up as first step for dtb-source: https://build.opensuse.org/request/show/344652 That allows dual-booting linux-next and Tumbleweed kernel with a hand-crafted extlinux.conf. 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

16.11.2015 04:05, Andreas Färber пишет:

Am 15.11.2015 um 19:50 schrieb Matwey V. Kornilov:

...

2015-11-15 21:34 GMT+03:00 Andreas Färber :

...

Am 28.10.2015 um 19:07 schrieb Matwey V. Kornilov:

...

I've just looked through perl-bootloader. It is not so hard to implement additional module Extlinux.pm, given there is hardware support to test. But I would say that to implement extlinux support seems to be way easier than direct u-boot anyway. Patching perl-bootloader should be sufficient for correct operation of kernel RPM post/pre scripts.

Have you looked further into implementing this?

I am testing changes to dtb-source, but I do not have a good solution for /boot/dtb symlink yet. Switching to extlinux would elegantly avoid tackling that. ;)

I've just tested that extlinux worked. I am going to start to implement initial support into perl-bootloader,

Great, then I'll leave my hands off.

I gathered that /etc/sysconfig/bootloader would need LOADER_TYPE="extlinux", and Library.pm:SetLoaderType() would need to handle "extlinux" to instantiate your new Core/Extlinux.pm. https://github.com/openSUSE/perl-bootloader

https://github.com/openSUSE/perl-bootloader/pull/81 Now I am going to implement DTB handling. kernel and dtb-* can be installed and removed independently. Among other, additional commands for update_bootloader are required. For dtb-*-%{version} %postin we need to scan entries with kernel %{version} and set fdtdir to "/boot/dtb-%{version}" For dtb-*-%{version} %preun we need to scan entries which use /boot/dtb-%{version} and set fdtdir to "/boot/dtb" fallback. The flavor of dtb (dtb file) is to be specified in /etc/sysconfig/bootloader -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

21.11.2015 01:08, Andreas Färber пишет:

Am 20.11.2015 um 20:09 schrieb Matwey V. Kornilov:

...

16.11.2015 04:05, Andreas Färber пишет:

...

Am 15.11.2015 um 19:50 schrieb Matwey V. Kornilov:

...

2015-11-15 21:34 GMT+03:00 Andreas Färber :

...

Am 28.10.2015 um 19:07 schrieb Matwey V. Kornilov:

...

I've just looked through perl-bootloader. It is not so hard to implement additional module Extlinux.pm, given there is hardware support to test. But I would say that to implement extlinux support seems to be way easier than direct u-boot anyway. Patching perl-bootloader should be sufficient for correct operation of kernel RPM post/pre scripts.

Have you looked further into implementing this?

I am testing changes to dtb-source, but I do not have a good solution for /boot/dtb symlink yet. Switching to extlinux would elegantly avoid tackling that. ;)

I've just tested that extlinux worked. I am going to start to implement initial support into perl-bootloader,

Great, then I'll leave my hands off.

I gathered that /etc/sysconfig/bootloader would need LOADER_TYPE="extlinux", and Library.pm:SetLoaderType() would need to handle "extlinux" to instantiate your new Core/Extlinux.pm. https://github.com/openSUSE/perl-bootloader

https://github.com/openSUSE/perl-bootloader/pull/81

Looks promising, do you have it packaged for testing?

https://build.opensuse.org/package/show/home:matwey:branches:Base:System/per...

...

Now I am going to implement DTB handling. kernel and dtb-* can be installed and removed independently. Among other, additional commands for update_bootloader are required. For dtb-*-%{version} %postin we need to scan entries with kernel %{version} and set fdtdir to "/boot/dtb-%{version}"

No, my plan was to just set fdtdir on kernel installation. The idea is that you can use a dtb-tegra124-4.3.0-1 with kernel-lpae-4.3.0-1 but not randomly mix and match versions. I definitely do not want installing a new dtb package to update all my old kernels to the new version - that's likely to break, they're not fully independent of each other.

If there's any Contrib packages installing to /boot/dtb we'll need to update them, too.

I probably poorly explained, sorry. In ideal world, we want the following entries (as you said, kernel version must match dtb version): 1. /boot/vmlinuz-4.3.1 with /boot/dtb-4.3.1/tegra.tdb 2. /boot/vmlinuz-4.3.0 with /boot/dtb-4.3.0/tegra.tdb 3. /boot/vmlinuz-4.2.0 with /boot/dtb-4.2.0/tegra.tdb In real world, the kernel package does not "Requires:" appropriate dtb-%{flavor}-%{version} because the %{flavor} is user and hardware dependent. We have a race condition here, two possibilities are available: 1) kernel-default-%{version} is installed AFTER the dtb-%{flavor}-%{version}, then perl-Bootloader can check that the directory /boot/dtb-%{version} already exists and create the following new entry, not modifying anything else: 1. /boot/vmlinuz-4.3.2 with /boot/dtb-4.3.2/tegra.tdb 2) kernel-default-%{version} is installed BEFORE dtb-%{flavor}-%{version}, then perl-Bootloader can not rely on the fact that /boot/dtb-%{version} will ever exists in the future. Fortunately, perl-Bootloader seems to be able to find the most appropriate entry to copy default config from. So, the best what we can in this situation is the following: 1. /boot/vmlinuz-4.3.2 with /boot/dtb-4.3.1/tegra.tdb Sure, it may not boot in theory, but /boot/dtb-4.3.2/tegra.tdb doesn't boot surely because there is no such directory /boot/dtb-4.3.2 2A) Sure, the most probable scenario is that dtb-%{flavor}-%{version} will be installed in the near future after kernel-default-%{version} installation. Then we need to go into perl-Bootloader again and check for entries for %{version}. We will find the following: 1. /boot/vmlinuz-4.3.2 with /boot/dtb-4.3.1/tegra.tdb Which can be now safely replaced to (see dtb-4.3.2 ?) 1. /boot/vmlinuz-4.3.2 with /boot/dtb-4.3.2/tegra.tdb

...

For dtb-*-%{version} %preun we need to scan entries which use /boot/dtb-%{version} and set fdtdir to "/boot/dtb" fallback.

Would the new perl-Bootloader ever realistically encounter dtb packages following the old /boot/dtb scheme?

Once we have everything in place for switching to extlinux.conf, we won't even need any /boot/dtb symlink. I've seen kernel uninstallation leaving the /boot/initrd symlink dangling, so I saw no need to go through hoops for /boot/dtb either.

...

The flavor of dtb (dtb file) is to be specified in /etc/sysconfig/bootloader

That shouldn't be necessary, U-Boot is supposed to provide $fdtfile. In my testing I didn't need to specify a dtb file in extlinux.conf, only the dtb directory.

That is great news, but I think it is better to provide optional possibility to set the file manually. Let me describe use-case. BeagleBone Black supports the capes, and the kernel still doesn't have an user-space API for overlays. So, to enable my specific hardware I will modify am335x-beaglebone.dts and compile new version, say am335x-beaglebone-with-geiger-counter-cap.dtb. Sure, when I will deploy this to my production, I will make a package dtb-am335x-with-geiger-counter-%{version}.rpm (Please, see above, imagine, new kernel update has been issued and my build service has not rebuild this package yet, so I'll receive an updated kernel and will not receive and updated dtb package) How should u-boot guess what I want now? So, please, let the user some freedom.

Regards, Andreas

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 21.11.2015 um 12:48 schrieb Stefan Bruens:

On Saturday 21 November 2015 08:49:47 Matwey V. Kornilov wrote:

...

...

...

The flavor of dtb (dtb file) is to be specified in /etc/sysconfig/bootloader> That shouldn't be necessary, U-Boot is supposed to provide $fdtfile. In my testing I didn't need to specify a dtb file in extlinux.conf, only the dtb directory.

That is great news, but I think it is better to provide optional possibility to set the file manually. Let me describe use-case.

BeagleBone Black supports the capes, and the kernel still doesn't have an user-space API for overlays. So, to enable my specific hardware I will modify am335x-beaglebone.dts and compile new version, say am335x-beaglebone-with-geiger-counter-cap.dtb. Sure, when I will deploy this to my production, I will make a package dtb-am335x-with-geiger-counter-%{version}.rpm (Please, see above, imagine, new kernel update has been issued and my build service has not rebuild this package yet, so I'll receive an updated kernel and will not receive and updated dtb package)

How should u-boot guess what I want now? So, please, let the user some freedom.

One possibility instead of choosing a different filename, use a different directory name, e.g.: /boot/dtb-4.3.0-geiger-cape/*dtb or /boot/dtb-4.3.0/geiger-cape/*dtb

That still leaves the question of how to get that directory into extlinux.conf - it can no longer be inferred from the kernel then. If the answer is hand-editing FDTDIR, then on the perl-bootloader side we only need to assure that on add/remove operations it does not override such local changes. Do we have any actual example of such a cape dtb package that's not self-made? I encountered and dropped some binary .dtb files in raspberrypi-firmware package, other than that I am not aware of any. And when self-made, doesn't that involve having a modified kernel-source package? 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 21.11.2015 um 18:33 schrieb Matwey V. Kornilov:

21.11.2015 15:59, Andreas Färber пишет:

...

Am 21.11.2015 um 12:48 schrieb Stefan Bruens:

...

On Saturday 21 November 2015 08:49:47 Matwey V. Kornilov wrote:

...

...

...

The flavor of dtb (dtb file) is to be specified in /etc/sysconfig/bootloader> That shouldn't be necessary, U-Boot is supposed to provide $fdtfile. In my testing I didn't need to specify a dtb file in extlinux.conf, only the dtb directory.

That is great news, but I think it is better to provide optional possibility to set the file manually. Let me describe use-case.

BeagleBone Black supports the capes, and the kernel still doesn't have an user-space API for overlays. So, to enable my specific hardware I will modify am335x-beaglebone.dts and compile new version, say am335x-beaglebone-with-geiger-counter-cap.dtb. Sure, when I will deploy this to my production, I will make a package dtb-am335x-with-geiger-counter-%{version}.rpm (Please, see above, imagine, new kernel update has been issued and my build service has not rebuild this package yet, so I'll receive an updated kernel and will not receive and updated dtb package)

How should u-boot guess what I want now? So, please, let the user some freedom.

One possibility instead of choosing a different filename, use a different directory name, e.g.: /boot/dtb-4.3.0-geiger-cape/*dtb or /boot/dtb-4.3.0/geiger-cape/*dtb

I would like to keep %{version} for directory name and %{ftd_flavour} for file name.

Where are you taking those variables from? It's %{kernel_version} and %{kernel_release} in dtb-source, and $ftdfile in U-Boot.

...

That still leaves the question of how to get that directory into extlinux.conf - it can no longer be inferred from the kernel then.

If the answer is hand-editing FDTDIR, then on the perl-bootloader side we only need to assure that on add/remove operations it does not override such local changes.

This is hard to achieve. Sure, entry may be marked as 'manual' and keep untouched but I am not sure how this Yast-magic works in real life.

Where would we need to mark it? Reinstalling my kernel-lpae package did not modify my extlinux.conf at all...

...

Do we have any actual example of such a cape dtb package that's not self-made? I encountered and dropped some binary .dtb files in raspberrypi-firmware package, other than that I am not aware of any. And when self-made, doesn't that involve having a modified kernel-source package?

Not necessary. I may enable UART number N or change pin multiplexing for BBB just editing (patching) .dts file, and this operation is safe. I don't need recompile the kernel.

My point was that .dts files are in kernel-source. So either you need a patch in kernel-source, which leads to a differing %{kernel_release}, or you have a patch in a dtb-source. If you locally patch a .dts file that's what I meant with "self-made". 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 22.11.2015 um 09:47 schrieb Matwey V. Kornilov:

21.11.2015 22:40, Andreas Färber пишет:

...

Am 21.11.2015 um 18:33 schrieb Matwey V. Kornilov:

...

21.11.2015 15:59, Andreas Färber пишет:

...

Do we have any actual example of such a cape dtb package that's not self-made? I encountered and dropped some binary .dtb files in raspberrypi-firmware package, other than that I am not aware of any. And when self-made, doesn't that involve having a modified kernel-source package?

Not necessary. I may enable UART number N or change pin multiplexing for BBB just editing (patching) .dts file, and this operation is safe. I don't need recompile the kernel.

My point was that .dts files are in kernel-source. So either you need a patch in kernel-source, which leads to a differing %{kernel_release}, or you have a patch in a dtb-source. If you locally patch a .dts file that's what I meant with "self-made".

Nothing can prevent me from branching dtb-source and do the following:

cp /usr/src/linux/COPYING . cp -r /usr/src/linux/ . chmod -R ug+rw linux %patch0 %patch1

And introduce a couple of new subpackages.

Right, that's my dtb-source case above, and as long as that is a branch in your home only, it remains your own problem... The easiest solution then is to patch the one .dts for the board if you always use that cape (see below), then nothing needs to be done on the perl-bootloader side. Otherwise if it's multiple files or even new subpackages, please give concrete examples (package URLs), so that we can either adapt them or use them as test cases for perl-bootloader. E.g., I found some instructions for TI PRU Cape, but for downstream SDK: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#Modify_D... Someone would need to maintain such .dtsi files and patches for our kernel versions. Today there is no Contrib project for TI, and if you submitted any extra dtb packages to Base:System or wherever then I am not aware... There is a binary (and questionably labeled GPL-2.0) .dtb file for Moonshot: https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:m400/dtb-m... And .dts and .dtsi files for Efika MX: https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:EFIKAMX/dt... In all other Contrib cases they seem to be from some kernel-source. Anyway, in particular I had in mind that it's quite possible that someone removes a cape before powering on the device and thus before being able to install a different dtb package. Therefore elsewhere I suggested having the core board plus some cape in the menu, which would mean either a) having new subpackages per cape with special %post handling adding that one cape to the menu or b) having packages any way the packagers see fit but letting the user configure which ones to show in the menu, which also requires having a way to regenerate extlinux.conf after updating /etc/sysconfig/bootloader without needing to reinstall all kernel and dtb packages. One concern I have with naming the board filename in a config is that .dtb names can change over time. My ODROID-XU .dts is still not accepted upstream, meaning exynos5410-smdk5410.dtb needs to be used until exynos5410-odroidxu.dtb is available, and for the Parallella we were discussing splitting zynq-parallella.dts into zynq-parallella1-*.dts for handling models with and without USB. One solution might be to allow for kernel-version-specific /etc/sysconfig/bootloader options to override the generic one. Another would be integrating scripts in some extlinux.d dir that dtb-zynq etc. could install. No perfect idea yet. FPGAs also pose further problems for .dtb handling, i.e. the physical board with or without extension boards plus software-defined hardware. Not yet sure whether the new FPGA Manager drivers in 4.4 interact with DT somehow... Do you see a way to configure the location of extlinux.conf maybe? U-Boot only searches in extlinux/extlinux.conf, so if we could optionally tweak that in /etc/sysconfig/bootloader then we could have U-Boot auto-load /boot/boot.scr and load /boot/extlinux.conf (instead of /boot/extlinux/extlinux.conf) from there after doing any env tweaks. 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 21.11.2015 um 18:41 schrieb Stefan Bruens:

On Saturday 21 November 2015 13:59:00 Andreas Färber wrote:

...

Do we have any actual example of such a cape dtb package that's not self-made? I encountered and dropped some binary .dtb files in raspberrypi-firmware package, other than that I am not aware of any. And when self-made, doesn't that involve having a modified kernel-source package?

For RPi, you *need* an overlay/modified dtb to enable the SPI controller. It is also useful to *configure* any SPI or I2C connected devices, e.g. RTCs, touchscreen controllers, LCD controllers. [...]

That's no answer. For me, an overlay is something external to be merged into the DT, not just a modified .dts/.dtb. I would like to know where we have any real geiger-counter cape or SPI dtb packaged. If we don't have any, this whole discussion is highly theoretical. I am guessing from READMEs that bootcode.bin has the ability to manipulate the DT, enabling/disabling nodes and possibly more. But we boot U-Boot from bootcode.bin and thus cannot use those facilities. In a boot.scr such modifications could be scripted via fdt command. But how is the kernel involved in overlays? From what I see, we can only supply one .dtb to the kernel, not a base one plus a list of overlays. 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

21.11.2015 15:47, Andreas Färber пишет:

Am 21.11.2015 um 06:49 schrieb Matwey V. Kornilov:

...

21.11.2015 01:08, Andreas Färber пишет:

...

Am 20.11.2015 um 20:09 schrieb Matwey V. Kornilov:

...

The flavor of dtb (dtb file) is to be specified in /etc/sysconfig/bootloader

That shouldn't be necessary, U-Boot is supposed to provide $fdtfile. In my testing I didn't need to specify a dtb file in extlinux.conf, only the dtb directory.

That is great news, but I think it is better to provide optional possibility to set the file manually. Let me describe use-case.

BeagleBone Black supports the capes, and the kernel still doesn't have an user-space API for overlays. So, to enable my specific hardware I will modify am335x-beaglebone.dts and compile new version, say am335x-beaglebone-with-geiger-counter-cap.dtb. Sure, when I will deploy this to my production, I will make a package dtb-am335x-with-geiger-counter-%{version}.rpm (Please, see above, imagine, new kernel update has been issued and my build service has not rebuild this package yet, so I'll receive an updated kernel and will not receive and updated dtb package)

How should u-boot guess what I want now? So, please, let the user some freedom.

Maybe your statement above was ambiguous - for me "is to be specified" reads as "must be specified". To that I objected.

You're free to add an optional mechanism to override it, of course. But I would prefer to get the current pull sorted out and tested before we investigate such extra features.

Sure, I've missed that fdtdir and fdt are mutually exclusive, I will handle this shortly and then update the pull-request.

I do wonder whether there is a better way, changing fdtfile in U-Boot's environment rather than FDT in extlinux.conf, for instance. Unfortunately extlinux.conf is read before boot.scr, otherwise you could've overridden it there and called sysboot from the script. And uEnv.txt is only read by a handful of boards, so not a general solution, but I believe Matthias reported such an error on BBB?

Yes, it can be a great solution. An environment should be fixed if we want to implement fallback booting finally. Unfortunately, I've heard nothing about issues with uEnv.txt on BBB.

Do you actually need a different filename though? If you want to have a side-by-side installation you would really also need two extlinux.conf entries per kernel to switch easily. Otherwise you could just leave the .dtb filename the same for your modified package, needing no modifications to extlinux.conf.

Why can't I have two entries with the same kernel and different dtb's? There are cases when editing of dts is safe and does not require recompiling the kernel. For instance, enabling some disabled-by-default node.

BTW I thought that months ago we had enabled DT overlays in the kernel on your request. What's missing to make overlays work? I don't have any capes/hats/shields/etc.

DT overlays is a technique to change device tree on the fly, it is great that it is compiled and does not crashes. Unfortunately, there is currently still no interface to ask the kernel: "ok, lets change the device tree in the specific manner". See https://lkml.org/lkml/2015/5/13/157 for instance

Regards, Andreas

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

21.11.2015 23:39, Andreas Färber пишет:

Am 21.11.2015 um 18:48 schrieb Matwey V. Kornilov:

...

21.11.2015 15:47, Andreas Färber пишет:

...

Am 21.11.2015 um 06:49 schrieb Matwey V. Kornilov:

...

21.11.2015 01:08, Andreas Färber пишет:

...

Am 20.11.2015 um 20:09 schrieb Matwey V. Kornilov:

...

The flavor of dtb (dtb file) is to be specified in /etc/sysconfig/bootloader

That shouldn't be necessary, U-Boot is supposed to provide $fdtfile. In my testing I didn't need to specify a dtb file in extlinux.conf, only the dtb directory.

That is great news, but I think it is better to provide optional possibility to set the file manually. Let me describe use-case.

BeagleBone Black supports the capes, and the kernel still doesn't have an user-space API for overlays. So, to enable my specific hardware I will modify am335x-beaglebone.dts and compile new version, say am335x-beaglebone-with-geiger-counter-cap.dtb. Sure, when I will deploy this to my production, I will make a package dtb-am335x-with-geiger-counter-%{version}.rpm (Please, see above, imagine, new kernel update has been issued and my build service has not rebuild this package yet, so I'll receive an updated kernel and will not receive and updated dtb package)

How should u-boot guess what I want now? So, please, let the user some freedom.

Maybe your statement above was ambiguous - for me "is to be specified" reads as "must be specified". To that I objected.

You're free to add an optional mechanism to override it, of course. But I would prefer to get the current pull sorted out and tested before we investigate such extra features.

Sure, I've missed that fdtdir and fdt are mutually exclusive, I will handle this shortly and then update the pull-request.

...

I do wonder whether there is a better way, changing fdtfile in U-Boot's environment rather than FDT in extlinux.conf, for instance. Unfortunately extlinux.conf is read before boot.scr, otherwise you could've overridden it there and called sysboot from the script. And uEnv.txt is only read by a handful of boards, so not a general solution, but I believe Matthias reported such an error on BBB?

Yes, it can be a great solution. An environment should be fixed if we want to implement fallback booting finally.

...

Unfortunately, I've heard nothing about issues with uEnv.txt on BBB.

No real issue, just a report that U-Boot was complaining about not finding uEnv.txt (because we don't supply any AFAICS). Which would in turn imply that it can read info from there if we provide it.

...

...

Do you actually need a different filename though? If you want to have a side-by-side installation you would really also need two extlinux.conf entries per kernel to switch easily. Otherwise you could just leave the .dtb filename the same for your modified package, needing no modifications to extlinux.conf.

Why can't I have two entries with the same kernel and different dtb's? There are cases when editing of dts is safe and does not require recompiling the kernel. For instance, enabling some disabled-by-default node.

I'm not saying you can't, just that automating this is somewhat problematic: When I install dtb-foo then it contains multiple .dtb files usually, but I don't want boot menu entries for all other boards, just the one (two when counting failsafe) determined by $fdtfile. In your case I imagine it would be both the default for $fdtfile plus an entry per cape dtb. The unanswered question is what correlation between extra dtb package and menu entries we might arrive at, i.e. would you have a package just for Geiger Cape that would add the entry as %post or would you have a package with several cape DTBs that you do not all want in your menu automatically.

A solution might be to extend your /etc/sysconfig/bootloader option suggestion to allow specifying multiple (e.g., space-delimited) dtb file names and generating a menu entry for each.

And here you are right. Moreover may "Failsafe" entries want to have dtb file different from default?

...

...

BTW I thought that months ago we had enabled DT overlays in the kernel on your request. What's missing to make overlays work? I don't have any capes/hats/shields/etc.

DT overlays is a technique to change device tree on the fly, it is great that it is compiled and does not crashes. Unfortunately, there is currently still no interface to ask the kernel: "ok, lets change the device tree in the specific manner".

So was that the proposed conditional sections for multiple BBB revisions in one .dts? Or is there a location like /boot/overlays/ in the RPi case that the kernel searches overlay files to be merged as-is? Or just an internal API?

...

See https://lkml.org/lkml/2015/5/13/157 for instance

Do you have a quick summary? :) I see a BBB-specific sysfs interface that gets info via EEPROM, which I guess means I2C. Does this need anything from our side in terms of .dtb files, or does it get everything from the cape EEPROM?

No, it only reads cape type and version from the cape's EEPROM and requests appropriate dtbo file from user-space.

For instance if the part-number is BB-BONE-SERL-03 and the version is 00A1 the firmware file requested will be BB-BONE-SERL-03-00A1-00A1.dtbo It will be located by the in-kernel firmware loader in the usual place, i.e. /lib/firmware/`uname -r`, /lib/firmware etc.

Regards, Andreas

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

21.11.2015 21:59, Andreas Färber пишет:

Am 21.11.2015 um 06:49 schrieb Matwey V. Kornilov:

...

21.11.2015 01:08, Andreas Färber пишет:

...

Am 20.11.2015 um 20:09 schrieb Matwey V. Kornilov:

...

16.11.2015 04:05, Andreas Färber пишет:

...

Am 15.11.2015 um 19:50 schrieb Matwey V. Kornilov:

...

2015-11-15 21:34 GMT+03:00 Andreas Färber : > Am 28.10.2015 um 19:07 schrieb Matwey V. Kornilov: >> I've just looked through perl-bootloader. It is not so hard to implement >> additional module Extlinux.pm, given there is hardware support to test. >> But I would say that to implement extlinux support seems to be way >> easier than direct u-boot anyway. >> Patching perl-bootloader should be sufficient for correct operation of >> kernel RPM post/pre scripts. > > Have you looked further into implementing this? > > I am testing changes to dtb-source, but I do not have a good solution > for /boot/dtb symlink yet. Switching to extlinux would elegantly avoid > tackling that. ;)

I've just tested that extlinux worked. I am going to start to implement initial support into perl-bootloader,

Great, then I'll leave my hands off.

I gathered that /etc/sysconfig/bootloader would need LOADER_TYPE="extlinux", and Library.pm:SetLoaderType() would need to handle "extlinux" to instantiate your new Core/Extlinux.pm. https://github.com/openSUSE/perl-bootloader

https://github.com/openSUSE/perl-bootloader/pull/81

Looks promising, do you have it packaged for testing?

https://build.opensuse.org/package/show/home:matwey:branches:Base:System/per...

When I run `update-bootloader --refresh` with my custom extlinux.conf in place, it appears to parse it okay and the file appears to be unmodified, not even getting a new date to my surprise.

As it should be, perl-bootloader checks if you need modifications and don't touch the file if you don't. --add and --remove commands work as expected (they of course do nothing with FDT not).

However, when I do not have /boot/extlinux/ or /boot/extlinux/extlinux.conf in place and run `update-bootloader --reinit`, it complains:

Perl-Bootloader: 2015-11-21 19:44:04 <3> pbl-5624.2 FileIO::ReadFileRaw.168: Error: Failed to open /boot/extlinux/extlinux.conf: No such file or directory

`--force` does not help either. /var/log/pbl.log did not show errors.

Shouldn't it generate some default config for either --refresh or --reinit when absent?

This is gray area for me, because none of existing modules does so (they have 'default' options but not write them out actually). I think the better solution is to place initial extlinux.conf into some RPM package where default values can be adjusted much simpler.

Regards, Andreas

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hello Matwey, On Wed, Oct 28, 2015 at 11:31 AM, Matwey V. Kornilov wrote:

27.10.2015 22:43, Misha Komarovskiy пишет:

...

Hello Matwey,

On Tue, Oct 27, 2015 at 9:52 PM, Matwey V. Kornilov wrote:

...

27.10.2015 11:04, Guillaume Gardet пишет:

...

Hi,

Le 26/10/2015 19:52, Matwey V. Kornilov a écrit :

...

Hello,

Why bootmenu command is not used atm? Are there any reasons?

You mean ansi bootmenu? If yes, ac100 community member tried to enable it for our board, but extlinux.conf was proposed as better solution, here is link http://patchwork.ozlabs.org/patch/450122/

I tried to use extlinux.conf with openSUSE on Chromebook Snow, because its support already enabled there, and it work flawlessly and very flexible, take a look at README.distro in u-boot repo, also as it is same as pxe config file kiwi probably already have support for it.

Here is example of my test extlinux.conf:

TIMEOUT 1000 ONTIMEOUT localboot DEFAULT default MENU TITLE Boot menu PROMPT 0

LABEL default MENU LABEL Default LINUX /boot/zImage FDT /boot/dtb/exynos5250-snow.dtb INITRD /boot/initrd APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 console=ttySAC3,115200n8 console=tty

LABEL failsafe MENU LABEL Failsafe LINUX /boot/zImage-4.1.5-exynos_defconfig FDT /boot/dtb/exynos5250-snow.dtb INITRD /boot/initrd-4.1.5-exynos_defconfig APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 console=ttySAC3,115200n8 console=tty

LABEL localboot MENU LABEL Local boot script (boot.scr) LOCALBOOT 1

Nice. I cannot understand is it uboot who runs extlinux or just support of extlinux configuration file syntax inside uboot?

It is pxe boot support inside u-boot, but this support can fallback to reading extlinux.conf from external media located in extlinux folder if no pxe network server was available on boot. And boards which have pxe/extlinux support available in their u-boot configs read extlinux.conf file prior to boot.scr file.

...

...

...

I think nobody worked on it until now.

Oh, I see.

But first I am going to introduce additional env variable to simplify selection of the kernel version from u-boot command line.

After then, I would highly want to have fallback possibility like the following:

https://www.gnu.org/software/grub/manual/legacy/Booting-fallback-systems.htm... which can be implemented using u-boot uEnv.txt file

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hello Matwey, On Thu, Oct 29, 2015 at 11:28 PM, Matwey V. Kornilov wrote:

28.10.2015 19:11, Misha Komarovskiy пишет:

...

Hello Matwey,

On Wed, Oct 28, 2015 at 11:31 AM, Matwey V. Kornilov wrote:

...

27.10.2015 22:43, Misha Komarovskiy пишет:

...

Hello Matwey,

On Tue, Oct 27, 2015 at 9:52 PM, Matwey V. Kornilov wrote:

...

27.10.2015 11:04, Guillaume Gardet пишет:

...

Hi,

Le 26/10/2015 19:52, Matwey V. Kornilov a écrit : > > Hello, > > Why bootmenu command is not used atm? Are there any reasons? >

You mean ansi bootmenu? If yes, ac100 community member tried to enable it for our board, but extlinux.conf was proposed as better solution, here is link http://patchwork.ozlabs.org/patch/450122/

I tried to use extlinux.conf with openSUSE on Chromebook Snow, because its support already enabled there, and it work flawlessly and very flexible, take a look at README.distro in u-boot repo, also as it is same as pxe config file kiwi probably already have support for it.

Here is example of my test extlinux.conf:

TIMEOUT 1000 ONTIMEOUT localboot DEFAULT default MENU TITLE Boot menu PROMPT 0

LABEL default MENU LABEL Default LINUX /boot/zImage FDT /boot/dtb/exynos5250-snow.dtb INITRD /boot/initrd APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 console=ttySAC3,115200n8 console=tty

LABEL failsafe MENU LABEL Failsafe LINUX /boot/zImage-4.1.5-exynos_defconfig FDT /boot/dtb/exynos5250-snow.dtb INITRD /boot/initrd-4.1.5-exynos_defconfig APPEND root=/dev/disk/by-id/mmc-SL08G_0x01978580-part3 loader=uboot disk=/dev/disk/by-id/mmc-SL08G_0x01978580 resume=/dev/disk/by-id/mmc-SL08G_0x01978580-part4 plymouth.enable=0 console=ttySAC3,115200n8 console=tty

LABEL localboot MENU LABEL Local boot script (boot.scr) LOCALBOOT 1

Nice. I cannot understand is it uboot who runs extlinux or just support of extlinux configuration file syntax inside uboot?

It is pxe boot support inside u-boot, but this support can fallback to reading extlinux.conf from external media located in extlinux folder if no pxe network server was available on boot. And boards which have pxe/extlinux support available in their u-boot configs read extlinux.conf file prior to boot.scr file.

In our am335x_evm config, bootloader selects dtb file name based on the data read from EEPROM. How could this be implemented with extlinux?

Then you probably need to export this data from eeprom to $board_name and $cpu u-boot variables (CONFIG_ENV_VARS_UBOOT_CONFIG content if i remember right), which exlinux use to load dtb file if only FDTDIR supplied. Probably some extra setting to your defconfig also required, check README.distro for full list of requirements: http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.distro;h=9e4722a86ee562...

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- Best Regards, Misha Komarovskiy zombahatgmaildotcom -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Wednesday 28 October 2015 11:31:20 Matwey V. Kornilov wrote:

27.10.2015 22:43, Misha Komarovskiy пишет:

Nice. I cannot understand is it uboot who runs extlinux or just support of extlinux configuration file syntax inside uboot?

The extlinux support is u-boot native support for the file format. You can find the specification here: http://code.metager.de/source/xref/denx/u-boot/doc/README.pxe I have not used it as local config file, but fetched it via TFTP/PXE. Very nice for development, just put the kernel/initrd on the file server. Btw, AFAIK Fedora has a patch for grub2 exlinux.cfg support. 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