Good day! Unfortunately, a lot of builds are failing with this error,
and it would be nice if you could fix this soon.
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
Dear coreboot developers,
In order to improve the user experience we would like to display a
message on the screen while memory training is in progress. As a first
step, we are working on Alder Lake and Raptor Lake platforms and are
leveraging the `libgfxinit' and VGA text mode. We have libgfxinit
patches for Tiger Lake, Alder Lake (and Raptor Lake) support under
review but this is not the object of this email (see
<https://review.coreboot.org/c/libgfxinit/+/65087> if you are
In the last few weeks, we have been working on a proof-of-concept to
ensure that we could overcome all the technical hardware challenges to
initialize VGA text mode and setup the display before we jump into FSP
Even though we are still working on some stability issues, we have a
"working" but hacky patch :-). But we have an aggressive timeline and
it works good enough that we believe it is time to start an open
discussion as the surface of the patch is important (linker scripts,
configuration flags logic ...). The changes have been reduced to a
unique patch after a lot of clean-up
(<https://review.coreboot.org/c/coreboot/+/69757>). This patch will be
split up in a couple of patches once we are done with some in progress
We identified three majors "issues" for which we are seeking feedback,
guidance or help.
PCI resource allocation
We need to configure the graphics PCI device to perform graphic
initialization. It requires to perform an early romstage PCI resource
allocation. For the proof-of-concept, we assigned the same resources
than the coreboot resource allocator would assign during ramstage. We
cannot leave hardcoded values like these. Any suggestion on how to
cleanly handle early PCI resources allocation ?
Configuration flags and "duplicated"
We had to "duplicate" some configuration flags such as
`MAINBOARD_USE_LIBGFXINIT' as a `ROMSTAGE_MAINBOARD_USE_LIBGFXINIT' for
instance. We want to separate configuration between romstage and
ramstage to offer flexibility to use to have VGA text mode in romstage
without any graphics initialization in ramstage or a graphic
initialization with the GOP driver in ramstage ...
We would appreciate some review and feedback on our clearly not perfect
`Kconfig' changes. Any suggestion is welcome.
libgfxinit and global initialized variables
`libgfxinit' has some initialized global variables ending up in the
Global *initialized* variables are not permitted in cache-as-ram and
with the current `car.ld' linker script I hit compilation link errors
due the following list of variables. Using objdump I collected their
initial value (note that I did not exhaustively checked all the
`[...]_E' ones but only a sample of them).
Address Type Name Value
ffffff60 d `hw__debug__register_write_delay_nanoseconds' 00
ffffff68 d `hw__debug__start_of_line' 01
ffffff2c d `hw__gfx__gma__registers__gtt_32__range_aXnnn' 00 20 00 00
ffffff28 d `hw__gfx__gma__registers__gtt_64__range_aXnnn' 00 80 00 00
ffffff30 d `hw__gfx__gma__registers__regs__range_aXnnn' 00 00 00 00
ffffff6e D `gma_E' 00 ...
ffffff70 D `gma__gfx_init_E' 00 ...
ffffff6a D `hw__debug_E' 00 ...
ffffff6c D `hw__debug_sink_E' 00 ...
ffffff02 D `hw__gfx__dp_aux_ch_E' 00 ...
ffffff04 D `hw__gfx__dp_dual_mode_E' 00 ...
ffffff06 D `hw__gfx__dp_info_E' 00 ...
ffffff08 D `hw__gfx__dp_training_E' 00 ...
ffffff0a D `hw__gfx__edid_E' 00 ...
ffffff0c D `hw__gfx__framebuffer_filler_E' 00 ...
ffffff3a D `hw__gfx__gma_E' 00 ...
ffffff3c D `hw__gfx__gma__combo_phy_E' 00 ...
ffffff00 D `hw__gfx__gma__config_E' 00 ...
ffffff0e D `hw__gfx__gma__config_helpers_E' 00 ...
ffffff10 D `hw__gfx__gma__connector_info_E' 00 ...
ffffff42 D `hw__gfx__gma__connectors_E' 00 ...
ffffff3e D `hw__gfx__gma__connectors__combo_phy_E' 00 ...
ffffff40 D `hw__gfx__gma__connectors__tc_E' 00 ...
ffffff12 D `hw__gfx__gma__display_probing_E' 00 ...
ffffff14 D `hw__gfx__gma__dp_aux_request_E' 00 ...
ffffff16 D `hw__gfx__gma__i2c_E' 00 ...
ffffff38 D `hw__gfx__gma__initialized' 00 ...
ffffff18 D `hw__gfx__gma__panel_E' 00 ...
ffffff1a D `hw__gfx__gma__pch__fdi_E' 00 ...
ffffff1c D `hw__gfx__gma__pch__sideband_E' 00 ...
ffffff1e D `hw__gfx__gma__pch__transcoder_E' 00 ...
ffffff20 D `hw__gfx__gma__pch__vga_E' 00 ...
ffffff22 D `hw__gfx__gma__pcode_E' 00 ...
ffffff24 D `hw__gfx__gma__pipe_setup_E' 00 ...
ffffff48 D `hw__gfx__gma__plls_E' 00 ...
ffffff44 D `hw__gfx__gma__plls__combo_phy_E' 00 ...
ffffff46 D `hw__gfx__gma__plls__dkl_E' 00 ...
ffffff4a D `hw__gfx__gma__port_detect_E' 00 ...
ffffff50 D `hw__gfx__gma__power_and_clocks_E' 00 ...
ffffff4c D `hw__gfx__gma__power_and_clocks__tgl_E' 00 ...
ffffff4e D `hw__gfx__gma__power_and_clocks__xelpd_E' 00 ...
ffffff34 D `hw__gfx__gma__registers_E' 00 ...
ffffff36 D `hw__gfx__gma__transcoder_E' 00 ...
ffffff52 D `hw__mmio_range_E' 00 ...
ffffff56 D `hw__mmio_regs_E' 00 ...
ffffff54 D `hw__pci__dev_E' 00 ...
ffffff58 D `hw__pci__mmconf_E' 00 ...
ffffff5a D `hw__port_io_E' 00 ...
ffffff5c D `hw__time_E' 00 ...
ffffff72 D `hw__time__timer_E' 00 ...
The symbols ending with `_E' are empty and initialized by GNAT generated
code (cf. `___elabs' functions) which is called using the
`$stage_adainit()' function. Therefor, I think it is safe to places
these into the `_bss' region of the `.car.data' section. What I don't
understand though is why isn't the GNAT compiler placing them into the
`.bss' region of the object file. Any idea ? I could not find any GNAT
compiler option for this but I am clearly not an ADA compiler expert
Now we are left with the following symbols:
- `hw__debug__register_write_delay_nanoseconds' is zero so installing it
in the `_bss' region of the `.car.data' section is "technically" fine.
- `hw__debug__start_of_line': Reverting the logic of this boolean makes it work
- The following three symbols are the most challenging ones:
They seem to be entirely by the compiler and I don't know how to
control them. Surprisingly, putting them in the `_bss' region of the
`.car.data' section which is making them zeros is not causing any
apparent issue while their initial value should not be zeros. I am
thinking that these could be used for code verification purposes
only. Does anyone knows before I adventure in to assembly code to
uncover their role ?
/One Emacs to rule them all/
I am Sarthak Rohatgi, a third year student from India. I am very much
interested in Google Summer of Code (GSOC) for 2023, would you be able to
guide me into it?
About myself -
I am Sarthak Rohatgi, currently a 3rd year student pursuing Computer
Science Engineering. I am really passionate about programming and have been
doing it for 4-5 years. I have worked with many different technologies and
GoLang, MySQL, PostgreSQL, WebRTC, WebSockets Bash and more. I did my
Apprenticeship for 1 month from Microsoft and created and deployed multiple
websites on the web. I also have experience in cross-platform development
using Flutter Framework and have developed 3 apps which are in production.
I have been interested in open-source for a long time but haven't had the
chance to get started with it. I would love to know how I can get started
with it and get selected as a GSOC Contributor as well. (Attached Below is
my resume which has all the links including my GitHub, Hackerrank, Project
links, Leetcode, etc.)
Thanks & Regards