| Age | Commit message (Collapse) | Author |
|---|
|
+ Current setup will likely not last long, just a stopgap until I figure
out how I want to build each testcase etc.
Probably dir based, but I'll probably add some scripts that generate
the build rules for each test case (or binary?). Also, should probably
put ouput files in a build directory and keep the source clean, but
again, good enough for now.
Will have to start implementing more extensive tests, and probably
come up with some way to compare textual output etc.
|
|
|
|
+ Took some fairly significant changes, for one the kernel is no longer
relocated at the start of a boot, instead it sits wherever the user
decides the kernel should sit. Similarly, the initial kernel stack and
page table are stored within the binary, slightly bloating the size
but making it much safer to boot since there's really no chance of us
overwriting the fdt or initrd in memory.
|
|
+ I keep starting to type src and wondering why autocomplete won't work,
I guess src is just uncounciously a better name
|
|
+ First part generates deps.mk, second part reads it.
Allows us to use both bmake and gmake with the same makefiles.
Only drawback seems to be that the first makefile considers all
individual files as 'finished' targets, meaning that it's more
difficult to do something like
make kernel.elf
though I haven't found this to be an issue.
|
|
+ User can now specify debug, release and assert handling
|
|
+ Not bootable quite yet. Among other things, I couldn't
get the current starfive u-boot fork to boot, so
try adding support for booting with precompiled u-boot
via the `go` command. Initial testing with qemu shows that
this should be possible, and if it works, might be useful
in the (far) future with other slightly janky SBCs.
Also, NS16550 is 8250-based, and I'm really only using the base
8250, so rename and add visionfive 2 uart to list of compatibles.
Visionfive 2 is still completely untested.
|
|
|
|
|
|
+ Both kind of go hand in hand, made sense to do both at the same time.
Some parts feel slightly hacky, the loader works by placing everything
on the stack and avoiding global values. Still, seems to work?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+ Might be a good idea to add some command line variable as debugging
release mode can be useful for performance profiling (until I start
writing proper serial userspace drivers)
|
|
|
|
+ May warn about PHDR not being in LOAD, there is a flag to silence it
(--no-warn-rwx-segment) but it doesn't seem to exist in
riscv64-unknown-elf for some reason.
|
|
|
|
|
|
+ Essentially, separate root process and remote procedure call handling.
I really should write down some documentation so I don't forget, but
essentially: All threads share a common process virtual memory, and
when a thread wants to make an rpc, it switches over to its own rpc
vmem space that is linked to the remote process.
|
|
|
|
|
|
The output is close enough, and I like that uncrustify is a third-party
tool, so people can install a single tool for formatting instead of
having to lug around a whole toolchain. I fully expect to have to add
settings to uncrustify.conf, but let's see how this goes.
|
|
|
|
+ Next step, start documenting contents of each file.
|
|
+ Completely unnecessary with gmake, but bmake seems to be a little more fussy with runtime dependency generation. No big deal.
|
|
+ GNU make knows how to automatically generate new include files, whereas BSD make apparently doesn't. The solution might be to add in a very simple configure script that just touches deps.mk?
|
|
+ Turns out I had a dumb debugging echo that was messing up my variables. Oh well.
+ I'd still like to get riscv64-unknown-elf-gcc to compile, currently I've only managed with riscv64--netbsd-gcc, weird. Also, I have learned that BSD make doesn't use $< for some reason, so all rules should reference the full file name henceforth. BSD make does use $@, but for consistency I did away with it as well.
|
|
+ Doesn't quite compile all the way unfortunately, building the GNU toolchain on NetBSD is a bit more difficult than I was expecting. LLVM does compile, but fails to link for some reason.
|
|
|
|
|
|
|
|
+ Will most probably not work on 32bit, but nice to make 'portable'
code.
|
|
|
|
|
|
|
|
+ Release mode is sort of broken, as lto doesn't work with linker
relaxation and turning the relaxation off causes issues with the jump
from init to kernel (as I've currently implemented it, could probably
be fixed with a manual jump from assembly, I'll add it to my TODO
list)
|
|
+ Runs a syntax check on all files of the selected arch
|
|
|
|
+ Who knew some reservations were a good thing? (at least relativelyy
speaking)
|
|
This reverts commit 69d13626a37e33f31627a1144605a8fb93684d25.
|
|
+ Not sure if I should go with noinit or init, fuck
|
|
|
|
|
|
Mainly to be used in spinlocks etc.
|
|
|
|
|
