Even though we only need 32 bits here, clang warns that we should be
using a "w" register in the inline assembly (which is not legal with
mrs/msr). Silence the warning by declaring the value as unsigned long.
(cherry picked from commit a0de5d88dfc67b3ba34c0455b1619e12e6cfccae)
Add a few more #defines for the status register
Tweak the FPU context switch to not rewrite the entire status register,
which may not be a generally safe thing to do.
Updated comment regarding clobbers on the SBI call.
Tweak a boot time print of SBI version.
Add a commented out line to the do-qemuriscv to assist in dumping future
device trees.
Move the mmu_initial_mapping from platform into arch/x86. For this
architecture the default mappings are basically hard coded in arch/x86
anyway, so move ownership of this data there, closer to where it's
actually initialized.
Update the 32 and 64bit paging code to properly use the paddr_to_kvaddr
and vice versa routines.
Update to allocate page tables directly from the pmm instead of the heap
(on 32bit code).
Clean up the x86.h file a bit with how constants are defined
Switch rdtsc to builtin
Added all of the known bits for the main CR registers.
Move the invlpg macro over to the common header.
Update comments in start.S
Trim the arch mmu unit tests accordingly.
Should probably switch this to a #define, but it's possible some of
these queries could be dynamically detected (XN for example). May
revisit at some point.
-Large cleanup of both the 32 and 64bit mmu code. Still the same general
flow but tighten up usage of mixing physical addresses with virtual
addresses.
-Remove the PAE code path from 32bit mmu, which was unused.
Allow asking the arch layer if it supports NX pages or NS pages.
Have the arch mmu test code test accordingly.
Also tweak the tests to pass on arm32 mmu, which does not precisely
match the return semantics of the rest of the mmu routines on map/unmap.
Some of the 16 bit values the cpu pushes on the stack are aligned to
32bit offsets but actually only 16 bits were pushed. Make sure printf
masks off the top 16 bits when printing these fields out.
Save the model/family information in a new structure.
Move the printing portion of the detection to the arch_init runtime
so it gets a chance to print after the uart is initialized.
Turns out all of the in and rep ins/outs instruction macros have been wrong
since they were first added.
-Make sure they clobber memory
-Make sure edi/esi/ecx registers are marked as both read and written by
the instruction.
The latter was causing a codegen problem in the ide driver where the
pointer was pushed forward by a rep ins but the compiler didn't know the
register was modified.
Parse up to 16 pmm arenas from the multiboot memory data structure. Roll
the 32bit code to properly trim at 1GB as before, but using new logic.
Remove conditional checks on WITH_KERNEL_VM in x86 code, which only
really compiles with the mmu and the vm on.
-march=x86-64-v2 is not supported on old compilers.
Can fix in the future, but for the moment may as well just drop -v2
since it's not really being used.
Change the early startup code to set TCR_EL1.IPS to
ID_AA64MMFR0_EL1.PARange if it has a defined value (the currently
defined values have the same meanings), but use 48-bit PAs if 52-bit
PAs are supported because 52-bit PAs have a different translation
table format that we don't support. Stash the computed TCR_EL1 in a
variable and use it in the context switch code.
Based on building with --warn-undefined-variables, find a few places in
the build system where undefined variables were used incorrectly, or
never set due to unused code.
When building fpu variant, use -march=rv64imafdc instead of rc64gc
since some older compilers and/or mainline do not understand the
equivalence when selecting libgcc.
This is only an issue on rv64 due to the need to pick out the medany
variant of libgcc.
Currently only implemented for double precision floating point.
Caveat: currently unable to only compile some code with or without
float. The linker is extremely picky about mixing float and no-float
objects, so stick with all on or off for now.
It's not as much of a problem currently because the toolchain is not
using any riscv vector instructions to assist normal code, so it's
generally only emitting fpu instructions for floating point code.
Have the arch define additional compiler flags to explicit support or
not support a floating point unit.
Add ability for modules to per file or for the whole module mark code
as needing floating point support.
Add default flags for arm64, riscv, and x86 toolchains.
Needed because gcc 12 is getting much more aggressive about using vector
instructions for non float code, so getting away with avoiding it was
no longer working.
Still not perfect: printf code is being compiled with float, so it's
possible to use floating point instructions inside core kernel or
interrupt handling code if a printf is used.
Possibly will have problems on architectures where mixing float and non
float code at the linker generates issues, but so far seems to be okay.
I noticed that LK failed to boot on systems that do not support 64KB
page sizes (e.g. Linux KVM guest on Apple M1) because the trampoline
translation table used a compile-time hardcoded 64KB page size.
Instead of trying to make the trampoline translation table code
look for a supported page size at runtime, I realized that it should
be possible to remove the trampoline translation table entirely by
replacing it with a VBAR that branches to the instruction following
the MMU enable. That's what this patch does.
Add cache clean + invalidate on the page tables that get modified during
startup before the MMU is enabled. Without this, if these memory regions
were present in cache before LK started, the CPU will see the stale
cached values as soon as the MMU is enabled. Invalidating these forces
the CPU to fetch the correct values from memory after the MMU is enabled.
This works around an issue with newer compilers that default to an
earlier ISA spec that doesn't by default include the zicsr extension by
default.
If the compiler doesn't support the switch, then it's assumed that it
has the extension by default, as older gcc compilers did.
If we were booted at EL2 (e.g. when passing -machine
virt,virtualization=on), we need to use SMC instead of HVC for PSCI
calls. Change psci_call() to do this and add a flag to do-qemuarm to
allow testing this scenario.
Port to the really neat 68010 based board at https://rosco-m68k.com/
Port Features:
-10Mhz 68010
-1MB ram
-Dual UART + timer implemented as a 68c681 chip
-timer running at 1Khz, UART A for console
-interrupt driven RX support
Some amount of extending of the 68k exceptinon code was needed to
support the autovectored irqs that the 68681 uart uses. Added build
system support for 68010.
It is possible for early initialization functions such as lk_main()
to contain NEON instructions because we don't build the kernel with
-mgeneral-regs-only. As a result we can end up taking an FPU exception
before we are ready to handle it.
We didn't have this problem when starting at a higher exception level
than EL1 because we turned off FPU traps in arm64_elX_to_el1(). But we
neglected to do so when starting at EL1. Fix the problem by moving the
CPACR_EL1 manipulation out of arm64_elX_to_el1() and into arm_reset().
Previously was hard coding the instructions to work around a limitation
of the assembler that did not allow using fpu instructions when the code
was being compiled without support. Move the zeroing routine into a
separate assembly file and override the architure at the top.
Much of the start.S path avoids using these registers up until now to
avoid trashing any state, but its getting fairly difficult and error
prone to keep this up. Save the args as soon as its known that its the
boot cpu in a temporary place prior to calling lk_main. Wastes 32 bytes
of memory but should be more solid.
It's called immediately upon entering the kernel entry vector, prior
to knowing if it's the boot cpu or needing to save any boot arguments,
so avoid using these registers
