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

[Pavel Herrmann <morpheus.ibis@gmail.com>]

Hi

On Thursday 27 of December 2012 09:59:07 Albert ARIBAUD wrote:
> Hi Pavel,
> 
> > Technically, the patch was quoted whole, but it goes on top of another,
> > that added the DM and early heap macros to the board config, so its of
> > no use as it is.
> 
> Ok, so IIUC this patch is not required for fixing anything in the
> current mainline u-boot, and would not break anything in mainline
> u-boot either, but is required to arrange pre-relocation memory mapping
> for current DM code to work.

Essentially yes, except it would not apply without the first patch. if you 
applied both to mainline, then nothing would hapen (some space would be 
allocated for the early heap, that would never get used), as you dont have any 
DM code there, so it would be just a useless defined macro.

> > > Based on the assumption that this patch is complete as quoted, and on
> > > your comments above, my comment would be (to both Marek and you) why do
> > > you nead a heap during flash-based inits?
> > 
> > We want the DM to replace most of the board-specific code (by providing a
> > "driver" that is configured by board-specific values, essentialy
> > encapsulating common init code independently on actual board and memory
> > layout), so that the board-specific init only loads required drivers with
> > correct parameters, instead of directly initializing the hardware (there
> > was a thought of having a RAM driver, that would init the main memory
> > when loaded, and provided relcation as a method/service, not sure if we
> > want to go this far at the moment).
> > for this we need the DM to run in early (flash-based) phase. The DM itself
> > cannot work without a heap, so we need one there.
> 
> Well, for lack of understanding of DM (I know DM documentation is out
> there, just haven't had time to look it up so far) I cannot tell
> whether it cannot work without a heap or whether it could work without
> it but hasn't been designed that way.
> 
> This leads to two questions:
> 
> 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.
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

> 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.
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).

Pavel Herrmann