Hi Michal, On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.si...@xilinx.com> wrote: > > Hi Simon, > > On 16. 08. 20 5:39, Simon Glass wrote: > > Hi Michal, > > > > On Fri, 14 Aug 2020 at 07:28, Michal Simek <mon...@monstr.eu> wrote: > >> > >> Hi Simon, > >> > >> ne 19. 7. 2020 v 22:06 odesÃlatel Simon Glass <s...@chromium.org> napsal: > >>> > >>> This option is used to run arch-specific shell scripts which produce .its > >>> files which are used to produce FIT images. We already have binman which > >>> is designed to produce firmware images. It is more powerful and has tests. > >>> > >>> So this option should be deprecated and not used. Existing uses should be > >>> migrated. > >>> > >>> Mentions of this in code reviews over the last year or so do not seem to > >>> have resulted in action, and things are getting worse. > >>> > >>> So let's add a warning. > >>> > >>> Signed-off-by: Simon Glass <s...@chromium.org> > >>> Reviewed-by: Bin Meng <bmeng...@gmail.com> > >>> --- > >>> > >>> (no changes since v1) > >>> > >>> Makefile | 9 +++++++++ > >>> 1 file changed, 9 insertions(+) > >>> > >>> diff --git a/Makefile b/Makefile > >>> index f1b5be1882..d73c10a973 100644 > >>> --- a/Makefile > >>> +++ b/Makefile > >>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y) > >>> @echo >&2 "See doc/driver-model/migration.rst for more info." > >>> @echo >&2 "====================================================" > >>> endif > >>> +endif > >>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),) > >>> + @echo >&2 "===================== WARNING ======================" > >>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please > >>> migrate" > >>> + @echo >&2 "to binman instead, to avoid the proliferation of" > >>> + @echo >&2 "arch-specific scripts with no tests." > >>> + @echo >&2 "====================================================" > >>> endif > >>> @# Check that this build does not use CONFIG options that we do > >>> not > >>> @# know about unless they are in Kconfig. All the existing CONFIG > >>> @@ -1345,6 +1352,8 @@ endif > >>> > >>> # Boards with more complex image requirements can provide an .its source > >>> file > >>> # or a generator script > >>> +# NOTE: Please do not use this. We are migrating away from Makefile > >>> rules to use > >>> +# binman instead. > >>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"") > >>> U_BOOT_ITS := u-boot.its > >>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE)) > >>> -- > >>> 2.28.0.rc0.105.gf9edc3c819-goog > >>> > >> > >> I just got to this conversion and I am curious how that transition > >> should look like. > >> I found how FIT image is created which is fine but I didn't find any > >> reference on how to generate images based on CONFIG_OF_LIST. > >> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see > >> that I loop over this entry and create multiple DT nodes and the same > >> amount of configurations to cover it. Is this supported by binman? > >> If yes, what's the syntax for it? > > > > The easiest way is probably to create a new entry type, like zynq-fit. > > Then you can generate the DT using the sequence writer functions. See > > _ReadSubNodes() in fit.py for an example. > > > > You can perhaps have a template subnode and use that in a for loop to > > generate the nodes. > > > >> > >> I tried several configurations and we can use that for generating qspi > >> images and also images with different configurations to have them > >> ready > >> but first I need to be able to handle the case above. > > > > I was thinking of converting sunxi which has the same need, but it > > sounds like you are on the case. Let me know if you need help. > > Nope. I just saw that message and started to play with it to find out > what needs to be done and how this fits to bigger picture. If this > doesn't work directly then the work needs to be planned which will take > time especially when this utility is new for us and we could have issues > with writing code in python. Would be good if you can do the first shot > because you know this utility and I am more than happy to test it, try > and adopt if needed for our case. > > Sunxi is very similar case as is zynqmp. Difference is they hardcode > default configuration to config_1. ZynqMP is setting up default based on > default DT configured at that time. > > In connection to binman I see that there would be a need to generate > images with ATF and without ATF in configuration node and with different > default configuration. There could be also a need to add additional > loadable entry such as bitstreams. > > Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp > type because as was state in commit message u-boot.itb generation is > very similar for all these boards that's why name for this new entry > should be generic. >
I sent an initial series to add this to binman. I've since found a few problems so will send a v2 at some point. You can try it out at u-boot-dm/binman-working Regards, SImon