Barebox as first and second stage bootloader

Barebox as first and second stage bootloader

[gianluca]

Hello,
I was wondering if it possible to program Barebox (2020.01 or later) as 
first and second stage bootloader using the STM32 Programmer CLI tool.

I have the stm32mp157 evk-dk2 and I would like to have a working 
bootloader (running from SDRAM) via USB programming.

I do not know how the OTP Fuses are set for trusted boot or simple SPL.
I suppose they are TF-A for first stage bootloader and SPL for the 
second one.

The images built by Barebox (start_stm32mp157c_dk2.pblb[.stm32] and 
barebox-stm32mp157c-dk2.img) are suitable to be used as first stage 
bootloader running from internal SRAM and the .img as the second stage 
bootloader running from external SDRAM DDR???

Is there somebody who is working with STM32 Cube Programmer or DFU-Utils 
to obtain this boot??

Regards,
Gianluca Renzi
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[Ahmad Fatoum]

Hello,

On 2/26/20 12:57 PM, gianluca wrote:
> Hello,
> I was wondering if it possible to program Barebox (2020.01 or later) as first and second stage bootloader using the STM32 Programmer CLI tool.

FSBL is not supported at the moment. We use TF-A for that.

> I have the stm32mp157 evk-dk2 and I would like to have a working bootloader (running from SDRAM) via USB programming.
> 
> I do not know how the OTP Fuses are set for trusted boot or simple SPL.

Not sure how this relates to booting over USB? You shouldn't need any
fuses burnt (but you can probably burn some to stop fallback to DFU)

> I suppose they are TF-A for first stage bootloader and SPL for the second one.
> 
> The images built by Barebox (start_stm32mp157c_dk2.pblb[.stm32] and barebox-stm32mp157c-dk2.img) are suitable to be used as first stage bootloader running from internal SRAM and the .img as the second stage bootloader running from external SDRAM DDR???

No, they aren't. The current barebox implementation doesn't set up SDRAM and doesn't install
a secure monitor.

USB on the STM32MP1 is not yet complete. I posted some basic patches for the PHY, but we still
need host USB driver adjustments and a gadget driver for the DWC2. 

> Is there somebody who is working with STM32 Cube Programmer or DFU-Utils to obtain this boot??

I don't think so. We will want to have a solution for this eventually though. Probably some
wrapper script that uses DFU to talk to BootROM, then to vendor TF-A, then to barebox.

As I understood, that's what the STM32CubeProgrammer is doing and it's shipped with
a FSBL and SSBL already for bootstrapping a system. Have you tried using that to
flash barebox?

Cheers
Ahmad

> 
> Regards,
> Gianluca Renzi


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[gianluca]

On 02/26/2020 03:28 PM, Ahmad Fatoum wrote:
> Hello,
>
> On 2/26/20 12:57 PM, gianluca wrote:
>> Hello,
>> I was wondering if it possible to program Barebox (2020.01 or later) as first and second stage bootloader using the STM32 Programmer CLI tool.
>
> FSBL is not supported at the moment. We use TF-A for that.

OK, I suppose that.

>
>> I have the stm32mp157 evk-dk2 and I would like to have a working bootloader (running from SDRAM) via USB programming.
>>
>> I do not know how the OTP Fuses are set for trusted boot or simple SPL.
>
> Not sure how this relates to booting over USB? You shouldn't need any
> fuses burnt (but you can probably burn some to stop fallback to DFU)
>

I was trying to say that I didn't know how the fallback is managed DFU 
via serial, usb or whatever or it is managed by some OTP fuses.


>> I suppose they are TF-A for first stage bootloader and SPL for the second one.
>>
>> The images built by Barebox (start_stm32mp157c_dk2.pblb[.stm32] and barebox-stm32mp157c-dk2.img) are suitable to be used as first stage bootloader running from internal SRAM and the .img as the second stage bootloader running from external SDRAM DDR???
>
> No, they aren't. The current barebox implementation doesn't set up SDRAM and doesn't install
> a secure monitor.
>

So I need a simple implementation of a SDRAM setup, a secure monitor 
(TF-A). What do you are using at the moment?

My goals are to setup the SDRAM and the secure monitor via USB (with DFU 
STM32 Cube Programmer), then loading via usb (using the same STM32 Cube 
Programmer) the barebox-stm32mp157c-dk2.img in the external SDRAM addresses.

When barebox is done, it will download from a TFTP server the production 
stuff (SDRAM setup, secure monitor, 
barebox-stm32mp157c-dk2-PRODUCTION.img) and write those stuff into eMMC 
partitions.

> USB on the STM32MP1 is not yet complete. I posted some basic patches for the PHY, but we still
> need host USB driver adjustments and a gadget driver for the DWC2.
>

Using the above procedure the USB support is given only by ROM Code 
written by ST, not by Barebox.

