Re: Compiling barebox without PBL and using dts from Linux dts upstream for Zynq SoC

["Michał Kruszewski" <mkru@protonmail.com>]

The buardate is correct:
CONFIG_BAUDRATE=115200
something else must be the problem.


> Just a guess, try swapping the order of
>  mci_of_parse(&arasan_sdhci->mci);
>  sdhci_setup_host(&arasan_sdhci->sdhci);
> in drivers/mci/arasan-sdhci.c and see if it makes a difference.

It didn't help.
�=�H�
         !1k̨�!H�sH�o�99ϭsMJ!�H�N�o�MJ�H�N�o�MJ!�H�N�o�9
                                                              �kMJKJH�N�o�JH�N�o�Switch to console [cs1]


barebox 2026.03.0-02720-g57db6e3f7c05-dirty #10 Mon Apr 13 17:30:00 CEST 2026


Board: Zynq Z-Turn MYIR Board V5
deep-probe: disabled in device tree
ERROR: could not get clock /axi/dma-controller@f8003000:apb_pclk(0)
ERROR: could not get clock /axi/etb@f8801000:apb_pclk(0)
ERROR: could not get clock /axi/tpiu@f8803000:apb_pclk(0)
ERROR: could not get clock /axi/funnel@f8804000:apb_pclk(0)
ERROR: could not get clock /axi/ptm@f889c000:apb_pclk(0)
ERROR: could not get clock /axi/ptm@f889d000:apb_pclk(0)
mdio_bus: miibus0: probed
macb e000b000.ethernet@e000b000.of: Cadence GEM at 0xe000b000
arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0
malloc space: 0x17e00000 -> 0x1fdfffff (size 128 MiB)
arasan-sdhci e0100000.mmc@e0100000.of: error while transferring data for command 6
arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0202 , interrupt = 0x00208000
mmc0: Card's startup fails with -74
barebox-environment chosen:environment-sd.of: probe failed: No such file or directory
environment load /dev/env0: No such file or directory
Maybe you have to create the partition.

Hit any to stop autoboot:    3
barebox@Zynq Z-Turn MYIR Board V5:/


I carried out some experiment and realized that the sd card is initialized correctly once after the hard power reset.
No matter whether I swap the order of:
  mci_of_parse(&arasan_sdhci->mci);
  sdhci_setup_host(&arasan_sdhci->sdhci)
It is never initialized correctly after using reset button.

Board: Zynq Z-Turn MYIR Board V5
deep-probe: disabled in device tree
ERROR: could not get clock /axi/dma-controller@f8003000:apb_pclk(0)
ERROR: could not get clock /axi/etb@f8801000:apb_pclk(0)
ERROR: could not get clock /axi/tpiu@f8803000:apb_pclk(0)
ERROR: could not get clock /axi/funnel@f8804000:apb_pclk(0)
ERROR: could not get clock /axi/ptm@f889c000:apb_pclk(0)
ERROR: could not get clock /axi/ptm@f889d000:apb_pclk(0)
mdio_bus: miibus0: probed
macb e000b000.ethernet@e000b000.of: Cadence GEM at 0xe000b000
arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0
malloc space: 0x17e00000 -> 0x1fdfffff (size 128 MiB)
mmc0: detected SD card version 3.0
mmc0: registered mmc0
environment load /mnt/mmc0.0/barebox.env: No such file or directory
Maybe you have to create the partition.

Hit any to stop autoboot:    3
barebox@Zynq Z-Turn MYIR Board V5:/ ls /dev/
cs0                    cs1                    full
mdio0-phy03            mem                    mmc0
mmc0.0                 mmc0.1                 null
prng                   ram0                   xilinx-fpga-manager
zero
barebox@Zynq Z-Turn MYIR Board V5:/


Regards,
Michał Kruszewski


Sent with Proton Mail secure email.

On Monday, April 13th, 2026 at 5:19 PM, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:

> Hello Michał,
> 
> On 4/13/26 5:08 PM, Michał Kruszewski wrote:
> > Good news.
> > I am able to boot barebox and Linux now.
> > Just one minor issue.
> > barebox prints some garbage before it starts:
> 
> Nice! The early PBL console output is before parsing the DT and it seems
> the baudrate was calculated incorrectly.
> 
> Is CONFIG_BAUDRATE of the correct value?
> 
> Next step would be to allow replacing the DT easily. I will let you know
> when there's something to test.
> 
> > Board: Zynq Z-Turn MYIR Board V5
> > deep-probe: disabled in device tree
> 
> I expect that wit barebox,disable-deep-probe removed in the DT, below
> errors should dsappear.
> 
> > ERROR: could not get clock /axi/dma-controller@f8003000:apb_pclk(0)
> > ERROR: could not get clock /axi/etb@f8801000:apb_pclk(0)
> > ERROR: could not get clock /axi/tpiu@f8803000:apb_pclk(0)
> > ERROR: could not get clock /axi/funnel@f8804000:apb_pclk(0)
> > ERROR: could not get clock /axi/ptm@f889c000:apb_pclk(0)
> > ERROR: could not get clock /axi/ptm@f889d000:apb_pclk(0)
> > mdio_bus: miibus0: probed
> > macb e000b000.ethernet@e000b000.of: Cadence GEM at 0xe000b000
> > arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0
> > malloc space: 0x17e00000 -> 0x1fdfffff (size 128 MiB)
> > arasan-sdhci e0100000.mmc@e0100000.of: error while transferring data for command 6
> > arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0202 , interrupt = 0x00208000
> > mmc0: Card's startup fails with -74
> 
> That's MMC_CMD_SWITCH that's failing.
> 
> Just a guess, try swapping the order of
> 
>   mci_of_parse(&arasan_sdhci->mci);
>   sdhci_setup_host(&arasan_sdhci->sdhci);
> 
> in drivers/mci/arasan-sdhci.c and see if it makes a difference.
> 
> > barebox-environment chosen:environment-sd.of: probe failed: No such file or directory
> > environment load /dev/env0: No such file or directory
> 
> This is expected when the MMC probe had failed.
> 
> Cheers,
> Ahmad
> 
> > Maybe you have to create the partition.
> >
> > Hit any to stop autoboot:    1
> > barebox@Zynq Z-Turn MYIR Board V5:/
> >
> >
> >
> > Regards,
> > Michał Kruszewski
> >
> >
> > Sent with Proton Mail secure email.
> >
> > On Monday, April 13th, 2026 at 3:58 PM, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> >> Hello,
> >>
> >> On 4/13/26 9:31 AM, Michał Kruszewski wrote:
> >>>> It isn't if the FSBL isn't able to load position-independent executables.
> >>>
> >>> I am pretty sure bootgen uses the PhysAddr (or VirtAddr) to determine where to load the partition.
> >>> The address from at 0x0 is OCM, not DDR.
> >>> I have never seen people loading the second or third stage bootloaders to OCM.
> >>>
> >>> I tried barebox-myir-zturn.elf.exe, no change.
> >>>
> >>> Partition Number: 12884901890
> >>> Header Dump
> >>> Image Word Len: 0x0000C06B
> >>> Data Word Len: 0x0000C06B
> >>> Partition Word Len:0x0000C06B
> >>> Load Addr: 0x00000000
> >>> Exec Addr: 0x04000000
> >>> Partition Start: 0x000FDE20
> >>> Partition Attr: 0x00000010
> >>> Partition Checksum Offset: 0x00000000
> >>> Section Count: 0x00000001
> >>> Checksum: 0xFBEDDE2D
> >>> Application
> >>> Handoff Address: 0x00000000
> >>> In FsblHookBeforeHandoff function
> >>> No Execution Address JTAG handoff
> >>>
> >>> I think we need position code with PhysAddr and VirtAddr other than 0x0.
> >>> Or maybe position independent code, but with another address.
> >>
> >> That it was saying 0 was not intended. I pushed my branch again, it
> >> looks like this now:
> >>
> >> Program Headers:
> >>   Type        Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> >>   LOAD        0x001000 0x04000000 0x04000000 0x2faf0 0x2faf0 RW  0x1000
> >>   GNU_STACK   0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
> >>
> >> Let me know how it goes.
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>
> >>>
> >>> Regards,
> >>> Michał Kruszewski
> >>>
> >>>
> >>> Sent with Proton Mail secure email.
> >>>
> >>> On Sunday, April 12th, 2026 at 8:50 PM, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>>
> >>>> Hello Michał,
> >>>>
> >>>> On 4/12/26 16:42, Michał Kruszewski wrote:
> >>>>>
> >>>>> It does not work.
> >>>>> No matter whether I change ENTRY_FUNCTION_WITHSTACK() to 0x200000.
> >>>>>
> >>>>> I see that both VirtAddr and PhysAddr of the executable section in your case are set to 0.
> >>>>> I am not sure this is safe.
> >>>>> u-boot uses 0x04000000.
> >>>>
> >>>> It isn't if the FSBL isn't able to load position-independent executables.
> >>>>
> >>>>> I enabled Zynq FSBL logging.
> >>>>> In the case of barebox, the FSBL for some reason thinks there is no section to hand off to.
> >>>>>
> >>>>> This is the log for u-boot:
> >>>>
> >>>> Thanks, this is useful. Could you pull my rft-myir-zturn branch again,
> >>>> build it and test barebox-myir-zturn.elf.exe?
> >>>>
> >>>> Same procedure as before with each of the two stack addresses.
> >>>>
> >>>> If it doesn't work, I am interested to see the FSBL log output.
> >>>>
> >>>> Thanks,
> >>>> Ahmad
> >>>>
> >>>>>
> >>>>> FPGA Done !
> >>>>> In FsblHookAfterBitstreamDload function
> >>>>> Partition Number: 12884901890
> >>>>> Header Dump
> >>>>> Image Word Len: 0x000423FC
> >>>>> Data Word Len: 0x000423FC
> >>>>> Partition Word Len:0x000423FC
> >>>>> Load Addr: 0x04000000
> >>>>> Exec Addr: 0x04000000
> >>>>> Partition Start: 0x000FDE20
> >>>>> Partition Attr: 0x00000010
> >>>>> Partition Checksum Offset: 0x00000000
> >>>>> Section Count: 0x00000001
> >>>>> Checksum: 0xF7E3B37A
> >>>>> Application
> >>>>> Handoff Address: 0x04000000
> >>>>> In FsblHookBeforeHandoff function
> >>>>> SUCCESSFUL_HANDOFF
> >>>>> FSBL Status = 0xE0001000
> >>>>> U-Boot 2026.01-00518-gc05dba22f1f2-dirty (Feb 06 2026 - 13:18:15 +0100)
> >>>>>
> >>>>> and this is the log for barebox:
> >>>>>
> >>>>> FPGA Done !
> >>>>> In FsblHookAfterBitstreamDload function
> >>>>> Partition Number: 17179869186
> >>>>> Header Dump
> >>>>> Image Word Len: 0x000017EA
> >>>>> Data Word Len: 0x000017EA
> >>>>> Partition Word Len:0x000017EA
> >>>>> Load Addr: 0x00000000
> >>>>> Exec Addr: 0x00000000
> >>>>> Partition Start: 0x000FDE20
> >>>>> Partition Attr: 0x00000010
> >>>>> Partition Checksum Offset: 0x00000000
> >>>>> Section Count: 0x00000002
> >>>>> Checksum: 0xFFEFD7AF
> >>>>> Application
> >>>>> Handoff Address: 0x00000000
> >>>>> In FsblHookBeforeHandoff function
> >>>>> No Execution Address JTAG handoff
> >>>>>
> >>>>>
> >>>>> Best regards,
> >>>>> Michał Kruszewski
> >>>>>
> >>>>>
> >>>>> Sent with Proton Mail secure email.
> >>>>>
> >>>>> On Friday, April 10th, 2026 at 1:11 PM, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 4/8/26 7:43 AM, Michał Kruszewski wrote:
> >>>>>>>> But first can you verify that using images/start_avnet_zedboard.pbl with
> >>>>>>>> DT replaced as described in a previous message of mine successfully
> >>>>>>>> boots to shell?
> >>>>>>>
> >>>>>>> No, it does not boot to shell.
> >>>>>>> I have replaced:
> >>>>>>>
> >>>>>>> -#include <arm/xilinx/zynq-zed.dts>
> >>>>>>> +/include/ "../../../dts/src/arm/xilinx/zynq-zturn-v5.dts"
> >>>>>>>
> >>>>>>> in arch/arm/dts/zynq-zed.dts file.
> >>>>>>>
> >>>>>>> Then I used images/start_avnet_zedboard.pbl for boot.bin generation.
> >>>>>>> I see no barebox output in terminal.
> >>>>>>
> >>>>>> Please give this patch a try:
> >>>>>>
> >>>>>> https://github.com/a3f/barebox/commit/1dc352b5de6e03429010a23ce6804a3e4c7109e1
> >>>>>>
> >>>>>> The image will be called start_myir_zturn.elf.
> >>>>>>
> >>>>>> If this is also completely silent, try changing the zero in
> >>>>>> ENTRY_FUNCTION_WITHSTACK() to 0x200000.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ahmad
> >>>>>>
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Michał Kruszewski
> >>>>>>>
> >>>>>>>
> >>>>>>> Sent with Proton Mail secure email.
> >>>>>>>
> >>>>>>> On Tuesday, April 7th, 2026 at 3:22 PM, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>>>>>>
> >>>>>>>> Hello Michał,
> >>>>>>>>
> >>>>>>>> I hope you had a please Easter.
> >>>>>>>>
> >>>>>>>> On 3/27/26 11:37 AM, Michał Kruszewski wrote:
> >>>>>>>>> Of course, due to the hurry, I made a mistake in my previous message.
> >>>>>>>>> The program for the boot.bin generation is called bootgen not bootbin.
> >>>>>>>>>
> >>>>>>>>> You can find AMD bootgen user guide here:
> >>>>>>>>>   https://docs.amd.com/r/en-US/ug1283-bootgen-user-guide/Introduction.
> >>>>>>>>>
> >>>>>>>>> The ELF file provided to the bootgen can have multiple loadable sections, each of which forms a partition in the boot image.
> >>>>>>>>> The AMD/Xilinx FSBL will load and hand-off execution to the next executable partition found in the boot.bin file.
> >>>>>>>>> The u-boot.elf file has one LOAD section:
> >>>>>>>>>   [user@host] readelf -l u-boot.elf
> >>>>>>>>>   Elf file type is EXEC (Executable file)
> >>>>>>>>>   Entry point 0x4000000
> >>>>>>>>>   There is 1 program header, starting at offset 52
> >>>>>>>>>   Program Headers:
> >>>>>>>>>     Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> >>>>>>>>>     LOAD           0x010000 0x04000000 0x04000000 0x108ff0 0x108ff0 RW  0x10000
> >>>>>>>>>    Section to Segment mapping:
> >>>>>>>>>     Segment Sections...
> >>>>>>>>>      00     .data
> >>>>>>>>> The readelf for barebox shows 3 LOAD sections and 1 DYNAMIC section.
> >>>>>>>>
> >>>>>>>> This is true for the "barebox" binary, but if you check the
> >>>>>>>> images/start_avnet_zedboard.pbl, the situation is different. It does
> >>>>>>>> have multiple sections too, but the initial LOAD section contains
> >>>>>>>> everything placed linearly.
> >>>>>>>>
> >>>>>>>>> The second difference is that Elf file type for u-boot is EXEC (Executable file), for barebox DYN (Position-Independent Executable file).
> >>>>>>>>
> >>>>>>>> I suspect that the ELF type doesn't actually matter, but we can
> >>>>>>>> easily change it should it really be needed.
> >>>>>>>>
> >>>>>>>>> The bootgen user guide has the table 49 with the following note for the ELF file format:
> >>>>>>>>> "Symbols and headers removed."
> >>>>>>>>> However, it is not clear whether bootgen automatically removes symbosls and headers, or whether it expects the elf file without symbols and headers.
> >>>>>>>>
> >>>>>>>> This is easily done with the strip command.
> >>>>>>>>
> >>>>>>>>> Now, I would like to describe a few ideas and potential problems.
> >>>>>>>>> I am by far not bootloaders expert.
> >>>>>>>>> However, I had to boot and debug booting on a few custom and off-the-shelf boards with AMD/Xilinx SoCs and MPSoCs.
> >>>>>>>>> All the things I write below are related to booting ADM/Xilinx chips only.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> There are 2 alternative paths you may chose when trying to boot AMD/Xilinx SoCs.
> >>>>>>>>>
> >>>>>>>>> Path 1: The no-FSBL path
> >>>>>>>>> This is the path currently supported by barebox.
> >>>>>>>>> You do not want to utilize the AMD/Xilinx automatically generated FSBL.
> >>>>>>>>> In such a case, you have to define a board, and provide C code for the low-level board initialization.
> >>>>>>>>> The barebox PBL does the FSBL job in this case.
> >>>>>>>>> I think this path is fine for hobby projects and off-the-shelf boards when you want to quickly get things running.
> >>>>>>>>> However, I am not a fan of this path in professional projects because of the following reasons:
> >>>>>>>>>   a) The FSBL code is automatically generated, it may include some workarounds or fixes for hardware bugs.
> >>>>>>>>>      The copied low-level initialization C code may potentially miss them.
> >>>>>>>>
> >>>>>>>> If you don't update your FPGA toolchain, you may miss these issues also
> >>>>>>>> and we have been burnt a lot in the past with FPGA toolchains adding
> >>>>>>>> subtle breakage all around.
> >>>>>>>>
> >>>>>>>>>   b) Forget about getting official support from AMD/Xilinx if you mention you don't use the official FSBL for boot.
> >>>>>>>>
> >>>>>>>> Yes, if you need FAE support, they may require you to reproduce using
> >>>>>>>> their bootloader.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Path 2: The FSBL path
> >>>>>>>>> For me, this is the way to go in professional projects.
> >>>>>>>>> Barebox currently does not support this path.
> >>>>>>>>> In this case, you do not want to be forced to define a board.
> >>>>>>>>> This is simply pointless, the FSBL is responsible for initializing the low-level stuff.
> >>>>>>>>> All you need to boot Linux when FSBL stops execution is some SSBL and device tree.
> >>>>>>>>
> >>>>>>>> I see your point.
> >>>>>>>>
> >>>>>>>>> Now, what a support for path 2 in the barebox could look like.
> >>>>>>>>> We could use the concept of the virtual board.
> >>>>>>>>> The virtual board is a board that:
> >>>>>>>>>   - is assumed to already be low-level initialized when barebox starts running,
> >>>>>>>>>   - can accept arbitrary device tree,
> >>>>>>>>>   - should not be bound to any specific device tree by default.
> >>>>>>>>> The boilerplate related to the board definition should not exist for the virtual board.
> >>>>>>>>
> >>>>>>>> Well, the boilerplate will exist, but you wouldn't need to modify it.
> >>>>>>>> The generic board would be just an extra image produced in the barebox
> >>>>>>>> build.
> >>>>>>>>
> >>>>>>>>> What the user experience would look like:
> >>>>>>>>>   1. make zynq_virt_defconfig,
> >>>>>>>>>   2. open menuconfig,
> >>>>>>>>>   3. find and set config containing path for the device tree file (can be out of tree),
> >>>>>>>>
> >>>>>>>> Linux regularly breaks forward and to a lesser degree backwards
> >>>>>>>> compatibility for device tree. We can make it possible to reference a
> >>>>>>>> device tree in dts/, but I don't want to make it possible to point an
> >>>>>>>> arbitrary device tree where it's unclear if the binding are compatible
> >>>>>>>> with barebox.
> >>>>>>>>
> >>>>>>>> If someone wants to inject a device tree, they should copy its source
> >>>>>>>> into barebox.
> >>>>>>>>
> >>>>>>>>>   4. make,
> >>>>>>>>>   5. copy the required elf and/or bin files to your project.
> >>>>>>>>
> >>>>>>>> This is doable, but I'd prefer a new images/barebox-zynq-ssbl.img that's
> >>>>>>>> just an extra image generated from the normal zynq_virt_defconfig.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The u-boot has a similar concept of virt defconfigs, for example:
> >>>>>>>>> xilinx_versal_virt_defconfig
> >>>>>>>>> xilinx_zynqmp_virt_defconfig
> >>>>>>>>> xilinx_zynq_virt_defconfig
> >>>>>>>>
> >>>>>>>> I see. I haven't worked myself with the Zynq, so I was not aware of how
> >>>>>>>> it's handled in U-Boot.
> >>>>>>>>
> >>>>>>>>> What potential problems do I see?
> >>>>>>>>> The bootgen handles elf files with multiple loadable sections by putting each section into a separate partition.
> >>>>>>>>> The FSBL simply loads and hands-off to the next executable partition from the boot.bin.
> >>>>>>>>> I do not know how barebox works and prepares images.
> >>>>>>>>
> >>>>>>>> That's not a problem. As mentioned in previous mails, barebox/vmbarebox
> >>>>>>>> is the wrong image to use however you look at it. You always need an
> >>>>>>>> image with PBL, even if the PBL only does decompression and passing
> >>>>>>>> along the DT without any lowlevel HW initialization at all.
> >>>>>>>>
> >>>>>>>>> However I can see 3 potential scenarios.
> >>>>>>>>
> >>>>>>>> [snip]
> >>>>>>>>
> >>>>>>>>> Unfortunately, I do not have enough skills to apply required changes to barebox to test these ideas on my own.
> >>>>>>>>> However, I would be more than happy to test your changes.
> >>>>>>>>
> >>>>>>>> Thanks and I would like to take you up on the offer.
> >>>>>>>>
> >>>>>>>> But first can you verify that using images/start_avnet_zedboard.pbl with
> >>>>>>>> DT replaced as described in a previous message of mine successfully
> >>>>>>>> boots to shell?
> >>>>>>>>
> >>>>>>>> Once we know that the ELF generated is ok in principle I can look into
> >>>>>>>> implementing a virt/ssbl image
> >>>>>>>>
> >>>>>>>>> Let me know what you think.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Ahmad
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Michał Kruszewski
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Pengutronix e.K.                  |                             |
> >>>>>>>> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> >>>>>>>> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> >>>>>>>> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Pengutronix e.K.                  |                             |
> >>>>>> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> >>>>>> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> >>>>>> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Pengutronix e.K.                           |                             |
> >>>> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> >>>> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> >>>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> >>>>
> >>>>
> >>>
> >>
> >> --
> >> Pengutronix e.K.                  |                             |
> >> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> >> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> >> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
> >>
> >>
> >>
> >
> 
> --
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
> 
> 
>