[U-Boot] [PATCH 3/4] fix memory corruption on versatile

[Albert ARIBAUD]

Hi Pavel,

> > 1) Why does the DM need a heap in the first place? When you look at the
> > DM requirements (as I understand them), they basically include a full C
> > runtime environment, which is precisely what we do *not* provide in the
> > first stage of U-Boot, because this first stage is *meant* to set the C
> > runtime environment up.
> 
> Yes, there are 2 problems (or maybe more) with C in the flash phase - you dont 
> have a heap, and everything except your stack is read-only.

These are not problems, these are initial conditions. The Flash phase
is precisely there to set up the hardware for running C code, so one
simply cannot expect a working C runtime there; and most of the code is
read-only because that's what Flash is about.

> the early heap solves the first issue, and the DM is aimed at solving the 
> second problem, as we avoid using any global data (well, except for the root 
> of DM driver tree, which is in GD), and have everything in per-driver-instance 
> data structures, which are allocated on the heap

Apart from being somewhat simplistically expressed ("problem: there is
no heap; solution: provide a heap"), the first "issue" does not exist
currently in U-Boot: no heap is needed by the code currently running in
the flash phase, only DM apparently needs it. so this first "issue"
only appears because of the solution brought to the second "issue".

As for the second "issue", it already has a solution, the GD, used by
existing code. What makes it impossible for the DM to extend the GD
structure with whatever data the DM must pass from flash to ram phase?

> > 2) Assuming these requirements can be met in a viable way, is this heap
> > supposed to survive through relocation? And if it is, then how will it,
> > and most of all, how will references to it, remain consistent without
> > an ugly manual relocation fixup process?
> 
> the heap is supposed to survive relocation, but only for a little while.

All the more an indication that it may not be needed at all.

> what we do is taht after setting up normal heap (and dlmalloc, instead of the 
> simple malloc we have in the early heap), we order each driver to relocate to 
> a new address. basically we have a "ugly manual relocation fixup process", that 
> is made manageable by dividing it between the individual drivers (as only the 
> driver knows what private data it created during initialization). we have an 
> infrastructure in place that walks the DM driver tree and calls these 
> relocation hooks in a sane order. after this is done, we forget about the 
> early heap (enable caches if it was in locked cache or whatever).

That's awful. I really wish I'd had more time to have a look at the big
picture of DM design earlier, because right now, it makes assumptions
about the available environment that are contrary to U-Boot's and
introduces back manual relocations which I took pains to get removed in
ARM.

So, new question:

1) Why does DM need a heap exactly? Can GD not be used or
adapted instead? How does DM ensure that the flash-based part will
not need more heap than available, and if it doesn't ensure it, How does
it handle overlimit conditions?

2) What are the types of manual relocations that DM requires? Why does
it require them at all?

> Pavel Herrmann

Amicalement,
-- 
Albert.