Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Using a custom device tree file

147 views
Skip to first unread message

Rainer Dorsch

unread,
Feb 11, 2018, 3:40:02 PM2/11/18
to
Hello,

I try to use a custom device tree file, but uEnv.txt does not have any effect:

rd@mohot:~$ cat /boot/uEnv.txt
fdtfile=imx6dl-hummingboard-spi.dtb
rd@mohot:~$ fdtdump /boot/dtbs/4.14.0-3-armmp/imx6dl-hummingboard-spi.dtb|grep
model

**** fdtdump is a low-level debugging tool, not meant for general use.
**** If you want to decompile a dtb, you probably want
**** dtc -I dtb -O dts <filename>

model = "SolidRun HummingBoard Solo/DualLite SPI enabled";
model = "On-board Codec";
model = "On-board SPDIF";
rd@mohot:~$ cat /proc/device-tree/model
SolidRun HummingBoard Dual/Quadrd@mohot:~$

Do I need to run flash-kernel or something else that uEnv.txt has any effect?

Thanks
Rainer

--
Rainer Dorsch
http://bokomoko.de/

Vagrant Cascadian

unread,
Feb 11, 2018, 4:30:03 PM2/11/18
to
On 2018-02-11, Rainer Dorsch wrote:
> I try to use a custom device tree file, but uEnv.txt does not have any effect:
>
> rd@mohot:~$ cat /boot/uEnv.txt
> fdtfile=imx6dl-hummingboard-spi.dtb
...
> Do I need to run flash-kernel or something else that uEnv.txt has any effect?

I don't believe the u-boot in Debian or mainline supports uEnv.txt for
the hummingboard variants. Or any of the variants supported in Debian's
u-boot package, though I haven't looked closely.

Try adding the following to /etc/flash-kernel/ubootenv.d/fdtfile:

setenv fdtfile imx6dl-hummingboard-spi.dtb

And running flash-kernel to regenerate the boot script.


live well,
vagrant
signature.asc

Rainer Dorsch

unread,
Feb 11, 2018, 4:30:03 PM2/11/18
to
Thanks for your quick answer Vagrant.

In case I try to boot a broken dtb (kernel does not boot), is there a way back
to the previous dtb?

Rainer Dorsch

unread,
Feb 17, 2018, 6:00:03 AM2/17/18
to
Hello,
AFAIK there are two ways to tell the kernel where to find the device tree:
-> append to the kernel binary
-> the bootloader handles this during boot and makes it available for the
kernel

Can anybody tell, which method u-boot in Debian implements (in particular for
the hummingboard)?

Can anybody tell, if it is possible to configure from u-boot shell to loada
custom device treefile?

Is that somewhere documented? The latest documentation on flash-kernelI found
is from 2011... https://wiki.debian.org/FlashKernelRework

Vagrant Cascadian

unread,
Feb 18, 2018, 1:10:02 PM2/18/18
to
On 2018-02-17, Rainer Dorsch wrote:
> Am Sonntag, 11. Februar 2018, 22:24:51 CET schrieb Rainer Dorsch:
>> Am Sonntag, 11. Februar 2018, 13:20:07 CET schrieb Vagrant Cascadian:
>> > On 2018-02-11, Rainer Dorsch wrote:
>> > Try adding the following to /etc/flash-kernel/ubootenv.d/fdtfile:
>> > setenv fdtfile imx6dl-hummingboard-spi.dtb
>> >
>> > And running flash-kernel to regenerate the boot script.
>>
>> Thanks for your quick answer Vagrant.
>>
>> In case I try to boot a broken dtb (kernel does not boot), is there a way
>> back to the previous dtb?
>
> AFAIK there are two ways to tell the kernel where to find the device tree:
> -> append to the kernel binary
> -> the bootloader handles this during boot and makes it available for the
> kernel
>
> Can anybody tell, which method u-boot in Debian implements (in particular for
> the hummingboard)?

In Debian, using Debian-supplied u-boot and a boot script generated by
flash-kernel, hummingboard/mx6cuboxi variants run a
bootscript... flash-kernel defines in /usr/share/flash-kernel/db/all.db:

