More definitively set up each cpu's SCTLR_EL1 instead of relying on any
default values being present. Also set all RES1 values to 1 according to
what is useful at the moment, generally giving the maximum amount of
priviledges EL1 and EL0.
The default printf and family will now not implement FPU support, a
second copy of the routines will be generated with the _float suffix.
ie, printf() has no %f support, but printf_float() does.
This is to avoid the default printf from emitting any floating point
instructions when used within core kernel code which has been an off and
on problem for years, especially on architectures that are eager to use
fpu/vector instructions for regular non-fpu code.
If FPU is not implemented on the arch, the *_float routines will alias
to the integer only one.
Perhaps a much more proper solution is to invert this and require every
caller of printf that cannot tolerate fpu codegen (which in mainline is
most of it) use a _nofloat implementation, but this would touch
pratically all printfs in mainline.
This solution acknowledges that for the most part most of the code in
mainline is in-kernel support code, and doesn't need floating point,
except for perhaps some app/* code, which already can opt in.
This solution also can potentially bloat the size of the binary by
having two complete implementations, though I think in practice the
architectures where the extra few KB of code will matter generally dont
have FPU support, or aren't using it. In the latter case the
link-time-gc should remove unused _float routines.
This will generally turn off more FPU codegen, even if its using
software fallback unless the project/target/platform selects a cpu that
has FPU support. This also turns off a few blocks of test code and the
upcoming floating point printf if it's not present on the arch.
This may break projects that were compiling for say cortex-m0 but
expected FPU code to be present. If so it should be pretty easy to
override it, but not going to add that yet unless it's necessary.
- X86 cpuid feature list dump was using the wrong array and walking off
the end of one.
- GICv2 code had a left shift by up to 31 of an integer. Needs to be
unsigned.
- PLIC same as GIC code.
- fdtwalker code should be using a bytewise accessor based helper
function for reading large integers out of an unaliged FDT.
- PCI BIOS32 search code could do a 32bit unaligned read of a string,
switch to using memcmp.
Be a bit more strict about what is accepted into mainline by building
with -Werror set for gcc builds.
Clang builds will get the same treatment soon.
Also turn off some ubsan compiles for some of the older arches where
there's very little value (and it probably doesn't work anyway).
Mostly from the use of ssize_t which does not play well with printf and
32bit arches on LK for underlying type reasons that haven't really ever
been sorted out properly.
The test inside riscv/rules.mk was assuming gcc and that the CC variable
isn't passed in from the user. This is not a very clean solution and
acts like a bandaid over the problem. Added some todos for a potential
solution.
Mostly dealing with comparing a pointer variable that is declared
nonnull, which I find to be a dubious warning but is pretty safe in this
case since the compiler will be more aggressive about the nullness of
the arguments.
This will boot a list of qemu emulated devices with the option to run
all of the unittests at boot.
Will be automatically enabled on the build servers soon which will fail
any pending CLs if it breaks.
This will cause the system to automatically run all of the unit tests
after a short pause on boot. Will be used by an automatic test script.
At the moment there aren't a lot of unit tests in the list, but this
should greatly increase the utility of them since they'll be
automatically run.
Have the unit tests for the FAT driver fail a bit more gracefully if the
test device is not present, to make it somewhat easier to live with this
driver present with systems a way to mount a test volume.
Most of the functions for this was declared in a top level lk/ include
space, so go ahead and move it there.
A few exceptions:
- Moved spin() over to platform/time.h and platform/time.c since the
function more logically belongs to platform/time.h. Any users of
spin() will need to update their headers to include platform/time.h
instead.
- Renamed spin_cycles() to arm_cm_spin_cycles() and moved over into
arm/cm.h since it is currently defined in arch/arm-m and only used for
targets that implicitly are for arm-m.
While waking up all threads from wait-queue, order should
start from tail to maintain correct scheduling sequence.
Signed-off-by: Mahavir Jain <mahavirpj@gmail.com>
Not exactly what we want but avoids the lapic code needing the per cpu
structures which aren't set up without SMP support.
Consider leaving the percpu structure in, just only support for cpu 0.
This fixes trying to boot the X86_LEGACY build on a machine with a local
apic.
Doesn't do much but provided the detection path for it and ability to
hold initialized state. The higher level platform code is going to need
to use it directly so will mostly just provide an api for access to it.
Moved ACPI sniffing back to just after the VM is initialized instead of
all the way into platform_init(). This should try to ensure that all
drivers that come up afterwards will have ioapics discovered in case
future development tries to enable and use them, kicking the machine out
of virtual-wire-mode.
I have a bulldozer machine here that curiously starts the APIC IDs for
the cpus at 16 and counts up.
This is a problem since the current code assumes that the boot cpu is 0,
and would try to start itself (apic id 16) later because it thought it
was the first secondary. Fix this by re-reading the APIC id on the boot
cpu and patching the percpu structure a bit into boot. Kinda a hack but
avoids having to detect the APIC, find the type of ID to read, etc.
Also means that practically speaking the system is using the full 32bit
APIC IDs if that feature is present, since now the local apic id is
entirely read from the local apic as it should be (if present).
Fixes#475
OEMs may want to override certain bio functions, hence mark
`open_block_device` and `open_async_block_device` as WEAK. This allows
OEMs to customize any of the bio functions
Forgot to expand the variable in the call to the TOBOOL function which
would cause the result to always be true. In this case always resulted
in the test code for these three modules to be included.
No real functional change except how the smaller ARCH_DEFAULT_PAGE_SIZE
is now computed and set in defines.h instead of rules.mk for arch/arm to
be consistent with the other arch that has a large/small build (riscv).
