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.
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
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
coreboot mailing list: email@example.com