returninfinity/pure64

Pure64 is a kernel/software loader for x86-64 systems.

pure64's Issues

Configure and activate the IO-APIC

Manual gives incomplete information regarding e820 table

The manual stats the following regarding the e820 memory map at address 0x4000: Each E820 record is 24 bytes in length and the memory map is terminated by a blank record.

The records actually are 24 bytes in length, but are padded out to 32 bytes

riscv64 Support

Riscv64 is a 64-bit architecture, aimed at taking over the server market.

Pure64 should support this architecture.

Switching File System to FAT32

The internal file system used by Pure64 works well, but FAT32 will need to be used to create UEFI compatible boot partitions. The internal file system should be switched to FAT32, so that two file systems are not simultaneously maintained.

Decreased binary size

The current Pure64 binary is padded to 6KB but only uses about ~4600 bytes. A good goal for file size would be 4KB.

Could Pure64 fit on a floppy disk? (maybe 2.88 MB if can't to 1.44 MB)

Even today the floppies are still being used, for example - as virtual floppies inside the coreboot open source BIOS. Just imagine: your wonderful OS could be a part of someone's BIOS build! (for coreboot supported motherboard, maybe you have or could get one - see https://www.coreboot.org/Supported_Motherboards )

If you already have a coreboot-supported motherboard, or a real chance to get one, - wouldn't it be cool to be able to launch your own OS straight from the BIOS chip? ;) With one simple command its possible to add any floppy to coreboot BIOS build - and then you see it as a boot entry! Multiple floppies could be added this way (as long as you have enough space left inside the BIOS flash chip, luckily LZMA compression could be used for the stored floppies to reduce their occupied size)

will hang up when rebooting the 3rd time

running in qemu, the os can only be rebooted 2 times using the reboot command without qemu virtual machine being powered off. the third time of rebooting will cause the system hang up in 'starting the kernel ...'.

also, it seemed cpu counter is not reset, causing cpu number keep increasing across reboot.

Missing mbr.sys

When running my build.sh, I receive the message dd: failed to open 'bin/mbr.sys': No such file or directory. The docs don't mention how it should be built(at least I couldn't find it) and I couldn't find any file with a name like 'mbr.sys', 'mbr.asm', or similar within the master branch.

Any help would be appreciated.

Also: I received a warning from nasm regarding line 351 in pure64.asm about a label without a colon. I assume the line should be retf instead of retfq, correct?

Question about ROM area

What's the purpose of the ROM area?

Writing software?

Apologies for the ignorance but the site isn't clear enough for the less informed on this topic. But how is software written and loaded into Pure64?

We use assembler? a specific compiler output?
Possible to port already existing tools?

Thanks

VESA mode setting

Ideally to "native" resolution of the screen if possible. Also, configured as a linear frame buffer.

Feature Request: Support for other file systems (especially FAT32 and NTFS)

I would recommend having Pure64 to have FAT32 support as it is currently the most widely used filesystem. Maybe you can also support NTFS?

Fail to load 32KB kernel

when set the size of the kernel to 32k
and add a magic number at the end

;; set the size & the magic number
   times (32 * 1024) - ($-$$) - 4 db 0x90
   ;times (26 * 1024) - ($-$$) - 4 db 0x90

   ;; 4 bytes magic number
   dd 26881h

and let the bootloader load a just a little more,
and let the bootloader check the magic number above,

and make the following change to Pure64
(to copy more and check the magic number too)

; Move the trailing binary to its final location
    mov rsi, 0x8000+6144        ; Memory offset to end of pure64.sys
    mov rdi, 0x100000       ; Destination address at the 1MiB mark
    ;mov rcx, 0x0D00            ; For up to 26KiB kernel (26624 / 8)
        mov rcx, (32*1024)/8        
    rep movsq           ; Copy 8 bytes at a time

    ;mov eax, dword[1*1024*1024 + 26*1024 - 4]
        mov eax, dword[1*1024*1024 + 32*1024 - 4]
    cmp eax, 26881h         ; Match against the kernel binary
    jne magic_fail

       ; ...
   magic_fail:
           mov rsi, msg_MagicFail
           call os_print_string
           hlt

   msg_MagicFail:  db "pure64 magic fail", 13, 10, 0

