Bump to version 1.5.1 from
https://github.com/raspberrypi/pico-sdk
6a7db34ff63345a7badec79ebea3aaef1712f374
All code verbatim with the exception of the removal of CmakeList.txt
files and a tweak to platform.h.
More code is using it, so try to build a more standardized version of
it. For now, since most of the defines that are needed are similar to
lk/compiler.h, mostly reimplement in terms of those.
The context switch is now always performed inside the PendSV handler,
which greatly simplifies the code by reducing all switches to a single
path. This should also eliminate any race conditions during the switch.
Because we always enter PendSV for a switch, there is a slight
performance penalty in the case of switching from a non-preempted thread
to another non-preempted thread (~40 cycles longer on an M4, compared to
the previous implementation)
It will be removed in a upcoming CL, so remove it now so the future CL
cleanly applies.
Bump the major number of the structure in case there's a tool somewhere
that uses it.
-Reinitialize the uart bit modes
-Ignore framing/break errors on receive. Unclear why they seem to always
be set in the fifo, but seems to be safe to ignore for now
-Make sure platform_pgetc returns the right error code
-Initialize the output ports to all gpios
-Hard set the spinlock type to uint32_t to be clearer
-Switch the free/held value to a simple 0 or 1
Previously, was writing the current cpu number into the spinlock, which
was only useful for debugging purposes. However, since the atomic
operation was an amoswap instead of a proper CAS, it would end up
overwriting the old cpu number with the new cpu number when it tried to
take it. It would still work as a spinlock, since the value was !0, but
it was falsely tracking which cpu actually held it.
To keep it simple, just switch to 0/1 and stick with the amoswap
instruction, which is much more efficient than a LR/SC pair to implement
CAS on riscv.
Internally still use an unsigned long for the old value, since the
amoswap instruction overwrites the entire Rd register, and thus keeps
the codegen efficient since it wont try to sign extend it for any
comparisons afterwards.
Thanks @loqoman (darwin.s.clark@gmail.com) for catching this one.
Need to move `size_t i` into the correct location. Also, set the
CONSOLE_OUTPUT_TO_PLATFORM_PUTC define in the module makefile.
Change-Id: I732ebbcc43219806d5dfd3b9bdd28bf1811248dc
dw/mw and the sister commands take virtual address as input for display
or modify. Option "-p" to the command signifies the address input is
physical, and the address translation is handled by the command.
Newly added option is available with WITH_KERNEL_VM, usage as follows
] dw 0xffffffff05100000 4
0xffffffff05100000: 0000dead
] dw 0x5100000 4 -p
0xffffffff05100000: 0000dead
Signed-off-by: VAMSHI GAJJELA <vamshigajjela@google.com>
Introduces a flag which allows a project to disable the default output
to platform_dputc. This is useful is the project wants to maintain
`platform_dputc` for panic conditions but otherwise use a registered
callback for console io.
Change-Id: I1362529a6bb40d191ac3f7c6069985c371d9284c
Currently, the compilation rules are mostly duplicated for normal vs
float vs ARM source files. This fix deduplicates the compilation logic
for these different "mode" of source files by using make's
Target-specific variable functionality.
https://www.gnu.org/software/make/manual/make.html#Target_002dspecific
This change was tested by using
[`bear`](https://github.com/rizsotto/Bear) to generate a
compile_commands.json file. The file was generated both before and after
the change and the json diff'd to ensure the generated compile commands
were not changed.
Change-Id: Id472045cc2e65bf542dfbf0ff52089be224c9d13
Certain projects may want to prevent the usage of certain modules from
being used. Here are two examples of when this may occur:
1. The Project has it's own fdt library and does not want developer's
using the version of libfdt included with LK
2. The project does not want developers using mincrypt.
`DENY_MODULES` is a list which developers can set in their own project
makefiles which is checked on each module inclusion. If that module is
on the deny list, it causes a build failure.
The wrong placement of the increment for index `i` causes an unexpected
behavior, which the `strncpy` writes an extra '\0'.
For example:
The `src` string is "abc". The buffer size of `dest` is 5.
When we call `strncpy(dest, src, 5)`, the first `for` loop copies the
characters, 'a', 'b', and 'c', to the `dest[0:2]`. In the 4th iteration,
however, the `for` loop breaks due to the termination of `src` whereas
the value of `i` stays 3. At the moment, it has copied 4 bytes,
including the '\0' of `src`.
In the second `for` loop, we have `i = 3` and `count = 5`, so the loop
copies two more '\0' to the `dest`. As a result, the `strncpy` copies 6
bytes to the `dest` buffer, leading to buffer overflow.
Fix the issue by increasing the index `i` before every copy.
Signed-off-by: Cody Wong <codycswong@google.com>
Precisely set bits [55:22] of the vaddress in bits [43:0] for the vae1is
and vaee1is TLBI commands.
On platforms where FEAT_TLL is implemented, bits [47:44] of the command
accept a TTL parameter which can optionally be set to hint the
translation table level containing the address being invalidated.
Implementations aren't architecturally required to perform the
invalidation if the hint is incorrect however. Invalidations may
therefore fail with the current implementation if the vaddress has bits
set in [58:55].
This is notably an issue on ARM fastmodels which doesn't perform the
invalidation when the TTL parameter is incorrect.
When building with clang -mcmodel=medany and linking with ld.lld, we get
out-of-range relocation errors for undefined __start_<section> symbols
since 0 cannot be represented as a PC-relative offset). This is not a
problem with ld.bfd since ld.bfd rewrites the instructions to avoid the
out-of-range PC-relative relocation. For now, the simplest workaround is
to build with -fpie -mcmodel=medany (thus indirecting these symbols via
the GOT). This will be done automatically once clang includes
https://reviews.llvm.org/D107280.
Without this change I get the following linker errors:
ld.lld: error: dev/driver.c:21:(.text+0x1E): relocation R_RISCV_PCREL_HI20 out of range: -524295 is not in [-524288, 524287]; references __start_devices
See https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/126 and
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/201.
We have to compile RISC-V code with -mno-relax when linking with ld.lld
since ld.lld does not yet support RISC-V linker relaxations. Without this
change, linking with ld.lld results in many errors such as:
`relocation R_RISCV_ALIGN requires unimplemented linker relaxation`.
This support was implemented as part of LLVM 15, but to support older
versions of ld.lld we add the flag unconditionally for now.
Clang's assembler rejects expressions containing e.g. (1u << N) in the
assembler. Instead using numeric expressions for per-privilege level
CSRs, we can prepend `m` or `s`. This also lets the compiler assign the
CSR encoding instead of having to hardcode it in the source code.
The current code results in
`error: invalid reassignment of non-absolute variable 'isr_stub_start'`.
Use a numbered label instead (as that can be reassigned) and reference
the last occurrence using the b suffix.
We should build with -ffreestanding since we are building an OS kernel and
cannot rely on all hosted environment functionality being present.
Specifically this fixes a compilation error with clang caused by the
the #include_next <limits.h>:
```
In file included from target/pc-x86/config.c:9:
In file included from dev/include/dev/driver.h:10:
In file included from lib/libc/include/sys/types.h:10:
In file included from lib/libc/include/limits.h:5:
In file included from /usr/lib/llvm-15/lib/clang/15.0.7/include/limits.h:21:
/usr/include/limits.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
#include <bits/libc-header-start.h>
```
The flag fixes this issue by ensuring that __STDC_HOSTED__ is no longer set
to 1, so Clang's limits.h will not try to include the host system one.
This only builds a subset of all targets for now since the remaining
ones (32-bit targets) would require libgcc/compiler-rt for the 64-bit
integer and/or double-precision float helper functions.
Currently, only aarch64 targets build with clang, but with follow-up
this can be extended to include x86_64 and RISCV64.
CC, LD, etc was already settable by the environment, but not by
local.mk, since they were assigned in engine.mk as :=. Change the set to
be conditional to fix this.
Clang incorrectly diagnoses msr operations as need a 64-bit operand even
if the underlying register is actually 32 bits. Silence this warning.
There are quite a few occurrences of this warning so I opted to add the
-Wno-flag instead of wrapping all callsites in
`#pragma clang diagnostic ignored -Wasm-operand-widths`.
Currently, clang does not support the -Wno-nonnull-compare and
-Wmaybe-uninitialized warning flags so this adds lots of unknown warning
flag output for each compile job when not using GCC.
This commit adds a makefile macro to check for supported warning flags
and only adds them if the compiler actually supports them.
Clang does not accept this .if condition since phys_offset is a register
alias and not an absolute expression. We can keep these two instructions
here if the argument is zero since the result will be the same.
Additionally, this macro is only called once and always passes a non-zero
argument. If more calls are added in the future and avoiding these two
instructions just before a loop is really important, we could use
`.ifnc \phys_offset,0` instead, but that looks rather obscure to me.
