From: Antony Pavlov <antonynpavlov@gmail.com>
To: "Clément Leger" <cleger@kalray.eu>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH v2 0/6] elf: add better bootm support
Date: Tue, 28 Apr 2020 15:40:50 +0300 [thread overview]
Message-ID: <20200428154050.961a724bb7e80d6ca712dad7@gmail.com> (raw)
In-Reply-To: <422912487.17009323.1587639977653.JavaMail.zimbra@kalray.eu>
On Thu, 23 Apr 2020 13:06:17 +0200 (CEST)
Clément Leger <cleger@kalray.eu> wrote:
> Hi Antony,
>
> ----- On 23 Apr, 2020, at 12:20, Antony Pavlov antonynpavlov@gmail.com wrote:
>
> > On Thu, 23 Apr 2020 10:17:05 +0200
> > Clement Leger <cleger@kalray.eu> wrote:
> >
> > Hi, Clement
> >
> > Just FYI. On MIPS barebox I use out-of-tree kexec-based ELF loader.
> >
> > This efforts started in 2012 (sic!):
> > http://lists.infradead.org/pipermail/barebox/2012-December/011771.html
> >
> > Alas! kexec patches are not mainlined still.
> >
> > public kexec patches are available in my github repo, e.g.
> > https://github.com/frantony/barebox/commits/20170319.mips-malta-elf-linux
> >
> > If your are interested in using kexec-style ELF loading I can prepare
> > patches on top of latest barebox master.
>
> If I understand correctly, the main advantage is to be able to load some code
> over the currently running code by using some sort of "relocation" right ?
Yes, you are right.
> Currently, on KVX, we load Linux in the beginning of the DDR and barebox is
> at DDR base + 256Mo so we don't have overlapping. But I bet that if we
> had that it would be useful.
On MIPS the situation is just the same: on start barebox relocates itself
to the top of memory (thank to 2019 Oleksij's patchseries)
so linux kernel and barebox overlaping is unlikely. So kexec-style ELF
loading was actual on MIPS before 2019.
> Anyway, even if we don't need it right now, that's a really nice feature !
>
> From what I see from your commit, I think a part of it could be integrated in
> the existing elf parser (in elf_request_region) and add the segment
> information in elf_section struct (the name is not really meaningful
> since it stores the elf segments :D). And then a bootm option would allow
> setting an "offset" at which will be loaded the elf waiting to be relocated
> and then call the arch assembly code to do the relocation and boot ?
>
> BTW, it makes me realize that currently, the elf is loaded when doing the
> elf_open and not it would probably be better to do it in bootm_load_os as
> for other file format. This would allow to open the elf file only in the
> first time and load it later and could probably help you to integrate
> kexec (ie load elf file only) and then do some kexec magic with the elf
> struct.
> Tell me if you think other improvements can be made.
First of all I have to check your v3 patchseries on MIPS.
The main problem of my kexec elf load patchseries that it was tested only on MIPS.
> Regards,
>
> Clément
>
> >
> >> Currently, when booting an elf file using "bootm /dev/mtdx", bootm will
> >> simply pass the file to the bootm and the read done on it will read the
> >> entire flash partition. This series starts by some cleanup and then add an
> >> elf_open function to load the elf file size only based on the elf header.
> >> A special handling for the elf file is also added in bootm data to allow
> >> using directly the elf file structure. Finally the mips bootm is modified
> >> to use bootm elf loading capability.
> >>
> >> Changes v1 -> v2
> >> - Add BOOTM_ELF config to select elf support and add checks in code
> >> - Add an elf_get_mem_size function to avoid computing elf size in bootm.c
> >> - Use xmalloc and read_full in elf_open instead of xzalloc/read
> >> - Fix data->elf NULL reset
> >> - Remove elf struct entirely from mips bootm code
> >>
> >> Clement Leger (6):
> >> common: elf: add computation of elf boundaries
> >> common: elf: fix warning on 32 bits architectures
> >> common: elf: split init to be reused from other function
> >> common: elf: add elf_open and elf_close
> >> common: bootm: add support for elf file loading
> >> mips: lib: bootm: use bootm elf loading capabilities
> >>
> >> arch/mips/lib/bootm.c | 27 +++--------
> >> common/Kconfig | 8 ++++
> >> common/bootm.c | 30 ++++++++++++
> >> common/elf.c | 107 ++++++++++++++++++++++++++++++++++++++++--
> >> include/bootm.h | 3 ++
> >> include/elf.h | 14 ++++++
> >> 6 files changed, 164 insertions(+), 25 deletions(-)
> >>
> >> --
> >> 2.17.1
> >>
> >>
> >> _______________________________________________
> >> barebox mailing list
> >> barebox@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/barebox
> >
> >
> > --
> > Best regards,
> > Antony Pavlov
--
Best regards,
Antony Pavlov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2020-04-28 12:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 8:17 Clement Leger
2020-04-23 8:17 ` [PATCH v2 1/6] common: elf: add computation of elf boundaries Clement Leger
2020-04-23 8:17 ` [PATCH v2 2/6] common: elf: fix warning on 32 bits architectures Clement Leger
2020-04-23 8:17 ` [PATCH v2 3/6] common: elf: split init to be reused from other function Clement Leger
2020-04-23 8:17 ` [PATCH v2 4/6] common: elf: add elf_open and elf_close Clement Leger
2020-04-28 6:39 ` Sascha Hauer
2020-04-28 7:38 ` Clément Leger
2020-04-23 8:17 ` [PATCH v2 5/6] common: bootm: add support for elf file loading Clement Leger
2020-04-23 8:17 ` [PATCH v2 6/6] mips: lib: bootm: use bootm elf loading capabilities Clement Leger
2020-04-28 6:41 ` Sascha Hauer
2020-04-23 8:17 ` [PATCH v2 6/6] mips: lib: bootm: use new data->elf member Clement Leger
2020-04-23 8:20 ` Clément Leger
2020-04-23 10:20 ` [PATCH v2 0/6] elf: add better bootm support Antony Pavlov
2020-04-23 11:06 ` Clément Leger
2020-04-28 12:40 ` Antony Pavlov [this message]
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=20200428154050.961a724bb7e80d6ca712dad7@gmail.com \
--to=antonynpavlov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=cleger@kalray.eu \
/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