one will find that
the checking of the magic number in the bootloader could pass,
but the checking of the magic number in pure64 will fail,

but when set the size of the kernel back to 26k,
both checking of the magic number will pass,
and the kernel runs fine.

!!!

so it is the copy in the pure64 that fail !
but how can this happen ?!

I see why now!
pure64 write to 8000h+26k -- 8000h+32k
before it copy the 32k to 1M

please delete this issue
I can load more know
and I will suggest a way to other users of you to load more in issue #11

Pure64 fails to compile

Hi!
I'm trying to compile Pure64 using nasm 2.11.08 on ubuntu 16.10 using the build.sh script.
This fails with

uefi.asm:322: warning: label alone on a line without a colon might be in error
uefi.asm:270: error: invalid combination of opcode and operands

Is there any known fix to this?

Thanks!

Loading PE Files, Again

PE support was dropped in the last release. It needs to be added again. Since Pure64 has the ability to run on Windows, it makes sense to support this format that are used by many Windows tools.

ELF64 loading

Currently Pure64 can start a flat binary as well as parse a PE header. Add code for parsing an ELF64 header.

Multiboot 2

Feature PE kernel loading

In order to boot into a PE file we need to compute its RVA by parsing the PE headers.

After doing a quick signature check:

; PE loader header check
    mov eax, [0x10003c]             ; Get the e_lfanew value which is the address of the PE header (32bit).
    mov bx, word [eax + 0x100000]   ; The PE header signature is here.
    cmp bx, word 'PE'               ; Compare the PE header signature to make sure it matches.
    jne normal_start                ; If it isn't equal jump to the normal starting address

to verify it is a PE file, we parse the header to get to AddressOfEntryPoint field and add it to ImageBase field (it should be set to 0x100000 in the linker settings of the compiler):

; PE loeader starting address (RVA) parsing
    add eax, 0x100028               ; Add size of PE header (24 bytes) and offset to
                                    ; AddressOfEntryPoint (16 bytes) to image base  0x100000
    mov ebx, [eax]                  ; AddressOfEntryPoint added to ImageBase to get entry point addreess
    add eax, 0x08                   ; Add the offset to get the ImageBase
    add ebx, [eax]                  ; Add ImageBase to AddressOfEntryPoint (ebx)

    xor rax, rax                    ; Clear rax; rbx has the jump location so don't clear it.

Finally we just need to jmp

pe_start:
    jmp rbx                         ; rbx has the compute RVA for the jmp

normal_start:
    xor rax, rax                    ; We can clear rax and rbx again
    xor rbx, rbx
    jmp 0x0000000000100000

In summary just replace line 625 in pure64.asm with:

; PE loader header check
    mov eax, [0x10003c]             ; Get the e_lfanew value which is the address of the PE header (32bit).
    mov bx, word [eax + 0x100000]   ; The PE header signature is here.
    cmp bx, word 'PE'               ; Compare the PE header signature to make sure it matches.
    jne normal_start                ; If it isn't equal jump to the normal starting address.

; PE loeader starting address (RVA) parsing
    add eax, 0x100028               ; Add size of PE header (24 bytes) and offset to
                                    ; AddressOfEntryPoint (16 bytes) to image base 0x100000
    mov ebx, [eax]                  ; AddressOfEntryPoint added to ImageBase to get entry point addreess
    add eax, 0x08                   ; Add the offset to get the ImageBase
    add ebx, [eax]                  ; Add ImageBase to AddressOfEntryPoint (ebx)

    xor rax, rax                    ; Clear rax; rbx has the jump location so don't clear it.

pe_start:
    jmp rbx                         ; rbx has the compute RVA for the jmp

