hello,
for some reason, I am using the "switch to 16 bit realmode" function
present in the linux kernel to execute various 16bit code. One thing
that I am doing is to read the mbr off a harddisk to 0x7c00 and then
jump to there. This allows to e.g. "quickboot dos" from linux without
having to go through bios startup.
I got this working with *one* exception: as soon as I load emm386
in config.sys, the system hangs. It doesn't hang completely, e.g.
the num-lock led changes light when pressing num-lock, and ctrlaltdel
reboots the system. When I "REM"ark the emm386.exe, then dos will
boot and display a "C:\>" prompt.
"machine_real_restart" is in <arch/i386/kernel/process.c> - possibly
it forgets to reset something particular in the cpu/mmu...and later on,
emm386.exe will hang the system. Interestingly, DOS4GW will *not* hang
the system and vertex-inducing games like doom & co. will work like
a charm (woah ... I haven't been playing doom for ages! <streisand> "memories"
</streisand>).
emm386.exe is about 116k byte, so it's probably not written in asm.
I've been searching the web for source-code for some emm, but so far,
no luck. any hint about what could be wrong? maybe I am only 1 bit
away from success, but I will like searching the bit in the haystack.
thanks in advance,
herp
[...]
> "machine_real_restart" is in <arch/i386/kernel/process.c> - possibly
> it forgets to reset something particular in the cpu/mmu...and later on,
> emm386.exe will hang the system. Interestingly, DOS4GW will *not* hang
> the system and vertex-inducing games like doom & co. will work like
^^^^^^
read: "vertigo-inducing games" I've been doing
too much computer graphics today ;-)
thanks,
herp
On Fri, 28 Feb 2003, H.Rosmanith (Kernel Mailing List) wrote:
>
> hello,
>
> for some reason, I am using the "switch to 16 bit realmode" function
> present in the linux kernel to execute various 16bit code. One thing
> that I am doing is to read the mbr off a harddisk to 0x7c00 and then
> jump to there. This allows to e.g. "quickboot dos" from linux without
> having to go through bios startup.
>
> I got this working with *one* exception: as soon as I load emm386
> in config.sys, the system hangs. It doesn't hang completely, e.g.
> the num-lock led changes light when pressing num-lock, and ctrlaltdel
> reboots the system. When I "REM"ark the emm386.exe, then dos will
> boot and display a "C:\>" prompt.
So you are trying a "home-brew" DOS-EMU which already exists and works
well.
emm386.exe attempts to go to protected mode. That's how it works.
That's how it's able to make "high-RAM" appear in "low-RAM" windows
for the emm386 specification. Of course it will fail when you
are in virtual 386 mode. The real DOS-EMU emulates the extended/expanded
memory specification so you don't need this in 'config.sys'. I sometimes
boot real DOS usinf DOS-EMU and it works fine. You need to configure
it so it will look at, say config.emu, instead of the DOS config.sys.
That way, you can keep boot-specific configuration files.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
"Richard B. Johnson" wrote:
>
> On Fri, 28 Feb 2003, H.Rosmanith (Kernel Mailing List) wrote:
>
> >
> > hello,
> >
> > for some reason, I am using the "switch to 16 bit realmode" function
> > present in the linux kernel to execute various 16bit code. One thing
> > that I am doing is to read the mbr off a harddisk to 0x7c00 and then
> > jump to there. This allows to e.g. "quickboot dos" from linux without
> > having to go through bios startup.
> >
> > I got this working with *one* exception: as soon as I load emm386
> > in config.sys, the system hangs. It doesn't hang completely, e.g.
> > the num-lock led changes light when pressing num-lock, and ctrlaltdel
> > reboots the system. When I "REM"ark the emm386.exe, then dos will
> > boot and display a "C:\>" prompt.
>
> So you are trying a "home-brew" DOS-EMU which already exists and works
> well.
No, that was not what he wrote. Try reading it again. There is
nothing being emulated there.
> emm386.exe attempts to go to protected mode. That's how it works.
Yes.
> That's how it's able to make "high-RAM" appear in "low-RAM" windows
> for the emm386 specification. Of course it will fail when you
> are in virtual 386 mode.
First of all IIRC emm will fail before it attempts to enter
protected mode. It will use some status function to read the
current mode and if it finds the CPU in vm86 mode, emm plain
refuses to work. (Insert appropriate rant about vm86 design
here.) But in this particular case the CPU is not in vm86
mode, but rather in real mode. Loading emm should work.
> The real DOS-EMU emulates the extended/expanded
> memory specification so you don't need this in 'config.sys'. I sometimes
> boot real DOS usinf DOS-EMU and it works fine. You need to configure
> it so it will look at, say config.emu, instead of the DOS config.sys.
> That way, you can keep boot-specific configuration files.
But an emulator is not always usable as a replacement for a
real DOS. There are some things you cannot do under the
emulation.
Booting DOS from Linux is not as easy as booting Linux from
DOS. DOS relies much more on the BIOS, and the state of the
computer as it is setup by the BIOS. What needs to be right
for DOS to work is the contents of the BIOS data areas of
RAM, and the interrupt vector table, and state of some of
the hardware.
It is surprising it worked that well. You can't even boot
DOS from DOS, DOS will have changed interrupt vectors which
would cause a second DOS to fail. If Linux is booted from
LOADLIN there will already be messed enough with the
interrupt vector table, that there is no hope of returning
to real mode and have a usable BIOS. Linux will AFAIK not
touch the interrupt vector table, but you need a loader,
that operates early enough and doesn't change them either.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
> On Fri, 28 Feb 2003, H.Rosmanith (Kernel Mailing List) wrote:
>
> >
> > hello,
> >
> > for some reason, I am using the "switch to 16 bit realmode" function
> > present in the linux kernel to execute various 16bit code. One thing
> > that I am doing is to read the mbr off a harddisk to 0x7c00 and then
> > jump to there. This allows to e.g. "quickboot dos" from linux without
> > having to go through bios startup.
> >
> > I got this working with *one* exception: as soon as I load emm386
> > in config.sys, the system hangs. It doesn't hang completely, e.g.
> > the num-lock led changes light when pressing num-lock, and ctrlaltdel
> > reboots the system. When I "REM"ark the emm386.exe, then dos will
> > boot and display a "C:\>" prompt.
>
> So you are trying a "home-brew" DOS-EMU which already exists and works
> well.
hm?
I am trying to boot "real" DOS from linux.
> emm386.exe attempts to go to protected mode. That's how it works.
and when going into protected mode, it crashes. I wonder why. I can
start DOS4GW, which does not crash, and I think that DOS4GW too works
with the protected mode features of the CPU.
> That's how it's able to make "high-RAM" appear in "low-RAM" windows
> for the emm386 specification. Of course it will fail when you
> are in virtual 386 mode. The real DOS-EMU emulates the extended/expanded
after executing "machine_real_start", the system is in 16 bit real mode,
not in vm86 mode.
> memory specification so you don't need this in 'config.sys'. I sometimes
> boot real DOS usinf DOS-EMU and it works fine. You need to configure
> it so it will look at, say config.emu, instead of the DOS config.sys.
> That way, you can keep boot-specific configuration files.
the problem is not only with DOS. when booting M$-Windows (w2k), the
boot-process will hang as soon as w2k tries to enter protected mode.
starting loadlin will hang the system too, as I just found out. hm,
well, at least it's easier looking into loadlin than looking into
emm386 !
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
> Why is the government concerned about the lunatic fringe? Think about it.
>
>
> Booting DOS from Linux is not as easy as booting Linux from
> DOS. DOS relies much more on the BIOS, and the state of the
> computer as it is setup by the BIOS. What needs to be right
> for DOS to work is the contents of the BIOS data areas of
> RAM, and the interrupt vector table, and state of some of
> the hardware.
as far as I know, linux does not touch the BIOS data areas,
and "machine_real_start" sets the IDT to 0,3ff again (the
contents of the real-mode IDT are not modified by linux).
the only piece of hardware neccessary to reset was the interrupt
controller, in particular, the IRQ mapping.
> It is surprising it worked that well. You can't even boot
> DOS from DOS, DOS will have changed interrupt vectors which
> would cause a second DOS to fail. If Linux is booted from
> LOADLIN there will already be messed enough with the
interesting that you mention loadlin. when I run loadlin in a
DOS which I booted from linux, (boot linux->boot dos->boot linux),
the 2nd linux boot (by loadlin) will hang with the following message:
C:\LOADLIN> loadlin
[...]
Your current DOS/CPU configuration is:
load buffer size: 0x[*HANGING*]
This looks promising. I think I gonna download loadlin source now :-)
On the other hand, when instead of loadling MBR and executing it, I
do a far jmp to 0xf000:0xfff0 from "machine_real_start", normal
boot-procedure is exected without haning anywhere. So I think that the
bios-setup is doing some kind of initialisation/modification to whatver(!?)
which the "machine_real_start" function does not.
thanks,
herbert rosmanith
"H.Rosmanith (Kernel Mailing List)" wrote:
>
> > Booting DOS from Linux is not as easy as booting Linux from
> > DOS. DOS relies much more on the BIOS, and the state of the
> > computer as it is setup by the BIOS. What needs to be right
> > for DOS to work is the contents of the BIOS data areas of
> > RAM, and the interrupt vector table, and state of some of
> > the hardware.
>
> as far as I know, linux does not touch the BIOS data areas,
> and "machine_real_start" sets the IDT to 0,3ff again (the
> contents of the real-mode IDT are not modified by linux).
I think you are right about that. But that of course only
helps if it was not modified by code before Linux is loaded.
> the only piece of hardware neccessary to reset was the interrupt
> controller, in particular, the IRQ mapping.
I believe you are right that the IRQ controller is the most
important hardware component to reprogram. But I don't think
it is the only. Certainly you ought to reprogram the PIT to
the right speed, but there might be other hardware that
needs to be reprogrammed as well.
>
> > It is surprising it worked that well. You can't even boot
> > DOS from DOS, DOS will have changed interrupt vectors which
> > would cause a second DOS to fail. If Linux is booted from
> > LOADLIN there will already be messed enough with the
>
> interesting that you mention loadlin. when I run loadlin in a
> DOS which I booted from linux, (boot linux->boot dos->boot linux),
> the 2nd linux boot (by loadlin) will hang with the following message:
>
> C:\LOADLIN> loadlin
> [...]
>
> Your current DOS/CPU configuration is:
> load buffer size: 0x[*HANGING*]
>
> This looks promising. I think I gonna download loadlin source now :-)
>
> On the other hand, when instead of loadling MBR and executing it, I
> do a far jmp to 0xf000:0xfff0 from "machine_real_start",
Isn't that code conventionally called by jumping to
0xffff:0x0000? (Not that it matters, because the first
instruction in all BIOSes I have seen is a jump to
0xf000:0xe05b.)
> normal
> boot-procedure is exected without haning anywhere. So I think that the
> bios-setup is doing some kind of initialisation/modification to whatver(!?)
> which the "machine_real_start" function does not.
Yes, the BIOS code usually knows almost everything that
needs to be initialized. If you are in real mode, and
jump to 0xFFFF:0x0000 there is almost nothing that can
possibly go wrong because you left some hardware in the
wrong state.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
> > On the other hand, when instead of loadling MBR and executing it, I
> > do a far jmp to 0xf000:0xfff0 from "machine_real_start",
>
> Isn't that code conventionally called by jumping to
> 0xffff:0x0000? (Not that it matters, because the first
> instruction in all BIOSes I have seen is a jump to
> 0xf000:0xe05b.)
my processor book says that a RESET sets cs to f000 and ip to fff0,
so I used the same values.
hello again,
I've still not found a solution, but at least I know what's happening
when emm386 or similar crash the system. e.g., when starting "loadlin"
(with no parameters!) the system will hang too. Reason is that loadlin
will generate an int 0x13, which is the general protection fault.
I wonder *why*. Well, the int 0x13 handler I wrote just writes
"int13" on top of the screen and does an iret, so the system will not
crash anymore, but of course, the programs wont work. Another
confusing thing I observed that even simply commands such as "copy <file1>
<file2>" cause an int13!? and that DOS will become unusable quite soon
(directories disappear and so on).
best regards,
herbert
> I've still not found a solution, but at least I know what's happening
> when emm386 or similar crash the system. e.g., when starting "loadlin"
> (with no parameters!) the system will hang too. Reason is that loadlin
> will generate an int 0x13, which is the general protection fault.
> I wonder *why*. Well, the int 0x13 handler I wrote just writes
just to be a bit more specific: yes, it is somehow related to
protected mode switching, but the in eflags, the VM86 bit is clear!
So I dont understand what's causing the fault.
best regards,
herbert
On 2 March 2003 12:26, H.Rosmanith (Kernel Mailing List) wrote:
> hello again,
>
> I've still not found a solution, but at least I know what's happening
> when emm386 or similar crash the system. e.g., when starting
> "loadlin" (with no parameters!) the system will hang too. Reason is
> that loadlin will generate an int 0x13, which is the general
int 0x0d (13 decimal) is a protections fault.
In DOS, int 0x13 is a BIOS interrupt for low-level disk io.
> protection fault. I wonder *why*. Well, the int 0x13 handler I wrote
> just writes "int13" on top of the screen and does an iret, so the
> system will not crash anymore, but of course, the programs wont work.
> Another confusing thing I observed that even simply commands such as
> "copy <file1> <file2>" cause an int13!? and that DOS will become
> unusable quite soon (directories disappear and so on).
It is to be expected when you kill int 0x13 ;)
BTW, you may try linld:
http://port.imtp.ilyichevsk.odessa.ua/linux/vda/linld/
instead of loadlin. Its source is way smaller ;)
--
vda