[U-Boot] early_malloc outline

Wolfgang Denk wd at denx.de
Wed Aug 1 21:09:10 CEST 2012


Dear Tomas,

In message <CAEB7QLCieZFKpam2TumS3Gqb=5McLVuFHm_PXbZfyVPDNWHNZw at mail.gmail.com> you wrote:
> 
> > It is difficult (or actually impossible) to answer this, if you do not
> > explain which concept you are talking about here, or why two copy
> > operations would be needed, what "in case of DM" means (and which
> > other cases exist), or how you intend to handle the problem of
> > changing addresses (and thus pointers becoming incorrect) for each of
> > such copy operations.
...
> Other guys working on DM wants AFAIK to create DM tree using
> early_malloc inside board_init_f(). The tree is going to have root and
> on some boards few extra elements, like 2 or 3 in this phase and each
> object has 16 bytes. Then they want to have this tree accessible (or
> at least a copy of the tree) in board_init_r(). They want to traverse
> the tree (by recomputing pointers) at some point in board_init_r(),
> allocate new tree objects using dlmalloc and copy the data into the
> new tree.

Hm... I have to admit that I am not really happy about such an
"explanation".  The statement that "other guys" want something is not
exactly an explanation of a concept that I can understand, and without
being able to understand it, I don't buy it.

Please do not assume that everybody has followed all (or any) or your
previous discussions on the DM list.  Please assume I have zero prior
knowledge about that stuff (which is about correct), and explain what
the concept is.  And please keep in mind that any time you write
"I/they want", I will wonder "why?", and probably we lose time in
another iteration because I will actually ask this question.

> The concept I am thinking about is reserving space for early heap
> right after GD by same platform specific means (i.e. subtracting
> CONFIG_SYS_INIT_SP_ADDR). Then I would like to reserve space in RAM

You are mixing design and implementation here.  Where exactly this
storage space is located, and how youcreate it etc., is implementation
details.  We should ignore this here.

> equal to used size of early_heap before relocation and memcpy the
> existing early_heap there (the same way GD are copied). Therefore we
> would have a copy of used early_heap in RAM and we can recompute
> pointers to traverse the tree in board_init_r().

But why would 2 copies be needed?  I understand then once regular
malloc() becomes available, you want to make sure all allocations are
maintained using this mechanism.  But I already wonder how you are
going to implement this - you will have to update all pointers.  How
will you find out where these might be?

Assume something like:

item *foo(...)
{
	static item *foo_local = malloc(size1);
	...
	return foo_local;
}

item *bar(..., item **ptr)
{
	static item *bar_local = malloc(size2);
	...
	*ptr = bar_local;
	return bar_local;
}

void some_function(...)
{
	item *x, *y;
	...
	x = bar(..., &y);
	baz(y);
	...
}

How will you later know which variables store the values from the early
malloc calls, and how will you access these for proper relocation?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is mind?  No matter.  What is matter?  Never mind.
                                      -- Thomas Hewitt Key, 1799-1875


More information about the U-Boot mailing list