Kconfig, init levels, kernel direct map + early MMIO#17
Merged
Conversation
So that we can implement recursive printf with %pV in the following commit. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Otherwise these become actual symbols that are reflected in the final binary, this is not what we were going for. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
d-tatianin
force-pushed
the
features
branch
17 times, most recently
from
f639cda to
0fd8e73
Compare
This is not needed right now, so let's get rid of it to simplify the code. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
This allows us to have finer control over where data is placed and use more precise page permissions. This also fixes a regression that prevented free-after-init text symbols from being generated as part of the kernel symbols file. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
So that arch-specific linker scripts have to do less code duplication. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
No functional changes here, just less code duplication as we reuse the same helper for all free-after-init sub-sections. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
So that architecture-specific code can reuse it with more ease. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
All the sections like DATA or TEXT are just linker inputs, but for some reason this was different for FREE_AFTER_INIT_TEXT etc. where these contained not only inputs but also the markers. Let's make sure section names only contain the inputs always to make it more intuitive to use. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
To follow the same ordering as other sections. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Runtime modules don't need a link script since they aren't linked at all, the end result is an object file, so it never made any sense to have one. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Multiple reasons: - We don't support any execution modes of arm and x86 other than the 64-bit ones. - Even if we did, execution modes seem to only make the surrounding build script logic a lot more complex for no apparent gain - In the future, if we add support for other execution modes, we will just treat those as separate architectures This also strips any remaining support for i686 and 32-bit arm which is no longer planned. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
There are use cases where using a struct is very bad for ergonomics, so add an ability to get the values inline. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
This adds a new arch-specific arch_try_recover_previous_frame callback, which is a best effort attempt to recover the caller frame. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
The bulk of helpers in x86_64 are arch-agnostic, so move them out to a generic header. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
The bulk of helpers in x86_64 are arch-agnostic, so move them out to a generic header. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Rely on DW_CFA_undefined being defined for us in the arch-specific assembly entrypoint stub, which this patch also adds. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Some of the early kernel allocations are critical and an OOM is not something we can recover from. Add a special helper for those so each such caller doesn't have to roll their own ad-hoc panic. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
This will be used to remap the kernel with proper protections later in the boot process. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
io.c is very much memory related, so it belongs in that subdirectory. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Use actual mapping helpers and an early bump allocation pool to store the firmware strings aside. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Switch to using the compiler driver instead of forcing the use of the linker binary directly, for the following reasons: - CMakeLists was designed to work with compiler drivers, so if we don't do it we're fighting against its design, which is evident from the workarounds that we had to use - Stuff like LTO doesn't even work with the raw linker binary in case of GCC since it requires the plugin as well as a whole bunch of other internal arguments Also fix the issue where target helpers completely bypassed the toolchain argument functions like ultra_target_compile_options. This also makes it so all compile flags are also inserted as the link flags in case LTO is enabled, which is the recommended approach. Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
Signed-off-by: Daniil Tatianin <99danilt@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.