>> Is there somebody who is working with STM32 Cube Programmer or DFU-Utils to obtain this boot??
>
> I don't think so. We will want to have a solution for this eventually though. Probably some
> wrapper script that uses DFU to talk to BootROM, then to vendor TF-A, then to barebox.
>

Having this wrapper script will be great. I will be grateful for the 
rest of my (working) life. ;-P


> As I understood, that's what the STM32CubeProgrammer is doing and it's shipped with
> a FSBL and SSBL already for bootstrapping a system. Have you tried using that to
> flash barebox?
>

Not really. I will check asap. In that way I could run barebox from a 
bootstrapped system using STM32CubeProgrammer FSBL and SSBL and hooking 
at the procedure as explained above.


Thanks a lot

Gianluca Renzi
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[Ahmad Fatoum]

Hello,

On 2/26/20 3:46 PM, gianluca wrote:
>> Not sure how this relates to booting over USB? You shouldn't need any
>> fuses burnt (but you can probably burn some to stop fallback to DFU)
>>
> 
> I was trying to say that I didn't know how the fallback is managed DFU via serial, usb or whatever or it is managed by some OTP fuses.

For development use, you can use the BOOT pins to configure DFU:
https://www.barebox.org/doc/latest/boards/stm32mp.html#boot-source-selection

>>> I suppose they are TF-A for first stage bootloader and SPL for the second one.
>>>
>>> The images built by Barebox (start_stm32mp157c_dk2.pblb[.stm32] and barebox-stm32mp157c-dk2.img) are suitable to be used as first stage bootloader running from internal SRAM and the .img as the second stage bootloader running from external SDRAM DDR???
>>
>> No, they aren't. The current barebox implementation doesn't set up SDRAM and doesn't install
>> a secure monitor.
>>
> 
> So I need a simple implementation of a SDRAM setup, a secure monitor (TF-A). What do you are using at the moment?

I am using TF-A v2.2. I thought about having a simple SDRAM setup in barebox
for flashing purposes, but got talked out of it, because that was code that's
untested unless you are doing a initial bring up and would be prone to bit rot.

Either go all the way, or don't.

> My goals are to setup the SDRAM and the secure monitor via USB (with DFU STM32 Cube Programmer), then loading via usb (using the same STM32 Cube Programmer) the barebox-stm32mp157c-dk2.img in the external SDRAM addresses.

I haven't tested this, but it should work. barebox doesn't need anything
special to be flashed by the DFU.

> When barebox is done, it will download from a TFTP server the production stuff (SDRAM setup, secure monitor, barebox-stm32mp157c-dk2-PRODUCTION.img) and write those stuff into eMMC partitions.

Doesn't the STM32 Cube Programmer already come with the necessary infrastructure
to partition the eMMC and write the images over USB?

>> USB on the STM32MP1 is not yet complete. I posted some basic patches for the PHY, but we still
>> need host USB driver adjustments and a gadget driver for the DWC2.
>>
> 
> Using the above procedure the USB support is given only by ROM Code written by ST, not by Barebox.

Not exactly, you communicate with the ROM Code to get TF-A into On-Chip RAM. Then you talk with
TF-A to get SSBL into SDRAM. Then you talk with SSBL to flash the rest. That's how the
STM32 Cube Programmer does it.

See below[0].

>>> Is there somebody who is working with STM32 Cube Programmer or DFU-Utils to obtain this boot??
>>
>> I don't think so. We will want to have a solution for this eventually though. Probably some
>> wrapper script that uses DFU to talk to BootROM, then to vendor TF-A, then to barebox.
>>
> 
> Having this wrapper script will be great. I will be grateful for the rest of my (working) life. ;-P

I'll take a look, once we have USB gadget support on the STM32.
Can't say for sure when this will be though. There are means[1] to
accelerate this however. ;-)

>> As I understood, that's what the STM32CubeProgrammer is doing and it's shipped with
>> a FSBL and SSBL already for bootstrapping a system. Have you tried using that to
>> flash barebox?
>>
> 
> Not really. I will check asap. In that way I could run barebox from a bootstrapped system using STM32CubeProgrammer FSBL and SSBL and hooking at the procedure as explained above.

AN5275[0] says that it's really a three stage process like I described.

If you manage to flash barebox with it, a Documentation patch about how to use the CLI version
of the tool would be very much appreciated.


[0]: https://www.st.com/content/ccc/resource/technical/document/application_note/group1/63/b3/70/f6/82/33/4e/5e/DM00589815/files/DM00589815.pdf/jcr:content/translations/en.DM00589815.pd
[1]: https://www.pengutronix.de/en/services/integration_testing.html

Cheers
Ahmad


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[gianluca]

