Booting questions ....

[Julian Elischer]

John Baldwin wrote:

>On Friday 05 November 2004 03:34 pm, Willem Jan Withagen wrote:
>  
>
>>John Baldwin wrote:
>>
>>[about the loader having flat addressspace....]
>>
>>    
>>
>>>>But is it unsegmented? (perhaps I have a wrong idea of a flat address
>>>>space)
>>>>        
>>>>
>>>Yes, it is unsegmented.  You can translate physical addresses to virtual
>>>addresses using PTOV() and vice versa using VTOP().
>>>      
>>>
>>I've run accross these calls, just need to figure out how to work them.
>>
>>    
>>
>>>>What I mean with this is that I can iterate from 0xa000 to 0xffffffff
>>>>with a "char *p" and do test_bytes( 0xa000, 0xffffffff, 0xff). (assuming
>>>>this all has memory)
>>>>        
>>>>
>>>Yes.
>>>      
>>>
>>Would be nice....
>>
>>    
>>
>>>>Next is then which ranges are valid to test, and then things really start
>>>>to get complicated and arch dependant. Which is why I ended up in
>>>>machdep.c right after the setting up of the memory ranges.
>>>>        
>>>>
>>>Heh, the above memory mapping is also i386 specific.  Alpha only has a
>>>small bit of memory mapped in the loader, same with sparc64, etc.
>>>      
>>>
>>Ehhhh, again more reasons to put this in the kernel, or something that
>>closely resembles a kernel.
>>    
>>
>
>Well, part of the problem there is that the early kernel code is all MD 
>anyway.  I think your best bet really is to write your own mini-kernel that 
>the loader can load to do this, but it will require MD stubs for early 
>bootstrapping as well as some kind of API for mapping a page so you can test 
>it and then unmap it, which is required for x86 machines with > 4GB of RAM 
>for example.
>  
>
to some extent you are describing reinventing memtest86
hense my original suggestion of adding loader support for loading 
binaries that are
designed to be independently loadable (e.g. memtest86)