From: Sascha Hauer <s.hauer@pengutronix.de>
To: Lior Weintraub <liorw@pliops.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>,
Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: Re: Barebox PBL with uncompressed barebox proper
Date: Wed, 16 Aug 2023 16:28:19 +0200 [thread overview]
Message-ID: <20230816142819.GH5650@pengutronix.de> (raw)
In-Reply-To: <PR3P195MB0555F57333C5D9E6A4951C00C315A@PR3P195MB0555.EURP195.PROD.OUTLOOK.COM>
On Wed, Aug 16, 2023 at 11:23:26AM +0000, Lior Weintraub wrote:
> Thanks Sascha!
>
> Before applying the recommended change the trace showed:
> uncompress.c: memory at 0xc000000000, size 0x00300000
> uncompress.c: uncompressing barebox binary at 0x000000c000002b60 (size 0x00030def) to 0xc000100000 (uncompressed size: 0x0005a9a0)
> uncompress.c: jumping to uncompressed image at 0x000000c000100000
>
> After applying this configuration, the .img file was increased (as expected) and the trace shows:
> uncompress.c: memory at 0xc000000000, size 0x00300000
> uncompress.c: uncompressing barebox binary at 0x000000c000002480 (size 0x0005a9a4) to 0xc000100000 (uncompressed size: 0x0005a9a0)
> uncompress.c: jumping to uncompressed image at 0x000000c000100000
>
> Indeed is seems link an uncompressed image because the sizes of the
> "compressed" match to the uncompress (well except 4 bytes which
> probably indicate the image size or the compression type (just a
> guess)).
>
> I assume that the decompress function detects the header and know that
> it is an uncompressed image and then just copy it to another location
> (in my case 0xc000100000).
>
> Can we avoid this step?
> Since the image was loaded into SRAM we wish to run locally without
> the extra relocation (which also takes simulation time).
I don't think this is easily possible, at least not in an upstreamable
way. Normally barebox puts itself at the end of available RAM and puts
the malloc space directly beneath it.
What you describe here seems to be a very special purpose barebox. What
you could do is to disable PBL support and only build a barebox proper.
Then add your own entry point and jump to start_barebox() from there.
You'll need to copy/adjust the useful things from
barebox_non_pbl_start() as well.
I am not sure what you are trying to archieve here, because copying the
binary usually takes time in the order of milliseconds and that is
normally not a problem.
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 |
next prev parent reply other threads:[~2023-08-16 14:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-16 10:36 Lior Weintraub
2023-08-16 10:44 ` Sascha Hauer
2023-08-16 11:23 ` Lior Weintraub
2023-08-16 14:28 ` Sascha Hauer [this message]
2023-08-16 16:48 ` Lior Weintraub
2023-08-16 19:18 ` Lior Weintraub
2023-08-17 5:34 ` Sascha Hauer
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=20230816142819.GH5650@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=liorw@pliops.com \
/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