Machine: SolidRun HummingBoard DL/Solo
Machine: SolidRun HummingBoard Solo/DualLite
Kernel-Flavors: armmp
DTB-Id: imx6dl-hummingboard.dtb
Boot-Script-Path: /boot/boot.scr
U-Boot-Script-Name: bootscr.uboot-generic
Required-Packages: u-boot-tools

Machine: SolidRun HummingBoard Dual/Quad
Kernel-Flavors: armmp
DTB-Id: imx6q-hummingboard.dtb
Boot-Script-Path: /boot/boot.scr
U-Boot-Script-Name: bootscr.uboot-generic
Required-Packages: u-boot-tools


So, flash-kernel copies the .dtb file listed there to
/boot/dtbs/VERSION/ and symlinks /boot/dtb* to the .dtb in the versioned
directory, based on the machine name defined in /proc/device-tree/model.

All the above variants use the uboot-generic boot script, which can be
found and edited on an installed system in:

/etc/flash-kernel/bootscript/

So you could edit the script to do whatever you want.


> Can anybody tell, if it is possible to configure from u-boot shell to loada
> custom device treefile?

To manually change it for a one-off boot:

# disable the built-in setting of fdtfile
setenv findfdt
# manually set fdtfile
setenv fdtfile /path/to/your/custom.dtb

You could, of course, also manually load the kernel, initrd, fdt and use
bootz rather than trying to work around the defaults in the boot script.


> Is that somewhere documented? The latest documentation on flash-kernelI found
> is from 2011...


I'm not sure what sort of documentation you're looking for.

