USB booting woes

[[e-mail]]

If I have a hard disk image burnt to USB and use
the BIOS to boot from USB in legacy mode, is
there some dependency for this to actually work,
specifically is INT 13H detected and redirected
by "the hardware"?

Such that if I copy the interrupt vector from
INT 13H to some other location, such as
INT 80H, and then attempt to do an INT 80H,
that won't work? Since it isn't the code at that
location that is so important, it is the interrupt
number itself? (not true of Bochs though).

If so, that would explain why PDOS/386 is not
booting from USB stick currently. It's just a theory
so far, I haven't isolated that yet. Here is the code
I am suspicious of, and the PIC remapping is
suspicious too (since I don't know what it is
doing).

#ifdef PDOS32
/* Copies BIOS interrupt vectors and remaps IRQs
* so they do not conflict with protected mode exceptions. */
{
disable();
/* 16 vectors from 0x10 to 0xA0. (BIOS calls) */
ivtCopyEntries(0xA0, 0x10, 16);
/* 8 vectors from 0x08 to 0xB0. (BIOS IRQ handlers 0 - 7) */
ivtCopyEntries(0xB0, 0x08, 8);
/* 8 vectors from 0x70 to 0xB8. (BIOS IRQ handlers 8 - 15) */
ivtCopyEntries(0xB8, 0x70, 8);
picRemap(0xB0, 0xB8);
enable();
}
#endif


Thanks. Paul.

[[e-mail]]

And another question.

If PDOS/386 was to directly manipulate the ATA
hard disk I/O ports like every other 32-bit operating
system does, would that prevent it from booting
from USB stick also?

If so, how do other operating systems manage to
boot from USB stick? Do they return to real mode
to do the BIOS interrupt?

Or do they detect that they are being booted from
USB stick and have code in place to read/write the
USB instead of pretending to be a hard disk?

Thanks. Paul.

[wolfgang kern]

Post by ***@gmail.com
And another question.
If PDOS/386 was to directly manipulate the ATA
hard disk I/O ports like every other 32-bit operating
system does, would that prevent it from booting
from USB stick also?

No of course, the boot process takes place before any OS could do something.

Post by ***@gmail.com
If so, how do other operating systems manage to
boot from USB stick? Do they return to real mode
to do the BIOS interrupt?

again, the OS got nothing to do with boot.

Post by ***@gmail.com
Or do they detect that they are being booted from
USB stick and have code in place to read/write the
USB instead of pretending to be a hard disk?

yeah, when the BIOS boots from USB it become a bit different and act as
if the USB device is a FD or HD or even a CD.
an OS which boots from USB may have restricted access to other device.

Search for Ben Lunt's advice on this, he is our USB expert.
__
wolfgang

[[e-mail]]

Post by wolfgang kern

Post by ***@gmail.com
If PDOS/386 was to directly manipulate the ATA
hard disk I/O ports like every other 32-bit operating
system does, would that prevent it from booting
from USB stick also?

No of course, the boot process takes place before any OS could do something.

That's not what I meant. What I mean is that when a
USB looks like a hard disk, and the OS is booted
like a hard disk, when a switch to protected mode is
made, and the BIOS is nominally no longer available,
at this point the OS needs to switch to manipulating
the I/O port for the hard disk. If it actually does this
(remembering that the hard disk is faked still), will
it fail?

With PDOS/386 I return to real mode to do the BIOS
interrupt, so I always go through the same process
that the boot sequence went through, to access the
faked hard disk.

BFN. Paul.

[Rod Pemberton]

On Thu, 4 Mar 2021 01:01:37 -0800 (PST)

Post by ***@gmail.com

Post by wolfgang kern

Post by ***@gmail.com
If PDOS/386 was to directly manipulate the ATA
hard disk I/O ports like every other 32-bit operating
system does, would that prevent it from booting
from USB stick also?

No of course, the boot process takes place before
any OS could do something.

That's not what I meant. What I mean is that when a
USB looks like a hard disk, and the OS is booted
like a hard disk, when a switch to protected mode is
made, and the BIOS is nominally no longer available,
at this point the OS needs to switch to manipulating
the I/O port for the hard disk. If it actually does this
(remembering that the hard disk is faked still), will
it fail?

