SoCkit support question?
A message that is not in the archive (sent off-list or not yet received): 940580837.479152.1392839319094.JavaMail.root@mail
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.
Quoted 21 lines · 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/PreloaderUbootCustomizationThen 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)
Quoted 6 lines
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
Quoted 4 lines
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).
Quoted 13 lines
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 ?)
Quoted 4 lines
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>
Hi Charles, S?bastien, all
Quoted 34 lines · Charles Manning
Quoted 22 lines · 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/PreloaderUbootCustomizationThen 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)Quoted 5 lines
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).
Quoted 7 lines
Yes, many people have observed. this. There are some discussions going on in the rocketboard rfi mailing list on that too,
Quoted 4 lines
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 :/.
Quoted 9 lines
Yesterday I posted a patch for uboot on the rocketboard RFI mailing list.
http://lists.rocketboards.org/pipermail/rfi/2014-February/001281.htmlThis patch adds a preloader signer (written in C) to the u-boot/tools as well as adding this to the
Makefileto 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.
Quoted 3 lines
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.
Quoted 16 lines
Quoted 16 lines
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 ?)
Quoted 6 lines
Quoted 3 lines
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.
Quoted 8 lines
-- Charles
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Quoted 41 lines · Maxime Hadjinlian
Hi Charles, S?bastien, all
Quoted 25 lines · Charles Manning
Quoted 21 lines · 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/PreloaderUbootCustomizationThen 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)Quoted 13 lines
Quoted 5 lines
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,
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 15 lines
Quoted 8 lines
Yesterday I posted a patch for uboot on the rocketboard RFI mailing list.
http://lists.rocketboards.org/pipermail/rfi/2014-February/001281.htmlThis patch adds a preloader signer (written in C) to the u-boot/tools as well as adding this to the
Makefileto 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.
Quoted 5 lines
Quoted 2 lines
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 ?
Quoted 30 lines
Quoted 14 lines
Quoted 14 lines
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 ?)Quoted 5 lines
Quoted 3 lines
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.
Quoted 7 lines
-- Charles
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Quoted 4 lines · On Friday 21 February 2014 10:30:11 Sebastien Bourdelin wrote:
Quoted 3 lines · Maxime Hadjinlian
Hi Charles, S?bastien, all
On Wed, Feb 19, 2014 at 9:34 PM, Charles Manning <[email protected]>
Quoted 39 lines · wrote:
Quoted 39 lines
Quoted 38 lines
On Thu, Feb 20, 2014 at 8:50 AM, S?bastien Bourdelin
Quoted 22 lines · <[email protected]> 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
zationThen 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)Quoted 5 lines
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,
Quoted 4 lines
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.
Quoted 24 lines
Quoted 5 lines
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.
Quoted 15 lines
Quoted 7 lines
Yesterday I posted a patch for uboot on the rocketboard RFI mailing list.
http://lists.rocketboards.org/pipermail/rfi/2014-February/001281.htmlThis patch adds a preloader signer (written in C) to the u-boot/tools as well as adding this to the
Makefileto 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.
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 32 lines
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 ?Quoted 24 lines
Quoted 14 lines
Quoted 14 lines
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 ?)Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
-- Charles
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Dear Charles Manning,
Quoted 9 lines · Charles Manning
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Hi Thomas,
Quoted 21 lines · Thomas Petazzoni
Dear Charles Manning,
Quoted 9 lines · Charles Manning
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.
Quoted 6 lines
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.