From: Alper Nebi Yasak <alpernebiyasak@gmail.com>
To: Simon Glass <sjg@chromium.org>
Cc: Ivan Mikhaylov <ivan.mikhaylov@siemens.com>,
Tom Rini <trini@konsulko.com>,
Philippe Reynes <philippe.reynes@softathome.com>,
huang lin <hl@rock-chips.com>,
Jeffy Chen <jeffy.chen@rock-chips.com>,
Kever Yang <kever.yang@rock-chips.com>,
U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [PATCH v2 19/25] binman: Keep a separate list of entries for fit
Date: Thu, 10 Mar 2022 22:30:21 +0300 [thread overview]
Message-ID: <08f24b2a-e2fb-8f61-e158-a5fa313ad231@gmail.com> (raw)
In-Reply-To: <CAPnjgZ2P4dDNxoZ=7QYanF=gZ_hYOKqi47-37q-=6ztMyVJb7Q@mail.gmail.com>
On 06/03/2022 06:08, Simon Glass wrote:
> On Thu, 3 Mar 2022 at 14:17, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>> This is a bit clumsy. We cannot build the image more than once, since the
>>> generator entries are lost during the first build. Binman requires that
>>> calling BuildSectionData() multiple times returns a valid result each
>>> time.
>>
>> I think the generator entries should be turned into concrete entries and
>> be removed in _gen_entries(), so BuildSectionData() should work on the
>> entries that were generated. This way the individual entries would show
>> up in fdtmap and could be binman-extracted/replaced as well.
>
> That makes sense, but I'm not sure how to implement it. The split-elf
> thing needs the contents of the entries which is not available at the
> start. It is likely available before BuildSectionData() is called, but
> not necessarily. So the template needs to hang around at least as long
> as that.
>
> I think there is something we could do here, but it isn't quite clear
> to me. Perhaps we need a expand-nodes-based-on-contents phase in
> control.py ? Eek...
I can't think of anything proper. I guess it could need architectural
changes, but I need to read more of the code and get a better grasp of
things.
>>
>> For FDTs we can generate blob entries for each file, for ELFs maybe we
>> can split them into files like the script used to do (bl31_0x<addr>.bin)
>> and do the same?
>
> I'm not a big fan of adding files. Binman should be able to hold
> everything in memory. It does generate files for later inspection
> though, so yes we could add this feature.
>
>>
>> Maybe some new entry types, "data" for arbitrary data unrelated to a
>> file whose contents we can set, or "elf-segment" that can extract a
>> segment from an ELF file (but I don't like the information loss there).
>
> Yes I quite like the idea of new entry types. In fact I was hoping to
> turn split-elf into an entry type (one that generated multiple
> entries). But I decided to stop before doing that since we really need
> to gets the code in there, fix the bugs /move forward with some of the
> ideas you and others have.
After this and the other fixes and such, I hope I can set aside some
time and experiment more on the ideas I've been throwing at you.
Sorry if I ended up delaying this too much already...
next prev parent reply other threads:[~2022-03-10 19:36 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 23:00 [PATCH v2 00/25] binman: rockchip: Migrate from rockchip SPL_FIT_GENERATOR script Simon Glass
2022-02-23 23:00 ` [PATCH v2 01/25] dtoc: Make GetArgs() more flexible Simon Glass
2022-03-03 21:07 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 02/25] moveconfig: Remove remove_defconfig() Simon Glass
2022-03-03 21:07 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 03/25] moveconfig: Use re.fullmatch() to avoid extra check Simon Glass
2022-03-03 21:07 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 04/25] spl: Correct Kconfig help for TPL_BINMAN_SYMBOLS Simon Glass
2022-03-03 21:08 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 05/25] dtoc: Tidy up implementation of AddStringList() Simon Glass
2022-03-03 21:08 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 06/25] elf: Rename load_segments() and module failure Simon Glass
2022-03-03 21:08 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 07/25] binman: Tweak collect_contents_to_file() and docs Simon Glass
2022-03-03 21:08 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 08/25] binman: Rename ExpandToLimit to extend_to_limit Simon Glass
2022-03-03 21:08 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 09/25] binman: Rename ExpandEntries to gen_entries Simon Glass
2022-03-03 21:09 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 10/25] binman: Refactor fit to generate output at the end Simon Glass
2022-03-03 21:09 ` Alper Nebi Yasak
2022-03-06 3:08 ` Simon Glass
2022-02-23 23:00 ` [PATCH v2 11/25] binman: Rename tools parameter to btools Simon Glass
2022-03-03 21:09 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 12/25] binman: Change how faked blobs are created Simon Glass
2022-03-03 21:09 ` Alper Nebi Yasak
2022-03-06 3:08 ` Simon Glass
2022-03-10 19:29 ` Alper Nebi Yasak
2022-03-12 5:02 ` Simon Glass
2022-03-14 21:29 ` Alper Nebi Yasak
2022-03-14 22:20 ` Simon Glass
2022-02-23 23:00 ` [PATCH v2 13/25] binman: Make fake blobs zero-sized by default Simon Glass
2022-03-03 21:09 ` Alper Nebi Yasak
2022-03-06 3:08 ` Simon Glass
2022-02-23 23:00 ` [PATCH v2 14/25] binman: Allow mkimage to use a non-zero fake-blob size Simon Glass
2022-03-03 21:09 ` Alper Nebi Yasak
2022-03-06 3:08 ` Simon Glass
2022-03-10 19:30 ` Alper Nebi Yasak
2022-03-12 5:02 ` Simon Glass
2022-02-23 23:00 ` [PATCH v2 15/25] binman: Read the fit entries only once Simon Glass
2022-03-03 21:10 ` Alper Nebi Yasak
2022-03-06 3:08 ` Simon Glass
2022-02-23 23:00 ` [PATCH v2 16/25] binman: Fix some pylint warnings in fit Simon Glass
2022-03-03 21:10 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 17/25] binman: Add a consistent way to report errors with fit Simon Glass
2022-03-03 21:10 ` Alper Nebi Yasak
2022-03-06 3:08 ` Simon Glass
2022-02-23 23:00 ` [PATCH v2 18/25] binman: Update fit to use node instead of subnode Simon Glass
2022-03-03 21:10 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 19/25] binman: Keep a separate list of entries for fit Simon Glass
2022-03-03 21:10 ` Alper Nebi Yasak
2022-03-06 3:08 ` Simon Glass
2022-03-10 19:30 ` Alper Nebi Yasak [this message]
2022-02-23 23:00 ` [PATCH v2 20/25] binman: Support splitting an ELF file into multiple nodes Simon Glass
2022-03-03 21:10 ` Alper Nebi Yasak
2022-03-06 3:08 ` Simon Glass
2022-02-23 23:00 ` [PATCH v2 21/25] rockchip: evb-rk3288: Drop raw-image support Simon Glass
2022-02-23 23:00 ` [PATCH v2 22/25] rockchip: Include binman script in 64-bit boards Simon Glass
2022-03-03 21:10 ` Alper Nebi Yasak
2022-02-23 23:00 ` [PATCH v2 23/25] rockchip: Support building the all output files in binman Simon Glass
2022-03-02 22:16 ` Peter Geis
2022-03-03 21:11 ` Alper Nebi Yasak
2022-03-03 22:34 ` Peter Geis
2022-03-06 3:08 ` Simon Glass
2022-02-23 23:00 ` [PATCH v2 24/25] rockchip: Convert all boards to use binman Simon Glass
2022-02-23 23:00 ` [PATCH v2 25/25] rockchip: Drop the FIT generator script Simon Glass
2022-03-01 2:48 ` [RFC] [PATCH] binman: support mkimage split files Peter Geis
2022-03-03 21:11 ` Alper Nebi Yasak
2022-03-04 17:47 ` Peter Geis
2022-03-04 19:56 ` [PATCH v2] binman: support mkimage separate files Peter Geis
2022-03-06 3:08 ` Simon Glass
2022-03-06 14:44 ` Peter Geis
2022-03-10 19:29 ` Alper Nebi Yasak
2022-03-10 23:19 ` Peter Geis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=08f24b2a-e2fb-8f61-e158-a5fa313ad231@gmail.com \
--to=alpernebiyasak@gmail.com \
--cc=hl@rock-chips.com \
--cc=ivan.mikhaylov@siemens.com \
--cc=jeffy.chen@rock-chips.com \
--cc=kever.yang@rock-chips.com \
--cc=philippe.reynes@softathome.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox