mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* RISC-V: erizo: large gap between bss and stack regions
@ 2021-04-14  5:54 Antony Pavlov
  2021-04-14  9:54 ` Sascha Hauer
  0 siblings, 1 reply; 7+ messages in thread
From: Antony Pavlov @ 2021-04-14  5:54 UTC (permalink / raw)
  Cc: barebox

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@90000000.of
  0x91000000 - 0x91000003 (size 0x00000004) 91000000.gpio@91000000.of
  0x91000004 - 0x91000007 (size 0x00000004) 91000000.gpio@91000000.of

I see large unused region between bss and stack regions (>1600 Kbytes).

For comparrison, the regions on mips malta are packed much more closely:

barebox@qemu malta:/ iomem
0x00000000 - 0xffffffff (size 0x00000000) iomem
  0x180003f8 - 0x180003ff (size 0x00000008) 180003f8.serial@180003f8.of
  0x1e000000 - 0x1e3fffff (size 0x00400000) 1e000000.flash@1e000000.of
  0x1f000900 - 0x1f00093f (size 0x00000040) 1f000900.serial@1f000900.of
  0x1f000b00 - 0x1f000b1f (size 0x00000020) 1f000b00.gpio@1f000b00.of
  0xa0000000 - 0xafffffff (size 0x10000000) kseg1_ram0
    0xafb39000 - 0xafb3ffff (size 0x00007000) stack
    0xafb40000 - 0xaff3ffff (size 0x00400000) malloc space
    0xaff40000 - 0xaffa417f (size 0x00064180) barebox
    0xaffa4180 - 0xafff263f (size 0x0004e4c0) barebox data
    0xafffa640 - 0xafffe7ab (size 0x0000416c) bss

-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RISC-V: erizo: large gap between bss and stack regions
  2021-04-14  5:54 RISC-V: erizo: large gap between bss and stack regions Antony Pavlov
@ 2021-04-14  9:54 ` Sascha Hauer
  2021-04-14 11:07   ` Antony Pavlov
  0 siblings, 1 reply; 7+ messages in thread
From: Sascha Hauer @ 2021-04-14  9:54 UTC (permalink / raw)
  To: Antony Pavlov; +Cc: barebox

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@90000000.of
>   0x91000000 - 0x91000003 (size 0x00000004) 91000000.gpio@91000000.of
>   0x91000004 - 0x91000007 (size 0x00000004) 91000000.gpio@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.

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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RISC-V: erizo: large gap between bss and stack regions
  2021-04-14  9:54 ` Sascha Hauer
@ 2021-04-14 11:07   ` Antony Pavlov
  2021-04-14 11:20     ` Ahmad Fatoum
  0 siblings, 1 reply; 7+ messages in thread
From: Antony Pavlov @ 2021-04-14 11:07 UTC (permalink / raw)
  To: Sascha Hauer, Ahmad Fatoum; +Cc: barebox

On Wed, 14 Apr 2021 11:54:27 +0200
Sascha Hauer <sha@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@90000000.of
> >   0x91000000 - 0x91000003 (size 0x00000004) 91000000.gpio@91000000.of
> >   0x91000004 - 0x91000007 (size 0x00000004) 91000000.gpio@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?

-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RISC-V: erizo: large gap between bss and stack regions
  2021-04-14 11:07   ` Antony Pavlov
@ 2021-04-14 11:20     ` Ahmad Fatoum
  2021-04-14 12:54       ` Antony Pavlov
  2021-04-15  7:54       ` Sascha Hauer
  0 siblings, 2 replies; 7+ messages in thread
From: Ahmad Fatoum @ 2021-04-14 11:20 UTC (permalink / raw)
  To: Antony Pavlov, Sascha Hauer; +Cc: barebox

On 14.04.21 13:07, Antony Pavlov wrote:
> On Wed, 14 Apr 2021 11:54:27 +0200
> Sascha Hauer <sha@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@90000000.of
>>>   0x91000000 - 0x91000003 (size 0x00000004) 91000000.gpio@91000000.of
>>>   0x91000004 - 0x91000007 (size 0x00000004) 91000000.gpio@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?

