From: "Clément Leger" <cleger@kalray.eu>
To: Antony Pavlov <antonynpavlov@gmail.com>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH v2 0/6] elf: add better bootm support
Date: Thu, 23 Apr 2020 13:06:17 +0200 (CEST) [thread overview]
Message-ID: <422912487.17009323.1587639977653.JavaMail.zimbra@kalray.eu> (raw)
In-Reply-To: <20200423132055.eb6f2d1918b736c92c026d69@gmail.com>
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 ?
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.
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.
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
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2020-04-23 11:06 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 [this message]
2020-04-28 12:40 ` Antony Pavlov
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=422912487.17009323.1587639977653.JavaMail.zimbra@kalray.eu \
--to=cleger@kalray.eu \
--cc=antonynpavlov@gmail.com \
--cc=barebox@lists.infradead.org \
/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