Re: FBSDBOOT.EXE
> > > The loader won't help you because you are booting from under DOS, but > > the loader will boot the kernel just fine off a DOS filesystem. > > I'd like to understand this aspect of the loader better. This mode > might be useful for booting from (for example) a DOS flash filesystem? Typically a bootable volume on the PC has a helper BIOS that makes it look like a floppy disk. > Um... off to the source code. Thanks for the tip. The loader's multiple filesystem support is pretty simple and consequently a bit stupid; it will simply apply every filesystem module to the current device until one works (yay!) or they all fail. It's so stupid that you can even call it recursively (this is how transparent gunzipping works, and why the files have to have different names). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
Lets also consider the case of a root partition exists on a device which the BIOS does not support, but DOS and FreeBSD do. A good example of this may be a SCSI controller without a BIOS, or maybe a network style load. A person could have just the kernel on the DOS parition, or have the driver for the device loaded and boot off of it that way. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
Anthony writes, > >The problem which remains unsolved is how to boot FreeBSD from >DOS/Windows without the ability to use a boot floppy or boot CD. > >Perhaps a DOS/Windows utility which installs boot blocks? > Such a utility may be useful in most cases, but I do not want to have to mess around with my users' boot blocks at this point. When Generic Windows is stable enough and is ready for prime-time, then I will have a use for such a utility. The idea is to minimize the changes done to a user's system so that uninstalling Generic Windows (name to change later) will be easy. It's just too risky to modify the boot blocks and then have to put it in its original state during uninstall. Carlos C. Tapang http://www.genericwindows.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Maxim writes, >Correct me if I'm wrong, but loader is unable to directly load kernel from >non-FreeBSD partition (DOS in your case), so problem is slightly more >complicated but I though your can take PicoBSD (FreeBSD on floppy) and tweak it >to match your needs. > I have tried booting /boot/loader from a floppy, and then have loader boot a kernel that resides in a DOS file system. As far as I can tell, it works flawlessly. Carlos C. Tapang http://www.genericwindows.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
The problem which remains unsolved is how to boot FreeBSD from DOS/Windows without the ability to use a boot floppy or boot CD. Perhaps a DOS/Windows utility which installs boot blocks? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
"Carlos C. Tapang" wrote: > Thanks to all who pitched in their input to this issue. Most users of my > system are running Windows and don't want to have to reformat or repartition > their hard disk. So I am stuck with the DOS file system. I think the best > solution is to have my users use a FreeBSD boot floppy. The floppy will have > /boot/loader which I will point to the DOS-formatted hard disk in which the > kernel resides. Correct me if I'm wrong, but loader is unable to directly load kernel from non-FreeBSD partition (DOS in your case), so problem is slightly more complicated but I though your can take PicoBSD (FreeBSD on floppy) and tweak it to match your needs. Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
On Wed, 19 May 1999, Luoqi Chen wrote: > > Jonathan Lemon says: > > : > > : Not true. VM86 is also required to support VESA. Also, it is used > > : for reliable memory detection (which is why I want to make it mandatory). > > : No more "My Stinkpad only detected 64M, what do I do now??!" questions. > > > > Actually, even with VM86, the kernel still doesn't correctly detect the > > StinkPad's memory. > > > > --Jerry > > > > name: Jerry Alexandratos || Open-Source software isn't a > > phone: 302.521.1018 || matter of life or death... > > email: jalex...@perspectives.net || ...It's much more important > > || than that! > > It just occurred to me that we might be able to use initial MTRR settings > by BIOS for memory detection (P6 and above, of course). Don't know how > reliable that is. And K6-family processors with newer BIOSes are usually write allocate-enabled and that can be used too. > > -lq > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Sounds like you want something like a FreeBSD version of DOS Linux. See http://www.tux.org/pub/people/kent-robotti/index.html. How do they overcome this problem? Greg At 02:45 PM 5/19/99 -0700, Carlos C. Tapang wrote: >Thanks to all who pitched in their input to this issue. Most users of my >system are running Windows and don't want to have to reformat or repartition >their hard disk. So I am stuck with the DOS file system. I think the best >solution is to have my users use a FreeBSD boot floppy. The floppy will have >/boot/loader which I will point to the DOS-formatted hard disk in which the >kernel resides. > >>The flags and values in the BIOS data area would not necessarily >>be at their default values, so restoring the vectors might itself >>crash the BIOS (because it's reconfigured itself for the present >>vectors/drivers, not the default ones). >> >>Some hardware (eg. popular SCSI controllers) also configures itself >>differently when it finds it's running on DOS/Windows. This kind >>of thing in any scenario in which we start DOS then kill it would >>have the potential to seriously confuse matters. >> >>Incidentally (to correct a point made in an earlier post) *all* >>versions of DOS since 1.x have changed interrupt vectors. This is >>not a DOS 7+ phenomenon. The reason FBSDBOOT.EXE is deprecated at >>this stage is that, in the future, VM86 will be increasingly relied >>on by FreeBSD. And FBSDBOOT.EXE has *never* worked reliably in a >>VM86 context. >> >>-- >>Robert Nordier >> >> >>To Unsubscribe: send mail to majord...@freebsd.org >>with "unsubscribe freebsd-current" in the body of the message >> > > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Thanks to all who pitched in their input to this issue. Most users of my system are running Windows and don't want to have to reformat or repartition their hard disk. So I am stuck with the DOS file system. I think the best solution is to have my users use a FreeBSD boot floppy. The floppy will have /boot/loader which I will point to the DOS-formatted hard disk in which the kernel resides. >The flags and values in the BIOS data area would not necessarily >be at their default values, so restoring the vectors might itself >crash the BIOS (because it's reconfigured itself for the present >vectors/drivers, not the default ones). > >Some hardware (eg. popular SCSI controllers) also configures itself >differently when it finds it's running on DOS/Windows. This kind >of thing in any scenario in which we start DOS then kill it would >have the potential to seriously confuse matters. > >Incidentally (to correct a point made in an earlier post) *all* >versions of DOS since 1.x have changed interrupt vectors. This is >not a DOS 7+ phenomenon. The reason FBSDBOOT.EXE is deprecated at >this stage is that, in the future, VM86 will be increasingly relied >on by FreeBSD. And FBSDBOOT.EXE has *never* worked reliably in a >VM86 context. > >-- >Robert Nordier > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
> > > > Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 > > > > boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel > > > > and hence the whole system. > > > > > > Obviously it makes no sense at all to make special DOS boot floppy with > > > old > er DOS > > > just to run FBSDBOOT - it simply enough to make "native" FreeBSD boot > > > flopp > y with > > > /boot/loader and hacked /boot/loader.conf to boot kernel from your hard > > > dri > ve, so it > > > seems that FBSDBOOT now totally useless :( > > > > > > Sincerely, > > > > > > Maxim > > > > > Why can't we make a copy of the vector table and save to file and have > > fbsdboot use the table from the file? > > How do we get this vector table in the first place? > > How do we keep it updated? The flags and values in the BIOS data area would not necessarily be at their default values, so restoring the vectors might itself crash the BIOS (because it's reconfigured itself for the present vectors/drivers, not the default ones). Some hardware (eg. popular SCSI controllers) also configures itself differently when it finds it's running on DOS/Windows. This kind of thing in any scenario in which we start DOS then kill it would have the potential to seriously confuse matters. Incidentally (to correct a point made in an earlier post) *all* versions of DOS since 1.x have changed interrupt vectors. This is not a DOS 7+ phenomenon. The reason FBSDBOOT.EXE is deprecated at this stage is that, in the future, VM86 will be increasingly relied on by FreeBSD. And FBSDBOOT.EXE has *never* worked reliably in a VM86 context. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
On May 05, 1999 at 12:27:31PM -0700, Mike Smith wrote: > The issue here is that the BIOS will tell us how much memory we are > _allowed_to_use_, which is not always the same as the amount of > physical memory present in the system. Some memory may be (is > sometimes) reserved for use by eg. APM/ACPI. We fare badly at the > moment on these systems because we ignore this and use all the memory > we can find. Yup. That's probably the problem with the Thinkpads; the code patch I just sent out will dump the ACPI System Address map, so I can figure out what is happening. I bet that it declares one memory range for all the ram, and then overlays a second "reserved" address on top of it. Right now, I don't handle that correctly. It "should" be simple to write some code to aggregate this map and fill in the phys_avail[] structure; then the entire memory probe in machdep.c can go away. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
> > > Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 > > > boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel > > > and hence the whole system. > > > > Obviously it makes no sense at all to make special DOS boot floppy with > > older DOS > > just to run FBSDBOOT - it simply enough to make "native" FreeBSD boot > > floppy with > > /boot/loader and hacked /boot/loader.conf to boot kernel from your hard > > drive, so it > > seems that FBSDBOOT now totally useless :( > > > > Sincerely, > > > > Maxim > > > Why can't we make a copy of the vector table and save to file and have > fbsdboot use the table from the file? How do we get this vector table in the first place? How do we keep it updated? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> > Not at all. If there's 640k chopped off the end of eg. 128M of > > physical memory, you'd have to use a 64M segment, a 32M segment, a 16M > > segment, an 8M segment, a 4M segment, a 2M segment, a 1M segment, a > > 256k segment and a 128k segment to map it accurately. That's 9 > > variable MTRRs, and the P6 only has 8. > > > No you don't need that many, fixed MTRRs take precedence over variable MTRRs, > so you can just use one variable segment covering 0-128M and override with > fixed MTRRs in the low memory area. I specifically said "640k chopped off the end", referring to the possibly non-aligned _end_ of physical memory. The issue here is that the BIOS will tell us how much memory we are _allowed_to_use_, which is not always the same as the amount of physical memory present in the system. Some memory may be (is sometimes) reserved for use by eg. APM/ACPI. We fare badly at the moment on these systems because we ignore this and use all the memory we can find. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
On May 05, 1999 at 03:38:05AM -0400, Jerry Alexandratos wrote:
> Jonathan Lemon says:
> :
> : Not true. VM86 is also required to support VESA. Also, it is used
> : for reliable memory detection (which is why I want to make it mandatory).
> : No more "My Stinkpad only detected 64M, what do I do now??!" questions.
>
> Actually, even with VM86, the kernel still doesn't correctly detect the
> StinkPad's memory.
Hm, if that's so, then it's an implementation bug. Can you try the
following patch, boot the system with the -v flag, and mail me back
the result of the dmesg output?
--
Jonathan
Index: i386/i386/vm86.c
===
RCS file: /tuna/ncvs/src/sys/i386/i386/vm86.c,v
retrieving revision 1.25
diff -u -r1.25 vm86.c
--- vm86.c 1999/05/12 21:38:45 1.25
+++ vm86.c 1999/05/19 15:47:10
@@ -41,6 +41,7 @@
#include
#include
+#include
#include
#include
@@ -524,6 +525,13 @@
*pte = (1 << PAGE_SHIFT) | PG_RW | PG_V;
/*
+* use whatever is leftover of the vm86 page layout as a
+* message buffer so we can capture early output.
+*/
+ msgbufinit((vm_offset_t)vm86paddr + sizeof(struct vm86_layout),
+ ctob(3) - sizeof(struct vm86_layout));
+
+ /*
* get memory map with INT 15:E820
*/
#define SMAPSIZsizeof(*smap)
@@ -541,6 +549,13 @@
i = vm86_datacall(0x15, &vmf, &vmc);
if (i || vmf.vmf_eax != SMAP_SIG)
break;
+ if (boothowto & RB_VERBOSE)
+ printf("SMAP type=%02x base=%08x %08x len=%08x %08x\n",
+ smap->type,
+ *(u_int32_t *)((char *)&smap->base + 4),
+ (u_int32_t)smap->base,
+ *(u_int32_t *)((char *)&smap->length + 4),
+ (u_int32_t)smap->length);
if (smap->type == 0x01 && smap->base >= highwat) {
*extmem += (smap->length / 1024);
highwat = smap->base + smap->length;
Index: kern/subr_prf.c
===
RCS file: /tuna/ncvs/src/sys/kern/subr_prf.c,v
retrieving revision 1.51
diff -u -r1.51 subr_prf.c
--- subr_prf.c 1998/12/03 04:45:56 1.51
+++ subr_prf.c 1999/03/19 19:10:47
@@ -674,10 +674,24 @@
}
}
+static void
+msgbufcopy(struct msgbuf *oldp)
+{
+ int pos;
+
+ pos = oldp->msg_bufr;
+ while (pos != oldp->msg_bufx) {
+ msglogchar(oldp->msg_ptr[pos], NULL);
+ if (++pos >= oldp->msg_size)
+ pos = 0;
+ }
+}
+
void
msgbufinit(void *ptr, size_t size)
{
char *cp;
+ static struct msgbuf *oldp = NULL;
cp = (char *)ptr;
msgbufp = (struct msgbuf *) (cp + size - sizeof(*msgbufp));
@@ -687,7 +701,10 @@
msgbufp->msg_size = (char *)msgbufp - cp;
msgbufp->msg_ptr = cp;
}
+ if (msgbufmapped && oldp != msgbufp)
+ msgbufcopy(oldp);
msgbufmapped = 1;
+ oldp = msgbufp;
}
#include "opt_ddb.h"
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
> > Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 > > boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel > > and hence the whole system. > > Obviously it makes no sense at all to make special DOS boot floppy with older > DOS > just to run FBSDBOOT - it simply enough to make "native" FreeBSD boot floppy > with > /boot/loader and hacked /boot/loader.conf to boot kernel from your hard > drive, so it > seems that FBSDBOOT now totally useless :( > > Sincerely, > > Maxim > Why can't we make a copy of the vector table and save to file and have fbsdboot use the table from the file? -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> Not at all. If there's 640k chopped off the end of eg. 128M of > physical memory, you'd have to use a 64M segment, a 32M segment, a 16M > segment, an 8M segment, a 4M segment, a 2M segment, a 1M segment, a > 256k segment and a 128k segment to map it accurately. That's 9 > variable MTRRs, and the P6 only has 8. > No you don't need that many, fixed MTRRs take precedence over variable MTRRs, so you can just use one variable segment covering 0-128M and override with fixed MTRRs in the low memory area. > -- > \\ The mind's the standard \\ Mike Smith > \\ of the man. \\ msm...@freebsd.org > \\-- Joseph Merrick \\ msm...@cdrom.com > > > -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> > Jonathan Lemon says: > > : > > : Not true. VM86 is also required to support VESA. Also, it is used > > : for reliable memory detection (which is why I want to make it mandatory). > > : No more "My Stinkpad only detected 64M, what do I do now??!" questions. > > > > Actually, even with VM86, the kernel still doesn't correctly detect the > > StinkPad's memory. This is because the BIOS probe results are still ignored. 8( > It just occurred to me that we might be able to use initial MTRR settings > by BIOS for memory detection (P6 and above, of course). Don't know how > reliable that is. Not at all. If there's 640k chopped off the end of eg. 128M of physical memory, you'd have to use a 64M segment, a 32M segment, a 16M segment, an 8M segment, a 4M segment, a 2M segment, a 1M segment, a 256k segment and a 128k segment to map it accurately. That's 9 variable MTRRs, and the P6 only has 8. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Matthew Thyer wrote: > Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 > boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel > and hence the whole system. Obviously it makes no sense at all to make special DOS boot floppy with older DOS just to run FBSDBOOT - it simply enough to make "native" FreeBSD boot floppy with /boot/loader and hacked /boot/loader.conf to boot kernel from your hard drive, so it seems that FBSDBOOT now totally useless :( Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
The problem is that recent versions of MS-DOS (version 7 and above ? ...definitely the DOS that comes with Windows 98 and I think the DOS with Windows 95 under some circumstances) change various vectors which destroy FBSDBOOTs ability to work (this is because there is no way to determine where these vectors used to point and the original addresses are required for correct operation of either FBSDBOOT or the kernel/ loader). What I do know is that at least some older versions of MS-DOS do not do this. Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel and hence the whole system. Hopefully now that Carlos Tapang has updated FBSDBOOT.EXE for ELF, such a boot floppy could boot a 3.1, 3.2 or -CURRENT system. Unfortunately the project cannot guarantee anything when you are booting from another vendor's operating system (such as MS-DOS) so its a lot easier to say that FBSDBOOT.EXE has been retired. Given the number of different DOSes that exist, that's an entirely understandable policy. I hope this clears things up (and adds a good summary to the archives). "Carlos C. Tapang" wrote: > > Mike, Thanks for trying fbsdboot.exe. I need more information to fix it. I > would like to fix it, so please describe exactly what the problem is. What > do you mean by the "need to reboot the system to restore various vectors > that DOS destroys"? Do you mean that prior to executing the FreeBSD kernel > init routines, DOS does something to the loaded area? I'm sorry I can't find > any info on this either in the mail threads or in freebsd.org. Probably I'm > not looking hard enough, but I believe it would be more efficient to just > ask you. > > Carlos C. Tapang > http://www.genericwindows.com > > -Original Message- > From: Mike Smith > To: Carlos C. Tapang > Cc: Bob Bishop ; Mike Smith ; > curr...@freebsd.org > Date: Sunday, May 16, 1999 7:28 PM > Subject: Re: FBSDBOOT.EXE > > >> >It doesn't work. Don't use it. You need to reboot the system to > >> >restore various vectors that DOS destroys. Please see the previous > >> >threads on this topic, especially anything from Robert Nordier. > >> > > >> The most relevant piece I can find from R. Nordier is the following: > >> "The fbsdboot.exe program should probably be considered obsolete. It > >> should (in theory) be possible to use it to load /boot/loader, which > >> can then load the kernel, but there are various reasons this doesn't > >> work too well." > > > >These reasons were also expounded, and I did summarise them in another > >message on this thread. > > > >> I have not tested the updated program with /boot/loader. /boot/loader does > >> not help me because my root directory is in a memory file system, and I can > >> not assume that my users will want to reformat their DOS drives or even > >> repartition it. So all FreeBSD files are in the DOS file system. > > > >The loader won't help you because you are booting from under DOS, but > >the loader will boot the kernel just fine off a DOS filesystem. > > > >-- > >\\ Sometimes you're ahead, \\ Mike Smith > >\\ sometimes you're behind. \\ m...@smith.net.au > >\\ The race is long, and in the \\ msm...@freebsd.org > >\\ end it's only with yourself. \\ msm...@cdrom.com > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> Jonathan Lemon says: > : > : Not true. VM86 is also required to support VESA. Also, it is used > : for reliable memory detection (which is why I want to make it mandatory). > : No more "My Stinkpad only detected 64M, what do I do now??!" questions. > > Actually, even with VM86, the kernel still doesn't correctly detect the > StinkPad's memory. > > --Jerry > > name: Jerry Alexandratos || Open-Source software isn't a > phone: 302.521.1018 || matter of life or death... > email: jalex...@perspectives.net || ...It's much more important > || than that! It just occurred to me that we might be able to use initial MTRR settings by BIOS for memory detection (P6 and above, of course). Don't know how reliable that is. -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
Jonathan Lemon says: : : Not true. VM86 is also required to support VESA. Also, it is used : for reliable memory detection (which is why I want to make it mandatory). : No more "My Stinkpad only detected 64M, what do I do now??!" questions. Actually, even with VM86, the kernel still doesn't correctly detect the StinkPad's memory. --Jerry name: Jerry Alexandratos || Open-Source software isn't a phone: 302.521.1018 || matter of life or death... email: jalex...@perspectives.net || ...It's much more important || than that! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
On May 05, 1999 at 05:00:16PM -0700, Carlos C. Tapang wrote: > > > >In a nutshell, there is a table of interrupt vectors which is set > >by the BIOS at boot time, which are used by the loader (and by the > >FreeBSD kernel, if VM86 is turned on). > > > Thanks, Jonathan. Are any of the following TRUE? > 1. FreeBSD is affected by these vectors only if VM86 is turned ON. Um, I would say that is true. Robert Nordier or Mike Smith may want to step in here and correct me as to what the loader is doing, but I think the kernel only uses the interrupt vectors if VM86 is on. > 2. If somebody is using VM86, s/he must be using DOSEMU or some other DOS > emulator also (I can't think of anything else one would use VM86 for). Not true. VM86 is also required to support VESA. Also, it is used for reliable memory detection (which is why I want to make it mandatory). No more "My Stinkpad only detected 64M, what do I do now??!" questions. > 3. DOSEMU or any other DOS emulator re-initializes the DOS vectors for > virtualization. True - ``doscmd'' has a virtual copy of the vectors that it initializes itself, and doesn't use the actual DOS vectors at all. > Basically, what I am guessing is that probably we can fix the problem during > vm86 or DOSEMU initialization. I am going to enable vm86 on my system and > see what happens. Right now I am not experiencing any problems, and that's > probably because I do not have vm86 enabled. The problem only comes into play during case 2; where the kernel actually calls the BIOS. The difficulty is that while FBSDBOOT.EXE may work in some cases, it is not guaranteed to work in _all_ cases (which causes a support nightmare). -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> >In a nutshell, there is a table of interrupt vectors which is set >by the BIOS at boot time, which are used by the loader (and by the >FreeBSD kernel, if VM86 is turned on). > Thanks, Jonathan. Are any of the following TRUE? 1. FreeBSD is affected by these vectors only if VM86 is turned ON. 2. If somebody is using VM86, s/he must be using DOSEMU or some other DOS emulator also (I can't think of anything else one would use VM86 for). 3. DOSEMU or any other DOS emulator re-initializes the DOS vectors for virtualization. Basically, what I am guessing is that probably we can fix the problem during vm86 or DOSEMU initialization. I am going to enable vm86 on my system and see what happens. Right now I am not experiencing any problems, and that's probably because I do not have vm86 enabled. --Carlos To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> DOS, when it boots, loads itself into memory somewhere, and then > changes the interrupt vectors to point to itself. How does Linux do it with loadlin? Tim To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
In article you write: >Mike, Thanks for trying fbsdboot.exe. I need more information to fix it. I >would like to fix it, so please describe exactly what the problem is. What >do you mean by the "need to reboot the system to restore various vectors >that DOS destroys"? Do you mean that prior to executing the FreeBSD kernel >init routines, DOS does something to the loaded area? I'm sorry I can't find >any info on this either in the mail threads or in freebsd.org. Probably I'm >not looking hard enough, but I believe it would be more efficient to just >ask you. In a nutshell, there is a table of interrupt vectors which is set by the BIOS at boot time, which are used by the loader (and by the FreeBSD kernel, if VM86 is turned on). DOS, when it boots, loads itself into memory somewhere, and then changes the interrupt vectors to point to itself. The problem is, when the kernel/loader is loaded by fbsdboot.exe, DOS is overwritten. This results in the interrupt vectors pointing to garbage, which causes "bad things" (tm) when the they are used. Even if we don't stomp on DOS, I don't quite think that a BIOS call that ends up calling a DOS routine will do the right thing. There isn't any way (AFAIK) to restore the vectors to the original BIOS boot state. You may want to search the archives for "vm86" and "terry lambert", (IIRC), for some hypothetical solutions that have been proposed for this problem. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
Mike, Thanks for trying fbsdboot.exe. I need more information to fix it. I would like to fix it, so please describe exactly what the problem is. What do you mean by the "need to reboot the system to restore various vectors that DOS destroys"? Do you mean that prior to executing the FreeBSD kernel init routines, DOS does something to the loaded area? I'm sorry I can't find any info on this either in the mail threads or in freebsd.org. Probably I'm not looking hard enough, but I believe it would be more efficient to just ask you. Carlos C. Tapang http://www.genericwindows.com -Original Message- From: Mike Smith To: Carlos C. Tapang Cc: Bob Bishop ; Mike Smith ; curr...@freebsd.org Date: Sunday, May 16, 1999 7:28 PM Subject: Re: FBSDBOOT.EXE >> >It doesn't work. Don't use it. You need to reboot the system to >> >restore various vectors that DOS destroys. Please see the previous >> >threads on this topic, especially anything from Robert Nordier. >> > >> The most relevant piece I can find from R. Nordier is the following: >> "The fbsdboot.exe program should probably be considered obsolete. It >> should (in theory) be possible to use it to load /boot/loader, which >> can then load the kernel, but there are various reasons this doesn't >> work too well." > >These reasons were also expounded, and I did summarise them in another >message on this thread. > >> I have not tested the updated program with /boot/loader. /boot/loader does >> not help me because my root directory is in a memory file system, and I can >> not assume that my users will want to reformat their DOS drives or even >> repartition it. So all FreeBSD files are in the DOS file system. > >The loader won't help you because you are booting from under DOS, but >the loader will boot the kernel just fine off a DOS filesystem. > >-- >\\ Sometimes you're ahead, \\ Mike Smith >\\ sometimes you're behind. \\ m...@smith.net.au >\\ The race is long, and in the \\ msm...@freebsd.org >\\ end it's only with yourself. \\ msm...@cdrom.com > > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
On Mon, 17 May 1999, Mike Smith wrote: > > > It doesn't work. Don't use it. You need to reboot the system to > > > restore various vectors that DOS destroys. Please see the previous > > > threads on this topic, especially anything from Robert Nordier. > > > > Would it be possible to add a driver to config.sys which could record the > > various vectors or is that too late? > > We've been here and asked this; it's too late. Feel free to ask Robert > for the details, or just trust me. 8) Sure. I'm just thinking aloud :-) > > The only way to get a clean slate with the system is to reboot. If you > can arrange a "controlled" reboot of some sort, we might get somewhere. If you are going to reboot anyway, its not too much to ask for a bootable floppy/cd to be inserted. I don't think fbsdboot.exe has much practical value at this time. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> > It doesn't work. Don't use it. You need to reboot the system to > > restore various vectors that DOS destroys. Please see the previous > > threads on this topic, especially anything from Robert Nordier. > > Would it be possible to add a driver to config.sys which could record the > various vectors or is that too late? We've been here and asked this; it's too late. Feel free to ask Robert for the details, or just trust me. 8) The only way to get a clean slate with the system is to reboot. If you can arrange a "controlled" reboot of some sort, we might get somewhere. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
On Sun, 16 May 1999, Mike Smith wrote: > > Hi, > > > > At 15:22 11/05/99 -0700, you wrote: > > >Because I need it, I have upgraded fbsdboot.exe so now it can recognize > > >ELF. > > >If anybody else needs it, please let me know and I'll see what I can do for > > >you. > > > > I'm going to have a use for it RSN > > It doesn't work. Don't use it. You need to reboot the system to > restore various vectors that DOS destroys. Please see the previous > threads on this topic, especially anything from Robert Nordier. Would it be possible to add a driver to config.sys which could record the various vectors or is that too late? -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> The loader won't help you because you are booting from under DOS, but > the loader will boot the kernel just fine off a DOS filesystem. I'd like to understand this aspect of the loader better. This mode might be useful for booting from (for example) a DOS flash filesystem? Um... off to the source code. Thanks for the tip. Cheers, Jerry Hicks wghi...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> >It doesn't work. Don't use it. You need to reboot the system to > >restore various vectors that DOS destroys. Please see the previous > >threads on this topic, especially anything from Robert Nordier. > > > The most relevant piece I can find from R. Nordier is the following: > "The fbsdboot.exe program should probably be considered obsolete. It > should (in theory) be possible to use it to load /boot/loader, which > can then load the kernel, but there are various reasons this doesn't > work too well." These reasons were also expounded, and I did summarise them in another message on this thread. > I have not tested the updated program with /boot/loader. /boot/loader does > not help me because my root directory is in a memory file system, and I can > not assume that my users will want to reformat their DOS drives or even > repartition it. So all FreeBSD files are in the DOS file system. The loader won't help you because you are booting from under DOS, but the loader will boot the kernel just fine off a DOS filesystem. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
>It doesn't work. Don't use it. You need to reboot the system to >restore various vectors that DOS destroys. Please see the previous >threads on this topic, especially anything from Robert Nordier. > The most relevant piece I can find from R. Nordier is the following: "The fbsdboot.exe program should probably be considered obsolete. It should (in theory) be possible to use it to load /boot/loader, which can then load the kernel, but there are various reasons this doesn't work too well." I have not tested the updated program with /boot/loader. /boot/loader does not help me because my root directory is in a memory file system, and I can not assume that my users will want to reformat their DOS drives or even repartition it. So all FreeBSD files are in the DOS file system. --Carlos To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
On Sun, 16 May 1999, Mike Smith wrote: > > Hi, > > > > At 15:22 11/05/99 -0700, you wrote: > > >Because I need it, I have upgraded fbsdboot.exe so now it can recognize > > >ELF. > > >If anybody else needs it, please let me know and I'll see what I can do for > > >you. > > > > I'm going to have a use for it RSN > > It doesn't work. Don't use it. You need to reboot the system to > restore various vectors that DOS destroys. Please see the previous > threads on this topic, especially anything from Robert Nordier. > > Well, it works for me. The only problem is that fbsdboot never returns, allowing win98 to clean up. Therefore win98 tries to start my "dos program" on each boot. Luckily I have C: accessible as /c, so I could edit autoexec.bat and config.sys Leif To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> Hi, > > At 15:22 11/05/99 -0700, you wrote: > >Because I need it, I have upgraded fbsdboot.exe so now it can recognize ELF. > >If anybody else needs it, please let me know and I'll see what I can do for > >you. > > I'm going to have a use for it RSN It doesn't work. Don't use it. You need to reboot the system to restore various vectors that DOS destroys. Please see the previous threads on this topic, especially anything from Robert Nordier. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
The binary is now available by anonymous ftp at ftp.genericwindows.com in the pub directory. If you have problems, please email me directly. Carlos C. Tapang http://www.genericwindows.com -Original Message- From: Max Khon To: Carlos C. Tapang Cc: Jordan K. Hubbard ; freebsd-current@FreeBSD.ORG Date: Tuesday, May 11, 1999 10:45 PM Subject: Re: FBSDBOOT.EXE >hi, there! > >On Tue, 11 May 1999, Carlos C. Tapang wrote: > >> Because I need it, I have upgraded fbsdboot.exe so now it can recognize ELF. >> If anybody else needs it, please let me know and I'll see what I can do for >> you. >> ps. I had to use my old Microsoft Visual C++ (ver 1.5) to do this >> modification. > >where can I get the diffs or binaries? > >/fjoe > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
hi, there! On Tue, 11 May 1999, Carlos C. Tapang wrote: > Because I need it, I have upgraded fbsdboot.exe so now it can recognize ELF. > If anybody else needs it, please let me know and I'll see what I can do for > you. > ps. I had to use my old Microsoft Visual C++ (ver 1.5) to do this > modification. where can I get the diffs or binaries? /fjoe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
Hi, At 15:22 11/05/99 -0700, you wrote: >Because I need it, I have upgraded fbsdboot.exe so now it can recognize ELF. >If anybody else needs it, please let me know and I'll see what I can do for >you. I'm going to have a use for it RSN >ps. I had to use my old Microsoft Visual C++ (ver 1.5) to do this >modification. Ick. I was hoping for a 32bit build at least, although I suppose it doesn't matter much. Will you be posting diffs? -- Bob Bishop +44 118 977 4017 r...@gid.co.uk fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
Because I need it, I have upgraded fbsdboot.exe so now it can recognize ELF. If anybody else needs it, please let me know and I'll see what I can do for you. ps. I had to use my old Microsoft Visual C++ (ver 1.5) to do this modification. Carlos C. Tapang http://www.genericwindows.com -Original Message- From: Jordan K. Hubbard To: Carlos C. Tapang Cc: freebsd-current@FreeBSD.ORG Date: Saturday, May 01, 1999 5:54 PM Subject: Re: FBSDBOOT.EXE >> Is there anybody out there working on upgrading fbsdboot.exe so that it can >> recognize ELF? > >I believe that fbsdboot.exe has, instead, simply been retired. Sorry >I don't have better news than this. > >- Jordan > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> Won't fbsdboot.exe be able to boot /boot/loader? (maybe I am just naive) > (or could it be modified to do so with little effort?) We've had this discussion. No. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> Does this mean that install.bat will disappear as well? It already did. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
On Saturday, 1 May 1999 at 17:54:26 -0700, Jordan K. Hubbard wrote: >> Is there anybody out there working on upgrading fbsdboot.exe so that it can >> recognize ELF? > > I believe that fbsdboot.exe has, instead, simply been retired. Sorry > I don't have better news than this. Does this mean that install.bat will disappear as well? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> Won't fbsdboot.exe be able to boot /boot/loader? (maybe I am just naive) > (or could it be modified to do so with little effort?) Good question - you tell me. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
Won't fbsdboot.exe be able to boot /boot/loader? (maybe I am just naive) (or could it be modified to do so with little effort?) -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
> Is there anybody out there working on upgrading fbsdboot.exe so that it can > recognize ELF? I believe that fbsdboot.exe has, instead, simply been retired. Sorry I don't have better news than this. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
FBSDBOOT.EXE
Is there anybody out there working on upgrading fbsdboot.exe so that it can recognize ELF? Carlos C. Tapang http://www.genericwindows.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
