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

[Kristian V. D. V. <va...@li...>]

On Saturday 13 November 2004 8:53 am, Arno Klenke wrote:
> 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?
>>
>> <snip>
>>
>> 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.

I think Jake is on the right track, provided we get the issues correctly 
solved.  We have to be realistic and foreign binary support will be an issue 
once we hit a certain point.  There is no sense in limiting ourselves.

Getting create_area() shouldn't be too tough, nor should fixing the device 
drivers.  It might be a good idea to add a MEMF_DMA flag to kmalloc() that in 
turn uses AREA_CONTIGOUS, so at least we don't need to make big changes to 
the existing code base.  Also note that nothing should be calling 
get_free_pages() directly; the emu10k1 driver hacks it up but shouldn't be 
doing it.  Henrik used it to get a page aligned area but it should really be 
using the PAGE_ALIGN() macro..

We already knew that Syllable wouldn't boot with systems of 2Gb or more, 
exactly because of that 1:1 kernel memory mapping.  For that reason alone 
it's good enough to move everything around and load the kernel at 0xc0000000 
(Could there possibly be a good reason for using more than 1Gb of virtual 
address space in a desktop OS kernel?  None I can think of).  At todays 
growth rate 2Gb+ machines as standard are not far off.  There is also some 
good news; current applications are compiled with -fPIC by default.  
Theoretically we don't even need any special case handling for old binaries; 
just load them at 0x08000000.

-- 
Vanders
http://syllable.sourceforge.net/
http://www.liqwyd.com