-- 
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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RISC-V: erizo: large gap between bss and stack regions
  2021-04-14 11:20     ` Ahmad Fatoum
@ 2021-04-14 12:54       ` Antony Pavlov
  2021-04-14 12:58         ` Sascha Hauer
  2021-04-15  7:54       ` Sascha Hauer
  1 sibling, 1 reply; 7+ messages in thread
From: Antony Pavlov @ 2021-04-14 12:54 UTC (permalink / raw)
  To: Ahmad Fatoum; +Cc: Sascha Hauer, barebox

On Wed, 14 Apr 2021 13:20:44 +0200
Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:

> On 14.04.21 13:07, Antony Pavlov wrote:
> > On Wed, 14 Apr 2021 11:54:27 +0200
> > Sascha Hauer <sha@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@90000000.of
> >>>   0x91000000 - 0x91000003 (size 0x00000004) 91000000.gpio@91000000.of
> >>>   0x91000004 - 0x91000007 (size 0x00000004) 91000000.gpio@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?
> 

On MIPS we already have:

   bss_len = (unsigned long)&__bss_stop - (unsigned long)__bss_start;

On RISC-V we have __bss_stop and __bss_start, but we don't use them as MIPS does.

P.S. hmmm... why there is '&' prior to __bss_stop on MIPS and there is no '&' prior to __bss_start?

> -- 
> 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 |


-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RISC-V: erizo: large gap between bss and stack regions
  2021-04-14 12:54       ` Antony Pavlov
@ 2021-04-14 12:58         ` Sascha Hauer
  0 siblings, 0 replies; 7+ messages in thread
From: Sascha Hauer @ 2021-04-14 12:58 UTC (permalink / raw)
  To: Antony Pavlov; +Cc: Ahmad Fatoum, barebox

On Wed, Apr 14, 2021 at 03:54:43PM +0300, Antony Pavlov wrote:
> On Wed, 14 Apr 2021 13:20:44 +0200
> Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> 
> > On 14.04.21 13:07, Antony Pavlov wrote:
> > > On Wed, 14 Apr 2021 11:54:27 +0200
> > > Sascha Hauer <sha@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@90000000.of
> > >>>   0x91000000 - 0x91000003 (size 0x00000004) 91000000.gpio@91000000.of
> > >>>   0x91000004 - 0x91000007 (size 0x00000004) 91000000.gpio@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?
> > 
> 
> On MIPS we already have:
> 
>    bss_len = (unsigned long)&__bss_stop - (unsigned long)__bss_start;

When running in the decompressor that gives you the bss size of the
decompressor binary, but we need the bss size of barebox proper.

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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RISC-V: erizo: large gap between bss and stack regions
  2021-04-14 11:20     ` Ahmad Fatoum
  2021-04-14 12:54       ` Antony Pavlov
@ 2021-04-15  7:54       ` Sascha Hauer
  1 sibling, 0 replies; 7+ messages in thread
From: Sascha Hauer @ 2021-04-15  7:54 UTC (permalink / raw)
  To: Ahmad Fatoum; +Cc: barebox

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@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@90000000.of
> >>>   0x91000000 - 0x91000003 (size 0x00000004) 91000000.gpio@91000000.of
> >>>   0x91000004 - 0x91000007 (size 0x00000004) 91000000.gpio@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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-04-15  7:55 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-14  5:54 RISC-V: erizo: large gap between bss and stack regions Antony Pavlov
2021-04-14  9:54 ` Sascha Hauer
2021-04-14 11:07   ` Antony Pavlov
2021-04-14 11:20     ` Ahmad Fatoum
2021-04-14 12:54       ` Antony Pavlov
2021-04-14 12:58         ` Sascha Hauer
2021-04-15  7:54       ` Sascha Hauer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox