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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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.

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

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?

> Pavel Herrmann

Amicalement,
-- 
Albert.