[Buildroot] SoCkit support question?

[Buildroot] SoCkit support question?

[Sébastien Bourdelin]

Hi,

I would like to submit the support for the SoCkit from Altera, but i have some questions regarding the bootloader step and need some advices on the best way to handle it.

The SoC combines a hard processing system (HPS) and an FPGA, so the board design can change and the bootloader must provide a preloader.

This preloader is normally generated using the Altera tools (Quartus, Qsys, bsp-editor) and results in source files defining the board that will be used in a patched u-boot from rocketboard (rocketboard is altera i guess).
For more informations on this step, please look at : http://www.rocketboards.org/foswiki/Documentation/PreloaderUbootCustomization

Then the preloader must be sign using an other tool from Altera (mkpimage) that comes with all the Altera dev environment.
Maxime Hadjinlian has done a fork of this tool in GO (https://github.com/maximeh/mkpimage)

If i use the sources from the rocketboard repository (http://git.rocketboards.org/?p=u-boot-socfpga.git;a=summary),
regardless the branch, the preloader generated doesn't work, even if i'm signing it with the mkpimage tool from Altera (may be i'm missing something here).

If i use the Altera tools to generate my preloader using Qsys and an example design from Altera, then use the result sources files that define the u-boot/board/altera/socfpga/*, built u-boot and sign it with the mkpimage from Altera then it works.

So my question is what the best way to provide the support for this board in buildroot ?

Assuming I have not made mistake, if you want to provide support for the bootloader of this board without using any tools from Altera, you must :

- Use the patched u-boot from rocketboard
- Define the board with a sample design, ie patch the sources in u-boot/board/altera/socfpga/*
- Generate the bootloader (u-boot) and preloader (u-boot SPL)
- Sign the preloader with a fork to mkpimage tools (recode the mkpimage from Maxim  Hadjinlian in C ?)

Another approach would be to consider that the end user must provide their bootloader and flash it, the buildroot board config take care of building only Linux and the rootfs.

[Buildroot] SoCkit support question?

[Charles Manning]

On Thu, Feb 20, 2014 at 8:50 AM, S?bastien Bourdelin <
sebastien.bourdelin@savoirfairelinux.com> wrote:

> Hi,
>
> I would like to submit the support for the SoCkit from Altera, but i have
> some questions regarding the bootloader step and need some advices on the
> best way to handle it.
>
> The SoC combines a hard processing system (HPS) and an FPGA, so the board
> design can change and the bootloader must provide a preloader.
>
> This preloader is normally generated using the Altera tools (Quartus,
> Qsys, bsp-editor) and results in source files defining the board that will
> be used in a patched u-boot from rocketboard (rocketboard is altera i
> guess).
> For more informations on this step, please look at :
> http://www.rocketboards.org/foswiki/Documentation/PreloaderUbootCustomization
>
> Then the preloader must be sign using an other tool from Altera (mkpimage)
> that comes with all the Altera dev environment.
> Maxime Hadjinlian has done a fork of this tool in GO (
> https://github.com/maximeh/mkpimage)
>
> If i use the sources from the rocketboard repository (
> http://git.rocketboards.org/?p=u-boot-socfpga.git;a=summary),
> regardless the branch, the preloader generated doesn't work, even if i'm
> signing it with the mkpimage tool from Altera (may be i'm missing something
> here).
>

Yes, many people have observed. this. There are some discussions going on
in the rocketboard rfi mailing list on that too,

If i use the Altera tools to generate my preloader using Qsys and an
> example design from Altera, then use the result sources files that define
> the u-boot/board/altera/socfpga/*, built u-boot and sign it with the
> mkpimage from Altera then it works.
>


Yesterday I posted a patch for uboot on the rocketboard RFI mailing list.
http://lists.rocketboards.org/pipermail/rfi/2014-February/001281.html

This patch adds a preloader signer (written in C) to the u-boot/tools as
well as adding this to the Makefile to run automatically (like say the OMAP
MLO signer does).

I am also putting together some build-root recipes to copy the binary over
(something like how the omap MLO is handled).



> So my question is what the best way to provide the support for this board
> in buildroot ?
>
> Assuming I have not made mistake, if you want to provide support for the
> bootloader of this board without using any tools from Altera, you must :
>
> - Use the patched u-boot from rocketboard
> - Define the board with a sample design, ie patch the sources in
> u-boot/board/altera/socfpga/*
> - Generate the bootloader (u-boot) and preloader (u-boot SPL)
> - Sign the preloader with a fork to mkpimage tools (recode the mkpimage
> from Maxim  Hadjinlian in C ?)
>
> Another approach would be to consider that the end user must provide their
> bootloader and flash it, the buildroot board config take care of building
> only Linux and the rootfs.
>

I think it is better to build the preloader from buildroot too.

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140220/420767bb/attachment.html>

[Buildroot] SoCkit support question?

[Maxime Hadjinlian]

Hi Charles, S?bastien, all

On Wed, Feb 19, 2014 at 9:34 PM, Charles Manning <cdhmanning@gmail.com> wrote:
>
>
>
> On Thu, Feb 20, 2014 at 8:50 AM, S?bastien Bourdelin
> <sebastien.bourdelin@savoirfairelinux.com> wrote:
>>
>> Hi,
>>
>> I would like to submit the support for the SoCkit from Altera, but i have
>> some questions regarding the bootloader step and need some advices on the
>> best way to handle it.
>>
>> The SoC combines a hard processing system (HPS) and an FPGA, so the board
>> design can change and the bootloader must provide a preloader.
>>
>> This preloader is normally generated using the Altera tools (Quartus,
>> Qsys, bsp-editor) and results in source files defining the board that will
>> be used in a patched u-boot from rocketboard (rocketboard is altera i
>> guess).
>> For more informations on this step, please look at :
>> http://www.rocketboards.org/foswiki/Documentation/PreloaderUbootCustomization
>>
>> Then the preloader must be sign using an other tool from Altera (mkpimage)
>> that comes with all the Altera dev environment.
>> Maxime Hadjinlian has done a fork of this tool in GO
>> (https://github.com/maximeh/mkpimage)
>>
>> If i use the sources from the rocketboard repository
>> (http://git.rocketboards.org/?p=u-boot-socfpga.git;a=summary),
>> regardless the branch, the preloader generated doesn't work, even if i'm
>> signing it with the mkpimage tool from Altera (may be i'm missing something
>> here).
>
>
> Yes, many people have observed. this. There are some discussions going on in
> the rocketboard rfi mailing list on that too,
>
>> If i use the Altera tools to generate my preloader using Qsys and an
>> example design from Altera, then use the result sources files that define
>> the u-boot/board/altera/socfpga/*, built u-boot and sign it with the
>> mkpimage from Altera then it works.
The fact that it doesn't work out of the box with a really minimal
configuration is a real PITA.
As a matter of fact, I have heard that Altera is working on the 2nd
version of theses boards, and it seems software and mainlining efforts
has been pretty much put to a stop :/.
>
>
>
> Yesterday I posted a patch for uboot on the rocketboard RFI mailing list.
> http://lists.rocketboards.org/pipermail/rfi/2014-February/001281.html
>
> This patch adds a preloader signer (written in C) to the u-boot/tools as
> well as adding this to the Makefile to run automatically (like say the OMAP
> MLO signer does).
That's really nice ! I ment to do that but never took the time. With
the documentation published it is easier to code this right.
Well done !
Try to push it over to the mainline U-Boot mailing list, that can
interests them, I already offered my Go and another Python version of
my mkpimage a while ago, but maybe your C version will raise more
interests to them.
>
> I am also putting together some build-root recipes to copy the binary over
> (something like how the omap MLO is handled).
Obvious idea, could you put your branch online somewhere so S?bastien
could work with you and so you don't do both the work :) ?
I would be happy to help.
>
>
>>
>> So my question is what the best way to provide the support for this board
>> in buildroot ?
>>
>> Assuming I have not made mistake, if you want to provide support for the
>> bootloader of this board without using any tools from Altera, you must :
>>
>> - Use the patched u-boot from rocketboard
>> - Define the board with a sample design, ie patch the sources in
>> u-boot/board/altera/socfpga/*
>> - Generate the bootloader (u-boot) and preloader (u-boot SPL)
>> - Sign the preloader with a fork to mkpimage tools (recode the mkpimage
>> from Maxim  Hadjinlian in C ?)
>>
>> Another approach would be to consider that the end user must provide their
>> bootloader and flash it, the buildroot board config take care of building
>> only Linux and the rootfs.
>
>
> I think it is better to build the preloader from buildroot too.
Ideally, it would be part of the uboot-tools packages.
That's also a reason why it would be nice if the U-Boot Tools could be
from the same sources as U-Boot, I had sent a patch regarding this
issues, but I have to rework my idea to re send this.
>
> -- Charles
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] SoCkit support question?

[Sebastien Bourdelin]

On 02/20/2014 04:08 AM, Maxime Hadjinlian wrote:
> Hi Charles, S?bastien, all
>
> On Wed, Feb 19, 2014 at 9:34 PM, Charles Manning <cdhmanning@gmail.com> wrote:
>>
>>
>> On Thu, Feb 20, 2014 at 8:50 AM, S?bastien Bourdelin
>> <sebastien.bourdelin@savoirfairelinux.com> wrote:
>>> Hi,
>>>
>>> I would like to submit the support for the SoCkit from Altera, but i have
>>> some questions regarding the bootloader step and need some advices on the
>>> best way to handle it.
>>>
>>> The SoC combines a hard processing system (HPS) and an FPGA, so the board
>>> design can change and the bootloader must provide a preloader.
>>>
>>> This preloader is normally generated using the Altera tools (Quartus,
>>> Qsys, bsp-editor) and results in source files defining the board that will
>>> be used in a patched u-boot from rocketboard (rocketboard is altera i
>>> guess).
>>> For more informations on this step, please look at :
>>> http://www.rocketboards.org/foswiki/Documentation/PreloaderUbootCustomization
>>>
>>> Then the preloader must be sign using an other tool from Altera (mkpimage)
>>> that comes with all the Altera dev environment.
>>> Maxime Hadjinlian has done a fork of this tool in GO
>>> (https://github.com/maximeh/mkpimage)
>>>
>>> If i use the sources from the rocketboard repository
>>> (http://git.rocketboards.org/?p=u-boot-socfpga.git;a=summary),
>>> regardless the branch, the preloader generated doesn't work, even if i'm
>>> signing it with the mkpimage tool from Altera (may be i'm missing something
>>> here).
>>
>> Yes, many people have observed. this. There are some discussions going on in
>> the rocketboard rfi mailing list on that too,
>>
>>> If i use the Altera tools to generate my preloader using Qsys and an
>>> example design from Altera, then use the result sources files that define
>>> the u-boot/board/altera/socfpga/*, built u-boot and sign it with the
>>> mkpimage from Altera then it works.
> The fact that it doesn't work out of the box with a really minimal
> configuration is a real PITA.
> As a matter of fact, I have heard that Altera is working on the 2nd
> version of theses boards, and it seems software and mainlining efforts
> has been pretty much put to a stop :/.
What i can do, is adding an u-boot patch for this board in buildroot
that will generate a working u-boot-spl based on the example design.
>>
>>
>> Yesterday I posted a patch for uboot on the rocketboard RFI mailing list.
>> http://lists.rocketboards.org/pipermail/rfi/2014-February/001281.html
>>
>> This patch adds a preloader signer (written in C) to the u-boot/tools as
>> well as adding this to the Makefile to run automatically (like say the OMAP
>> MLO signer does).
> That's really nice ! I ment to do that but never took the time. With
> the documentation published it is easier to code this right.
> Well done !
> Try to push it over to the mainline U-Boot mailing list, that can
> interests them, I already offered my Go and another Python version of
> my mkpimage a while ago, but maybe your C version will raise more
> interests to them.
>> I am also putting together some build-root recipes to copy the binary over
>> (something like how the omap MLO is handled).
> Obvious idea, could you put your branch online somewhere so S?bastien
> could work with you and so you don't do both the work :) ?
> I would be happy to help.
I'm not sure it will be necessary, until the Charles patchs are mainline
or at least in buildroot i could not use it.
I think we could just generate an un-sign preloader and let the end user
know that currently he has to sign it using the Altera tool or your tool
Maxime, then if the Charles patchs are accepted we could changed the
board config.
What do you think ?
>>
>>> So my question is what the best way to provide the support for this board
>>> in buildroot ?
>>>
>>> Assuming I have not made mistake, if you want to provide support for the
>>> bootloader of this board without using any tools from Altera, you must :
>>>
>>> - Use the patched u-boot from rocketboard
>>> - Define the board with a sample design, ie patch the sources in
>>> u-boot/board/altera/socfpga/*
>>> - Generate the bootloader (u-boot) and preloader (u-boot SPL)
>>> - Sign the preloader with a fork to mkpimage tools (recode the mkpimage
>>> from Maxim  Hadjinlian in C ?)
>>>
>>> Another approach would be to consider that the end user must provide their
>>> bootloader and flash it, the buildroot board config take care of building
>>> only Linux and the rootfs.
>>
>> I think it is better to build the preloader from buildroot too.
> Ideally, it would be part of the uboot-tools packages.
> That's also a reason why it would be nice if the U-Boot Tools could be
> from the same sources as U-Boot, I had sent a patch regarding this
> issues, but I have to rework my idea to re send this.
>> -- Charles
>>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] SoCkit support question?

[Charles Manning]

On Friday 21 February 2014 10:30:11 Sebastien Bourdelin wrote:
> On 02/20/2014 04:08 AM, Maxime Hadjinlian wrote:
> > Hi Charles, S?bastien, all
> >
> > On Wed, Feb 19, 2014 at 9:34 PM, Charles Manning <cdhmanning@gmail.com> 
wrote:
> >> On Thu, Feb 20, 2014 at 8:50 AM, S?bastien Bourdelin
> >>
> >> <sebastien.bourdelin@savoirfairelinux.com> wrote:
> >>> Hi,
> >>>
> >>> I would like to submit the support for the SoCkit from Altera, but i
> >>> have some questions regarding the bootloader step and need some advices
> >>> on the best way to handle it.
> >>>
> >>> The SoC combines a hard processing system (HPS) and an FPGA, so the
> >>> board design can change and the bootloader must provide a preloader.
> >>>
> >>> This preloader is normally generated using the Altera tools (Quartus,
> >>> Qsys, bsp-editor) and results in source files defining the board that
> >>> will be used in a patched u-boot from rocketboard (rocketboard is
> >>> altera i guess).
> >>> For more informations on this step, please look at :
> >>> http://www.rocketboards.org/foswiki/Documentation/PreloaderUbootCustomi
> >>>zation
> >>>
> >>> Then the preloader must be sign using an other tool from Altera
> >>> (mkpimage) that comes with all the Altera dev environment.
> >>> Maxime Hadjinlian has done a fork of this tool in GO
> >>> (https://github.com/maximeh/mkpimage)
> >>>
> >>> If i use the sources from the rocketboard repository
> >>> (http://git.rocketboards.org/?p=u-boot-socfpga.git;a=summary),
> >>> regardless the branch, the preloader generated doesn't work, even if
> >>> i'm signing it with the mkpimage tool from Altera (may be i'm missing
> >>> something here).
> >>
> >> Yes, many people have observed. this. There are some discussions going
> >> on in the rocketboard rfi mailing list on that too,
> >>
> >>> If i use the Altera tools to generate my preloader using Qsys and an
> >>> example design from Altera, then use the result sources files that
> >>> define the u-boot/board/altera/socfpga/*, built u-boot and sign it with
> >>> the mkpimage from Altera then it works.
> >
> > The fact that it doesn't work out of the box with a really minimal
> > configuration is a real PITA.
> > As a matter of fact, I have heard that Altera is working on the 2nd
> > version of theses boards, and it seems software and mainlining efforts
> > has been pretty much put to a stop :/.
>
> What i can do, is adding an u-boot patch for this board in buildroot
> that will generate a working u-boot-spl based on the example design.
>
> >> Yesterday I posted a patch for uboot on the rocketboard RFI mailing
> >> list.
> >> http://lists.rocketboards.org/pipermail/rfi/2014-February/001281.html
> >>
> >> This patch adds a preloader signer (written in C) to the u-boot/tools as
> >> well as adding this to the Makefile to run automatically (like say the
> >> OMAP MLO signer does).
> >
> > That's really nice ! I ment to do that but never took the time. With
> > the documentation published it is easier to code this right.
> > Well done !
> > Try to push it over to the mainline U-Boot mailing list, that can
> > interests them, I already offered my Go and another Python version of
> > my mkpimage a while ago, but maybe your C version will raise more
> > interests to them.

I know people like python and Go, but it adds complexity to the whole of 
u-boot building for little gain. All the existing tools are C and this signer 
was trivial to do in C.

> >
> >> I am also putting together some build-root recipes to copy the binary
> >> over (something like how the omap MLO is handled).
> >
> > Obvious idea, could you put your branch online somewhere so S?bastien
> > could work with you and so you don't do both the work :) ?
> > I would be happy to help.
>
> I'm not sure it will be necessary, until the Charles patchs are mainline
> or at least in buildroot i could not use it.
> I think we could just generate an un-sign preloader and let the end user
> know that currently he has to sign it using the Altera tool or your tool
> Maxime, then if the Charles patchs are accepted we could changed the
> board config.
> What do you think ?
>
> >>> So my question is what the best way to provide the support for this
> >>> board in buildroot ?
> >>>
> >>> Assuming I have not made mistake, if you want to provide support for
> >>> the bootloader of this board without using any tools from Altera, you
> >>> must :
> >>>
> >>> - Use the patched u-boot from rocketboard
> >>> - Define the board with a sample design, ie patch the sources in
> >>> u-boot/board/altera/socfpga/*
> >>> - Generate the bootloader (u-boot) and preloader (u-boot SPL)
> >>> - Sign the preloader with a fork to mkpimage tools (recode the mkpimage
> >>> from Maxim  Hadjinlian in C ?)
> >>>
> >>> Another approach would be to consider that the end user must provide
> >>> their bootloader and flash it, the buildroot board config take care of
> >>> building only Linux and the rootfs.
> >>
> >> I think it is better to build the preloader from buildroot too.
> >
> > Ideally, it would be part of the uboot-tools packages.
> > That's also a reason why it would be nice if the U-Boot Tools could be
> > from the same sources as U-Boot, I had sent a patch regarding this
> > issues, but I have to rework my idea to re send this.


I have just sent my second patch for this to the u-boot list. They didn't like 
my last one because it was standalone and not integrated into mkimage. They 
might come back with some formatting stuff, but I think it will be mainlined 
in a day or two.

Once that is in place, it can be patched into the u-boot-socfpga tree and the 
preloader is built and signed as part of a regular u-boot build. It just 
needs a build-root copy step to copy it into output/images. I will be doing 
that today.

> >
> >> -- Charles
> >>
> >>
> >> _______________________________________________
> >> buildroot mailing list
> >> buildroot at busybox.net
> >> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] SoCkit support question?

[Thomas Petazzoni]

Dear Charles Manning,

On Fri, 21 Feb 2014 11:24:02 +1300, Charles Manning wrote:

> I have just sent my second patch for this to the u-boot list. They didn't like 
> my last one because it was standalone and not integrated into mkimage. They 
> might come back with some formatting stuff, but I think it will be mainlined 
> in a day or two.
> 
> Once that is in place, it can be patched into the u-boot-socfpga tree and the 
> preloader is built and signed as part of a regular u-boot build. It just 
> needs a build-root copy step to copy it into output/images. I will be doing 
> that today.

In the mean time (until your patch gets accepted, and a new U-Boot
release is made with it), it is still possible to support the SoCkit by
having U-Boot build an unsigned image, and let the user manually use
the Altera provided mkpimage tool to sign it. It just needs to be
documented in board/arrow/sockit/readme.txt, with all the other details
on how to actually set up the board to use the bootloader and kernel
images produced by Buildroot.

Don't wait for perfection. Do something simple that works now, and
improve on top of it progressively :)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] SoCkit support question?

[Sebastien Bourdelin]

Hi Thomas,

On 02/21/2014 06:30 AM, Thomas Petazzoni wrote:
> Dear Charles Manning,
>
> On Fri, 21 Feb 2014 11:24:02 +1300, Charles Manning wrote:
>
>> I have just sent my second patch for this to the u-boot list. They didn't like 
>> my last one because it was standalone and not integrated into mkimage. They 
>> might come back with some formatting stuff, but I think it will be mainlined 
>> in a day or two.
>>
>> Once that is in place, it can be patched into the u-boot-socfpga tree and the 
>> preloader is built and signed as part of a regular u-boot build. It just 
>> needs a build-root copy step to copy it into output/images. I will be doing 
>> that today.
> In the mean time (until your patch gets accepted, and a new U-Boot
> release is made with it), it is still possible to support the SoCkit by
> having U-Boot build an unsigned image, and let the user manually use
> the Altera provided mkpimage tool to sign it. It just needs to be
> documented in board/arrow/sockit/readme.txt, with all the other details
> on how to actually set up the board to use the bootloader and kernel
> images produced by Buildroot.
>
> Don't wait for perfection. Do something simple that works now, and
> improve on top of it progressively :)
>
> Best regards,
>
> Thomas

I will send you patches for the unsigned version with documentation today.

Best regards,

Sebastien.