Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Nov 2004 00:41:37 +0100
From:      Willem Jan Withagen <wjw@withagen.nl>
To:        Scott Long <scottl@freebsd.org>
Cc:        "arch@freebsd.org" <arch@freebsd.org>
Subject:   Re: Booting questions ....
Message-ID:  <418ABE31.9040502@withagen.nl>
In-Reply-To: <418AB9E2.6070708@freebsd.org>
References:  <418AB176.9030604@withagen.nl> <418AB649.80809@freebsd.org> <418AB888.7070305@withagen.nl> <418AB9E2.6070708@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote:
>>> The loader has a protected mode environment.  It is apparently not all
>>> that hard to port memtest86 into it.  I'd highly recommend doing this
>>> rather than trying to hack up the early pmap initialization.
>>
>> Is that so.... I was unable to find that. :( can you give me a pointer??
> 
> Sorry, I know of some private efforts, but not any public efforts.

To bad... Would be nice, but perhaps again too much arch dependant.

>> And like I wrote in the previous discussion. The algorithms are not 
>> all that difficult to write. It is getting easy access to the memory.
>> If you look at memtest86, you'll that they have to get a lot of work 
>> done to get to the actual job: memory testing.
>> And that only for the x86 type processors, which are already served by 
>> memtest86.
>>
>> But reading your question, the answer would be:
>>     too complex to get this figured out
> 
> Not too complex, just full of landmines.  I'm not sure that you can put
> generic code into the VM system to do this without concerning yourself
> about the per-arch pmap layout.  Also, how do you handle traps that are
> generated by the memtest?  That's another per-arch thing that you have
> to think about.

That's why I was looking at the phys_avail[] ranges, assuming that the kernel 
has a relative simple mapping (1:1) on this.

Perhaps a little naive, but I'm not really aware of any runtime traps that can 
occur whilest staying within the ranges of valid memory.
Not counting NMI's when parity errors occur. Not shure what ECC-memory would 
give me if the errors prove to be uncorrectable.
e.g. Illegal instruction traps should not occur, since this would be either a 
compiler error or programmer error.
(not shure that memtest86 does anything serious with traps....)

Julian made a valid point, which I had not thought of: PAE.
That is again back to 1980, and do bankswapping to get > 64KB on a Z80 :)

--WjW



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?418ABE31.9040502>