From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 20:27:05 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 402D616A4CE; Mon, 8 Nov 2004 20:27:05 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1686F43D48; Mon, 8 Nov 2004 20:27:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id E0ACC7A440; Mon, 8 Nov 2004 12:27:04 -0800 (PST) Message-ID: <418FD698.7060108@elischer.org> Date: Mon, 08 Nov 2004 12:27:04 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin References: <418AB176.9030604@withagen.nl> <200411051400.34684.jhb@FreeBSD.org> <418BE3D2.2030205@withagen.nl> <200411081353.15394.jhb@FreeBSD.org> In-Reply-To: <200411081353.15394.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Willem Jan Withagen cc: freebsd-arch@freebsd.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 20:27:05 -0000 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)