Re: Barebox PBL with uncompressed barebox proper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 |




[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux