Sadly this doesn't really work in all situations and only happens to
work with gcc + binutils for 32bit accesses, presumably because gnu as
replaces a literal 0 with wzr.
Clang doesn't understand it at all.
This reverts commit 6c14941dec.
When dumping_mode_regs() on a fault, avoid printing the stack beyond the
current page. This prevents exceeding the stack base and hitting a
guard page in the case the stack use is < 128 bytes.
Bug: 336957655
Test: crash test, observe double fault fixed
Change-Id: If49b5fe5e1651557d19bf18c4026224cfb038101
For older compilers (gcc 7.5.0 in particular) avoid using
-mgeneral-regs-only to override the floating point switches, since it
doesn't seem to understand that switch.
Instead more properly add the floating point switches for a module or
source file compiled with float. More compatible with all compilers.
Was already added to arm64, but arch/arm hadn't picked up this feature
yet. Uncovered a few places here or there that wasn't marking code as
float/no-float, but this fixes a problem where newer compilers are
starting to sneak in vector code because they can.
Issue #406
It's just a test routine that's using floating point, but since nothing
in cmpctmalloc should be used in interrupt context, it should be okay to
mark this code as using float.
Some routines inside the sensor bus code in dartuino need floating
point, so put those in MODULE_FLOAT_SRCS.
Also mark app/accellerometer as needing float.
This was the driver that triggered the whole thing, since GCC 14.1 was
starting to use more fancier addressing modes that was causing QEMU to
bomb out when using KVM.
To work properly with some hypervisors on various architectures (ARM,
ARM64, x86), add global routines to allow access to MMIO registers via
architecturally defined accessors.
Add accessors for ARM, ARM64, and x86-32/64. Have the other arches
default to just using whatever the compiler emits.
Will need to generally move things off the legacy REG*() accessors
since they're really not safe going forward with what compilers emit.
The accessing method the compiler is emitting for the *REG32 macros on
arm32 and arm64 is occasionally generating load/stores with writeback.
Though this has worked before, it seems to be rejected with whatever
combination of qemu + linux + hardware on this Raspberry Pi 5.
Convert the register accessors to inline asm that uses basic load/store
instructions, which is really the only correct thing to do now and in
the long run. Add a TODO to move this to reg.h and start to revamp how
registers are accessed across LK, but for now keep it just here to fix
things.
Add a simple test to validate the filesystem APIs that connect the LK
filesystem layer and the virtualIO 9p devices. The test does the same as
`app/tests/v9p_tests.c` to mount the littlekernel codebase folder as the
`/v9p` on the LK filesystem. Then it tries to read the `LICENSE` file
under the codebase and show the first 1024 bytes of the file.
For example:
```
starting internet servers
starting app shell
entering main console loop
] v9fs_tests
0x80017060: 2f 2a 0a 20 2a 20 43 6f 70 79 72 69 67 68 74 20 |/*. * Copyright
0x80017070: 28 63 29 20 32 30 30 38 2d 32 30 31 35 20 54 72 |(c) 2008-2015 Tr
0x80017080: 61 76 69 73 20 47 65 69 73 65 6c 62 72 65 63 68 |avis Geiselbrech
0x80017090: 74 0a 20 2a 0a 20 2a 20 50 65 72 6d 69 73 73 69 |t. *. * Permissi
0x800170a0: 6f 6e 20 69 73 20 68 65 72 65 62 79 20 67 72 61 |on is hereby gra
...
```
Signed-off-by: Cody Wong <codycswong@google.com>
- Add the file operations APIs for VirtIO 9p devices, such as file
create/open/close/read/write/stat.
- After this commit, almost complete file operations for v9p file
sharing are supported. An intuitive example is that users can use
filesystem commands, such as `ls`, to examine the shared folder.
Example:
```
# Build the littlekernel with the current directory (the codebase) as
the shared v9p folder
$ scripts/do-qemuarm -f .
...
welcome to lk/MP
boot args 0x0 0x0 0x0 0x0
INIT: cpu 0, calling hook 0x8011fa81 (version) at level 0x3ffff,
flags 0x1
...
# Mount the default VirtIO 9p device `v9p0` as the 9p filesystem onto
# `/v9p` path
] fs mount /v9p 9p v9p0
# List the `/v9p` folder, and we can see the littlekernel codebase
] ls /v9p
D 4096 arch
F 590 lk_inc.mk.example
D 4096 .cache
D 4096 project
D 4096 .github
D 4096 platform
D 4096 kernel
D 4096 external
F 1132 LICENSE
D 4096 target
D 4096 dev
D 4096 .git
F 120 .gitignore
F 12579 engine.mk
F 1388 README.md
D 4096 make
D 4096 top
error -2 opening file '/v9p/..'
D 4096 build-qemu-virt-arm32-test
F 763965 compile_commands.json
D 4096 scripts
D 4096 lib
D 4096 app
D 4096 docs
D 4096 .
D 4096 tools
F 1113 makefile
```
Signed-off-by: Cody Wong <codycswong@google.com>
- Add the directory operations, e.g., open directory, make directory,
read directory, and close directory.
Signed-off-by: Cody Wong <codycswong@google.com>
Add the fundamental filesystem structure to attach a VirtualIO 9p
device. With the implementation of VirtIO 9p devices (lk/dev/virtio/9p),
we can use those APIs to connect to a shared folder as a LK filesystem.
Signed-off-by: Cody Wong <codycswong@google.com>
With this change printf passes the fuchsia unit tests, except the lack
of field with and precision support. Disabled those parts of the test
for now.
Original change at
https://fuchsia.googlesource.com/fuchsia/+/db61af0d1fc27c4c807f5da7d0553a4bb422882b
The old code used to pad the output with zeros before the 0x,
so you would end up with a 0000000x10. This is not the intended
behavior.
Original author: pedro.falcato@gmail.com
The fuchsia printf unit tests are a derivative of the current LK ones in
app/tests, but have been somewhat expanded. Pull in the new copy and add
it to the new libc test module.
No real functional change, just following the pattern of moving unittest
code into a sub module that is picked up by the build system when
WITH_TESTS is set.
Some of the recent refactoring may cause some of the inner error codes
to be eaten or misinterpreted. Restructure fread/fwrite to handle these
a bit more gracefully.
There's some careful use with ssize_t vs size_t here to try to deal with
negatves values properly.
Three platforms had basically duplicated logic that just was pulled into
the fdtwalk library. Fix these up to call into those routines instead.
-qemu-virt-arm
-qemu-virt-riscv
-jh7110 (visionfive 2 soc)
Instead of one large routine that takes a list of optional callbacks,
build some helper routines that do the work that a few platforms have
implemented on their own to share some code between them.
Future enhancements: move some of the helpers out of this library into
the library that implements the thing it's helping with (ie, PCI
bringup, bootstrapping arch specific cores). For now just leave them in
helper.cc which is conditionally compiled.
Update libfdt from https://github.com/dgibson/dtc at revision
855c934e26aeadb5bab878d1b148090af2480c90
Source is verbatim except moving headers into an include directory added
to the path.
Using 2-clause BSD option.
This reverts commit 37c3228443.
Decided it's probably not worth maintaining this and simply removed this
particular build combination (clang 13 + riscv) from the build matrix.
-Don't try to compile any riscv targets on gcc 7.5.0 which is a bit too
old to deal with any of the newer ISA extensions.
-Stop building UBSAN on 7.5.0 builds since that's not particularly
useful.
