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>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?418FD698.7060108>