On 02/26/2020 04:08 PM, Ahmad Fatoum wrote:
> Hello,
>
> On 2/26/20 3:46 PM, gianluca wrote:
>>> Not sure how this relates to booting over USB? You shouldn't need any
>>> fuses burnt (but you can probably burn some to stop fallback to DFU)
>>>
>>
>> I was trying to say that I didn't know how the fallback is managed DFU via serial, usb or whatever or it is managed by some OTP fuses.
>
> For development use, you can use the BOOT pins to configure DFU:
> https://www.barebox.org/doc/latest/boards/stm32mp.html#boot-source-selection
>

Ok I will check that.

>>
>> So I need a simple implementation of a SDRAM setup, a secure monitor (TF-A). What do you are using at the moment?
>
> I am using TF-A v2.2. I thought about having a simple SDRAM setup in barebox
> for flashing purposes, but got talked out of it, because that was code that's
> untested unless you are doing a initial bring up and would be prone to bit rot.
>
> Either go all the way, or don't.
>

I understand. If TF-A v2.2 is setting the SDRAM correctly and if it is 
installing a secure monitor, I can use that.

>> My goals are to setup the SDRAM and the secure monitor via USB (with DFU STM32 Cube Programmer), then loading via usb (using the same STM32 Cube Programmer) the barebox-stm32mp157c-dk2.img in the external SDRAM addresses.
>
> I haven't tested this, but it should work. barebox doesn't need anything
> special to be flashed by the DFU.
>

Not flashed into eMMC but stored into external SDRAM then let it run 
from there.

>> When barebox is done, it will download from a TFTP server the production stuff (SDRAM setup, secure monitor, barebox-stm32mp157c-dk2-PRODUCTION.img) and write those stuff into eMMC partitions.
>
> Doesn't the STM32 Cube Programmer already come with the necessary infrastructure
> to partition the eMMC and write the images over USB?
>

Using the latest en.stm32cubeprog_v2-3-0.zip of 172Mb I have found 
nothing. Maybe I am the dumbest person in the world, but a quick search 
I was not be able to find anything useful for that.

>> Using the above procedure the USB support is given only by ROM Code written by ST, not by Barebox.
>
> Not exactly, you communicate with the ROM Code to get TF-A into On-Chip RAM. Then you talk with
> TF-A to get SSBL into SDRAM. Then you talk with SSBL to flash the rest. That's how the
> STM32 Cube Programmer does it.
>

the TF-A talk to get SSBL into SDRAM could be done with STM32Cube 
Programmer? I.e. the TF-A know something about the USB stuff??

What about the ethernet support (with tftpboot) in Barebox for this 
STM32MP157 SoC???

> See below[0].
>

Error 404

>>>> Is there somebody who is working with STM32 Cube Programmer or DFU-Utils to obtain this boot??
>>>
>>> I don't think so. We will want to have a solution for this eventually though. Probably some
>>> wrapper script that uses DFU to talk to BootROM, then to vendor TF-A, then to barebox.
>>>
>>
>> Having this wrapper script will be great. I will be grateful for the rest of my (working) life. ;-P
>
> I'll take a look, once we have USB gadget support on the STM32.
> Can't say for sure when this will be though. There are means[1] to
> accelerate this however. ;-)
>

For sure, but from a production point of view, the usb must be connected 
as little as possible. It is better to download everything from Ethernet 
and/or from NFS rootfilesystem to me.

>>> As I understood, that's what the STM32CubeProgrammer is doing and it's shipped with
>>> a FSBL and SSBL already for bootstrapping a system. Have you tried using that to
>>> flash barebox?
>>>
>>
>> Not really. I will check asap. In that way I could run barebox from a bootstrapped system using STM32CubeProgrammer FSBL and SSBL and hooking at the procedure as explained above.
>
> AN5275[0] says that it's really a three stage process like I described.
>

Like above: PAGE NOT FOUND 404


> If you manage to flash barebox with it, a Documentation patch about how to use the CLI version
> of the tool would be very much appreciated.
>
>

Of course! Even the support for our new boards too! ;-)

> [0]: https://www.st.com/content/ccc/resource/technical/document/application_note/group1/63/b3/70/f6/82/33/4e/5e/DM00589815/files/DM00589815.pdf/jcr:content/translations/en.DM00589815.pd
> [1]: https://www.pengutronix.de/en/services/integration_testing.html
>


Regards,
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[Ahmad Fatoum]

On 2/26/20 4:30 PM, gianluca wrote:
>>> My goals are to setup the SDRAM and the secure monitor via USB (with DFU STM32 Cube Programmer), then loading via usb (using the same STM32 Cube Programmer) the barebox-stm32mp157c-dk2.img in the external SDRAM addresses.
>>
>> I haven't tested this, but it should work. barebox doesn't need anything
>> special to be flashed by the DFU.
>>
> 
> Not flashed into eMMC but stored into external SDRAM then let it run from there.
>>> When barebox is done, it will download from a TFTP server the production stuff (SDRAM setup, secure monitor, barebox-stm32mp157c-dk2-PRODUCTION.img) and write those stuff into eMMC partitions.
>>
>> Doesn't the STM32 Cube Programmer already come with the necessary infrastructure
>> to partition the eMMC and write the images over USB?
>>
> 
> Using the latest en.stm32cubeprog_v2-3-0.zip of 172Mb I have found nothing. Maybe I am the dumbest person in the world, but a quick search I was not be able to find anything useful for that.