You can learn about u-boot by looking in the source code for the README,
the doc/* files, and of course the source code itself.

Many modern boards are using distro_bootcmd, which is documented in
doc/README.distro, which has improved the consistancy of behavior of
boards.

There's the README for flash-kernel in
/usr/share/doc/flash-kernel/README*


> https://wiki.debian.org/FlashKernelRework

Some of the features documented there have been implemented, or don't
really apply to modern boards that make use of distro_bootcmd.

Now that I'm on a roll and this email is getting really long...

I do think we should consider replacing flash-kernel with something else
at this point. The tool has grown and evolved all sorts of features;
I've never used it to "flash a kernel". I've exclusively used it for
purposes other than it's original design (mostly just copying a .dtb and
generating a boot script that is essentially re-useable on most boards I
use it with).

Scalability is a bit questionable; it actually cats the entire contents
of all.db and reads it into a variable, and then does "echo $VARIABLE |
grep FOO" type things in order to get data out of it. With new sunxi
boards coming out what *feels* like twice each week, grepping through an
echo'ed variable starts to seem like a bad idea to me.

Of course, it also kind of works well enough for what it is... but
adding new features is, in my experience, an unpleasant task. And
occasionally those new features are really needed with modern changes.


I've used u-boot-menu on a handful of boards, although it also currently
has some limitations. For example, it doesn't support /boot on a
separate partition without manual configuration ... anyone remember the
lovely hack "ln -s . /boot/boot" ... well, yeah... using *that*
again. It also doesn't handle copying the .dtb into /boot, so I still
need flash-kernel for that.

And then there's the support for u-boot emulating EFI so you could use
grub-efi-*, which has made great progress in recent u-boot versions. But
then we could use grub on more platforms ... that would be a nice goal
for buster, at least.


live well,
vagrant
signature.asc

Gene Heskett

unread,
Feb 18, 2018, 5:00:03 PM2/18/18
to
Thank you very very much, this is probably the post, a howto, that I've
been looking for, for months.

Now my problem is that the db for flash-kernel is 2 or 3 years out of
date and contains no mention of either the pi-3b, nor the pine offering
called the rock64. And quite likely, u-boot-tools is also dated. Where
can I report that?

Another similar boot composer needs docker, but that doesn't run on
stretch for arm64's.

Many thanks for more info.

> live well,
> vagrant

Take care, Gene

--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Vagrant Cascadian

unread,
Feb 18, 2018, 5:50:02 PM2/18/18
to
On 2018-02-18, Gene Heskett wrote:
> On Saturday 17 February 2018 19:22:06 Vagrant Cascadian wrote:
>> On 2018-02-17, Rainer Dorsch wrote:
>> > Am Sonntag, 11. Februar 2018, 22:24:51 CET schrieb Rainer Dorsch:
>> >> Am Sonntag, 11. Februar 2018, 13:20:07 CET schrieb Vagrant Cascadian:
>> >> > On 2018-02-11, Rainer Dorsch wrote:
...
> Thank you very very much, this is probably the post, a howto, that I've
> been looking for, for months.

Glad it was helpful.


> Now my problem is that the db for flash-kernel is 2 or 3 years out of
> date and contains no mention of either the pi-3b,

Please report bugs against flash-kernel, but please first check against
current versions of flash-kernel. There's support for raspberry pi 2b
and and 3b in the current version of flash-kernel.

You can sometimes grab the relevent stanzas from newer versions and use
them on the old version of flash-kernel by adding them to
/etc/flash-kernel/db:

Machine: Raspberry Pi 3 Model B
Kernel-Flavors: arm64 armmp armmp-lpae
DTB-Id: bcm2837-rpi-3-b.dtb
U-Boot-Script-Name: bootscr.uboot-generic
Required-Packages: u-boot-tools
Boot-Script-Path: /boot/boot.scr


I am using the pi 2b with the version of linux and flash-kernel from
Debian stretch. Raspbian's kernel likely has the legacy device-tree
names and you might have to adjust flash-kernel configuration for
that. Raspbian also doesn't typically use u-boot for a bootloader, and
flash-kernel doesn't do anything to configure booting from the default
boot firmware.


> nor the pine offering called the rock64.

There isn't support for the rock64 in mainline u-boot, and I'm not sure
how good the linux kernel support is. So I'm not sure it makes sense to
add a flash-kernel entry for it until it's better supported in mainline
linux and u-boot; Debian doesn't usually add support that isn't present
in mainline, as long-term maintenance impractical.

I've got one, so I'll keep an eye on it and try to enable support in
Debian as it becomes available.


> And quite likely, u-boot-tools is also dated.

I'm not sure what you're referring to here, but there's u-boot 2018.01
in experimental, and 2017.11 in sid/buster. There's a 2018.03-rc1 that I
haven't yet uploaded. Stretch has the most recent u-boot version at the
time of stretch freeze, which was in late 2016, so it only has
2016.11. But that's how stable releases work; major new versions of
software does not typically get added to a stable release.


> Where can I report that?

In Debian, it's often good to report a bug through the Debian Bug
Tracking System:

https://www.debian.org/Bugs/Reporting


live well,
vagrant
signature.asc

Gene Heskett

unread,
Feb 18, 2018, 6:10:02 PM2/18/18
to
On Sunday 18 February 2018 17:43:11 Vagrant Cascadian wrote:

> On 2018-02-18, Gene Heskett wrote:
> > On Saturday 17 February 2018 19:22:06 Vagrant Cascadian wrote:
> >> On 2018-02-17, Rainer Dorsch wrote:
> >> > Am Sonntag, 11. Februar 2018, 22:24:51 CET schrieb Rainer Dorsch:
> >> >> Am Sonntag, 11. Februar 2018, 13:20:07 CET schrieb Vagrant
Cascadian:
> >> >> > On 2018-02-11, Rainer Dorsch wrote:
>
> ...
>
> > Thank you very very much, this is probably the post, a howto, that
> > I've been looking for, for months.
>
> Glad it was helpful.
>
> > Now my problem is that the db for flash-kernel is 2 or 3 years out
> > of date and contains no mention of either the pi-3b,
>
> Please report bugs against flash-kernel, but please first check
> against current versions of flash-kernel. There's support for
> raspberry pi 2b and and 3b in the current version of flash-kernel.
>
2b is listed, but not the 3b in an uptodate yesterday stretch install.

> You can sometimes grab the relevent stanzas from newer versions and
> use them on the old version of flash-kernel by adding them to
> /etc/flash-kernel/db:

I'd imagine so.
>
> Machine: Raspberry Pi 3 Model B
> Kernel-Flavors: arm64 armmp armmp-lpae
> DTB-Id: bcm2837-rpi-3-b.dtb
> U-Boot-Script-Name: bootscr.uboot-generic
> Required-Packages: u-boot-tools
> Boot-Script-Path: /boot/boot.scr
>
>
> I am using the pi 2b with the version of linux and flash-kernel from
> Debian stretch. Raspbian's kernel likely has the legacy device-tree
> names and you might have to adjust flash-kernel configuration for
> that. Raspbian also doesn't typically use u-boot for a bootloader, and
> flash-kernel doesn't do anything to configure booting from the default
> boot firmware.

The machine in question is a pair of 4Gb rock64's.

> > nor the pine offering called the rock64.
>
> There isn't support for the rock64 in mainline u-boot, and I'm not
> sure how good the linux kernel support is.

The existing kernel in an ayufan release is solid, but I need to replace
it with a local build, on the rockchip, v4.14.15-rt13 kernel.

> So I'm not sure it makes
> sense to add a flash-kernel entry for it until it's better supported
> in mainline linux and u-boot; Debian doesn't usually add support that
> isn't present in mainline, as long-term maintenance impractical.
>
> I've got one, so I'll keep an eye on it and try to enable support in
> Debian as it becomes available.
>
> > And quite likely, u-boot-tools is also dated.
>
> I'm not sure what you're referring to here, but there's u-boot 2018.01
> in experimental, and 2017.11 in sid/buster. There's a 2018.03-rc1 that
> I haven't yet uploaded. Stretch has the most recent u-boot version at
> the time of stretch freeze, which was in late 2016, so it only has
> 2016.11. But that's how stable releases work; major new versions of
> software does not typically get added to a stable release.

What do I use for a deb entry in sources.list.d to access this later
stuffs?
>
> > Where can I report that?
>
> In Debian, it's often good to report a bug through the Debian Bug
> Tracking System:
>
> https://www.debian.org/Bugs/Reporting
>
I'll see about this after I fix dinner for us. Thank you.
>
> live well,
> vagrant

ibu ☉ radempa

unread,
Feb 19, 2018, 1:50:02 PM2/19/18
to
Yes, I'd appreciate grub.

When debugging the boot process with an encrypted rootfs on my Odroid
XU4s I found it very comfortable to be able to easily switch between
boot configurations with grub (which I had thanks to sesse's install
script for XU4). And maybe it's not just me, because one of the usage
scenarios for SBCs will be self-hosted services (think of freedombox),
for which disk encryption can be an issue.

ibu

Rainer Dorsch

unread,
Feb 19, 2018, 5:10:02 PM2/19/18
to
Hi Vagrant,

many thanks for the comprehensive answer and summary on how flash-kernel works.

Am Samstag, 17. Februar 2018, 16:22:06 CET schrieb Vagrant Cascadian:

>
> In Debian, using Debian-supplied u-boot and a boot script generated by
> flash-kernel, hummingboard/mx6cuboxi variants run a
> bootscript... flash-kernel defines in /usr/share/flash-kernel/db/all.db:
>
> Machine: SolidRun HummingBoard DL/Solo
> Machine: SolidRun HummingBoard Solo/DualLite
> Kernel-Flavors: armmp
> DTB-Id: imx6dl-hummingboard.dtb
> Boot-Script-Path: /boot/boot.scr
> U-Boot-Script-Name: bootscr.uboot-generic
> Required-Packages: u-boot-tools
>
> Machine: SolidRun HummingBoard Dual/Quad
> Kernel-Flavors: armmp
> DTB-Id: imx6q-hummingboard.dtb
> Boot-Script-Path: /boot/boot.scr
> U-Boot-Script-Name: bootscr.uboot-generic
> Required-Packages: u-boot-tools
>
>
> So, flash-kernel copies the .dtb file listed there to
> /boot/dtbs/VERSION/ and symlinks /boot/dtb* to the .dtb in the versioned
> directory, based on the machine name defined in /proc/device-tree/model.

I replaced the dtb file in /boot/dtbs/VERSION/ that worked well. Thank you.
Also mounting the sdcard and reverting back to the old one worked ;-)

> All the above variants use the uboot-generic boot script, which can be
> found and edited on an installed system in:
>
> /etc/flash-kernel/bootscript/
>
> So you could edit the script to do whatever you want.
>
> > Can anybody tell, if it is possible to configure from u-boot shell to
> > loada
> > custom device treefile?
>
> To manually change it for a one-off boot:
>
> # disable the built-in setting of fdtfile
> setenv findfdt
> # manually set fdtfile
> setenv fdtfile /path/to/your/custom.dtb

Where is findfdt defined?

$ grep findfdt /etc/flash-kernel/bootscript/*
$

>From looking into the bootscr fdtfile needs only the filename:

if test -n "${fdtfile}"; then
setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
else
setenv fdtpath dtb-${fk_kvers}
fi

Correct?

> You could, of course, also manually load the kernel, initrd, fdt and use
> bootz rather than trying to work around the defaults in the boot script.

Hmm... not sure how that works, but would be worthwhile to document,. I assume
I need to do something like

load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${pathprefix}
vmlinuz \
&& load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${pathprefix}dtb \
&& load ${devtype} ${devnum}:${partition} ${ramdisk_addr_r} ${pathprefix}
initrd.img \
&& echo "Booting Debian from ${devtype} ${devnum}:${partition}..." \
&& bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

I did not find an easy way to boot the .old kernel, just wondering if it would
make sense to do add a kernelpostfix

load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${pathprefix}vmlinuz$
{kernelpostfix}

and similar for the other lines. Then it would be sufficient to set in the u-
boot shell: kernelpostfix to .old


> > Is that somewhere documented? The latest documentation on flash-kernelI
> > found is from 2011...
>
> I'm not sure what sort of documentation you're looking for.
>
> You can learn about u-boot by looking in the source code for the README,
> the doc/* files, and of course the source code itself.
>
> Many modern boards are using distro_bootcmd, which is documented in
> doc/README.distro, which has improved the consistancy of behavior of
> boards.

I have never seen that, thanks for mentioning this.

> There's the README for flash-kernel in
> /usr/share/doc/flash-kernel/README*
>
> > https://wiki.debian.org/FlashKernelRework
>
> Some of the features documented there have been implemented, or don't
> really apply to modern boards that make use of distro_bootcmd.
>
> Now that I'm on a roll and this email is getting really long...
>
> I do think we should consider replacing flash-kernel with something else
> at this point. The tool has grown and evolved all sorts of features;

I did not want to imply replacing flash-kernel....

> I've never used it to "flash a kernel". I've exclusively used it for
> purposes other than it's original design (mostly just copying a .dtb and
> generating a boot script that is essentially re-useable on most boards I
> use it with).
>
> Scalability is a bit questionable; it actually cats the entire contents
> of all.db and reads it into a variable, and then does "echo $VARIABLE |
> grep FOO" type things in order to get data out of it. With new sunxi
> boards coming out what *feels* like twice each week, grepping through an
> echo'ed variable starts to seem like a bad idea to me.
>
> Of course, it also kind of works well enough for what it is... but
> adding new features is, in my experience, an unpleasant task. And
> occasionally those new features are really needed with modern changes.
>
>
> I've used u-boot-menu on a handful of boards, although it also currently
> has some limitations. For example, it doesn't support /boot on a
> separate partition without manual configuration ... anyone remember the
> lovely hack "ln -s . /boot/boot" ... well, yeah... using *that*
> again. It also doesn't handle copying the .dtb into /boot, so I still
> need flash-kernel for that.
>
> And then there's the support for u-boot emulating EFI so you could use
> grub-efi-*, which has made great progress in recent u-boot versions. But
> then we could use grub on more platforms ... that would be a nice goal
> for buster, at least.
>

Many thanks for the detailed description, I bookmarked your post in the
mailing list archive :-)

Does it make sense to paste the big picture in a Debian wiki page (or multiple
of them) and link the /usr/share/doc/... files?

Thanks a lot again

Vagrant Cascadian

unread,
Mar 7, 2018, 8:10:02 PM3/7/18
to
On 2018-02-19, Rainer Dorsch wrote:
> Am Samstag, 17. Februar 2018, 16:22:06 CET schrieb Vagrant Cascadian:
>> > Can anybody tell, if it is possible to configure from u-boot shell to
>> > loada
>> > custom device treefile?
>>
>> To manually change it for a one-off boot:
>>
>> # disable the built-in setting of fdtfile
>> setenv findfdt
>> # manually set fdtfile
>> setenv fdtfile /path/to/your/custom.dtb
>
> Where is findfdt defined?

In the built-in u-boot environment on some boards. Typically with u-boot
variants that can support multiple similar boards; a single mx6cuboxi
u-boot binary supports several cubox-i and hummingboard variants.

It's typically run from bootcmd, so "printenv bootcmd" from the u-boot
prompt might show something like "run findfdt ; run distro_bootcmd".


>>From looking into the bootscr fdtfile needs only the filename:
>
> if test -n "${fdtfile}"; then
> setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
> else
> setenv fdtpath dtb-${fk_kvers}
> fi
>
> Correct?

Ah, yes, full path wouldn't work in this case- you'd have to have it in
one of the above locations the boot scripts look for.


live well,
vagrant
signature.asc

Rainer Dorsch

unread,
Jul 9, 2018, 9:40:03 AM7/9/18
to
Hi Vagrant,

I want to use a modified dts file for a Hummingboard, I do enable spidev for
the spi interfaces:

What I did so far is I created a new file:

rd@master:/mnt/disk/scratch/rd$ diff -u ./debian/kernel/linux-source-4.14/
arch/arm/boot/dts/imx6q-hummingboard.dts ./debian/kernel/linux-source-4.14/
arch/arm/boot/dts/imx6q-hummingboard-spi.dts
--- ./debian/kernel/linux-source-4.14/arch/arm/boot/dts/imx6q-hummingboard.dts
2018-01-10 09:31:23.000000000 +0100
+++ ./debian/kernel/linux-source-4.14/arch/arm/boot/dts/imx6q-hummingboard-
spi.dts 2018-02-18 21:29:20.870755691 +0100
@@ -45,7 +45,7 @@
#include "imx6qdl-hummingboard.dtsi"

/ {
- model = "SolidRun HummingBoard Dual/Quad";
+ model = "SolidRun HummingBoard Dual/Quad spidev enabled";
compatible = "solidrun,hummingboard/q", "fsl,imx6q";
};

@@ -56,3 +56,36 @@
fsl,transmit-atten-16ths = <9>;
fsl,receive-eq-mdB = <3000>;
};
+
+&ecspi2 {
+ fsl,spi-num-chipselects = <2>;
+ cs-gpios = <&gpio2 26 1>, <&gpio2 27 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard_spi>;
+ status = "okay";
+ spidev@0x00 {
+ compatible = "spidev";
+ spi-max-frequency = <5000000>;
+ reg = <0>;
+ };
+ spidev@0x01 {
+ compatible = "spidev";
+ spi-max-frequency = <5000000>;
+ reg = <1>;
+ };
+};
+
+
+&iomuxc {
+ hummingboard {
+ pinctrl_hummingboard_spi: hummingboard_spi {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x80000000
+ MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x80000000
+ >;
+ };
+ };
+};
rd@master:/mnt/disk/scratch/rd$

and build a new dtb and copied it to

# cp arch/arm/boot/dts/imx6dl-hummingboard-spi.dtb /boot/dtbs/4.14.0-3-armmp/

and copied it to imx6q-hummingboard.dtb (i.e. overwrote the old supplied dtb
after making a copy of it).

Introducing a new model name was probably not a good idea, since it breaks the
upgrade, so I try to go back to the unmodified model name. Then after each
kernel upgrade I need to go through the manual procedure of rebuilding a new
modified dtb file.... do you see a better way to keep spidev enabled?

Thanks
Rainer
0 new messages