It seems that you're asking at what point, if any, does
the legacy drive emulation turn off or become disabled.
I seem to recall that being discussed some years ago,
but I don't recall the answer. Have you checked the
ATA/ATAPI documents?

[Scott Lurndal]

This post might be inappropriate. Click to display it.

[Rod Pemberton]

On Wed, 3 Mar 2021 04:26:30 -0800 (PST)

Post by ***@gmail.com
If I have a hard disk image burnt to USB and use
the BIOS to boot from USB in legacy mode, is
there some dependency for this to actually work,
specifically is INT 13H detected and redirected
by "the hardware"?

IDK

Post by ***@gmail.com
Such that if I copy the interrupt vector from
INT 13H to some other location, such as
INT 80H, and then attempt to do an INT 80H,
that won't work? Since it isn't the code at that
location that is so important, it is the interrupt
number itself? (not true of Bochs though).

...

Post by ***@gmail.com
If so, that would explain why PDOS/386 is not
booting from USB stick currently. It's just a theory
so far, I haven't isolated that yet.

Ok.

Post by ***@gmail.com
Here is the code
I am suspicious of, and the PIC remapping is
suspicious too (since I don't know what it is
doing).
#ifdef PDOS32
/* Copies BIOS interrupt vectors and remaps IRQs
* so they do not conflict with protected mode exceptions. */
{
disable();
/* 16 vectors from 0x10 to 0xA0. (BIOS calls) */
ivtCopyEntries(0xA0, 0x10, 16);
/* 8 vectors from 0x08 to 0xB0. (BIOS IRQ handlers 0 - 7) */
ivtCopyEntries(0xB0, 0x08, 8);
/* 8 vectors from 0x70 to 0xB8. (BIOS IRQ handlers 8 - 15) */
ivtCopyEntries(0xB8, 0x70, 8);
picRemap(0xB0, 0xB8);
enable();
}
#endif
Thanks. Paul.

It would appear that you,

a) relocated BIOS interrupts (INT 10h to INT 1Fh) to INT A0h-AFh
b) relocated low IRQs (IRQ 0 to IRQ 7) to INT B0h-B7h
c) relocated high IRQs (IRQ 8 to IRQ 15) to INT B8H-BFh
d) reprogrammed the PICs (IRQs) to be at vectors B0h and B8h

After reprogramming the PICS, they should
correctly trigger the IRQ vectors in their
new location. I.e., b) c) d) don't seem
suspect to me.

I'm not sure however as to what redirects
the old BIOS calls to their new interrupts.
I.e., a) seems suspect to me.

E.g., it's possible that some code is
calling the original INT 13h while other
code is calling the new INT A3h. E.g.,
non-PDOS code is calling INT 13h, while
PDOS code is directly calling INT A3h?

Did you install a wrapper or redirect
code to move calls to the old locations
to their new locations? Or, did you wipe
the original BIOS vectors? E.g., dummy
IRET routine etc.

Honestly, I don't understand why the BIOS
calls were moved, as I don't currently
know of a need for it. Maybe, they were
moved to verify the code was independent
of any other code which would call the
original interrupts? What happens if you
#if-def out ivtCopyEntries() call for the
BIOS calls? Does your OS work? Does it
boot?

It's possible that there may also be
some issue with the INT 13h re-vector.
INT 13h is normally set to F000:EC59 for
floppy disk, but is relocated to INT 40h
if a hard disk is found. If a hard disk
is found INT 13h is then normally set to
F000:E3FE. You've relocated INT 10h
through INT 1Fh, which includes INT 13h,
up to INT A0h through INT AFh.

--

[[e-mail]]

Post by Rod Pemberton
a) relocated BIOS interrupts (INT 10h to INT 1Fh) to INT A0h-AFh
b) relocated low IRQs (IRQ 0 to IRQ 7) to INT B0h-B7h
c) relocated high IRQs (IRQ 8 to IRQ 15) to INT B8H-BFh
d) reprogrammed the PICs (IRQs) to be at vectors B0h and B8h
After reprogramming the PICS, they should
correctly trigger the IRQ vectors in their
new location. I.e., b) c) d) don't seem
suspect to me.

Ok, thanks.