Haven't tried myself, so that's why I asked for documentation patches when you figure
it out ^^.

>>> Using the above procedure the USB support is given only by ROM Code written by ST, not by Barebox.
>>
>> Not exactly, you communicate with the ROM Code to get TF-A into On-Chip RAM. Then you talk with
>> TF-A to get SSBL into SDRAM. Then you talk with SSBL to flash the rest. That's how the
>> STM32 Cube Programmer does it.
>>
> 
> the TF-A talk to get SSBL into SDRAM could be done with STM32Cube Programmer? I.e. the TF-A know something about the USB stuff??

ST's TF-A fork does. Upstream TF-A doesn't. The Programmer software uses vendor TF-A.

> What about the ethernet support (with tftpboot) in Barebox for this STM32MP157 SoC???

It works fine on the two boards I've tried. If it doesn't for you, send a bug report.

>> See below[0].
>>
> 
> Error 404

Sorry, forgot a letter:
https://www.st.com/content/ccc/resource/technical/document/application_note/group1/63/b3/70/f6/82/33/4e/5e/DM00589815/files/DM00589815.pdf/jcr:content/translations/en.DM00589815.pdf

>> I'll take a look, once we have USB gadget support on the STM32.
>> Can't say for sure when this will be though. There are means[1] to
>> accelerate this however. ;-)
>>
> 
> For sure, but from a production point of view, the usb must be connected as little as possible. It is better to download everything from Ethernet and/or from NFS rootfilesystem to me.

Why though? You need USB anyway to get at least FSBL and SSBL onto the board, why
not use it to flash the rootfs as well? Or upload kernel and initramfs to barebox
and have barebox boot them?

I've so far used network boot only for development, so I am interested
on how you're doing it.

>> If you manage to flash barebox with it, a Documentation patch about how to use the CLI version
>> of the tool would be very much appreciated.
> 
> Of course! Even the support for our new boards too! ;-)

Great! Looking forward to it.


Cheers
Ahmad


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[Ahmad Fatoum]

Hello,

please keep the barebox mailing list in CC.

On 2/27/20 12:44 PM, gianluca wrote:
>> ST's TF-A fork does. Upstream TF-A doesn't. The Programmer software uses vendor TF-A.
>>
> 
> I've found the forked ST's TF-A repo:
> 
> https://github.com/STMicroelectronics/arm-trusted-firmware
> 
> is it right?

Yes. I have only tried upstream TF-A though.

> I tried to compile for STM32MP1 but it gives me a lot of issues regarding the compiler toolchain.
> 
> I have used:
> 
>> Using built-in specs.
>> COLLECT_GCC=arm-none-eabi-gcc
>> COLLECT_LTO_WRAPPER=/home/gianluca/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/lto-wrapper
>> Target: arm-none-eabi
>> Configured with: /tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/src/gcc/configure --target=arm-none-eabi --prefix=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native --libexecdir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/lib --infodir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap
>> --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/arm-none-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr --with-mpfr=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr --with-mpc=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr --with-isl=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr --with-libelf=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr
>> --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for Arm Embedded Processors 7-2018-q2-update' --with-multilib-list=rmprofile
>> Thread model: single
>> gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)
> 
> but when trying compiling it gives me this error:
> 
>> STM32MP_EMMC=1 CROSS_COMPILE=arm-none-eabi- make PLAT=stm32mp1
>>   CC      lib/libfdt/fdt.c
>> arm-none-eabi-gcc: error: unrecognized command line option '-mgeneral-regs-only'
>> arm-none-eabi-gcc: error: unrecognized command line option '-mstrict-align'; did you mean '-Wstrict-aliasing'?
>> lib/libfdt/libfdt.mk:19: recipe for target 'build/stm32mp1/release/libfdt/fdt.o' failed
>> make: *** [build/stm32mp1/release/libfdt/fdt.o] Error 1
> 
> What compiler are you using to compile TF-A???

OSELAS.Toolchain-2019.09.1

But I think you are calling it with the wrong parameters, you need:

make ARCH=aarch32 ARM_ARCH_MAJOR=7 AARCH32_SP=sp_min DEBUG=1 STM32MP_EMMC=1 \
        DTB_FILE_NAME=stm32mp157c-dk2.dtb \
        CROSS_COMPILE=${CROSS_COMPILE} \
        PLAT=stm32mp

It's described in the TF-A platform documentation.
You can also check out the ptxdist rule for building it:
https://www.mail-archive.com/ptxdist@pengutronix.de/msg15787.html

