Re: emm386 hangs when booting from linux

[Kasper Dupont <kasperd@daimi.au.dk>]

"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:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);