[GH-ISSUE #6] bootloader and kernel will not work with machines that have over 512MB of RAM #4

New issue

Open

opened 2026-11-03 22:02:02 -07:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-11-03 22:02:02 -07:00

Owner

Originally created by @raynorpat on GitHub (Oct 10, 2025).
Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/6

Originally assigned to: @raynorpat on GitHub.

There is a hard coded limit of 512MB in sizememory.c in boot2.

Originally created by @raynorpat on GitHub (Oct 10, 2025). Original GitHub issue: https://github.com/RhapsodiOS/RhapsodiOS/issues/6 Originally assigned to: @raynorpat on GitHub. There is a hard coded limit of 512MB in sizememory.c in boot2.

gitea-mirror added the

bug

label

2026-11-03 22:02:02 -07:00

gitea-mirror referenced this issue

2026-11-03 22:02:03 -07:00

[GH-ISSUE #4] x86 barebones drivers #6

gitea-mirror commented

2026-11-03 22:02:04 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 10, 2025):

A possible fix for this issue is in main, but needs to be tested in the wild before I close this out

@raynorpat commented on GitHub (Oct 10, 2025): A possible fix for this issue is in main, but needs to be tested in the wild before I close this out

gitea-mirror commented

2026-11-03 22:02:05 -07:00

Author

Owner

@raynorpat commented on GitHub (Oct 12, 2025):

There are some additional places we need to modify the kernel to get anything over 1GB working:

a) Virtual address space in pmap.c - With 3GB of physical RAM for example, the direct mapping alone would need addresses from 0x00000000 to 0xC0000000 (3GB), which would collide with the 1GB kernel virtual address space limit (VM_MAX_KERNEL_ADDRESS at 0x40000000)

b) Page Table Allocation - The kernel attempts to pre-allocate page tables covering 6410241024 + zone_map_sizer() + buffer_map_sizer(). With 3GB RAM, this calculation would try to allocate virtual addresses beyond VM_MAX_KERNEL_ADDRESS, causing pmap_map() to panic.

c) Double Mapping - The kernel creates a double mapping where kernel memory is mapped both at low addresses (0x0 - 0x40000000) and at high addresses (0xC0000000+)

So at least some of the memory management subsystem will need to be refactored further for more RAM to be used

@raynorpat commented on GitHub (Oct 12, 2025): There are some additional places we need to modify the kernel to get anything over 1GB working: a) Virtual address space in pmap.c - With 3GB of physical RAM for example, the direct mapping alone would need addresses from 0x00000000 to 0xC0000000 (3GB), which would collide with the 1GB kernel virtual address space limit (VM_MAX_KERNEL_ADDRESS at 0x40000000) b) Page Table Allocation - The kernel attempts to pre-allocate page tables covering 64*1024*1024 + zone_map_sizer() + buffer_map_sizer(). With 3GB RAM, this calculation would try to allocate virtual addresses beyond VM_MAX_KERNEL_ADDRESS, causing pmap_map() to panic. c) Double Mapping - The kernel creates a double mapping where kernel memory is mapped both at low addresses (0x0 - 0x40000000) and at high addresses (0xC0000000+) So at least some of the memory management subsystem will need to be refactored further for more RAM to be used