From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: BAREBOX <barebox@lists.infradead.org>,
"Claude Sonnet 4.5" <noreply@anthropic.com>
Subject: Re: [PATCH 00/19] PBL: Add PBL ELF loading support with dynamic relocations
Date: Tue, 6 Jan 2026 09:35:22 +0100 [thread overview]
Message-ID: <9e784cef-5e19-4500-bd9a-b7c760c9b7ce@pengutronix.de> (raw)
In-Reply-To: <aVvrNMgMrgCaPCiU@pengutronix.de>
Hi,
On 1/5/26 17:47, Sascha Hauer wrote:
> On Mon, Jan 05, 2026 at 03:08:03PM +0100, Ahmad Fatoum wrote:
>> Hi,
>>
>> On 1/5/26 12:26 PM, Sascha Hauer wrote:
>>> Until now we linked the raw barebox proper binary into the PBL which
>>> comes with a number of disadvantages. We rely on self-modifying code
>>> to in barebox proper (relocate_to_current_adr()) and have no initialized
>>> bss segment (setup_c()). Also we can only mark the .text and .rodata as
>>> readonly during runtime of barebox proper.
>>>
>>> This series overcomes this by linking a ELF image into the PBL. This
>>> image is properly layed out, linked and initialized in the PBL. With
>>> this barebox proper has a proper C environment and text/rodata
>>> protection from the start.
>>>
>>> As a bonus this series also adds initial MMU support for RISCV, also
>>> based on loading the ELF image and configuring the MMU from the PBL.
>>>
>>> This series also marks my start into AI assisted programming as you can
>>> see in the Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
>>> and 🤖 Generated with [Claude Code](https://claude.com/claude-code)
>>> tags. Without it I wouldn't have started this series during my xmas
>>> break, but with it it was actually quite fun to do; it felt like having
>>> a programming team which I just had to delegate new tasks to while
>>> having fun with my family myself ;)
>>
>> Did you do size comparisons to determine how much this series affects
>> binary size? I found that compressing every segment separately resulted
>> in a smaller binary size even after addition of ELF parsing to PBL, but
>> I used a purpose-built ELF loader unlike to what you did here.
>
> I did now.
>
> ARM64 barebox-dt-2nd.img raw: 1246506
> ARM64 barebox-dt-2nd.img ELF: 1248892 (+ 2386 bytes)
> ARM32 barebox-dt-2nd.img raw: 1217036
> ARM32 barebox-dt-2nd.img ELF: 1219159 (+ 2123 bytes)
>
> With --strip-section-headers instead of --strip-debug --strip-unneeded
> the last image goes down to 1217940 bytes, so only 904 bytes size
> increase.
Is the raw image from before the series was applied, so we can judge the
total size increase?
I redid tests for my series, but this time in the same build directory and
got values similar to yours:
ARM64 barebox-dt-2nd.img before: 992276
ARM64 barebox-dt-2nd.img after: 993029 (+ 753 bytes)
Previous measurement of ELF compression being smaller must have been
a mistake it seems.
Cheers,
Ahmad
>
> Sascha
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
prev parent reply other threads:[~2026-01-06 8:36 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 11:26 Sascha Hauer
2026-01-05 11:26 ` [PATCH 01/19] elf: Use memcmp to make suitable for PBL Sascha Hauer
2026-01-05 11:46 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 02/19] elf: build for PBL as well Sascha Hauer
2026-01-05 11:26 ` [PATCH 03/19] elf: add dynamic relocation support Sascha Hauer
2026-01-05 14:05 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 04/19] ARM: implement elf_apply_relocations() for ELF " Sascha Hauer
2026-01-05 11:58 ` Ahmad Fatoum
2026-01-05 19:53 ` Sascha Hauer
2026-01-05 11:26 ` [PATCH 05/19] riscv: " Sascha Hauer
2026-01-05 11:26 ` [PATCH 06/19] elf: implement elf_load_inplace() Sascha Hauer
2026-01-05 13:37 ` Ahmad Fatoum
2026-01-05 22:42 ` Sascha Hauer
2026-01-06 8:18 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 07/19] elf: create elf_open_binary_into() Sascha Hauer
2026-01-05 11:26 ` [PATCH 08/19] Makefile: add barebox.elf build target Sascha Hauer
2026-01-05 12:22 ` Ahmad Fatoum
2026-01-05 15:43 ` Sascha Hauer
2026-01-05 17:11 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 09/19] PBL: allow to link ELF image into PBL Sascha Hauer
2026-01-05 12:11 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 10/19] mmu: add MAP_CACHED_RO mapping type Sascha Hauer
2026-01-05 12:14 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 11/19] mmu: introduce pbl_remap_range() Sascha Hauer
2026-01-05 12:15 ` Ahmad Fatoum
2026-01-06 8:50 ` Ahmad Fatoum
2026-01-06 9:25 ` Sascha Hauer
2026-01-05 11:26 ` [PATCH 12/19] ARM: use relative jumps in exception table Sascha Hauer
2026-01-05 11:44 ` Ahmad Fatoum
2026-01-05 12:29 ` Sascha Hauer
2026-01-05 12:31 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 13/19] ARM: exceptions: make in-binary exception table const Sascha Hauer
2026-01-05 11:26 ` [PATCH 14/19] ARM: linker script: create separate PT_LOAD segments for text, rodata, and data Sascha Hauer
2026-01-05 13:11 ` Ahmad Fatoum
2026-01-05 23:01 ` Sascha Hauer
2026-01-06 7:59 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 15/19] ARM: link ELF image into PBL Sascha Hauer
2026-01-05 12:27 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 16/19] ARM: PBL: setup MMU with proper permissions from ELF segments Sascha Hauer
2026-01-05 12:58 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 17/19] riscv: link ELF image into PBL Sascha Hauer
2026-01-05 13:12 ` Ahmad Fatoum
2026-01-05 11:26 ` [PATCH 18/19] riscv: linker script: create separate PT_LOAD segments for text, rodata, and data Sascha Hauer
2026-01-05 13:40 ` Ahmad Fatoum
2026-01-05 11:27 ` [PATCH 19/19] riscv: add ELF segment-based memory protection with MMU Sascha Hauer
2026-01-05 13:58 ` Ahmad Fatoum
2026-01-05 14:08 ` [PATCH 00/19] PBL: Add PBL ELF loading support with dynamic relocations Ahmad Fatoum
2026-01-05 16:47 ` Sascha Hauer
2026-01-06 8:35 ` Ahmad Fatoum [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=9e784cef-5e19-4500-bd9a-b7c760c9b7ce@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=noreply@anthropic.com \
--cc=s.hauer@pengutronix.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