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