Post by Rod Pemberton
I'm not sure however as to what redirects
the old BIOS calls to their new interrupts.
I.e., a) seems suspect to me.
E.g., it's possible that some code is
calling the original INT 13h while other
code is calling the new INT A3h. E.g.,
non-PDOS code is calling INT 13h, while
PDOS code is directly calling INT A3h?
Did you install a wrapper or redirect
code to move calls to the old locations
to their new locations? Or, did you wipe
the original BIOS vectors? E.g., dummy
IRET routine etc.

The BIOS calls in 32-bit are done like this:

#define BIOS_INT_OFFSET 0x90 /* BIOS interrupt 0x10 is moved to 0xA0. */

int86x(0x13 + BIOS_INT_OFFSET, &regsin, &regsout, &sregs);

I don't think there is any way for someone to use
the old interrupt numbers.

Also, I now realize that it can't just be disk emulation,
because this is also enough to cause PDOS/386 to
reboot when booted from USB stick:

BosWriteText(0, 'Z', 0);

Post by Rod Pemberton
Honestly, I don't understand why the BIOS
calls were moved, as I don't currently
know of a need for it. Maybe, they were
moved to verify the code was independent
of any other code which would call the
original interrupts?

They were moved so that when there is a 32-bit
interrupt, e.g. TRAP D, it is distinguished from a
BIOS call with the same value.

I'm not sure if there was a better option.

Personally I thought it was premature to care about
TRAP Ds, but it was driven by whatever Alica felt
like doing, as she had essentially taken over the
project. With her apparent assassination by
Microsoft's goons, I'm probably going to be ripping
out some of her work to get it back to being simple
and understandable. I'm not going to rip out the
wonderful FAT32, LFN, Windows DLL work though.

Post by Rod Pemberton
What happens if you
#if-def out ivtCopyEntries() call for the
BIOS calls? Does your OS work? Does it
boot?

I will try doing that and adjusting the BIOS_INT_OFFSET
to 0.

Post by Rod Pemberton
It's possible that there may also be
some issue with the INT 13h re-vector.
INT 13h is normally set to F000:EC59 for
floppy disk, but is relocated to INT 40h
if a hard disk is found. If a hard disk
is found INT 13h is then normally set to
F000:E3FE. You've relocated INT 10h
through INT 1Fh, which includes INT 13h,
up to INT A0h through INT AFh.

Ok, I think 40H should survive.

Thanks. Paul.

[wolfgang kern]

Post by Rod Pemberton
It would appear that you,
a) relocated BIOS interrupts (INT 10h to INT 1Fh) to INT A0h-AFh
b) relocated low IRQs (IRQ 0 to IRQ 7) to INT B0h-B7h
c) relocated high IRQs (IRQ 8 to IRQ 15) to INT B8H-BFh
d) reprogrammed the PICs (IRQs) to be at vectors B0h and B8h
After reprogramming the PICS, they should
correctly trigger the IRQ vectors in their
new location. I.e., b) c) d) don't seem
suspect to me.
I'm not sure however as to what redirects
the old BIOS calls to their new interrupts.
I.e., a) seems suspect to me.

BIOS will choke on redirected IRQs, PIT and RTCL may make it just hang
but all which are dedicated to devices (HD/FD/USB) will crash.

[...INT13]
it's really a bad idea to call the BIOS INT13 routines (as said above).
I'd copy this BIOS parts and modify it to my own desire and then assign
an INT_## to it. (I wrote the whole thing myself, weren't a big deal).
__
wolfgang

[[e-mail]]

Post by Rod Pemberton
a) relocated BIOS interrupts (INT 10h to INT 1Fh) to INT A0h-AFh
I'm not sure however as to what redirects
the old BIOS calls to their new interrupts.
I.e., a) seems suspect to me.

Well I managed to get it working by subtracting 0x90
from the interrupt number before executing it in real
mode.

That then led me to the next problem, which was CR3
was being set to some junk value on USB, and the code
couldn't cope with that.

So I initialized CR3 to 0 and everything started working.

I then went to double-check that the BIOS interrupt 0x10/0xA0
writing a single character still failed, and I was shocked to find
that 0xA0 was now working.

I rebuilt with a new screen eyecatcher, because I didn't believe
it, but same result.

So that mystery is no longer repeatable.

But it's fantastic to be able to boot on real hardware again.

Thanks for your help.

BFN. Paul.