Folks, Prior to hardware being available I am getting a headstart on coreboot using Trace32 in simulator mode.
Most of the SOC support is stubbed out, e.g. dram initialization.
I can extract the COREBOOT CBFS partition from coreboot.rom using cbfstool and load this file along with bootblock.elf into T32.
I can step from bootblock to romstage to ramstage, look at console output in memory, etc.
This call in ...src/lib/prog_loader.c:payload_load() fails:
/* Pass cbtables to payload if architecture desires it. */ prog_set_entry(payload, selfload(payload, true), cbmem_find(CBMEM_ID_CBTABLE));
payload_targets_usable_ram() follows this path: /* Payload segment not targeting RAM. */ printk(BIOS_ERR, "SELF Payload doesn't target RAM:\n"); printk(BIOS_ERR, "Failed Segment: 0x%lx, %lu bytes\n", ptr->s_dstaddr, ptr->s_memsz);
If I disable the check in call to selfload, I can step into bl31. Interestingly bl31 is loaded with selfload() with the check disabled.
My suspicion is that some underlying resource structure is not initialized correctly with my dram info, because I'm skipping all of the basic initialization and the simulator doesn't care.
Can anybody comment on this suspicion, as well as why the check is enabled for payload load but disabled for bl31 load?
Since the boolean parameter is part of the selfload() api I'm trying to understand the history here. Cheers, T.mike
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/.
-
Julius Werner -
tmiket