Add a pre-relocation malloc() implementation

These don't really serve any purpose in the modern age. On the other hand they show up as annoying control characters in my editor, which then happily removes them.

I believe we can drop these characters from the file.

Signed-off-by Simon Glass <[email protected]>

At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that the global_data pointer is set up in board_init_f(). However it is actually set up before this, it just isn't zeroed.

If we zero the global data before calling board_init_f() then we don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.

Make this change (on arm32 only) to simplify the init process. I don't have the ability to test aarch64 yet.

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Fix assembler code comment in crt0.S to say GD, not BSS
- Ensure that aarch64 stays as it was
- Add newline after clr_gd label
- Remove redundant mov r0, #0

Changes in v2: None

  arch/arm/include/asm/config.h | 2 ++
  arch/arm/lib/crt0.S           | 9 +++++++++
  2 files changed, 11 insertions(+)

Hello Simon,

Quoted 19 lines · Simon Glass

At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that the global_data pointer is set up in board_init_f(). However it is actually set up before this, it just isn't zeroed.

If we zero the global data before calling board_init_f() then we don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.

Make this change (on arm32 only) to simplify the init process. I don't have the ability to test aarch64 yet.

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Fix assembler code comment in crt0.S to say GD, not BSS
- Ensure that aarch64 stays as it was
- Add newline after clr_gd label
- Remove redundant mov r0, #0

Quoted 6 lines

Changes in v2: None

  arch/arm/include/asm/config.h | 2 ++
  arch/arm/lib/crt0.S           | 9 +++++++++
  2 files changed, 11 insertions(+)

Looks good to me. I picked up this one instead
of my memset version.

Thanks, Jeroen

+Albert, Tom

Hi Albert,

Quoted 18 lines · Jeroen Hofstee

Hello Simon,

Quoted 14 lines · Simon Glass

At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that the global_data pointer is set up in board_init_f(). However it is actually set up before this, it just isn't zeroed.

If we zero the global data before calling board_init_f() then we don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.

Make this change (on arm32 only) to simplify the init process. I don't have the ability to test aarch64 yet.

Signed-off-by Simon Glass <[email protected]>

---

Quoted 5 lines

Quoted 5 lines

Changes in v3:
- Fix assembler code comment in crt0.S to say GD, not BSS
- Ensure that aarch64 stays as it was
- Add newline after clr_gd label
- Remove redundant mov r0, #0

Are you happy with this patch? I would like to apply to to the dm repo, but would quite like to get an ack first.

Quoted 8 lines

Quoted 7 lines

Changes in v2: None

  arch/arm/include/asm/config.h | 2 ++
  arch/arm/lib/crt0.S           | 9 +++++++++
  2 files changed, 11 insertions(+)

Quoted 5 lines

Looks good to me. I picked up this one instead
of my memset version.

Thanks, Jeroen

Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 29 lines · Simon Glass

+Albert, Tom

Hi Albert,

Quoted 23 lines · Jeroen Hofstee

Hello Simon,

Quoted 19 lines · Simon Glass

At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that the global_data pointer is set up in board_init_f(). However it is actually set up before this, it just isn't zeroed.

If we zero the global data before calling board_init_f() then we don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.

Make this change (on arm32 only) to simplify the init process. I don't have the ability to test aarch64 yet.

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Fix assembler code comment in crt0.S to say GD, not BSS
- Ensure that aarch64 stays as it was
- Add newline after clr_gd label
- Remove redundant mov r0, #0

Quoted 2 lines

Are you happy with this patch? I would like to apply to to the dm repo, but would quite like to get an ack first.

Acked-by Tom Rini <[email protected]>

But still want Albert to chime in too. He should be back now :)

At present sandbox defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that the global_data pointer is set up in board_init_f().

If we set up and zero the global data before calling board_init_f() then we don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.

Make this change to simplify the init process.

Signed-off-by Simon Glass <[email protected]>

If we are to have driver model before relocation we need to support some way of calling memory allocation routines.

The standard malloc() is pretty complicated:

1. It uses some BSS memory for its state, and BSS is not available before relocation

2. It supports algorithms for reducing memory fragmentation and improving performace of free(). Before relocation we could happily just not support free().

3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since this has been loaded anyway this is not really a problem.

The simplest way to support pre-relocation malloc() is to reserve an area of memory and allocate it in increasing blocks as needed. This implementation does this.

To enable it, you need to define the size of the malloc() pool as described in the README. It will be located above the pre-relocation stack on supported architectures.

Note that this implementation is only useful on machines which have some memory available before dram_init() is called - this includes those that do no DRAM init (like tegra) and those that do it in SPL (quite a few boards). Enabling driver model preior to relocation for the rest of the boards is left for a later exercise.

Signed-off-by Simon Glass <[email protected]>

Add support for re-relocation malloc() in arm's start-up code.

Signed-off-by Simon Glass <[email protected]>

---

Changes in v3:
- Rebase on earlier patch

Changes in v2: None

 README              | 3 +++
 arch/arm/lib/crt0.S | 5 ++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

README +3 -0