Cheers,
Ahmad
                                                                        
 
> Regards,
> Gianluca


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[gianluca]

On 02/27/2020 12:51 PM, Ahmad Fatoum wrote:
> Hello,
>
> please keep the barebox mailing list in CC.
>
> On 2/27/20 12:44 PM, gianluca wrote:
>>> ST's TF-A fork does. Upstream TF-A doesn't. The Programmer software uses vendor TF-A.
>>>
>>
>> I've found the forked ST's TF-A repo:
>>
>> https://github.com/STMicroelectronics/arm-trusted-firmware
>>
>> is it right?
>
> Yes. I have only tried upstream TF-A though.
>
>> I tried to compile for STM32MP1 but it gives me a lot of issues regarding the compiler toolchain.
>>
>> I have used:
>>
>>> Using built-in specs.
>>> COLLECT_GCC=arm-none-eabi-gcc
>>> COLLECT_LTO_WRAPPER=/home/gianluca/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/lto-wrapper
>>> Target: arm-none-eabi
>>> Configured with: /tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/src/gcc/configure --target=arm-none-eabi --prefix=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native --libexecdir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/lib --infodir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap
>>> --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/install-native/arm-none-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr --with-mpfr=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr --with-mpc=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr --with-isl=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr --with-libelf=/tmp/jenkins/jenkins-GCC-7-build_toolchain_docker-775_20180622_1529687456/build-native/host-libs/usr
>>> --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for Arm Embedded Processors 7-2018-q2-update' --with-multilib-list=rmprofile
>>> Thread model: single
>>> gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)
>>
>> but when trying compiling it gives me this error:
>>
>>> STM32MP_EMMC=1 CROSS_COMPILE=arm-none-eabi- make PLAT=stm32mp1
>>>   CC      lib/libfdt/fdt.c
>>> arm-none-eabi-gcc: error: unrecognized command line option '-mgeneral-regs-only'
>>> arm-none-eabi-gcc: error: unrecognized command line option '-mstrict-align'; did you mean '-Wstrict-aliasing'?
>>> lib/libfdt/libfdt.mk:19: recipe for target 'build/stm32mp1/release/libfdt/fdt.o' failed
>>> make: *** [build/stm32mp1/release/libfdt/fdt.o] Error 1
>>
>> What compiler are you using to compile TF-A???
>
> OSELAS.Toolchain-2019.09.1
>
> But I think you are calling it with the wrong parameters, you need:
>
> make ARCH=aarch32 ARM_ARCH_MAJOR=7 AARCH32_SP=sp_min DEBUG=1 STM32MP_EMMC=1 \
>         DTB_FILE_NAME=stm32mp157c-dk2.dtb \
>         CROSS_COMPILE=${CROSS_COMPILE} \
>         PLAT=stm32mp
>

PLAT=stm32mp1

;-)

Now it compiles with the gcc version 7.3.1 20180622 (release) 
[ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded 
Processors 7-2018-q2-update).
Built build/stm32mp1/debug/tf-a-stm32mp157c-dk2.bin successfully


Generated build/stm32mp1/debug/tf-a-stm32mp157c-dk2.stm32
tools/stm32image/stm32image -s 
./build/stm32mp1/debug/tf-a-stm32mp157c-dk2.bin -d 
build/stm32mp1/debug/tf-a-stm32mp157c-dk2.stm32 -l 0x000000002ffc2500 -e 
0x000000002ffd8000 -v 0
Image Type   : ST Microelectronics STM32 V1.0
Image Size   : 245128 bytes
Image Load   : 0x2ffc2500
Entry Point  : 0x2ffd8000
Checksum     : 0x00ebe57e
Option     : 0x00000001
Version	   : 0x00000000


> It's described in the TF-A platform documentation.

Frankly, the documentation in the github repo is quite messy. Anyway 
thanks for your support.

> You can also check out the ptxdist rule for building it:
> https://www.mail-archive.com/ptxdist@pengutronix.de/msg15787.html
>

I will do ASAP. Thank you again.

Gianluca
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[gianluca]

On 02/28/2020 08:50 AM, gianluca wrote:
> Now it compiles with the gcc version 7.3.1 20180622 (release)
> [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded
> Processors 7-2018-q2-update).
> Built build/stm32mp1/debug/tf-a-stm32mp157c-dk2.bin successfully
>
>
> Generated build/stm32mp1/debug/tf-a-stm32mp157c-dk2.stm32
> tools/stm32image/stm32image -s
> ./build/stm32mp1/debug/tf-a-stm32mp157c-dk2.bin -d
> build/stm32mp1/debug/tf-a-stm32mp157c-dk2.stm32 -l 0x000000002ffc2500 -e
> 0x000000002ffd8000 -v 0
> Image Type   : ST Microelectronics STM32 V1.0
> Image Size   : 245128 bytes
> Image Load   : 0x2ffc2500
> Entry Point  : 0x2ffd8000
> Checksum     : 0x00ebe57e
> Option     : 0x00000001
> Version       : 0x00000000
>

Now having the following .tsv file:

> #Opt	Id	Name	Type	IP	Offset	Binary
> -	0x01	fsbl1-boot	Binary	none	0x0	tf-a-stm32mp157c-dk2.stm32
> -	0x03	ssbl-boot	Binary	none	0x0	barebox-stm32mp157c-dk2.img

The STM32_Programmer_CLI cmdline gives those messages:

  ---> (cmdline) STM32_Programmer_CLI -c port=usb1 -w 
stm32mp157c-dk2.tsv <---

>       -------------------------------------------------------------------
>                         STM32CubeProgrammer v2.3.0
>       -------------------------------------------------------------------
>
>
>
> USB speed   : High Speed (480MBit/s)
> Manuf. ID   : STMicroelectronics
> Product ID  : DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000
> SN          : 0022002B3338510534383330
> FW version  : 0x0110
> Device ID   : 0x0500
> Device name : STM32MPxxx
> Device type : MPU
> Device CPU  : Cortex-A7
>
>
> Start Embedded Flashing service
>
>
>
> Memory Programming ...
> Opening and parsing file: tf-a-stm32mp157c-dk2.stm32
>   File          : tf-a-stm32mp157c-dk2.stm32
>   Size          : 245384 Bytes
>   Partition ID  : 0x01
>
> Download in Progress:
> [==================================================] 100%
>
> File download complete
> Time elapsed during download operation: 00:00:00.830
>
> RUNNING Program ...
>   PartID:      :0x01
> Start operation done successfully at partition 0x01
>
> Flashlayout Programming ...
> [==================================================] 100%
> Running Flashlayout Partition ...
> Flashlayout partition started successfully
>
>
> Memory Programming ...
> Opening and parsing file: barebox-stm32mp157c-dk2.img
>   File          : barebox-stm32mp157c-dk2.img
>   Size          : 284074 Bytes
>   Partition ID  : 0x03
>
> Download in Progress:
> [==================================================] 100%
>
> File download complete
> Time elapsed during download operation: 00:00:00.232
>
> RUNNING Program ...
>   PartID:      :0x03
>
> reconnecting the device ...
>
> Error: unable to reconnect the target device: time out expired
>
>
> Error: Start operation failed at partition 0x03
> Error: TSV flashing service failed

So in the console debug (via ttyACM usb gadget) I have these messages:

> NOTICE:  CPU: STM32MP157CAC Rev.B
> NOTICE:  Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
> NOTICE:  Board: MB1272 Var2 Rev.C-01
> INFO:    Reset reason (0x14):
> INFO:      Pad Reset from NRST
> INFO:    PMIC version = 0x10
> INFO:    Using USB
> INFO:      Instance 2
> INFO:    Boot used partition fsbl1
> NOTICE:  BL2: v2.0-r3.0(debug):v2.0-stm32mp-r3
> NOTICE:  BL2: Built : 08:44:36, Feb 28 2020
> INFO:    BL2: Doing platform setup
> INFO:    RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.45
> INFO:    Memory size = 0x20000000 (512 MB)
> INFO:    BL2 runs SP_MIN setup
> INFO:    BL2: Loading image id 4
> INFO:    Loading image id=4 at address 0x2ffef000
> INFO:    Image id=4 loaded: 0x2ffef000 - 0x30000000
> INFO:    BL2: Loading image id 5
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    UPLOAD :
> INFO:                   Phase ID : 0
> INFO:                   address 0x2ffed78c
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    UPLOAD :
> INFO:                   Phase ID : 0
> INFO:                   address 0x2ffed78c
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    Start Download partition 0 to address 0xc0000000 length 0
> INFO:    USB : DFU : end of download partition : 0
> INFO:    Loading image id=5 at address 0xc0100000
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    UPLOAD :
> INFO:                   Phase ID : 3
> INFO:                   address 0x2ffed78c
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    receive request 6
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    UPLOAD :
> INFO:                   Phase ID : 3
> INFO:                   address 0x2ffed78c
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    usb_partition_size: partition size : 0x454aa
> INFO:    Start Download partition 3 to address 0xc0100000 length 283818
> INFO:    USB : DFU : end of download partition : 3
> WARNING: Skip signature check (header option)
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    UPLOAD :
> INFO:                   Phase ID : 0
> INFO:                   address 0xffffffff
> INFO:    Send detach request
> INFO:    GETSTATUS :
> INFO:                   DFU_STATE_IDLE
> INFO:    Receive Detach
> INFO:    Image id=5 loaded: 0xc0100000 - 0xc01454aa
> NOTICE:  BL2: Booting BL32
> INFO:    Entry point address = 0x2ffef000
> INFO:    SPSR = 0x1d3
> NOTICE:  SP_MIN: v2.0-r3.0(debug):v2.0-stm32mp-r3
> NOTICE:  SP_MIN: Built : 08:44:45, Feb 28 2020
> INFO:    ARM GICv2 driver initialized
> INFO:    stm32mp HSI (18): Secure only
> INFO:    stm32mp HSE (20): Secure only
> INFO:    stm32mp PLL2 (27): Secure only
> INFO:    stm32mp PLL2_R (30): Secure only
> INFO:    SP_MIN: Initializing runtime services
> INFO:    SP_MIN: Preparing exit to normal world

