bschnepp / feral Goto Github PK

Having a GUI on top of Feral would be great to port some existing software fairly easily.

Kernel is loaded to lower memory and kept there. Not ideal.

Currently no nice easy way to add more memory, and allocator doesnt do anything yet.

Since the CMake migration (79a9c3a), it appears that the serial driver no longer functions, and COM1 is empty when the kernel finished booting.

Porting to different architectures will be much easier when supporting a common bootloader like uboot.

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.

( 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.

PIC may have weird behavior sometimes. Page faults are currently not hooked. Other events are ignored. PIC also needs remapping.

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.

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.

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.

When using -O0, the kernel gets a bug check where the stack canary value was somehow modified by the serial driver.

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

FERALKER.EFI should also be built alongside FERALKER.NEL, in order to ease an EFI port.

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.

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.

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.

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 pages generated as of right now aren't put together quite cohesively.

Needs some additional testing and validation within qemu and bochs (and eventually, real hardware) so we can be sure this works as intended.

Unable to dynamically allocate and deallocate memory

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.

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.

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.

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.

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.

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

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!

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.

We're dropping a line when pushing up: need to (probably) just rewrite our generic VGA driver entirely.

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.

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.
	

)

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.

There is currently no unit testing framework in place.

Currently does not read ELF sections to find this information.

On a 17z laptop with a Zen 2500U CPU, the keyboard is totally ignored by the kernel.

It appears the PMM has issues with memory ranges, and possibly some other unknown issues.
These should be resolved as soon as possible.

Almost always, if not always, the MmKernelMalloc function returns an area in use by a node for the allocator.

Kernel currently doesn't initialize the APIC, and stays in 8259 compatibility mode.

Need to build system for managing symmetric multiprocessing.
We should categorize based upon some basic hardware details:

• Which CCX is this processor?
• How many SMT threads are supported?
• What other processors does this share L1op, L1data, L2, L3, L4 cache with?
• Latencies between cores? (Do we need NUMA?)

VGA context should be on the heap now, since it's using precious stack space to set up line length, width, colors, etc.

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.

Feral currently does not use the TSS. This should be done in order to properly initialize and use the features of the Zen CPU.

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.