index 11e9d31..73abbf0 100644
@@ -3749,6 +3749,9 @@ Configuration Settings:
                The memory will be freed (or in fact just forgotton) when
                U-Boot relocates itself.
 
+               Pre-relocation malloc() is only supported on ARM at present
+               but is fairly easy to enable for other archs.
+
 - CONFIG_SYS_BOOTM_LEN:
                Normally compressed uImages are limited to an
                uncompressed size of 8 MBytes. If this is not enough,

arch/arm/lib/crt0.S +4 -2

index 43aa212..29cdad0 100644
@@ -78,7 +78,10 @@ clr_gd:
        strlo   r0, [r1]                /* clear 32-bit GD word */
        addlo   r1, r1, #4              /* move to next */
        blo     clr_gd
-
+#if defined(CONFIG_SYS_MALLOC_F_LEN) && !defined(CONFIG_SPL_BUILD)
+       sub     sp, sp, #CONFIG_SYS_MALLOC_F_LEN
+       str     sp, [r9, #GD_MALLOC_BASE]
+#endif
        /* mov r0, #0 not needed due to above code */
        bl      board_init_f
 
--

2.0.0.526.g5318336

Set up and zero global data before board_init_f() is called so that we can remove the need for CONFIG_SYS_GENERIC_GLOBAL_DATA.

Signed-off-by Simon Glass <[email protected]>

Enable this for sandbox so that we will be able to use driver model before relocation.

Signed-off-by Simon Glass <[email protected]>

Tun on DEBUG in malloc(). This adds code space and slows things down but for sandbox this is acceptable. We gain the ability to check for memory leaks in tests.

Signed-off-by Simon Glass <[email protected]>

There has been talk on and off of a pre-relocation malloc() implementation. Driver model needs this so that it can work before relocation.

A previous implementation was sent in a v1 series.

This implementation works by allocating space on the stack. The benefit is that boards do not need to specify the address of the malloc() area, only the size. The down-side is that due to the way board_init_f() is called, architecture-specific code needs to be used to allocate the space.

No clever algorithms are used to allocate space, free() is a nop and realloc() is not supported. This fits well with the desire to avoid wasting space on bucket tables and the hassle of supporting BSS data before relocation. We don't expect 'churn' in the pre-relocation case - we just want to allocate small amounts of memory temporarily.

After relocation a new malloc() pool is created and the old one is lost, although pointers into it will survive the immediate process of relocation.

Implementations are provided for sandbox and arm (32-bit only).

A related change is made to the early init for each arch to make this work.

Quoted 19 lines · Simon Glass

There has been talk on and off of a pre-relocation malloc() implementation. Driver model needs this so that it can work before relocation.

A previous implementation was sent in a v1 series.

This implementation works by allocating space on the stack. The benefit is that boards do not need to specify the address of the malloc() area, only the size. The down-side is that due to the way board_init_f() is called, architecture-specific code needs to be used to allocate the space.

No clever algorithms are used to allocate space, free() is a nop and realloc() is not supported. This fits well with the desire to avoid wasting space on bucket tables and the hassle of supporting BSS data before relocation. We don't expect 'churn' in the pre-relocation case - we just want to allocate small amounts of memory temporarily.

After relocation a new malloc() pool is created and the old one is lost, although pointers into it will survive the immediate process of relocation.

Quoted 3 lines

Implementations are provided for sandbox and arm (32-bit only).

A related change is made to the early init for each arch to make this work.

My concern without a fix right now is how to make use of this in SPL, when we're able to move SPL over to using still more generic code rather than re-inventing the board_init_{f,r} wheels, in the case where we init DRAM.

Hi Tom,

Quoted 22 lines · Tom Rini

Quoted 19 lines · Simon Glass

There has been talk on and off of a pre-relocation malloc() implementation. Driver model needs this so that it can work before relocation.

A previous implementation was sent in a v1 series.

This implementation works by allocating space on the stack. The benefit is that boards do not need to specify the address of the malloc() area, only the size. The down-side is that due to the way board_init_f() is called, architecture-specific code needs to be used to allocate the space.

No clever algorithms are used to allocate space, free() is a nop and realloc() is not supported. This fits well with the desire to avoid wasting space on bucket tables and the hassle of supporting BSS data before relocation. We don't expect 'churn' in the pre-relocation case - we just want to allocate small amounts of memory temporarily.

After relocation a new malloc() pool is created and the old one is lost, although pointers into it will survive the immediate process of relocation.

Quoted 8 lines

Quoted 3 lines

Implementations are provided for sandbox and arm (32-bit only).

A related change is made to the early init for each arch to make this work.

My concern without a fix right now is how to make use of this in SPL, when we're able to move SPL over to using still more generic code rather than re-inventing the board_init_{f,r} wheels, in the case where we init DRAM.

One option would be to split this new code out into a separate file, and have two malloc() implementations:

- big one - falls back to small one pre-relocation
- small one - used for SPL

Hi,

Quoted 37 lines · Simon Glass

Hi Tom,

Quoted 22 lines · Tom Rini

Quoted 19 lines · Simon Glass

There has been talk on and off of a pre-relocation malloc() implementation. Driver model needs this so that it can work before relocation.

A previous implementation was sent in a v1 series.

This implementation works by allocating space on the stack. The benefit is that boards do not need to specify the address of the malloc() area, only the size. The down-side is that due to the way board_init_f() is called, architecture-specific code needs to be used to allocate the space.

No clever algorithms are used to allocate space, free() is a nop and realloc() is not supported. This fits well with the desire to avoid wasting space on bucket tables and the hassle of supporting BSS data before relocation. We don't expect 'churn' in the pre-relocation case - we just want to allocate small amounts of memory temporarily.

After relocation a new malloc() pool is created and the old one is lost, although pointers into it will survive the immediate process of relocation.

Quoted 8 lines

Quoted 3 lines

Implementations are provided for sandbox and arm (32-bit only).

A related change is made to the early init for each arch to make this work.

My concern without a fix right now is how to make use of this in SPL, when we're able to move SPL over to using still more generic code rather than re-inventing the board_init_{f,r} wheels, in the case where we init DRAM.

One option would be to split this new code out into a separate file, and have two malloc() implementations:

Quoted 2 lines

- big one - falls back to small one pre-relocation
- small one - used for SPL

I'm thinking of applying this to the dm repo now, except for the arm patches where I would like to get Albert's ack (so I'll wait a few more days).

Any objections?

Quoted 43 lines · Simon Glass

Hi,

Quoted 39 lines · Simon Glass

Hi Tom,

Quoted 22 lines · Tom Rini

Quoted 19 lines · Simon Glass

There has been talk on and off of a pre-relocation malloc() implementation. Driver model needs this so that it can work before relocation.

A previous implementation was sent in a v1 series.

This implementation works by allocating space on the stack. The benefit is that boards do not need to specify the address of the malloc() area, only the size. The down-side is that due to the way board_init_f() is called, architecture-specific code needs to be used to allocate the space.

No clever algorithms are used to allocate space, free() is a nop and realloc() is not supported. This fits well with the desire to avoid wasting space on bucket tables and the hassle of supporting BSS data before relocation. We don't expect 'churn' in the pre-relocation case - we just want to allocate small amounts of memory temporarily.

After relocation a new malloc() pool is created and the old one is lost, although pointers into it will survive the immediate process of relocation.

Quoted 8 lines

Quoted 3 lines

Implementations are provided for sandbox and arm (32-bit only).

A related change is made to the early init for each arch to make this work.

My concern without a fix right now is how to make use of this in SPL, when we're able to move SPL over to using still more generic code rather than re-inventing the board_init_{f,r} wheels, in the case where we init DRAM.

One option would be to split this new code out into a separate file, and have two malloc() implementations:

- big one - falls back to small one pre-relocation
- small one - used for SPL

Quoted 5 lines

I'm thinking of applying this to the dm repo now, except for the arm patches where I would like to get Albert's ack (so I'll wait a few more days).

Any objections?

I think we'll be OK. I checked over the callpath again on OMAP parts and we setup DDR prior to _main (in SPL) so we'll be fine.

Hi Tom,

Quoted 48 lines · Tom Rini

Quoted 47 lines · Simon Glass

Hi,

Quoted 34 lines · Simon Glass

Hi Tom,

Quoted 22 lines · Tom Rini

Quoted 19 lines · Simon Glass

There has been talk on and off of a pre-relocation malloc() implementation. Driver model needs this so that it can work before relocation.

A previous implementation was sent in a v1 series.

This implementation works by allocating space on the stack. The benefit is that boards do not need to specify the address of the malloc() area, only the size. The down-side is that due to the way board_init_f() is called, architecture-specific code needs to be used to allocate the space.

No clever algorithms are used to allocate space, free() is a nop and realloc() is not supported. This fits well with the desire to avoid wasting space on bucket tables and the hassle of supporting BSS data before relocation. We don't expect 'churn' in the pre-relocation case - we just want to allocate small amounts of memory temporarily.

After relocation a new malloc() pool is created and the old one is lost, although pointers into it will survive the immediate process of relocation.

Quoted 8 lines

Quoted 3 lines

Implementations are provided for sandbox and arm (32-bit only).

A related change is made to the early init for each arch to make this work.

My concern without a fix right now is how to make use of this in SPL, when we're able to move SPL over to using still more generic code rather than re-inventing the board_init_{f,r} wheels, in the case where we init DRAM.

Quoted 5 lines

One option would be to split this new code out into a separate file, and have two malloc() implementations:

- big one - falls back to small one pre-relocation
- small one - used for SPL

I'm thinking of applying this to the dm repo now, except for the arm patches where I would like to get Albert's ack (so I'll wait a few more days).

Quoted 4 lines

Quoted 1 line

Any objections?

I think we'll be OK. I checked over the callpath again on OMAP parts and we setup DDR prior to _main (in SPL) so we'll be fine.

OK, I'll prepare a pull request for the ARM-related malloc() patches soon, along with the GPIO things (sandbox only at this stage as we need to make progress on applying exynos patches first).