mail archive of the barebox mailing list
 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 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