So it seems it hangs on running or transferring Barebox as SSBL... Or 
the Barebox output is not the same as TF-A...

The Barebox is 2020.01.0, the steps to build it are:

1- make ARCH=arm stm32mp_defconfig
2- make ARCH=arm all

>   CHK     include/generated/version.h
>   CHK     include/generated/utsrelease.h
>   CREATE  include/config.h
>   CHK     include/generated/compile.h
>   ENV     defaultenv/barebox_default_env
>   ENV     defaultenv/defaultenv-2-base.bbenv
>   ENV     defaultenv/defaultenv-2-menu.bbenv
>   CHKFILESIZE images/start_stm32mp157c_dk2.pblb
>   LN      images/../barebox-flash-image
> images built:
> barebox-stm32mp157c-dk2.img

So the SSBL the .tsv file is referring to is the last build of Barebox.

Any hint? Clue? or whatever?

Is the console output of Barebox in the stm32mp_defconfig routed to the 
same RX & TX pins for the ttyACM as for the TF-A components?


Gianluca
-- 
Eurek s.r.l.                          |
Electronic Engineering                | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[Ahmad Fatoum]

Hi,

On 2/28/20 9:28 AM, gianluca wrote:
>> RUNNING Program ...
>>   PartID:      :0x03
>>
>> reconnecting the device ...
>>
>> Error: unable to reconnect the target device: time out expired
>>
>>
>> Error: Start operation failed at partition 0x03
>> Error: TSV flashing service failed
> 
> So in the console debug (via ttyACM usb gadget) I have these messages:
> 
>> NOTICE:  CPU: STM32MP157CAC Rev.B
>> NOTICE:  Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
>> NOTICE:  Board: MB1272 Var2 Rev.C-01
>> INFO:    Reset reason (0x14):
>> INFO:      Pad Reset from NRST
>> INFO:    PMIC version = 0x10
>> INFO:    Using USB
>> INFO:      Instance 2
>> INFO:    Boot used partition fsbl1
>> NOTICE:  BL2: v2.0-r3.0(debug):v2.0-stm32mp-r3
>> NOTICE:  BL2: Built : 08:44:36, Feb 28 2020
>> INFO:    BL2: Doing platform setup
>> INFO:    RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.45
>> INFO:    Memory size = 0x20000000 (512 MB)
>> INFO:    BL2 runs SP_MIN setup
>> INFO:    BL2: Loading image id 4
>> INFO:    Loading image id=4 at address 0x2ffef000
>> INFO:    Image id=4 loaded: 0x2ffef000 - 0x30000000
>> INFO:    BL2: Loading image id 5
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    UPLOAD :
>> INFO:                   Phase ID : 0
>> INFO:                   address 0x2ffed78c
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    UPLOAD :
>> INFO:                   Phase ID : 0
>> INFO:                   address 0x2ffed78c
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    Start Download partition 0 to address 0xc0000000 length 0
>> INFO:    USB : DFU : end of download partition : 0
>> INFO:    Loading image id=5 at address 0xc0100000
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    UPLOAD :
>> INFO:                   Phase ID : 3
>> INFO:                   address 0x2ffed78c
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    receive request 6
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    UPLOAD :
>> INFO:                   Phase ID : 3
>> INFO:                   address 0x2ffed78c
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    usb_partition_size: partition size : 0x454aa
>> INFO:    Start Download partition 3 to address 0xc0100000 length 283818
>> INFO:    USB : DFU : end of download partition : 3
>> WARNING: Skip signature check (header option)
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    UPLOAD :
>> INFO:                   Phase ID : 0
>> INFO:                   address 0xffffffff
>> INFO:    Send detach request
>> INFO:    GETSTATUS :
>> INFO:                   DFU_STATE_IDLE
>> INFO:    Receive Detach
>> INFO:    Image id=5 loaded: 0xc0100000 - 0xc01454aa
>> NOTICE:  BL2: Booting BL32
>> INFO:    Entry point address = 0x2ffef000
>> INFO:    SPSR = 0x1d3
>> NOTICE:  SP_MIN: v2.0-r3.0(debug):v2.0-stm32mp-r3
>> NOTICE:  SP_MIN: Built : 08:44:45, Feb 28 2020
>> INFO:    ARM GICv2 driver initialized
>> INFO:    stm32mp HSI (18): Secure only
>> INFO:    stm32mp HSE (20): Secure only
>> INFO:    stm32mp PLL2 (27): Secure only
>> INFO:    stm32mp PLL2_R (30): Secure only
>> INFO:    SP_MIN: Initializing runtime services
>> INFO:    SP_MIN: Preparing exit to normal world
> 
> So it seems it hangs on running or transferring Barebox as SSBL... Or the Barebox output is not the same as TF-A...