normal_start:
    xor rax, rax                    ; We can clear rax and rbx again
    xor rbx, rbx
    jmp 0x0000000000100000

Graphics mode

Start the system in graphics mode and ditch text mode.

This is required for UEFI as there is no text mode anymore. A linear frame buffer should be configured on bootup and that information (memory address, resolution, color depth) should be stored in the infomap.

The BareMetal kernel should start in a serial I/O mode by default. Alloy can then take over the b_output* syscalls.

Times negative

When i build pure64.sys, nasm reports a error about the times function (line 841). The count is negative.

New Fs

1. Ext4 is faster than Fat12, Fat16 and Fat32.
2. Ext4 supports 16 Terabyte files and 1 Exabyte volumes.
3. Fat32 only supports 4 Gigabyte files, and 8 Terabyte volumes. (And the rest of the File Allocation Table Versions are even lower)
4. Extended filesystems has higher file and volume capacity than File Allocation Tables.
5. Also, Extended filesystems beats File Allocation Tables in speed.

Check out ZFS, it is even better then all of them. Source:
https://en.wikipedia.org/wiki/Comparison_of_file_systems

Ability to configure VESA mode on startup

Would also need to save the value across reboots.

Something like holding down 'Space' on bootup to get to a config menu would be ideal. Similar to the BeOS loader.

x2APIC support

Support x2APIC for computers with more than 256 CPU cores.

Non-text graphics mode support.

It would be nice, if it'd be possible to specify the graphics mode you need. Pure64 can easily use BIOS interrupts for that, but a kernel loaded by it must support the graphics card to do it.

Update pxestart.asm

It needs to switch to 32-bit mode.

Memory Map - `BSP_IP` is a 16 bit value (not 32 bit)

I've just been poking at the Info Table at 0x5000, and discovered while mapping it to a struct that BSP_ID is a 16 bit value. The address/offset is correct, but the width is incorrect in the documentation.

Meaning of an address

Hello,
What is the purpose of address 0x000b809c? I have hard time thinking it is video address.

Thanks

Disable hardware cursor (still shows on some systems)

Ability to load more that 26KB

Read the payload to memory while still in 16-bit mode (Switch to Unreal mode involved).

mips64 Support

While I don't know of any cheap hardware to test this on, QEMU has an emulator for it.

Loading Position Independent Kernels

Pure64 should be able to load position independent kernels. This will make it easier for kernel developers to support multiple architectures (some of which contain very different memory layouts.)

AP's fail to start on 16-core AMD system

Halts at '3 58'. This is right before the APs are started in smp.asm. The most likely issue is the RTC interrupt is not firing. Verify interrupts are working before proceeding with AP initialization.

Elaborate a bit about the IDT when Pure64 is used

From what I've seen in BareMetal's source, Pure64 sets up some kind of IDT starting at memory address 0.

I've tried various things, and none of them work. It would be VERY helpful if there a document somewhere explaining how this works.

UEFI compatibility

Need to investigate what is required to boot with UEFI.

How to get the memory map?
Is a GPT (instead of MBR) partition format needed?
Where are the ACPI tables?

Easiest method is to use GRUB and load a multiboot file.

There is no text mode in UEFI! Graphics are required.

Setting Up Partition Information

Since Pure64 parses GPT structures, it should be able to pass the partition offsets and sizes in the information structure. This information can be used by kernels to avoid overwriting partition data.

aarch64 Support

64-bit ARM systems would be good to support. It would be neat to support the Raspberry PI 3, or Pine64 boards.

Custom Bootsector

If, for whatever reason, that the boot sectors that come with Pure64 do not work as desired, allow for a custom boot sector to be added. It would look something like this in the config file.

bootsector: custom
bootsector_path: "./path/to/bootsector.sys"

PXE booting is broken

Tested in VirtualBox.

Support as coreboot payload

Please, add support for building as ELF coreboot payload http://www.coreboot.org/Payloads