I took a novel approach here. I didn't want to duplicate any config. I realized since this is just a Makefile, we can use the include directive.

These magic values were copied from the X230 config.

make rule syntax is:

targets : prerequisites
        recipe
        …

Where a "target" is a path to a file that needs to exist. So, we create two targets for mrc.bin and me.bin with recipes that run the corresponding blob scripts. And we make the Coreboot build target (defined elsewhere) depend on these blob targets.

Since a target is a path to a file, if the blobs already exist (e.g., user-supplied blobs), make will skip these recipes.

See: https://www.gnu.org/software/make/manual/make.html#Rule-Syntax

This value for the CBFS size is arbitrary. Originally, I had totaled the size of all binary blobs, subtracted that from the T440p's ROM size (12 MiB), and used the remaining space as the CBFS size (~11.68 MiB). However, this caused very long RAM initialization times (courtesy of cbmem -t). And, an anecdote in https://groups.google.com/a/chromium.org/g/chromium-os-reviews/c/lUqRrGUoEBY/m/ka7L1f2BS8gJ suggested that this value needs to be a power of 2.

So, I picked a size I expected our Linux payload to fit into that was a power of 2 that I also expected would leave enough space in the ROM for the IFD, ME, GbE, and Coreboot.

Now, it takes less than a second for RAM initialization after flashing/first boot (anecdotally, it seems the MRC needs to be "trained?").

I have the impression that your initial CBFS_SIZE value might have been good, but not matching ifd defined region).

Ifd needs to be modified to take output of neutered ME size while ME region needs to be reduced under ifd, and the freed space added to BIOS region there. That BIOS size would become the size of cbfs region under coreboot config from memory, but will have to find traces again which I was unsuccessful finding last time.

Will try to find that information back since it needs to be part of the porting guide as well.

I have the impression that your initial CBFS_SIZE value might have been good, but not matching ifd defined region).

Ah, okay, this makes sense. I ran me_cleaner on my original ROM again and then used ifdtool to dump the IFD regions:

$ python me_cleaner.py -S -r -t -d -O out.bin -D ifd_shrinked.bin -M me_shrinked.bin ~/projects/t440p/t440p_original.bin 
. . .
$ ./ifdtool -f layout.txt ifd_shrinked.bin && cat layout.txt
00000000:00000fff fd
00021000:00bfffff bios
00003000:00020fff me
00001000:00002fff gbe

Putting this into a notepad (using Soulver), I determined the size of each region and that there is 1 byte of padding between each region:

So maybe 0xBDEFFF is the maximum CBFS size? I will recompile, flash, and see. It would be cool if we could automate this math.

Update: 0xBDEFFF did not work. RAM initialization times are back up. ☹️.

@rbreslow I finally joined coreboot channel and posted my question directly to them here: https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$N_Nh4qJeU9gquoE9tzjeERYzsxgYB6j79uB6uvnoPdM?via=libera.chat&via=matrix.org&via=foss.wtf

@rbreslow I finally joined coreboot channel and posted my question directly to them here: https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$N_Nh4qJeU9gquoE9tzjeERYzsxgYB6j79uB6uvnoPdM?via=libera.chat&via=matrix.org&via=foss.wtf

icon on coreboot channel answered. Excerpt:

icon:
it's not end - start but end - start + 1
but that's not why it's slowing down. I assume with the bigger size, not everything in CBFS can be cached
there's CAR (cache as RAM) at 0xff7c0000..0xff7effff. this is used to store data before the DRAM is up
the BIOS region is mapped directly below 4G (0x100000000). so making CBFS too big, it could even conflict with CAR
I don't think this can be changed without also changing the MRC blob
so the best option is really to set CBFS_SIZE to 8MiB
one could still make the rest of the BIOS region available with a custom FMAP. only not as part of CBFS

I replied:

Interesting. Has no impact on ivy/sandy which extends cbfs region to reuse all liberated space from ME (11.5mb for heads maximized boards). But yet again, native ram init there.
Misalignments increased boot time in the past, but those were linked to tpm measurements problems (increasing boot time by 50 seconds, but also on older versions of coreboot).

Then icon replied:

yes, CAR is in 0xfefe0000..0xfefeffff for SNB
that's DCACHE_RAM_BASE/_SIZE in Kconfig btw.
oh, actually it's bigger

nic3-14159 added:

Side note, IIRC the coreboot build system rounds CBFS_SIZE down to 64KiB boundaries

@rbreslow Can you adjust the calculations and test with new CBFS? Might be a limitation of the MRC blob on which we might need to accept caching time (and document properly under board config as current limitation)

@tlaurion Here are my cbmem logs from the CBFS_SIZE set 0xBDEFFF: https://gist.github.com/rbreslow/50b45e538437dd10f9e2bf51abd260de. What size would you like me to try now?

So maybe 0xBDEFFF is the maximum CBFS size? I will recompile, flash, and see. It would be cool if we could automate this math.

Basically, the right calculation is taking output of ifdtool -f layout.txt path/to/ifd_output_from_me_cleaner_on_fullrom_backup.rom and parsing the BIOS region, substracting end address to begin address.

@rbreslow Seems like xx30 and xx20 might have been off all along. Redoing.

Without this, neither Qubes OS nor the Qubes OS installer would start. Presumably, because we're "kexecing" from an already running kernel, we need this set at the Coreboot level? Testing revealed that including intel_iommu=igfx_off in the CONFIG_BOOT_KERNEL_ADD board config option did nothing. And, the Qubes OS default boot option already contains intel_iommu=igfx_off.

See:

• https://www.qubes-os.org/doc/installation-troubleshooting/#not-asking-for-vnc-because-we-dont-have-a-network--x-startup-failed-aborting-installation--pane-is-dead-error-during-installation
• https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/intel-igfx-troubleshooting.md
• https://www.kernel.org/doc/html/v5.10/x86/intel-iommu.html?highlight=igfx_off#graphics-problems

Exactly. Otherwise the iommu is configured incorrectly since first kernel boot would try to isolate Intel iommu and the kexec'ed kernel would not be able set differently.

Coreboot defined kernel option defines Heads behavior.