[coreboot] ARMv8 prototype in simulator failing at payload_load()

[tmiket]

Julius,
I appreciate the background on the API change and the pointer
to what to fix in the code.  I have stubbed out the soc chip operations
and now am letting coreboot know that there is a region of dram.
The simulation train continues.
Cheers,
T.mike

On 2016-10-13 14:30, Julius Werner wrote:
> You need a call like ram_resource(<any device node>, 0, <start of DRAM
> in KB>, <size of DRAM in KB>); somewhere in ramstage... e.g. as in
> src/soc/rockchip/rk3288/soc.c. Even if you're running on an emulator,
> you'll still have to decide on a memory range that you want to be your
> emulated DRAM so that coreboot knows where it can put stuff.
> 
>> Can anybody comment on this suspicion, as well as why the check is 
>> enabled
>> for payload load but disabled for bl31 load?
> 
> This was a recent change that became necessary to support a special
> case... before that, the check was always mandatory. The memory
> allocator situation is a little ugly on non-x86 devices since they
> usually have separate SRAM and DRAM areas. The resource allocator was
> written for x86 and only meant to dynamically track DRAM (and
> non-memory) resources in ramstage. On non-x86 devices it became
> necessary to handle SRAM allocations in earlier stages and we invented
> the static memlayout.ld mechanism. The two don't really talk much, and
> thus the ramstage resource allocator doesn't know about SRAM (we
> should probably try to improve that, but as usual, it's a little
> tricky in the details and nobody has the time right now). We needed
> BL31 to be loaded through the same mechanism as the payload, but some
> platforms want to place (parts of) it in SRAM... so we had to hack out
> the usable memory check for it to get it to work. You can see some of
> the original discussion in
> https://chromium-review.googlesource.com/c/376849/.