[U-Boot] [PATCH v2 06/12] virt-dt: Allow reservation of the secure region when it is in a RAM carveout.

[Thierry Reding <treding@nvidia.com>]

On Tue, Feb 17, 2015 at 11:55:24AM +0000, Mark Rutland wrote:
> [...]
> 
> > >> This is getting invasive:
> > >>
> > >> If I add carveouts via adjusting memory banks, I need to account for the
> > >> case that an existing bank is split into two halves, creating additional
> > >> banks this way. But then current fdt_fixup_memory_banks will no longer
> > >> work due to its limitation to the number of physical banks. I could
> > >> always add one spare bank to that service, ok, but then the next use
> > >> case for carveouts will hit the wall again. So I better double that
> > >> limit, or so.
> > > 
> > > Yeah, not fun.
> > > 
> > > If the code is position-independent then you might be able to simply
> > > carve out a sufficient proportion from the start of the first entry or
> > > the end of the last one, which would avoid splitting. If either of said
> > > regions are too small for the monitor code then it's questionable as to
> > > whether the OS can make use of it.
> > 
> > The code /seems/ to be position-independent, but locations are so far
> > hard-coded in those places that prepare it and move it around. Maybe we
> > can decide about the location at runtime, maybe we can simply demand it
> > to be at the end or the beginning of some bank.
> 
> If it's possible to do so, it would seem like the nicest option to me.

Using the top of memory for this seems like the most natural choice, so
I think if we restrict ourselves to that for now we should be fine. The
code could probably just get the top of memory from the memory node and
adjust it according to the size specified for the secure monitor.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150219/1d99ae00/attachment.sig>