Re: [Syllable-kernel] Special handling for >1GB RAM and loading apps at 0x04000000 not 0x80000000?

[Arno K. <arn...@ya...>]

Jake Hamby schrieb:

> After upgrading my laptop to 1.25 GB of RAM (for Windows XP of course, 
> not for Syllable!), I have to force Syllable to use a memsize lower 
> than 1GB in the bootloader or else I get a bunch of fatal areas 
> errors.  I am trying to figure out what needs to be done to fix 
> Syllable to work on machines with up to 4GB of RAM.  Does anyone know 
> if there is any special quirkiness related to Intel-based PC handling 
> of 1GB to 4GB RAM, and if so, how to handle it?
>
> One reason I ask is because I recently discovered that Linux's default 
> kernel only supports up to 896MB of physical memory.  You need a 
> special HIGHMEM enabled kernel to go up to 4GB (or 64GB with 36-bit 
> addressing) of RAM.  I've never had that much RAM before so I never 
> noticed.  :-)  I guess I will have to grep through the kernel and see 
> what had to be changed in Linux to support large memory systems.  I 
> had assumed that it would be a simple matter of not accidentally using 
> signed variables for pointer arithmetic and taking care to stuff the 
> addresses into the page table entries in the correct quirky Intel 
> format that the processor can understand.  Apparently it isn't that 
> simple.
>
> Since we have been talking about glibc and ELF issues this week, I've 
> been thinking that we should consider moving the default application 
> start address from 0x80000000 to the 0x00000000-0x7fffffff range that 
> is used by every other OS I have worked with recently... 

There are some problems with this:

Syllable currently maps all the present physical memory at the same 
position in the virtual space. This means in the kernel you have a 1:1 
mapping. This behaviour limits the ram to 2GB but is required by many 
device drivers that use kmalloc() to allocate dma buffers because 
create_area() does not currently have a way to allocate a linear buffer 
of memory. There is a flag AREA_CONTIGUOUS but no implementation for 
this. If we changed all device drivers to use create_area() with this 
flag (and use get_area_physical() to get the physical address) instead 
of calls to kmalloc() or get_free_page() and also change kmalloc() to 
use areas then we could follow your plan.

Arno