really inspiring to see all progress 
1 Like
After some fighting with PCI interrupt handling (NVMe disk driver seems expecting MSI-X interrupt handling that is not supported yet for riscv64. Also MSI/MSI-X Haiku driver API is currently x86-specific), NVMe disk is working. HiFive Unmatched has NVMe SSD disk slot.
26 Likes
Trying to run emulated PCI ATI Rage 128 Pro graphics card that is supported by both Qemu (-device ati-vga) and Haiku. Crashes for now. I see some suspicious places that seems to be not compatible with 64 bits.
10 Likes
do the old rage ati cards support 64 bit adress spaces ??
Support of 64 bit addresses by graphics card is not required, 32 bit physical addresses can be allocated by PCI resource allocator.
ATI Rage 128 graphics card is working. Adding Rage128_SetDPMSMode(B_DPMS_ON); call was required because monitor is turned off by default. Resolution and bits per pixel change is working. I disabled ramfb driver so no graphics output is produced until app_server is started (on real hardware something similar will be likely occur because u-boot likely don’t have PCI graphics card drivers). Also I fixed a bug when kernel crash if no kernel framebuffer is provided.
23 Likes
I tried to keep ramfb driver and that caused 2 Qemu windows to open: one is ramfb with kernel framebuffer and second is ATI Rage 128 Pro with app_server.
24 Likes
there have been issues with audio drivers and adress space, i mentioned it because it’s one of those issues that have been randomly popping up since the 64b changes were made years ago
EFI boot and SBI timer is working. Page table initialization code was moved from kernel to haiku_loader.efi. u-boot messed interrupt controller (PLIC) and PCI bus so some adjustments was needed. Also u-boot seems to provide wrong memory map: bootServicesData block is not available for memory allocation, it cause physical memory access exception. Provided FDT table seems fine.
u-boot don’t provide GOP framebuffer because Qemu-compatible driver is not implemented. It have simple-framebuffer driver that is supported by TinyEMU, but not Qemu. I currently use PCI ATI Rage 128 Pro video card (-device ati-vga).
haiku_loader.riscv is still working, kernel can work with 2 platforms: riscv and sbi/efi.
@kallisti5 may be interested.
OpenSBI v0.9
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
Platform Name : riscv-virtio,qemu
Platform Features : timer,mfdeleg
Platform HART Count : 1
Firmware Base : 0x80000000
Firmware Size : 100 KB
Runtime SBI Version : 0.2
Domain0 Name : root
Domain0 Boot HART : 0
Domain0 HARTs : 0*
Domain0 Region00 : 0x0000000080000000-0x000000008001ffff ()
Domain0 Region01 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address : 0x0000000080200000
Domain0 Next Arg1 : 0x000000009f000000
Domain0 Next Mode : S-mode
Domain0 SysReset : yes
Boot HART ID : 0
Boot HART Domain : root
Boot HART ISA : rv64imafdcsu
Boot HART Features : scounteren,mcounteren,time
Boot HART PMP Count : 16
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Count : 0
Boot HART MHPM Count : 0
Boot HART MIDELEG : 0x0000000000000222
Boot HART MEDELEG : 0x000000000000b109
U-Boot 2021.04-00604-ga1e95e3805 (Apr 09 2021 - 18:20:46 -0500)
CPU: rv64imafdcsu
Model: riscv-virtio,qemu
DRAM: 512 MiB
In: uart@10000000
Out: uart@10000000
Err: uart@10000000
Net: eth0: virtio-net#3
Hit any key to stop autoboot: 0
Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 2.8 MB = 0.0 GB (5760 x 512)
... is now current device
Scanning virtio 0:1...
** Unable to read file / **
Failed to load '/'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk virtio-blk#4...
Scanning disk virtio-blk#5...
** Unrecognized filesystem type **
Found 3 disks
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootriscv64.efi
449079 bytes read in 2 ms (214.1 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Booting /efi\boot\bootriscv64.efi
System provided memory map:
phys: 0x80000000, virt: 0x80000000, size: 0x20000, bootServicesData, attrs: 0x8
phys: 0x80020000, virt: 0x80020000, size: 0x7edb000, conventionalMemory, attrs: 0x8
phys: 0x87efb000, virt: 0x87efb000, size: 0xa000, ACPIReclaimMemory, attrs: 0x8
phys: 0x87f05000, virt: 0x87f05000, size: 0x141f2000, conventionalMemory, attrs: 0x8
phys: 0x9c0f7000, virt: 0x9c0f7000, size: 0x25db000, loaderData, attrs: 0x8
phys: 0x9e6d2000, virt: 0x9e6d2000, size: 0x55000, loaderCode, attrs: 0x8
phys: 0x9e727000, virt: 0x9e727000, size: 0x7000, reservedMemoryType, attrs: 0x8
phys: 0x9e72e000, virt: 0x9e72e000, size: 0x1000, bootServicesData, attrs: 0x8
phys: 0x9e72f000, virt: 0x9e72f000, size: 0x1000, runtimeServicesData, attrs: 0x8000000000000008
phys: 0x9e730000, virt: 0x9e730000, size: 0x2000, bootServicesData, attrs: 0x8
phys: 0x9e732000, virt: 0x9e732000, size: 0x1000, reservedMemoryType, attrs: 0x8
phys: 0x9e733000, virt: 0x9e733000, size: 0x3000, runtimeServicesData, attrs: 0x8000000000000008
phys: 0x9e736000, virt: 0x9e736000, size: 0x1000, bootServicesData, attrs: 0x8
phys: 0x9e737000, virt: 0x9e737000, size: 0x4000, runtimeServicesData, attrs: 0x8000000000000008
phys: 0x9e73b000, virt: 0x9e73b000, size: 0x1000, bootServicesData, attrs: 0x8
phys: 0x9e73c000, virt: 0x9e73c000, size: 0x2000, reservedMemoryType, attrs: 0x8
phys: 0x9e73e000, virt: 0x9e73e000, size: 0x2000, bootServicesData, attrs: 0x8
phys: 0x9e740000, virt: 0x9e740000, size: 0x1000, reservedMemoryType, attrs: 0x8
phys: 0x9e741000, virt: 0x9e741000, size: 0x2000, bootServicesData, attrs: 0x8
phys: 0x9e743000, virt: 0x9e743000, size: 0x1822000, loaderData, attrs: 0x8
phys: 0x9ff65000, virt: 0x9ff65000, size: 0x1000, runtimeServicesCode, attrs: 0x8000000000000008
phys: 0x9ff66000, virt: 0x9ff66000, size: 0x9a000, loaderData, attrs: 0x8
physMemRange: 0x80020000, 0x1ffe0000
MapRange(0x3fe0020000, 0x80020000, 0x1ffe0000)
MapRange(0x40008000, 0x40008000, 0x10)
MapRange(0xc000000, 0xc000000, 0x210000)
MapRange(0x2000000, 0x2000000, 0x10000)
MapRange(0x10000000, 0x10000000, 0x100)
MapRange(0x9c0f7000, 0x9c0f7000, 0x25db000)
MapRange(0x9e6d2000, 0x9e6d2000, 0x55000)
MapRange(0x9e743000, 0x9e743000, 0x1822000)
MapRange(0x9ff66000, 0x9ff66000, 0x9a000)
Kernel entry point
platform1: sbi
platform2: efi
arch_debug_init_early()
image "kernel_riscv64"
text: 0x9c4dd000 - 0x9c659000, 474861568
data: 0x9c659000 - 0x9c6c2000, 474861568
image "session"
text: 0x9c10c000 - 0x9c10f000, 2618343424
data: 0x9c10f000 - 0x9c110000, 2618343424
image "write_overlay"
text: 0x9c110000 - 0x9c116000, 2618359808
data: 0x9c116000 - 0x9c117000, 2618359808
image "udf"
text: 0x9c117000 - 0x9c123000, 2618388480
data: 0x9c123000 - 0x9c124000, 2618388480
image "reiserfs"
text: 0x9c134000 - 0x9c143000, 2618507264
data: 0x9c143000 - 0x9c144000, 2618507264
image "ntfs"
text: 0x9c144000 - 0x9c194000, 2618572800
data: 0x9c194000 - 0x9c198000, 2618572800
image "log_overlay"
text: 0x9c198000 - 0x9c1a0000, 2618916864
data: 0x9c1a0000 - 0x9c1a1000, 2618916864
image "iso9660"
text: 0x9c1b1000 - 0x9c1b5000, 2619019264
data: 0x9c1b5000 - 0x9c1b6000, 2619019264
image "fat"
text: 0x9c1b6000 - 0x9c1d2000, 2619039744
data: 0x9c1d2000 - 0x9c1d4000, 2619039744
image "ext2"
text: 0x9c1e4000 - 0x9c206000, 2619228160
data: 0x9c206000 - 0x9c208000, 2619228160
image "exfat"
text: 0x9c208000 - 0x9c20f000, 2619375616
data: 0x9c20f000 - 0x9c210000, 2619375616
image "btrfs"
text: 0x9c210000 - 0x9c228000, 2619408384
data: 0x9c228000 - 0x9c229000, 2619408384
image "bindfs"
text: 0x9c229000 - 0x9c22d000, 2619510784
data: 0x9c22d000 - 0x9c22e000, 2619510784
image "attribute_overlay"
text: 0x9c23e000 - 0x9c243000, 2619596800
data: 0x9c243000 - 0x9c244000, 2619596800
image "xhci"
text: 0x9c244000 - 0x9c259000, 2619621376
data: 0x9c259000 - 0x9c25a000, 2619621376
image "virtio_scsi"
text: 0x9c25a000 - 0x9c25e000, 2619711488
data: 0x9c25e000 - 0x9c25f000, 2619711488
image "virtio_pci"
text: 0x9c25f000 - 0x9c261000, 2619731968
data: 0x9c261000 - 0x9c262000, 2619731968
image "virtio_mmio"
text: 0x9c262000 - 0x9c266000, 2619744256
data: 0x9c266000 - 0x9c267000, 2619744256
image "virtio_block"
text: 0x9c267000 - 0x9c26a000, 2619764736
data: 0x9c26a000 - 0x9c26b000, 2619764736
image "virtio"
text: 0x9c27b000 - 0x9c280000, 2619846656
data: 0x9c280000 - 0x9c281000, 2619846656
image "usb_disk"
text: 0x9c281000 - 0x9c292000, 2619871232
data: 0x9c292000 - 0x9c297000, 2619871232
image "usb"
text: 0x9c297000 - 0x9c2a5000, 2619961344
data: 0x9c2a5000 - 0x9c2a6000, 2619961344
image "uhci"
text: 0x9c2a6000 - 0x9c2b8000, 2620022784
data: 0x9c2b8000 - 0x9c2b9000, 2620022784
image "silicon_image_3112"
text: 0x9c2c9000 - 0x9c2cc000, 2620166144
data: 0x9c2cc000 - 0x9c2cd000, 2620166144
image "sdhci_pci"
text: 0x9c2cd000 - 0x9c2d2000, 2620182528
data: 0x9c2d2000 - 0x9c2d3000, 2620182528
image "scsi_periph"
text: 0x9c2d3000 - 0x9c2d7000, 2620207104
data: 0x9c2d7000 - 0x9c2d8000, 2620207104
image "scsi_disk"
text: 0x9c2d8000 - 0x9c2da000, 2620227584
data: 0x9c2da000 - 0x9c2db000, 2620227584
image "scsi_cd"
text: 0x9c2db000 - 0x9c2de000, 2620239872
data: 0x9c2de000 - 0x9c2df000, 2620239872
image "scsi"
text: 0x9c2df000 - 0x9c2e6000, 2620256256
data: 0x9c2e6000 - 0x9c2e7000, 2620256256
image "pci"
text: 0x9c2e7000 - 0x9c2f3000, 2620289024
data: 0x9c2f3000 - 0x9c2f4000, 2620289024
image "packagefs"
text: 0x9c31e000 - 0x9c375000, 2620514304
data: 0x9c375000 - 0x9c37a000, 2620514304
image "ohci"
text: 0x9c38a000 - 0x9c39c000, 2620956672
data: 0x9c39c000 - 0x9c39d000, 2620956672
image "nvme_disk"
text: 0x9c39d000 - 0x9c3a9000, 2621034496
data: 0x9c3a9000 - 0x9c3aa000, 2621034496
image "mmc_disk"
text: 0x9c3aa000 - 0x9c3ad000, 2621087744
data: 0x9c3ad000 - 0x9c3ae000, 2621087744
image "mmc"
text: 0x9c3ae000 - 0x9c3b1000, 2621104128
data: 0x9c3b1000 - 0x9c3b2000, 2621104128
image "locked_pool"
text: 0x9c3b2000 - 0x9c3b4000, 2621120512
data: 0x9c3b4000 - 0x9c3b5000, 2621120512
image "legacy_sata"
text: 0x9c3b5000 - 0x9c3b7000, 2621132800
data: 0x9c3b7000 - 0x9c3b8000, 2621132800
image "it8211"
text: 0x9c3b8000 - 0x9c3b9000, 2621145088
data: 0x9c3b9000 - 0x9c3ba000, 2621145088
image "intel"
text: 0x9c3ca000 - 0x9c3d5000, 2621218816
data: 0x9c3d5000 - 0x9c3d7000, 2621218816
image "highpoint_ide_pci"
text: 0x9c3d7000 - 0x9c3d9000, 2621272064
data: 0x9c3d9000 - 0x9c3da000, 2621272064
image "generic_ide_pci"
text: 0x9c3da000 - 0x9c3db000, 2621284352
data: 0x9c3db000 - 0x9c3dc000, 2621284352
image "fdt"
text: 0x9c3dc000 - 0x9c3e2000, 2621292544
data: 0x9c3e2000 - 0x9c3e3000, 2621292544
image "ehci"
text: 0x9c3e3000 - 0x9c3f7000, 2621321216
data: 0x9c3f7000 - 0x9c3f8000, 2621321216
image "efi_gpt"
text: 0x9c408000 - 0x9c413000, 2621472768
data: 0x9c413000 - 0x9c415000, 2621472768
image "dpc"
text: 0x9c415000 - 0x9c416000, 2621526016
data: 0x9c416000 - 0x9c417000, 2621526016
image "config_manager"
text: 0x9c417000 - 0x9c418000, 2621534208
data: 0x9c418000 - 0x9c419000, 2621534208
image "bfs"
text: 0x9c422000 - 0x9c454000, 2621579264
data: 0x9c454000 - 0x9c456000, 2621579264
image "ata_adapter"
text: 0x9c456000 - 0x9c458000, 2621792256
data: 0x9c458000 - 0x9c459000, 2621792256
image "ata"
text: 0x9c459000 - 0x9c462000, 2621804544
data: 0x9c462000 - 0x9c463000, 2621804544
image "ahci"
text: 0x9c463000 - 0x9c46e000, 2621845504
data: 0x9c46e000 - 0x9c470000, 2621845504
Welcome to kernel debugger output!
Haiku revision: , debug level: 2
INIT: init CPU
INIT: init interrupts
reserve_io_interrupt_vectors: reserved 64 vectors starting from 0
INIT: init VM
vm_translation_map_init: entry
kernel args ranges:
9c6c2000 - 9c6d2000
9c470000 - 9c4dd000
9c419000 - 9c422000
9c3f8000 - 9c408000
9c3ba000 - 9c3ca000
9c37a000 - 9c38a000
9c2f4000 - 9c31e000
9c2b9000 - 9c2c9000
9c26b000 - 9c27b000
9c22e000 - 9c23e000
9c1d4000 - 9c1e4000
9c1a1000 - 9c1b1000
9c124000 - 9c134000
9c0fc000 - 9c10c000
physical memory ranges:
80020000 - 87efb000
87f05000 - 9e727000
9e743000 - 9ff65000
9ff66000 - a0000000
allocated physical ranges:
9bed1000 - 9e6d2000
9e743000 - 9ff65000
9ff66000 - a0000000
allocated virtual ranges:
9c0f7000 - 9c6d2000
physMapBase: 0x3fe0020000
physMemBase: 0x80020000
mark_page_range_in_use(0x0, 0x80020): start page is before free list
vm_translation_map_init_post_area: entry
25 Likes
Nice work!! What was causing the issues jumping into the kernel from EFI? I assumed it was the SV39 page tables not being properly setup… but still not sure.
Be sure to keep those patches coming into Gerrit. I’m pausing reviewing them until tomorrow since the R1 / Beta 3 branch is so close.
– Alex
1 Like
I implemented my own MMU code in both “efi” and “riscv” platforms, there are no machine mode and page table setup code in kernel anymore. There are some tricky things such as arch_enter_kernel() function code should be identity mapped, otherwise it will crash after setting SATP register. Also boot loader maps MMIO registers of some devices such as UART, PLIC, CLINT.
Page table initialization code looks very nice:
static void
SetupPageTable()
{
sPageTable = AllocPhysPage();
PreallocKernelRange();
// Physical memory mapping
gKernelArgs.arch_args.physMap.size
= gKernelArgs.physical_memory_range[0].size;
gKernelArgs.arch_args.physMap.start = KERNEL_TOP + 1
- gKernelArgs.arch_args.physMap.size;
MapRange(gKernelArgs.arch_args.physMap.start,
gKernelArgs.physical_memory_range[0].start,
gKernelArgs.arch_args.physMap.size,
(1 << pteRead) | (1 << pteWrite));
// Boot loader
MapRangeIdentity((addr_t)gMemBase, &gStackEnd - gMemBase,
(1 << pteRead) | (1 << pteWrite) | (1 << pteExec));
// Memory regions
MemoryRegion* region;
for (region = sRegions; region != NULL; region = region->next) {
uint64 flags = 0;
if ((region->protection & B_READ_AREA) != 0)
flags |= (1 << pteRead);
if ((region->protection & B_WRITE_AREA) != 0)
flags |= (1 << pteWrite);
if ((region->protection & B_EXECUTE_AREA) != 0)
flags |= (1 << pteExec);
MapRange(region->virtAdr, region->physAdr, region->size, flags);
}
// Devices
MapAddrRange(gKernelArgs.arch_args.clint, (1 << pteRead) | (1 << pteWrite));
MapAddrRange(gKernelArgs.arch_args.htif, (1 << pteRead) | (1 << pteWrite));
MapAddrRange(gKernelArgs.arch_args.plic, (1 << pteRead) | (1 << pteWrite));
if (gKernelArgs.arch_args.uart.kind != kUartKindNone) {
MapAddrRange(gKernelArgs.arch_args.uart.regs,
(1 << pteRead) | (1 << pteWrite));
}
}
EFI version:
uint64
arch_mmu_generate_post_efi_page_tables(size_t memory_map_size,
efi_memory_descriptor *memory_map, size_t descriptor_size,
uint32_t descriptor_version)
{
sPageTable = mmu_allocate_page();
memset(VirtFromPhys(sPageTable), 0, B_PAGE_SIZE);
PreallocKernelRange();
gKernelArgs.arch_args.num_virtual_ranges_to_keep = 0;
FillPhysicalMemoryMap(memory_map_size, memory_map, descriptor_size, descriptor_version);
addr_range physMemRange;
GetPhysMemRange(physMemRange);
printf("physMemRange: 0x%" B_PRIxADDR ", 0x%" B_PRIxSIZE "\n", physMemRange.start, physMemRange.size);
// Physical memory mapping
gKernelArgs.arch_args.physMap.start = KERNEL_TOP + 1 - physMemRange.size;
gKernelArgs.arch_args.physMap.size = physMemRange.size;
MapRange(gKernelArgs.arch_args.physMap.start, physMemRange.start, physMemRange.size, (1 << pteRead) | (1 << pteWrite));
// Devices
MapAddrRange(gKernelArgs.arch_args.clint, (1 << pteRead) | (1 << pteWrite));
MapAddrRange(gKernelArgs.arch_args.htif, (1 << pteRead) | (1 << pteWrite));
MapAddrRange(gKernelArgs.arch_args.plic, (1 << pteRead) | (1 << pteWrite));
if (gKernelArgs.arch_args.uart.kind != kUartKindNone) {
MapAddrRange(gKernelArgs.arch_args.uart.regs,
(1 << pteRead) | (1 << pteWrite));
}
for (size_t i = 0; i < memory_map_size / descriptor_size; ++i) {
efi_memory_descriptor* entry = &memory_map[i];
switch (entry->Type) {
case EfiLoaderCode:
case EfiLoaderData:
MapRange(entry->VirtualStart, entry->PhysicalStart, entry->NumberOfPages * B_PAGE_SIZE, (1 << pteRead) | (1 << pteWrite) | (1 << pteExec));
break;
default:
;
}
}
return GetSatp();
}
6 Likes
Another GCC behavior that makes me angry: it produce wrong stack frames for leaf functions even if -fno-omit-frame-pointer is provided: Clang, GCC. GCC put previous frame pointer at wrong offset for leaf functions.
This cause broken stack traces:
PANIC: vm_page_fault: unhandled page fault in kernel space at 0xffffffff4a70e940, ip 0x100171978
Welcome to Kernel Debugging Land...
Thread 444 "app_server" running on CPU 0
Stack:
FP: 0x100a29e30
FP: 0x100a29f40, PC: 0x1001655f9 <kernel_riscv64> arch_debug_call_with_fault_handler + 91
FP: 0x100a29f90, PC: 0x1000ddb89 <kernel_riscv64> debug_call_with_fault_handler.localalias.7 + 129
FP: 0x100a2a020, PC: 0x1000df1c9 <kernel_riscv64> _ZL20kernel_debugger_loopPKcS0_Pvi + 299
FP: 0x100a2a090, PC: 0x1000df4b5 <kernel_riscv64> _ZL24kernel_debugger_internalPKcS0_Pvi + 135
FP: 0x100a2a0d0, PC: 0x1000df7fd <kernel_riscv64> panic + 101
FP: 0x100a2a200, PC: 0x100152bcd <kernel_riscv64> vm_page_fault + 541
FP: 0x100a2a2e0, PC: 0x100166591 <kernel_riscv64> STrap + 255
FP: 0x100a2a3e0, PC: 0x10016482d <kernel_riscv64> SVec + 77
FP: 0x100a2a3f0, PC: 0x100171977 <kernel_riscv64> strcpy + 15
FP: 0x8198cb80, PC: 0x100a2a4df <app_server_444_kstack> 0x44df // PC is really FP here and FP is garbage
FP: 0xde01d898, PC: 0x0 0x0
FP: 0x8198d3f0, PC: 0x8104b47f <slab area> 0x4b47f
FP: 0x0, PC: 0x2 0x2
kdebug>
I also have GCC some workarounds for code that works fine in Mini OS and Clang.
Someday I will probably throw away GCC and fully switch to Clang. GCC is terrible in all ways including ancient autotools build system that also cause troubles when crosscompiling on Haiku.
FreeBSD already switched to Clang.
6 Likes
Offtopic, but can Haiku be built with clang?
I managed to build fully operational Haiku for x86_64: Why MergeObjectFromObjects1 rule is needed? - #21 by X512. But Clang build is not yet officially supported and it require some patches to produce working system. Haiku buildtools are GCC-based, there are no Clang-based buildtools for now.
10 Likes
Very cool!
I figured about the buildtools at least.
1 Like
Hi @X512, @Coldfirex has suggested we add the RISC-V port to the Haiku port status page (Haiku port status | Haiku Project), so I’m working on that right now.
Could you have a look at the ports tables already present and let me know what values the RISC-V ports entries would have? For example, the x86 ports table has the different platforms listed, the different targets, the status and the status of work on critical components like the app_server, so what would the RISC-V table list as platforms, what would be the different targets and the status of work?
1 Like
All 3 items (Haiku Loader, Haiku Kernel, Application Server) are working. TinyEMU (raw platform), Qemu (raw platform, SBI/EFI) are supported. Real hardware is not yet tested. Remaining major problems are partially broken libstdc++ and many packages not yet compiled such as Mesa, WebKit.
Most of kernel code is not yet submitted to Haiku source tree because cleanup is needed (removing temporary workarounds, code style cleanup). Only raw platform boot loader code (haiku_loader.riscv) is already submitted, but it is a bit obsolete for now (machine-mode services and MMU page table initialization were recently added).
Official nightly builds are not yet operational, I provided my own builds if someone want to test it (it is also a bit obsolete for now).
14 Likes
@X512 Thanks for the info, I’ve added your port to the ports status page. You can view the commit on GitHub here:
1 Like
AHCI (SATA disks) are working. The problem was here in “packed” struct attribute that cause per-byte access to MMIO registers instead of 32 bit access.
Also PCI register allocator was improved to support proper alignment (register addresses should be aligned with reported register size). Some hardcoding was removed.
PCI bus related kernel serial output:
pci_controller_init()
reg[0]: (0x30000000, 0x10000000)
interrupt-map:
bus: 0, dev: 0, fn: 0, childIrq: 1, parentIrq: (3, 32)
bus: 0, dev: 0, fn: 0, childIrq: 2, parentIrq: (3, 33)
bus: 0, dev: 0, fn: 0, childIrq: 3, parentIrq: (3, 34)
bus: 0, dev: 0, fn: 0, childIrq: 4, parentIrq: (3, 35)
bus: 0, dev: 1, fn: 0, childIrq: 1, parentIrq: (3, 33)
bus: 0, dev: 1, fn: 0, childIrq: 2, parentIrq: (3, 34)
bus: 0, dev: 1, fn: 0, childIrq: 3, parentIrq: (3, 35)
bus: 0, dev: 1, fn: 0, childIrq: 4, parentIrq: (3, 32)
bus: 0, dev: 2, fn: 0, childIrq: 1, parentIrq: (3, 34)
bus: 0, dev: 2, fn: 0, childIrq: 2, parentIrq: (3, 35)
bus: 0, dev: 2, fn: 0, childIrq: 3, parentIrq: (3, 32)
bus: 0, dev: 2, fn: 0, childIrq: 4, parentIrq: (3, 33)
bus: 0, dev: 3, fn: 0, childIrq: 1, parentIrq: (3, 35)
bus: 0, dev: 3, fn: 0, childIrq: 2, parentIrq: (3, 32)
bus: 0, dev: 3, fn: 0, childIrq: 3, parentIrq: (3, 33)
bus: 0, dev: 3, fn: 0, childIrq: 4, parentIrq: (3, 34)
ranges:
IOPORT (0x01000000): child: 00000000, parent: 03000000, len: 10000
MMIO32 (0x02000000): child: 40010000, parent: 40010000, len: 3f000000
MMIO64 (0x03000000): child: 400000000, parent: 400000000, len: 400000000
AllocRegs()
AllocRegsForDevice(bus: 0, device: 0, function: 0)
bar[0]: MMIO32, adr: 0x0, size: 0x0
bar[1]: MMIO32, adr: 0x0, size: 0x0
bar[2]: MMIO32, adr: 0x0, size: 0x0
bar[3]: MMIO32, adr: 0x0, size: 0x0
bar[4]: MMIO32, adr: 0x0, size: 0x0
bar[5]: MMIO32, adr: 0x0, size: 0x0
rom_bar: adr: 0x0, size: 0x0
intLine: 32
intPin: -
AllocRegsForDevice(bus: 0, device: 1, function: 0)
bar[0]: MMIO32, adr: 0x0, size: 0x1000000 -> 0x41000000
bar[1]: IOPORT, adr: 0x0, size: 0x100 -> 0x100
bar[2]: MMIO32, adr: 0x0, size: 0x4000 -> 0x42000000
bar[3]: MMIO32, adr: 0x0, size: 0x0
bar[4]: MMIO32, adr: 0x0, size: 0x0
bar[5]: MMIO32, adr: 0x0, size: 0x0
rom_bar: adr: 0x0, size: 0x10000 -> 0x42010000
intLine: 33
intPin: INTA#
AllocRegsForDevice(bus: 0, device: 2, function: 0)
bar[0]: MMIO64, adr: 0x0, size: 0x4000 -> 0x400000000
bar[2]: MMIO32, adr: 0x0, size: 0x0
bar[3]: MMIO32, adr: 0x0, size: 0x0
bar[4]: MMIO32, adr: 0x0, size: 0x0
bar[5]: MMIO32, adr: 0x0, size: 0x0
rom_bar: adr: 0x0, size: 0x0
intLine: 34
intPin: INTA#
AllocRegsForDevice(bus: 0, device: 3, function: 0)
bar[0]: MMIO64, adr: 0x0, size: 0x4000 -> 0x400004000
bar[2]: MMIO32, adr: 0x0, size: 0x0
bar[3]: MMIO32, adr: 0x0, size: 0x0
bar[4]: MMIO32, adr: 0x0, size: 0x0
bar[5]: MMIO32, adr: 0x0, size: 0x0
rom_bar: adr: 0x0, size: 0x0
intLine: 35
intPin: INTA#
AllocRegsForDevice(bus: 0, device: 4, function: 0)
bar[0]: MMIO32, adr: 0x0, size: 0x0
bar[1]: MMIO32, adr: 0x0, size: 0x0
bar[2]: MMIO32, adr: 0x0, size: 0x0
bar[3]: MMIO32, adr: 0x0, size: 0x0
bar[4]: IOPORT, adr: 0x0, size: 0x20 -> 0x200
bar[5]: MMIO32, adr: 0x0, size: 0x1000 -> 0x42020000
rom_bar: adr: 0x0, size: 0x0
intLine: 32
intPin: INTA#
PCI: [dom 0, bus 0] bus 0, device 0, function 0: vendor 1b36, device 0008, revision 00
PCI: class_base 06, class_function 00, class_api 00
PCI: line_size 00, latency 00, header_type 00, BIST 00
PCI: ROM base host 00000000, pci 00000000, size 00000000
PCI: cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI: interrupt_line 20, interrupt_pin 00, min_grant 00, max_latency 00
PCI: base reg 0: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 1: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI: Capabilities: (not supported)
PCI: [dom 0, bus 0] bus 0, device 1, function 0: vendor 1002, device 5046, revision 00
PCI: class_base 03, class_function 00, class_api 00
PCI: line_size 00, latency 00, header_type 00, BIST 00
PCI: ROM base host 42010000, pci 42010000, size 00010000
PCI: cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI: interrupt_line 21, interrupt_pin 01, min_grant 00, max_latency 00
PCI: base reg 0: host 41000000, pci 41000000, size 01000000, flags 08
PCI: base reg 1: host 00000100, pci 00000100, size 00000100, flags 01
PCI: base reg 2: host 42000000, pci 42000000, size 00004000, flags 00
PCI: base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI: Capabilities: (not supported)
PCI: [dom 0, bus 0] bus 0, device 2, function 0: vendor 1033, device 0194, revision 03
PCI: class_base 0c, class_function 03, class_api 30
PCI: line_size 00, latency 00, header_type 00, BIST 00
PCI: ROM base host 00000000, pci 00000000, size 00000000
PCI: cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI: interrupt_line 22, interrupt_pin 01, min_grant 00, max_latency 00
PCI: base reg 0: host 00000000, pci 00000000, size 00004000, flags 04
PCI: base reg 1: host 00000004, pci 00000004, size 00000000, flags 00
PCI: base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI: Capabilities: MSI-X, PCIe, MSI
PCI: Extended capabilities: (empty list)
PCI: [dom 0, bus 0] bus 0, device 3, function 0: vendor 1b36, device 0010, revision 02
PCI: class_base 01, class_function 08, class_api 02
PCI: line_size 00, latency 00, header_type 00, BIST 00
PCI: ROM base host 00000000, pci 00000000, size 00000000
PCI: cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI: interrupt_line 23, interrupt_pin 01, min_grant 00, max_latency 00
PCI: base reg 0: host 00004000, pci 00004000, size 00004000, flags 04
PCI: base reg 1: host 00000004, pci 00000004, size 00000000, flags 00
PCI: base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
PCI: Capabilities: MSI-X, PCIe
PCI: Extended capabilities: (empty list)
PCI: [dom 0, bus 0] bus 0, device 4, function 0: vendor 8086, device 2922, revision 02
PCI: class_base 01, class_function 06, class_api 01
PCI: line_size 00, latency 00, header_type 00, BIST 00
PCI: ROM base host 00000000, pci 00000000, size 00000000
PCI: cardbus_CIS 00000000, subsystem_id 1100, subsystem_vendor_id 1af4
PCI: interrupt_line 20, interrupt_pin 01, min_grant 00, max_latency 00
PCI: base reg 0: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 1: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
PCI: base reg 4: host 00000200, pci 00000200, size 00000020, flags 01
PCI: base reg 5: host 42020000, pci 42020000, size 00001000, flags 00
PCI: Capabilities: MSI, SATA
32 Likes
I get swapped kernel and user address space ranges working. Now kernel can use high addresses and user can use low addresses as it usually done. Address ranges can be configured here (some address ranges hardcoding was removed), system still can be compiled and run with old address ranges. problem was addressed here and here.
It do not affect userland applications binary compatibility, but it affects kernel modules because of IS_USER_ADDRESS/IS_KERNEL_ADDRESS macro.
23 Likes