The original tooling is lost to the mists of time and long-discarded
workstations, but this generates identical results and will enable
updating the code on the m0 sub-processor going forward. Yay.
The xxd tool generates two spaces of indent, not four.
Fix this existing file to match the tool output to make it easier
to detect changes to the resulting image header when rebuilt.
Instead of compiling each .c or .cpp or .S file into an equivalent .o file,
map it to a file with .c.o or .cpp.o extension.
IE,
foo.c -> foo.c.o
bar.cpp -> bar.cpp.o
Reason for this being that if you change the suffix of a file it'll
automatically pick it up and recompile.
-Add support for probing SBI extensions
-Switch to newer versions if present
-Add HBM extension which allows proper secondary cpu bootstrap
-Add support for secondary bootup via HBM.
Turns out that in some cases we can't really rely on a particular boot cpu id
so go ahead and simply dynamically assign cpu numbers by having each cpu
increment an atomic number in the very top of start.S. The first one in gets
the worm.
In a two segment binary was previously trying to use MAXPAGESIZE set to 4
to cram the sections in very tight for embedded. This seemed to with this
toolchain cause the linker to get confused and sometimes appear to stuff in
an extra 4 bytes in the output file, thus misaligning the data segment.
It's possible it's still a bug on my side in the linker, but setting
max_page_size to 8 seems to work around it for now. Possible there's some
implicit 64bit aligning slipped in a stage somewhere in binutils thats
causing it to get confused. Either way, 8 byte alignment is no large loss
here.
Previous to now it had always relied on a custom patched gcc
and a custom sim. In the interim since the initial port went in
some time in 2015 GCC and QEMU have both officially picked up support
for the architecture and the machine that was emulated in the previous
emultor.
Using gcc 10.2 fix up the build and get it basically working. Timers
seem to not be working right but it's probably fairly easy to fix.
Just an itch that has bothered me for a while. Current time is not
strictly speaking platform specific though it's usually associated
with platform code. Move it into its own header and add some text
to explain a bit whats going on.
Add some more comments for other headers while in there.
Using the RTC1 module for the LK tick (instead of arm systick)
Use the nrf_hal library for peripheral manipulation instead of
direct register access. Fixed race condition in current_time_hires
which would result in non monotonic readings.
Tested with clock_tests on:
nrf52-pca10040-test (nrf52832)
nrf52-pca10056-test (nrf52840)
1) Decode FSC and dump more human readable status
2) Add support of stack unwinding as referred from
arm64 procedure call standard and frame pointer usage.
3) Compiler options for not omitting frame pointer
are enabled to ensure usage of frame pointers even
with higher optimization levels enabled.
Signed-off-by: vannapurve <vannapurve@google.com>
Since the i2c driver is optional (not required for platform) the
i2c_init should be done during target initialization. The flags
used to include the i2c driver should be in either target or project
files so it makes sense that the i2c_init should also be called from
target files.
When the nrf52xxx platform was changed to use the Nordic nrfx
libraries the pca10040 target was broken due to differences in
how the platform handled initialization.
In a previous patch, on architectures where SMP is disabled,
thread_pinned_cpu() will always return a negative number. GCC 10.2
is somewhat more aggressive about negative shift values so it wasn't
detecting that the second path of an if statement is never taken.
Solution is to cache the pinned cpu value and use it for both the
test and the operation.
This change ensures that during thread scheduling
only needed cores are woken up as per the thread's
CPU affinity rather than all cores. This would avoid
un-necessary wakup for other cores from lower power
states without having to execute anything.
Signed-off-by: vannapurve <vannapurve@google.com>
All shipping ARMv7-R processors include VFPv3-D16, a subset of VFPv3
with only 16 double-precision registers. The first -R profile CPU
with a complete VFP or NEON implementation is the Cortex-R52,
implementing ARMv8-R.
LK's context switch code had a dynamic check and would only save
d16-d31 if present, but gcc/gas will not assemble code that includes
references to d16-d31 when mcpu=cortex-r4f or other v7-R CPUs.
Ideally we'd key the #if off of __TARGET_FPU_VFPV3_D16, but that
only appears to be defined by the ARM compilers, not gcc. Use
V7-R as the key instead.
Using Nordic's nrfx driver for the clock control peripheral since
it address a handful of errata and abstracts some differences
in the nrf52 family of parts.
Platform gpio driver now uses the nrfx library for gpio manipulation.
This allows utilization of second gpio bank present on some parts
and handling of errata.
Use twim(i2c) driver from nrfx library. See comments and patterns in
target/nrf-pca10056 for info on how to properly utilize driver as it
requires some GLOBAL_DEFINES and gpio defines.
From working with -Wpacked its clear that some of the virtio
structures are overly packed and result in bad codegen on particular
architectures such as riscv. Roll back from using packed but
statically assert that the sizes are correct for some future arch
where things naturally pack differently.
Mostly just a few warnings where things are promoted via passing floats to
printf. Those we should generally remove anyway because they're just
benchmarking code. Most things LK runs on either doesn't have float or
doesn't have double sized floats.
