Move the irq registration of the virtio drivers into their init hooks so
the driver is fully working at partition scan time.
TODO: think of a more integrated solution for this. Triggering from the
bio layer, for example.
GLOBAL_CFLAGS will only work for .c files, which breaks on the first
inclusion of the headers by a .cpp file. *_COMPILEFLAGS is for all
language types (C, asm, C++)
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.
The IRQ calculation for the virtio range was off by 8, which caused the
virtio code to override the interrupt registration for the RTC, which
caused it to stop firing. Clean up the #defines that define irq mappings
to fix this issue.
-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.
This allows you to tag your build dirs with an optional string.
Update scripts/buildall to also allow building all release (DEBUG=0)
builds. Add a few other convenience switches.
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.
GCC 12 seems to be much more aggressive about warnings about any
dereferences near 0. For this particular piece of code, which is
explicitly trying to force a fault by touching address 1, simply disable
the warning around the block of code.
Move more of the driver into a proper object oriented model.
Start to build the structure to track open file/dirs so as to
allow multiple open instances share the same underlying object.
