- Make the secondary entry point be logically separate function, though
declared in the same file.
- Add a trick where the kernel base + 4 is the secondary entry point.
Not really useful except makes it easy to compute the offset
elsewhere.
- Changed the entry point to arm64_reset and move _start to the linker
script, which is what most other arches do.
- While was in the linker script, make sure the text segment is aligned
on MAXPAGESIZE, though doesn't make any real difference currently.
- Generally clean up the assembly in start.S with newer macros from
Fuchsia, and avoid using ldr X, =value as much as possible.
- Fix and make sure arm64 can build and run with WITH_SMP set to false.
Add a new no-smp project to test this.
Note this will likely break systems where all of the cpus enter the
kernel simultaneously, which we can fix if that becomes an issue.
Secondary code now completely assumes the cpu number is passed in x0.
This can be emulated with platform specific trampoline code if it needs
to that then just directs into the the secondary entry point, instead of
trying to make the arch code have to deal with all cases.
- Add a percpu structure for each cpu, akin to x86-64 and riscv. Pointed
to by x18, which is now reserved for this in the kernel. Tweaked
exception and context switch routines to leave x18 alone.
- Remove the cpu-trapping spinlock logic that is unused in mainline,
probably. (Can add a new version of it back if it's necessary).
- Switch fdtwalk helper to using the newer, cleaner way of initializing
secondaries using the PSCI CPU_ON argument that should be pretty
standard on modern implementations. (Possibly an issue with old
firmware).
- Remove the notion of computing the cpu ID from the Affinity levels,
which doesn't really work properly on modern ARM CPUs which more or
less abandoned the logical meaning of AFFn.
- General cleanup of the driver a bit
- Aadd a boot time message that prints the version
- Add the argument field to CPU_ON
- Pass the cpu number through from fdtwalk library
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
