RISC-V: erizo: large gap between bss and stack regions

[Sascha Hauer]

On Wed, Apr 14, 2021 at 01:20:44PM +0200, Ahmad Fatoum wrote:
> On 14.04.21 13:07, Antony Pavlov wrote:
> > On Wed, 14 Apr 2021 11:54:27 +0200
> > Sascha Hauer <sha at pengutronix.de> wrote:
> > 
> >> On Wed, Apr 14, 2021 at 08:54:22AM +0300, Antony Pavlov wrote:
> >>> Hi Ahmad!
> >>>
> >>> Here is the iomem command output on erizo:
> >>>
> >>> barebox:/ iomem
> >>> 0x00000000 - 0xffffffff (size 0x00000000) iomem
> >>>   0x80000000 - 0x807fffff (size 0x00800000) ram0
> >>>     0x804ffd00 - 0x805ffcff (size 0x00100000) malloc space
> >>>     0x805ffd00 - 0x805fffe6 (size 0x000002e7) board data
> >>>     0x80600000 - 0x80636b1f (size 0x00036b20) barebox
> >>>     0x80636b20 - 0x8063ec9b (size 0x0000817c) barebox data
> >>>     0x8063ec9c - 0x80643147 (size 0x000044ac) bss
> >>>     0x807e0000 - 0x807fffff (size 0x00020000) stack
> >>>   0x90000000 - 0x9000001f (size 0x00000020) 90000000.uart at 90000000.of
> >>>   0x91000000 - 0x91000003 (size 0x00000004) 91000000.gpio at 91000000.of
> >>>   0x91000004 - 0x91000007 (size 0x00000004) 91000000.gpio at 91000000.of
> >>>
> >>> I see large unused region between bss and stack regions (>1600 Kbytes).
> >>
> >> That's normal. The compressed barebox knows the size of the uncompressed
> >> barebox, but it doesn't know the size of the bss segment above it. For
> >> that reason we have a very pessimistic estimate of:
> >>
> >> #define MAX_BSS_SIZE SZ_1M
> >>
> >> The barebox binary itself is then aligned to the previous 1MiB
> >> boundary, so barebox usually starts at 2MiB below the end of SDRAM.
> >> That's a bit wasteful for boards with very little memory like the erizo,
> >> but that's how things are at the moment.
> > 
> > Can we make it configurable via Kconfig?
> 
> Or even better: Could we easily add to the piggy data the size of bss
> it contains?

That probably depends on your definition of 'easily', but that would be
the preferred solution for me as well.
We already include a sha256 of the compressed image in the pbl binary,
maybe we could include the bss size in a similar way.

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 |