All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 [PATCH v2 0/6] elf: add better bootm support 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.