[PATCH v2] Porting barebox to a new SoC
Lior Weintraub
liorw at pliops.com
Sun Jun 18 23:40:24 PDT 2023
Hello Ahmad,
Thanks again for your great tips.
Using the addpart command seems to work and give same results as the pre-partitioned flash node on the DT.
When I deleted the whole flash node and extended the memory node to include all 768MB the following commands worked on barebox:
addpart /dev/ram0 "512M at 0(dram512),0xB30000 at 0x20000000(kernel),0x8000 at 0x20FF8000(oftree),0x800000 at 0x21000000(rootfs),-"
After that, checking the devinfo gave:
`-- mem0
`-- 0x00000000-0x2fffffff ( 768 MiB): /dev/ram0
`-- 0x00000000-0x1fffffff ( 512 MiB): /dev/ram0.dram512
`-- 0x20000000-0x20b2ffff ( 11.2 MiB): /dev/ram0.kernel
`-- 0x20ff8000-0x20ffffff ( 32 KiB): /dev/ram0.oftree
`-- 0x21000000-0x217fffff ( 8 MiB): /dev/ram0.rootfs
`-- 0x21800000-0x2fffffff ( 232 MiB): /dev/
Now running the bootm:
bootm -o /dev/ram0.oftree -r /dev/ram0.rootfs -a 0 /dev/ram0.kernel
The Linux kernel starts running but has issues (still probably missing parts on my QEMU machine).
Notice that I had to set the "kernel" partition to size 0xB30000 because otherwise it gave me the same error of "conflict":
__request_region ok: 0x00000000:0x00ffffff flags=0x200
__request_region ok: 0x00000000:0x00ff7fff flags=0x200
__request_region: 0x00b30000:0x00b4ffff (image) conflicts with 0x00000000:0x00ff7fff (image)
unable to request SDRAM 0x00b30000-0x00b4ffff
handler failed with: Out of memory
Could it be somehow related to the way I build the kernel?
Cheers,
Lior.
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum at pengutronix.de>
> Sent: Friday, June 16, 2023 7:21 PM
> To: Lior Weintraub <liorw at pliops.com>; Ahmad Fatoum <ahmad at a3f.at>;
> barebox at lists.infradead.org
> Subject: Re: [PATCH v2] Porting barebox to a new SoC
>
> CAUTION: External Sender
>
> Hello Lior,
>
> On 14.06.23 08:42, Lior Weintraub wrote:
> > Hi Ahmad,
> >
> > Looks like I found the issue :-)
> >
> > When I declared the flash at 0 node I used about 16MB for the kernel
> partition even though currently my kernel image is around 11MB:
> > flash at 0 {
> > compatible = "mtd-rom";
> > probe-type = "map_rom";
> > reg = <0x0 0x20000000 0x0 0x10000000>; /* Offset 512MB, size 256MB
> */
> > bank-width = <4>;
> > device-width = <1>;
> >
> > #address-cells = <1>;
> > #size-cells = <1>;
> > kernel at 0 { /* 16MB (minus 32KB) */
> > label = "kernel";
> > //reg = <0x0 0x00FF8000>; // This line caused the error
> > reg = <0x0 0x00b30000>;
> > };
> > oftree at 00FF8000 { /* 32KB for DTB image */
> > label = "oftree";
> > reg = <0x00FF8000 0x00008000>;
> > };
> > rootfs at 1000000 { /* Offset 512MB+16MB with size 8MB */
> > label = "rootfs";
> > reg = <0x01000000 0x00800000>;
> > };
> > };
> >
> > From the error message I saw that barebox tried to place the rootfs on
> address 0xb30000 and that conflicted with the kernel:
> > mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> > __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> > mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> > __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
> 0x00000000:0x00ff7fff (image)
>
> This error message still doesn't make sense to me. No idea why this conflicts.
> I see now though that I made this more complicated that it needs be. Please
> scratch all that, remove the mtd-rom and revert the /memory node to
> encompass
> all memory. Then you can at runtime, just create the partitions with the
> addpart
> command (see help addpart for info). Then you can boot normally.
>
> >
> > So I changed the kernel at 0 node and used size 0x00b30000 and now kernel
> starts running.
> > The kernel is producing all kinds of errors but at least it's a start :-)
> > The errors are now related to pieces of HW that we didn't implement on
> QEMU so it is understandable.
> >
> > How can we control where the rootfs is copied to?
>
> Normally, global.bootm.initrd.loadaddr, but you shouldn't need to do
> that. Try it with addpart and let me know.
>
> Cheers,
> Ahmad
>
> >
> > Thanks again for your kind advise and patience.
> > Cheers,
> > Lior.
> >
> >> -----Original Message-----
> >> From: Lior Weintraub
> >> Sent: Tuesday, June 13, 2023 4:28 PM
> >> To: Ahmad Fatoum <a.fatoum at pengutronix.de>; Ahmad Fatoum
> >> <ahmad at a3f.at>; barebox at lists.infradead.org
> >> Subject: RE: [PATCH v2] Porting barebox to a new SoC
> >>
> >> Hi Ahmad,
> >>
> >> I also thought that load address was suspicious (0x8000000) but then I
> saw
> >> the following comment on nxp_imx8mq_evk_start:
> >> /*
> >> * On completion the TF-A will jump to
> >> MX8MQ_ATF_BL33_BASE_ADDR
> >> * in EL2. Copy the image there, but replace the PBL part of
> >> * that image with ourselves. On a high assurance boot only
> >> the
> >> * currently running code is validated and contains the
> >> checksum
> >> * for the piggy data, so we need to ensure that we are
> >> running
> >> * the same code in DRAM.
> >> */
> >> Our code was based on this function and as a result it copies the barebox
> >> image into address 0x8000000 (which is our settings of
> >> ATF_BL33_BASE_ADDR).
> >> The fact that Linux image is also copied there seemed reasonable (I might be
> >> wrong here) because once loading is done and we jump to Linux there is no
> >> need for barebox code anymore.
> >>
> >> In any case, at that time when I thought it was wrong I also tried to run the
> >> bootm command with "-a 0" but I got exactly the same error:
> >> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs -a 0
> >> /dev/mtdrom0.kernel
> >> getopt: optindex: 1 nonopts: 0 optind: 1
> >> getopt: optindex: 1 nonopts: 0 optind: 3
> >> getopt: optindex: 1 nonopts: 0 optind: 5
> >> getopt: optindex: 1 nonopts: 0 optind: 7
> >> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
> >>
> >> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> >> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
> >> MZ at .?.#.........
> >> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
> >> ................
> >> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >> ................
> >> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
> >> ........ARMd at ...
> >> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
> >> PE..d...........
> >> booti: Kernel to be loaded to 0+b30000
> >> __request_region ok: 0x00000000:0x0001ffff flags=0x200
> >> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> >> __request_region ok: 0x00000000:0x0003ffff flags=0x200
> >> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> >> __request_region ok: 0x00000000:0x0005ffff flags=0x200
> >> .
> >> .
> >> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> >> __request_region ok: 0x00000000:0x00ff7fff flags=0x200
> >> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> >> __request_region: 0x00b30000:0x00b4ffff (image) conflicts with
> >> 0x00000000:0x00ff7fff (image)
> >> unable to request SDRAM 0x00b30000-0x00b4ffff
> >> handler failed with: Out of memory
> >>
> >>
> >> The iomem before:
> >> barebox:/ iomem
> >> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
> iomem
> >> 0x0000000000000000 - 0x000000001fffffff (size
> 0x0000000020000000)
> >> ram0
> >> 0x00000000079fef00 - 0x0000000007dfeeff (size
> 0x0000000000400000)
> >> malloc space
> >> 0x0000000007dfef00 - 0x0000000007dfffd1 (size
> 0x00000000000010d2)
> >> board data
> >> 0x0000000007e00000 - 0x0000000007e3d95f (size
> >> 0x000000000003d960) barebox
> >> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
> >> 0x0000000000013258) barebox data
> >> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
> >> 0x0000000000002f88) bss
> >> 0x0000000007ff0000 - 0x0000000007ff7fff (size
> 0x0000000000008000)
> >> stack
> >> 0x0000000020000000 - 0x000000002fffffff (size
> 0x0000000010000000)
> >> 20000000.flash at 0.of
> >> 0x000000d000307000 - 0x000000d000307fff (size
> >> 0x0000000000001000) amba
> >>
> >> After:
> >> barebox:/ iomem
> >> 0x0000000000000000 - 0xffffffffffffffff (size 0x0000000000000000)
> iomem
> >> 0x0000000000000000 - 0x000000001fffffff (size
> 0x0000000020000000)
> >> ram0
> >> 0x00000000079fef00 - 0x0000000007dfeeff (size
> 0x0000000000400000)
> >> malloc space
> >> 0x0000000007dfef00 - 0x0000000007dfffd1 (size
> 0x00000000000010d2)
> >> board data
> >> 0x0000000007e00000 - 0x0000000007e3d95f (size
> >> 0x000000000003d960) barebox
> >> 0x0000000007e3d960 - 0x0000000007e50bb7 (size
> >> 0x0000000000013258) barebox data
> >> 0x0000000007e50bb8 - 0x0000000007e53b3f (size
> >> 0x0000000000002f88) bss
> >> 0x0000000007ff0000 - 0x0000000007ff7fff (size
> 0x0000000000008000)
> >> stack
> >> 0x0000000020000000 - 0x000000002fffffff (size
> 0x0000000010000000)
> >> 20000000.flash at 0.of
> >> 0x000000d000307000 - 0x000000d000307fff (size
> >> 0x0000000000001000) amba
> >>
> >> I did not set global.bootm.image.loadaddr
> >> Speaking of env, the last few lines on the barebox terminal are:
> >> initcall-> load_environment+0x0/0x4c
> >> loading defaultenv
> >> environment load /dev/env0: No such file or directory
> >> Maybe you have to create the partition.
> >> initcalls done
> >>
> >> When I run "printenv" I am getting:
> >> barebox:/ printenv
> >> locals:
> >> globals:
> >> bootsource=unknown
> >> bootsource_instance=unknown
> >> PATH=/env/bin
> >>
> >> Hope this info can help.
> >> Cheers,
> >> Lior.
> >>
> >>
> >>> -----Original Message-----
> >>> From: Ahmad Fatoum <a.fatoum at pengutronix.de>
> >>> Sent: Tuesday, June 13, 2023 3:51 PM
> >>> To: Lior Weintraub <liorw at pliops.com>; Ahmad Fatoum
> <ahmad at a3f.at>;
> >>> barebox at lists.infradead.org
> >>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>
> >>> CAUTION: External Sender
> >>>
> >>> On 13.06.23 14:39, Lior Weintraub wrote:
> >>>> Hi Ahmad,
> >>>>
> >>>> As usual, your comments are spot on :-)
> >>>>
> >>>> After fixing the DT, devinfo command shows correct flash node:
> >>>> `-- 20000000.flash at 0.of
> >>>> `-- mtdrom0
> >>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/mtdrom0
> >>>> `-- mtdrom0.kernel
> >>>> `-- 0x00000000-0x00ff7fff ( 16 MiB): /dev/mtdrom0.kernel
> >>>> `-- mtdrom0.oftree
> >>>> `-- 0x00000000-0x00007fff ( 32 KiB): /dev/mtdrom0.oftree
> >>>> `-- mtdrom0.rootfs
> >>>> `-- 0x00000000-0x007fffff ( 8 MiB): /dev/mtdrom0.rootfs
> >>>>
> >>>> As can be seen above, we chose to map this "flash" node on DRAM
> >> address
> >>> 0x20000000 (offset 512MB).
> >>>> The BL1 code correctly copy the 3 artifacts into those location (verified
> the
> >>> content via "md -l -s /dev/mtdrom0.kernel").
> >>>> Running "drvinfo" shows:
> >>>> mtdram
> >>>> 20000000.flash at 0.of
> >>>>
> >>>> Now when I try to run "bootm -o /dev/mtdrom0.oftree -r
> >>> /dev/mtdrom0.rootfs /dev/mtdrom0.kernel" I am getting this error:
> >>>>
> >>>> barebox:/ bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.rootfs
> >>> /dev/mtdrom0.kernel
> >>>> getopt: optindex: 1 nonopts: 0 optind: 1
> >>>> getopt: optindex: 1 nonopts: 0 optind: 3
> >>>> getopt: optindex: 1 nonopts: 0 optind: 5
> >>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00001000
> >>>>
> >>>> Loading ARM aarch64 Linux image '/dev/mtdrom0.kernel'
> >>>> header 00000000: 4d 5a 40 fa 3f 1a 23 14 00 00 00 00 00 00 00 00
> >>> MZ at .?.#.........
> >>>> header 00000010: 00 00 b3 00 00 00 00 00 0a 00 00 00 00 00 00 00
> >>> ................
> >>>> header 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>> ................
> >>>> header 00000030: 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00
> >>> ........ARMd at ...
> >>>> header 00000040: 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00
> >>> PE..d...........
> >>>> booti: Kernel to be loaded to 8000000+b30000
> >>>
> >>> Kernel image is relocatable and ARM64 header in hexdump says that
> >>> load offset is zero. Yet, barebox wants to load your image to
> >>> 8000000, which is already reserved.
> >>>
> >>> What's the output of the iomem command before and after the failed
> >>> boot attempt?
> >>>
> >>>> __request_region ok: 0x08000000:0x0801ffff flags=0x200
> >>>> mtdrom0.kernel: read ofs: 0x00000000 count: 0x00020000
> >>>> __request_region ok: 0x08000000:0x0803ffff flags=0x200
> >>>> mtdrom0.kernel: read ofs: 0x00020000 count: 0x00020000
> >>>> .
> >>>> .
> >>>> mtdrom0.kernel: read ofs: 0x00fe0000 count: 0x00018000
> >>>> __request_region ok: 0x08000000:0x08ff7fff flags=0x200
> >>>> mtdrom0.rootfs: read ofs: 0x00000000 count: 0x00000800
> >>>> __request_region: 0x08b30000:0x08b4ffff (image) conflicts with
> >>> 0x08000000:0x08ff7fff (image)
> >>>> unable to request SDRAM 0x08b30000-0x08b4ffff
> >>>> handler failed with: Out of memory
> >>>
> >>> Just to be sure: You don't set global.bootm.image.loadaddr, right?
> >>>
> >>> Cheers,
> >>> Ahmad
> >>>
> >>>>
> >>>> Appreciate your advice,
> >>>> Cheers,
> >>>> Lior.
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Ahmad Fatoum <a.fatoum at pengutronix.de>
> >>>>> Sent: Monday, June 12, 2023 6:08 PM
> >>>>> To: Lior Weintraub <liorw at pliops.com>; Ahmad Fatoum
> >> <ahmad at a3f.at>;
> >>>>> barebox at lists.infradead.org
> >>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>
> >>>>> CAUTION: External Sender
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On 12.06.23 16:59, Lior Weintraub wrote:
> >>>>>> Hello Ahmad,
> >>>>>>
> >>>>>> Just for simple simulations we make the ROM size 192MB so it can
> >> include
> >>> all
> >>>>> needed artifacts.
> >>>>>
> >>>>> I am not convinced that this is much of a simplification over having
> >>>>> your Qemu machine provide cfi-flash.
> >>>>>
> >>>>>> When we get this simple system to work we will move the relevant
> parts
> >>> to
> >>>>> BL2.
> >>>>>
> >>>>> Ok.
> >>>>>
> >>>>>> DRAM is also simulated now as SRAM so we are not worried about
> >>>>> initializations.
> >>>>>>
> >>>>>> So if I understand correctly, we can decide that address 0x10000000
> will
> >>> be
> >>>>> reserved for "flash" and add the following node:
> >>>>>> flash at 0 {
> >>>>>
> >>>>> flash at 10000000, but that's just for informational purposes.
> >>>>>
> >>>>>> compatible = "mtd-rom";
> >>>>>> probe-type = "map_rom";
> >>>>>> reg = <0x10000000 0x10000000>;
> >>>>>> bank-width = <4>;
> >>>>>> device-width = <1>;
> >>>>>>
> >>>>>> #address-cells = <1>;
> >>>>>> #size-cells = <1>;
> >>>>>> kernel at 0 {
> >>>>>> label = "kernel";
> >>>>>> reg = <0x0 0x01000000>;
> >>>>>> };
> >>>>>> rootfs at 1000000 {
> >>>>>> label = "rootfs";
> >>>>>> reg = <0x01000000 0x00800000>;
> >>>>>> };
> >>>>>> };
> >>>>>>
> >>>>>> When I use this node on our DT I see the following devinfo:
> >>>>>> barebox:/ devinfo
> >>>>>> `-- global
> >>>>>> `-- nv
> >>>>>> `-- platform
> >>>>>> `-- machine
> >>>>>> `-- psci.of
> >>>>>> `-- 1000000010000000.flash at 0.of
> >>>>>
> >>>>> As you can see the address is wrong. That's because you have
> >>>>> #address-cells = <2>;
> >>>>> #size-cells = <2>;
> >>>>>
> >>>>> Yet, you wrote reg as if it was <1>/<1>. Change it to
> >>>>>
> >>>>> reg = <0x0 0x10000000 0x0 0x10000000>;
> >>>>>
> >>>>> Remember all device tree integers are 32-bit big endian.
> >>>>>
> >>>>>> `-- soc.of
> >>>>>> `-- c000000000.sram at c000000000.of
> >>>>>> `-- soc:pmu.of
> >>>>>> `-- soc:timer.of
> >>>>>> `-- e000000000.interrupt-controller at E000000000.of
> >>>>>> `-- mem0
> >>>>>> `-- 0x00000000-0x0fffffff ( 256 MiB): /dev/ram0
> >>>>>> `-- mem1
> >>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/mem
> >>>>>> `-- amba
> >>>>>> `-- d000307000.serial at d000307000.of
> >>>>>> `-- cs0
> >>>>>> `-- 0x00000000-0xffffffffffffffff ( 0 Bytes): /dev/cs0
> >>>>>> `-- spi
> >>>>>> `-- fs
> >>>>>> `-- ramfs0
> >>>>>> `-- devfs0
> >>>>>> `-- pstore0
> >>>>>>
> >>>>>> Not sure how to proceed from here...
> >>>>>
> >>>>> Type drvinfo command to see what drivers are bound to what devices.
> >>>>> If you see no driver bound to your flash device, then maybe you need
> >>>>> to enable the correct driver, that would be CONFIG_MTD_MTDRAM
> >> (which
> >>>>> handles both read-only and read-write memory mapped MTD).
> >>>>>
> >>>>> Cheers,
> >>>>> Ahmad
> >>>>>
> >>>>>> Cheers,
> >>>>>> Lior.
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Ahmad Fatoum <a.fatoum at pengutronix.de>
> >>>>>>> Sent: Monday, June 12, 2023 3:29 PM
> >>>>>>> To: Lior Weintraub <liorw at pliops.com>; Ahmad Fatoum
> >>> <ahmad at a3f.at>;
> >>>>>>> barebox at lists.infradead.org
> >>>>>>> Subject: Re: [PATCH v2] Porting barebox to a new SoC
> >>>>>>>
> >>>>>>> CAUTION: External Sender
> >>>>>>>
> >>>>>>> Hello Lior,
> >>>>>>>
> >>>>>>> On 12.06.23 11:27, Lior Weintraub wrote:
> >>>>>>>> Hi Ahmad,
> >>>>>>>>
> >>>>>>>> Regarding the rootfs and Linux run question:
> >>>>>>>> Our board doesn't include eMMC\SD card.
> >>>>>>>> We only have our NOR Flash to store the binaries and our BL1 code
> >> will
> >>>>> make
> >>>>>>> sure to copy those blobs into DRAM.
> >>>>>>>
> >>>>>>> How could BL1 copy artifacts in DRAM when BL2 first needs to set up
> >>>>> DRAM?
> >>>>>>>
> >>>>>>>> The use of QEMU needs to be as simple as possible so no hidden
> virtio
> >>>>>>> drivers and such because we would like to simulate the real HW flow.
> >>>>>>>
> >>>>>>> cfi-flash is just memory-mapped flash, which is the next simplest
> thing
> >>>>>>> after BL1 copies stuff into (limited-to-4M) on-chip SRAM.
> >>>>>>>
> >>>>>>>> Our DTS file now includes the GIC, timer and arm,psci-1.0.
> >>>>>>>> We have an initial build of Linux kernel Image (using buildroot) and a
> >>>>>>> rootfs.cpio.xz.
> >>>>>>>> I assume we can somehow reserve a portion of the DRAM to store
> >>> those
> >>>>>>> binaries and let barebox boot this Linux.
> >>>>>>>
> >>>>>>> You can make this work, but this is not how your actual system will
> >>>>>>> look like and trying to make this work is harder than it needs to be.
> >>>>>>>
> >>>>>>> Just add a cfi-flash that corresponds to the Linux/rootfs flash in
> >>>>>>> your actual system, then boot with bootm (type help bootm for info
> >>>>>>> on how to use it). You don't need to hardcode the load addresses,
> >>>>>>> barebox will determine them automatically.
> >>>>>>>
> >>>>>>>> Can you please advise how to make it work?
> >>>>>>>
> >>>>>>> For completion's sake, if you have 64M of RAM that's preloaded with
> >>>>>>> boot images:
> >>>>>>>
> >>>>>>> - Remove the 64M from the barebox /memory node. You can use a
> >>>>> different
> >>>>>>> DT for kernel, but if you have memory that barebox shouldn't
> >> override,
> >>>>>>> you need to tell it that.
> >>>>>>>
> >>>>>>> - Add a mtd-rom node that describes these 64M that you have. You
> >> can
> >>>>>>> add partitions for the region used for kernel and oftree
> >>>>>>>
> >>>>>>> - boot with bootm -o /dev/mtdrom0.oftree -r /dev/mtdrom0.initrd
> \
> >>>>>>> /dev/mtdrom0.kernel
> >>>>>>>
> >>>>>>> That's admittedly cumbersome, but necessary, so barebox knows
> what
> >>>>>>> memory
> >>>>>>> it may use for itself and what memory may be used for boot.
> >>>>>>>
> >>>>>>> Correct solution is to use cfi-flash or similar.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Ahmad
> >>>>>>> --
> >>>>>>> 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 |
More information about the barebox
mailing list