Nico Huber nico.h@gmx.de writes:
Hi Jeremy,
welcome to the mailinglist! It's nice to see libgfxinit working for you and in this special case. :)
On 22.11.22 03:51, Compostella, Jeremy wrote:
In order to improve the user experience we would like to display a message on the screen while memory training is in progress.
I was wondering so far what the use case would be. Thinking about it for a moment, I guess this makes much sense. coreboot users are used to a very quick boot and the memory training takes very long; and will probably take even longer in the future. I could imagine users (even myself) getting impatient and hitting the power button. Is that the reason for the on-screen message?
Indeed this is the main motivation behind this. However, very early graphic initialization opens the door to other feature such as displaying early boot coreboot message for debug purposes ...
How long does the memory training actually take?
It depends on plenty of parameters such as the SoC generation, the type of RAM, the size of RAM, the number of RAM modules ... I have seen it vary from 30s to two minutes over the last 9 years of work of various platform and projects.
Regarding the libgfxinit integration, I don't know if you noticed but I made some progress and I am going to need your help to close on it.
1. Using the static MMIO driver got me rid of the `hw__gfx__gma__registers__{gtt_32,gtt_64,regs}__range_aXnnn' initialized symbols. This is a suggestion you made a long time ago and I am glad I was able to leverage it. 2. I modified two boolean variables of the libhwbase debug module (https://review.coreboot.org/c/libhwbase/+/69854) to make their "default logical value" `False', remove their default value setting and move their symbol to the `.bss' section. 3. I performed the same operation for the remaining variable in libgfxinit (https://review.coreboot.org/c/coreboot/+/69757) 4. Then I am left with elaboration functions only which I noticed are zeros and it allowed to make a "clean" and simple change in the linker script (https://review.coreboot.org/c/coreboot/+/69757/4/src/arch/x86/car.ld#70)
As an alternative to #2 and #3 which I guess is going to be a concern for you (machine checker ...) we could create a variable naming convention which would could used by the linker script to filter symbols in the `.bss' section.
What do think ? Do you have any other suggestion ? Do you think the current implementation/proposal is acceptable ?