barebox output is uart4 (ttyACM of ST-Link).

> The Barebox is 2020.01.0, the steps to build it are:
> 
> 1- make ARCH=arm stm32mp_defconfig
> 2- make ARCH=arm all
> 
>>   CHK     include/generated/version.h
>>   CHK     include/generated/utsrelease.h
>>   CREATE  include/config.h
>>   CHK     include/generated/compile.h
>>   ENV     defaultenv/barebox_default_env
>>   ENV     defaultenv/defaultenv-2-base.bbenv
>>   ENV     defaultenv/defaultenv-2-menu.bbenv
>>   CHKFILESIZE images/start_stm32mp157c_dk2.pblb
>>   LN      images/../barebox-flash-image
>> images built:
>> barebox-stm32mp157c-dk2.img
> 
> So the SSBL the .tsv file is referring to is the last build of Barebox.
> 
> Any hint? Clue? or whatever?
> 
> Is the console output of Barebox in the stm32mp_defconfig routed to the same RX & TX pins for the ttyACM as for the TF-A components?

Yes. Try enabling CONFIG_DEBUG_LL to see if you get some early output from barebox
before the UART driver was probed.

barebox might not work under a "trusted" TF-A, because it isolates some peripherals behind
vendor-specific secure monitor calls. I intend to add support for these, once upstream TF-A
has SCMI support.

For now, you may be better off using the flash tool like it's intended and write vendor
TF-A and vendor U-Boot to RAM and then use those to flash barebox and TF-A to eMMC.

See FlashLayout_sdcard_stm32mp157c-ev1-basic.tsv[1] for an example.

[1]: https://wiki.st.com/stm32mpu/wiki/STM32MP1_Starter_Package_-_images

Cheers
Ahmad

> 
> 
> Gianluca

-- 
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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Barebox as first and second stage bootloader

[Ahmad Fatoum]

Hi,

On 2/26/20 5:37 PM, gianluca wrote:
> On 02/26/2020 04:46 PM, Ahmad Fatoum wrote:
> Ok. Now you know: there is NOTHING ABOUT FSBL or SSBL as well.

How you mean?

> So I suppose if I do not change the ethernet phy or anything else from evalboard everything from Ethernet will work as-is.

Yes. The realtek PHY on the DK-2 works nicely. Make sure to check the SoC errata sheet,
there's one about booting from eMMC that may be relevant to you.

>>> For sure, but from a production point of view, the usb must be connected as little as possible. It is better to download everything from Ethernet and/or from NFS rootfilesystem to me.
>>
>> Why though? You need USB anyway to get at least FSBL and SSBL onto the board, why
>> not use it to flash the rootfs as well? Or upload kernel and initramfs to barebox
>> and have barebox boot them?
>>
>> I've so far used network boot only for development, so I am interested
>> on how you're doing it.
>>
> 
> Depends on how many board you are planning to produce. Actually we have a board version based on iMX28 and the procedure is the same:
> 
> 1- load via imx-usb-loader the bootlets and barebox (takes a couple of seconds)
> 
> 2- let barebox download uImage and device-tree blob from tftp server (takes 5/6 seconds)
> 
> 3- boot into linux. this very small (busybox based linux) write on eMMC the bootlets and the barebox as well then poweroff itself (boot and flash will take less than a minute)
> 
> 4- The operator take the board and put it in a rack with other 24 boards. It will powerup and load bootlets + barebox and download uImage and boot from a NFS Server.
> 
> 5- This NFS server will flash the eMMC with rootfs and application data. When done it will flash some leds (it takes less than 10 minutes)
> 
> 6- At this point when done, the operator will bring back the board to the programming place so it can complete the procedure. When rebooted the board will ask for a specific ethernet MAC Address given via USB BarCode Reader. At the end the MAC-HW sticker will be placed on the board. That's it.
> 
> In this way we did not use the microSD connector nor USB Host connector because the customer does not want that. It needs to cut down the cost as much as possible.
> 
> The same procedure should be used with the same board based on STM32MP1 SoC.

I see. Thanks for the perspective. For the STM32MP, I think it would be better if you
had the flashing tool directly write the SSBL and FSBL. Then you can disconnect
and have barebox boot Linux from network as usual.

>>>> If you manage to flash barebox with it, a Documentation patch about how to use the CLI version
>>>> of the tool would be very much appreciated.
>>>
>>> Of course! Even the support for our new boards too! ;-)
>>
>> Great! Looking forward to it.
>>
> 
> Sure.
> 
> Gianluca Renzi

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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox