Date: Mon, 08 Nov 2004 12:27:04 -0800 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Booting questions .... Message-ID: <418FD698.7060108@elischer.org> In-Reply-To: <200411081353.15394.jhb@FreeBSD.org> References: <418AB176.9030604@withagen.nl> <200411051400.34684.jhb@FreeBSD.org> <418BE3D2.2030205@withagen.nl> <200411081353.15394.jhb@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
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)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?418FD698.7060108>