mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Lior Weintraub <liorw@pliops.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
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:48:37 +0000	[thread overview]
Message-ID: <PR3P195MB05559A232A25A80463C4D60EC315A@PR3P195MB0555.EURP195.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20230816142819.GH5650@pengutronix.de>

Thanks Sascha,

The thing I am trying to achieve is to run RTL simulations in a reasonable time frame on our bootloader and barebox loading.
On RTL simulation environment it takes about 5 min for each 40 us which is about 2 hours for 1 ms of CPU time.
When the original code with the relocation and decompression was tested it was still in the middle of decompression after 2 hole days of simulation.
I managed to patch the code to avoid the decompression (which is actually a memcpy in this case) and it seems to work fine (tested on QEMU).
The patch I used:

diff --git a/arch/arm/cpu/uncompress.c b/arch/arm/cpu/uncompress.c
index a481c4634d..cde03dc0c1 100644
--- a/arch/arm/cpu/uncompress.c
+++ b/arch/arm/cpu/uncompress.c
@@ -71,9 +71,14 @@ void __noreturn barebox_pbl_start(unsigned long membase, unsigned long memsize,
 	pg_len = pg_end - pg_start;
 	uncompressed_len = get_unaligned((const u32 *)(pg_start + pg_len - 4));
 
-	if (IS_ENABLED(CONFIG_RELOCATABLE))
+	if (IS_ENABLED(CONFIG_RELOCATABLE)) {
+#ifdef CONFIG_IMAGE_COMPRESSION_NONE
+        barebox_base = (void *)pg_start;
+#else
 		barebox_base = arm_mem_barebox_image(membase, endmem,
 						     uncompressed_len + MAX_BSS_SIZE);
+#endif
+    }
 	else
 		barebox_base = TEXT_BASE;
 
@@ -87,12 +92,14 @@ void __noreturn barebox_pbl_start(unsigned long membase, unsigned long memsize,
 	free_mem_ptr = arm_mem_early_malloc(endmem);
 	free_mem_end_ptr = arm_mem_early_malloc_end(endmem);
 
+#ifndef CONFIG_IMAGE_COMPRESSION_NONE
 	pr_debug("uncompressing barebox binary at 0x%p (size 0x%08x) to 0x%08lx (uncompressed size: 0x%08x)\n",
 			pg_start, pg_len, barebox_base, uncompressed_len);
 
 	pbl_barebox_uncompress((void*)barebox_base, pg_start, pg_len);
 
 	sync_caches_for_execution();
+#endif
 
 	if (IS_ENABLED(CONFIG_THUMB2_BAREBOX))
 		barebox = (void *)(barebox_base + 1);


Your call if that makes sense to include in the upstream or not :-)
Thanks again for your kind support,
Cheers,
Lior.

> -----Original Message-----
> From: Sascha Hauer <s.hauer@pengutronix.de>
> Sent: Wednesday, August 16, 2023 5:28 PM
> To: Lior Weintraub <liorw@pliops.com>
> Cc: barebox@lists.infradead.org; Ahmad Fatoum
> <a.fatoum@pengutronix.de>
> Subject: Re: Barebox PBL with uncompressed barebox proper
> 
> CAUTION: External Sender
> 
> 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://secure-
> web.cisco.com/1XpYzNc191JjtGaWh_8mPulQQYcyNjNxrljKOy4EXP2rJ6BI69y
> LQZalS_CIiCjQ0DKAyT3wD0pqV_fDARkSkZJR-
> QINkixMViIHKcS0xPNjMFyt4edli64apIWuOxcO_28UOr2R8MQOuS7ZeOhXjm
> fpSK85jwv7AhOTHiCnokRyVhHNWfbb1o05jLvnoR6zBmZ8U5MiQ5cwXYnEq
> w4fYe6wBKoBmerRBThjYiwC7_6_5LUEtO3BFAF-
> brnGnHBd9opXwB2Lq4kXhbQ4HLNnL1ZiAuKMKm7EYhvbN3y3BML9T-
> mz5ZvxUqx6VzqE8FAGv/http%3A%2F%2Fwww.pengutronix.de%2F  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




  reply	other threads:[~2023-08-16 16:50 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
2023-08-16 16:48       ` Lior Weintraub [this message]
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=PR3P195MB05559A232A25A80463C4D60EC315A@PR3P195MB0555.EURP195.PROD.OUTLOOK.COM \
    --to=liorw@pliops.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --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