Re: [U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation
Hi,
On 28 July 2014 06:16, Simon Glass wrote:
> Hi Tom,
>
>
> On 23 July 2014 14:41, Tom Rini wrote:
>> On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote:
>>> Hi,
>>>
>>> On 14 July 2014 18:16, Simon Glass wrote:
>>> > Hi Tom,
>>> >
>>> > On 14 July 2014 16:28, Tom Rini wrote:
>>> >>
>>> >> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
>>> >>
>>> >> > 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.
>>> >>
>>> >> 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
>>>
>>> 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.
>
> 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).
I haven't heard from Albert or Minkyu so will go ahead with this plan.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation
Hi Tom,
On 23 July 2014 14:41, Tom Rini wrote:
> On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote:
>> Hi,
>>
>> On 14 July 2014 18:16, Simon Glass wrote:
>> > Hi Tom,
>> >
>> > On 14 July 2014 16:28, Tom Rini wrote:
>> >>
>> >> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
>> >>
>> >> > 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.
>> >>
>> >> 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
>>
>> 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.
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).
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation
On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote:
> Hi,
>
> On 14 July 2014 18:16, Simon Glass wrote:
> > Hi Tom,
> >
> > On 14 July 2014 16:28, Tom Rini wrote:
> >>
> >> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
> >>
> >> > 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.
> >>
> >> 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
>
> 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.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation
Hi,
On 14 July 2014 18:16, Simon Glass wrote:
> Hi Tom,
>
> On 14 July 2014 16:28, Tom Rini wrote:
>>
>> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
>>
>> > 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.
>>
>> 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
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?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation
Hi Tom,
On 14 July 2014 16:28, Tom Rini wrote:
>
> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
>
> > 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.
>
> 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
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation
On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
> 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.
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.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation
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. 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 - Rebase on earlier patch - Put the two CONFIG changes together in sandbox.h Changes in v2: - Tidy up commit message typo Simon Glass (9): Remove form-feeds from dlmalloc.c arm: Set up global data before board_init_f() sandbox: Set up global data before board_init_f() Add a simple malloc() implementation for pre-relocation arm: Support pre-relocation malloc() exynos: Enable pre-relocation malloc() sandbox: Support pre-relocation malloc() sandbox: config: Enable pre-relocation malloc() sandbox: Always enable malloc debug README| 16 arch/arm/include/asm/config.h | 2 + arch/arm/lib/crt0.S | 12 ++ arch/sandbox/cpu/start.c | 8 arch/sandbox/include/asm/config.h | 1 - common/board_f.c | 12 ++ common/board_r.c | 4 ++ common/dlmalloc.c | 85 --- include/asm-generic/global_data.h | 5 +++ include/configs/exynos5-dt.h | 4 +- include/configs/sandbox.h | 4 +- lib/asm-offsets.c | 3 ++ 12 files changed, 129 insertions(+), 27 deletions(-) -- 2.0.0.526.g5318336 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
