bschnepp / feral Goto Github PK
View Code? Open in Web Editor NEWA 64-bit operating system kernel for PCs
License: Boost Software License 1.0
A 64-bit operating system kernel for PCs
License: Boost Software License 1.0
PIC may have weird behavior sometimes. Page faults are currently not hooked. Other events are ignored. PIC also needs remapping.
We'll need a new bootloader to handle initialization of GOP, and some nice things about UEFI.
Multiboot 2 support should be cut pretty soon.
At the moment, the CI script relies upon packages installed on a dedicated host I have lying around.
This needs to be changed so it's easy for others to build, along with setup for automatic testing and validation for functional builds or not.
Kernel currently doesn't initialize the APIC, and stays in 8259 compatibility mode.
Porting to different architectures will be much easier when supporting a common bootloader like uboot.
It appears the PMM has issues with memory ranges, and possibly some other unknown issues.
These should be resolved as soon as possible.
We're dropping a line when pushing up: need to (probably) just rewrite our generic VGA driver entirely.
Some files like kern/entry/mb2entry.c have some issues where they were written with the old style guide, and should be reformatted and fixed to comply with the new style guide.
Most of this is simply making the first letter of a variable uppercase, and some others are changing from snake_case to PascalCase.
Need to build system for managing symmetric multiprocessing.
We should categorize based upon some basic hardware details:
The pages generated as of right now aren't put together quite cohesively.
Commit 17e9d1d introduces a new PMM.
Under kern/mm/createpage.c, there is a possibility that a very big array is allocated (~200MB!!!) on the stack.
The kernel's stack is only 16KiB. This doesn't seem to be causing a fault (somehow) right now, but this shouldn't be possible.
UINT8 ShiftAmt = 3; /* Map 1 bit to 8 bytes at least (2^3) */
while (sz >>= 1)
{
++ShiftAmt;
}
FreeMemory >>= ShiftAmt;
UINT8 map[FreeMemory];
In the case of 6GiB of free memory, this would be FreeMemory = (6 * 1024 * 1024 * 1024) / (8 * 4096), which is many many many times larger than 16384. Naturally, there should be a stack overrun expected here to deal with.
Having a GUI on top of Feral would be great to port some existing software fairly easily.
x86outb might be wrong, or maybe the actual function for moving the VGA cursor is wrong. Something is causing the kernel to not have the VGA cursor move to 4,4 in the test.
Consider construction of a finite state machine to handle processing during idle kernel time, rather than immediately, so interrupts can be re-enabled more quickly
VGA context should be on the heap now, since it's using precious stack space to set up line length, width, colors, etc.
Need to support actually using virtual memory.
VMM should be built up with basic components, primarily as Pager and a Swapper.
The Pager handles actually mapping physical memory into a contiguous, flat virtual address space, whereas the Swapper handles moving those to disk if we were to run out of physical space. The important part is doing the former, as we can dump pages to disk later on.
Feral kernel mode code should be easy to identify: if we're in ring 0, and the bit indicating higher half memory (bit 47 or 48, whichever it is that has to be copied over to the rest of the address space), is 1, then we're in the kernel. Otherwise, user mode pointer. If the rings don't match the pointer (not higher half pointer), do a bugcheck.
There is currently no unit testing framework in place.
In order to have one machine language to rule them all, AML (for ACPI) should be compiled to Forth, and then executed to prepare hardware devices.
This provides a nice layer where the translation layer is unnecessary (many many many examples of RISC hardware just use a variant of OpenFirmware.) It also means we don't have to deal with AML!
Overall, everything is a bit messy with code thrown about all over the place.
Renaming files, reorganizing code, etc. needs to be done to make maintainability and further development easier.
PCI support should be added as soon as possible, so that PCIe support can be added, and then important controllers like an E1000 network controller or an xHCI USB controller and so on can be accessed.
Bug in this function causes the system to double fault (and with no idt, triple fault), as a result of badly handling the function in general. Only works in very specific circumstances.
On a real device (Braswell N3700 CPU), the VGA cursor fails to be moved correctly, instead causing a weird distortion on the screen while typing.
Almost always, if not always, the MmKernelMalloc function returns an area in use by a node for the allocator.
When using -O0, the kernel gets a bug check where the stack canary value was somehow modified by the serial driver.
PMM should be built to use a best fit scheme, such that it's not always just looking for a group of 4KiB chunks to use.
Ideally, we should split up each available physical memory region into 512K sectors, of which we can allocate as small as 4KiB, or the entire 512K section if needed. We can thus be partitioning in terms of 512K blocks (usually owned by the same process), and try to be more compact in allocation. (ie, have some 8KiB blocks and some 16KiB blocks where needed, instead of flat 4KiB chunks.)
Something similar to Linux's Buddy system or something.
The bootloader currently assumes no physical address conflicts with the kernel's expected physical address. This needs to be resolved to support boards that expect that location to be used for operations like DMA.
Since the CMake migration (79a9c3a), it appears that the serial driver no longer functions, and COM1 is empty when the kernel finished booting.
On a 17z laptop with a Zen 2500U CPU, the keyboard is totally ignored by the kernel.
Currently does not read ELF sections to find this information.
At some point, the framebuffer(s) will need to be accessed by the kernel. It would make sense to re-use the page tables UEFI provides, but doing it this way would also allow for flexibility, since we're free to just go ahead and destroy whatever boot structures the bootloader made.
( Related to #8 )
A lot of the older code in place no longer follows the standards used to develop to kernel (snake_case for arch-dependent code, consistent use of prefixes, PascalCase for function and variable names, UPPER_SNAKE_CASE for macros and c #define
constants, but most importantly, always use function prototypes before the first use of the function.
Feral's general entry point (except for multiboot) should be KiSystemStartup, with the kernel environment passed along to it.
The kernel, at this point, should assume that the TLB is correct, and that paging is set up exactly the same as in arch/x86_64/boot/init.asm
(Specifically,
; FFFFFFFFC0000000, which is the full P4, P3, but entry 0 for P2.
KERN_VIRT_OFFSET EQU 0xFFFFFFFFC0000000
section .data
; Store our multiboot pointer.
multiboot_value dd 0
ALIGN 4096
p4_table:
dq (p3_table - KERN_VIRT_OFFSET) + 3
times 510 dq 0
dq (p3_table - KERN_VIRT_OFFSET) + 3
p3_table:
dq (p2_table - KERN_VIRT_OFFSET) + 3
times 510 dq 0
dq (p2_table - KERN_VIRT_OFFSET) + 3
p2_table:
times 512 dq 0 ; Declare 512 entries.
)
Feral currently does not support any ethernet drivers whatsoever.
A basic one to start would be the E1000, as it's common for virtual machines and with plenty of
original hardware available to buy online.
After this, support for the i211 should be supported to support actual ethernet controllers one would find on a real Zen-based computer.
The lines
/* HACK: first and second are sizes.*/
DisplayBuffers[(3 * Iterator) + 0] = CurrentWidth;
DisplayBuffers[(3 * Iterator) + 1] = CurrentHeight;
DisplayBuffers[(3 * Iterator) + 2]
= GraphicsProtocol->Mode->FrameBufferBase;
in the EFI bootloader should be replaced with something much simpler, such as an array of structs with the same information.
Post results of attempting to boot Feral on this machine with the following configuration:
AMD Ryzen 1700X Octa-Core CPU
16GB DDR4 3200Mhz non-ECC unbuffered main system memory
a graphics card
1 serial port (exposed through COM1 on motherboard, presumably through the right port number?)
USB over Bluetooth keyboard and mouse
Needs some additional testing and validation within qemu and bochs (and eventually, real hardware) so we can be sure this works as intended.
FERALKER.EFI should also be built alongside FERALKER.NEL, in order to ease an EFI port.
May need to have a separate entry point after all for EFI version on x86_64.
It would be nice to keep things like the EFI variables around, so that they can be changed, we can mess with the boot order, and I think you can play with the KEK with runtime services..?
Either way, it would be nice so that we don't rely on a BOOTX64.EFI, which is probably going to be fairly annoying for anyone who wants to dual boot.
Unable to dynamically allocate and deallocate memory
Feral currently does not use the TSS. This should be done in order to properly initialize and use the features of the Zen CPU.
Currently no nice easy way to add more memory, and allocator doesnt do anything yet.
There's a ton of code all over the place that's currently not being used, resulting in duplicate code all over the place.
This needs to be refactored.
Kernel is loaded to lower memory and kept there. Not ideal.
Feral currently only builds for the x86-64 Multiboot2 target. Adding support for UEFI/UBoot Aarch64 would be a good step in ensuring compatibility with as many different architectures as possible.
At certain sizes, causes something to happen in which the screen is blanked, but not a triple fault. At others, causes a triple fault. Issue unclear yet, but probably related to overwriting kernel memory.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.