[U-Boot] early_malloc outline

[Tomas Hlavacek]

Hi Graeme,

On Wed, Aug 1, 2012 at 4:57 AM, Graeme Russ <graeme.russ at gmail.com> wrote:

> More specifically, we must not assume that we have a single, contiguous
> region of memory capable of holding pre-relocations early stack,
> pre-relocation global data, pre-console buffer, and early (pre-relocation)
> heap.

Agreed.

>
> Forget about 'locked cache lines' - That is only important when considering
> when to call enable_caches(). The cover the generic case (which covers all
> architectures) we simply need to keep in mind that enable_caches() can only
> be called _after_ the early heap has been moved to the final (SDRAM) heap.
> Therefore, we must keep in mind that any code which manipulated the early
> heap into the final heap is going to be performance-hindered.

Yes. And actually there might be platforms or boards that do not need
early_malloc for DM and since there are no other users yet we might
want to switch it off completely not to waste memory and CPU cycles on
initialization etc.

>
>> Pavel Hermann said that we would have to copy data twice (first before
>> the RAM is up and running and caches are still off and second after
>> RAM and dlmalloc is initialized).
>
> I think I understand why now - The idea is to blind-copy the early-heap
> into SDRAM, enable caches and then process the early heap into final heap.
> This _may_ provide a performance bonus on _some_ (most) cases

Exactly. But we are a bit afraid of this copy-twice process. In fact
in meantime between relocation start and second copying finish DM
would be inactive (DM tree will be unavailable, therefore it is going
to be impossible to use drivers through DM etc.)

> OK, I'm going to go out on a long and thin limb here (i.e. look out for
> daft ideas) and say that all we need before relocation and final heap
> initialisation is an early stack and an early heap (no global data or no
> pre-relocation buffer as they are currently implemented). What! I hear you
> say :)
>
> Well, why can't we put global data and pre-relocation buffer _on_ the early
> heap? Yes, it will be a bit tricky as there is some very early code (in
> assembler) that reads/writes to/from GD, but if GD is placed at the top of
> the heap, it's members can still be directly referenced.

Well, since I am new to U-Boot development and I have not even managed
to read and understand line-by-line or better
instruction-by-instruction the early init code for all architectures
except for ARM yet, I am not be able to appreciate nor understand all
implications nor implement this idea. But I can prepare the
early_mallocator for this by using  by using your frame header struct
early_heap_info and by implementing heap list traversal into
early_malloc().

(But it may be considered as dead code now, because without any
working early_sbrk() it would add extra complexity without any
benefit. And I am certainly not the right person who could attempt
making such a deep changes to borad_init_f, move GD to early_heap
etc.)

> And as for the question of fixing up pointer in the structures allocated on
> the early heap, that is entirely up to the user of the early heap as only
> they know what the contents of the structures mean.

Exactly. And I will blind-copy only used early_heap, not the whole
early_heap in order not to waste space and CPU cycles.


Thanks,
Tomas



-- 
Tomáš Hlaváček <tmshlvck at gmail.com>