drivers

[muta...@gmail.com]

What is the reason that drivers for various bits of
hardware are being put into the operating system,
usually only the very latest version of Windows,
instead of being flashed onto the firmware with
an API that is available (via BIOS or UEFI) to all
operating systems?

Thanks. Paul.

[Joe Monk]

The average user knows nothing about flashing drivers in BIOS. The average user knows to plug in a USB connector and let the OS load the driver. Remember, OS'es arent written for technical people. They are written for the average user.

Joe

[JJ]

Moreover, BIOS/firmware EEPROM chips can only be flashed for a limited
number of times.

[muta...@gmail.com]

On Saturday, July 10, 2021 at 12:04:51 PM UTC+10, Joe Monk wrote:

> > What is the reason that drivers for various bits of
> > hardware are being put into the operating system,
> > usually only the very latest version of Windows,
> > instead of being flashed onto the firmware with
> > an API that is available (via BIOS or UEFI) to all
> > operating systems?

> The average user knows nothing about flashing drivers
> in BIOS. The average user knows to plug in a USB
> connector and let the OS load the driver. Remember,
> OS'es arent written for technical people. They are
> written for the average user.

Ok, so how about plugging in the USB to the computer
and letting the computer load the driver instead of the
OS loading the driver?

Isn't it more appropriate for the computer to be doing this?

Maybe press F5 when booting and the computer will
load all drivers on all USB sticks?

BFN. Paul.

[muta...@gmail.com]

On Saturday, July 10, 2021 at 2:16:35 PM UTC+10, JJ wrote:

> Moreover, BIOS/firmware EEPROM chips can only be flashed for a limited
> number of times.

Ok, in the same way that the computer reads BOOTX64.EFI,
why can't it read a whole stack of drivers.EFI in the same
directory?

I was going to suggest that the firmware have its own disk
drive, but if it wants to share, I guess that's ok, since it is
already mandated most of the time anyway.

BFN. Paul.

[Joe Monk]

> Ok, so how about plugging in the USB to the computer
> and letting the computer load the driver instead of the
> OS loading the driver?

Your question doesnt make sense. Im not going to plug in my USB drive until I want to read my data from it. So when would the hardware load the driver versus the OS loading the driver?

Joe

[muta...@gmail.com]

I don't know if plugging in a USB device causes an interrupt,
but if it does, the BIOS/UEFI gets control and does its stuff,
and then informs the OS via an agreed interrupt that the OS
hooked in to that there is a new device available?

BFN. Paul.

[Joe Monk]

> I don't know if plugging in a USB device causes an interrupt,
> but if it does, the BIOS/UEFI gets control and does its stuff,
> and then informs the OS via an agreed interrupt that the OS
> hooked in to that there is a new device available?

The OS comes first in the interrupt chain, not the hardware. The OS will trap the interrupt, especially in PM.

See https://docs.microsoft.com/en-us/windows/win32/devio/wm-devicechange

Joe

[muta...@gmail.com]

On Saturday, July 10, 2021 at 9:08:47 PM UTC+10, Joe Monk wrote:

> > I don't know if plugging in a USB device causes an interrupt,
> > but if it does, the BIOS/UEFI gets control and does its stuff,
> > and then informs the OS via an agreed interrupt that the OS
> > hooked in to that there is a new device available?

> The OS comes first in the interrupt chain, not the hardware.
> The OS will trap the interrupt, especially in PM.

That is a choice of the OS. It's also a choice to directly
manipulate I/O ports.

I'm asking why there can't be some default computer-provided
device handler, just like there already is for serial ports. Yes,
the OS can bypass INT 14H. But if it doesn't, the computer
should be able to handle that particular device, and the OS
can choose to make use of it. Why not all devices? Especially
Bluetooth when it isn't even plugged in to a USB port.

BFN. Paul.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>What is the reason that drivers for various bits of
>hardware are being put into the operating system,
>usually only the very latest version of Windows,
>instead of being flashed onto the firmware with
>an API that is available (via BIOS or UEFI) to all

Do recall that for many years, the BIOS was in
ROM or EPROM (and later EEPROM). It's only recently
that Flash devices have been used.

In any case, why put all that cruft (do you know just
how many Windows (and Linux, and Wind River, and QNX
et alia) device drivers exist in the world? They
wouldn't all fit in the firmware.

Were they in the firmware, all operating systems would
be limited to the functionality provided by the firmware and
unable to take advantage of new capabilities on the device.

There are, of course, several standard host controller
hardware interfaces (AHCI, UHCI, EHCI, XHCI, NVMe, SDHC) for
which a common driver will work on all hardware conforming
to the standards. Those, in and of themselves, end up
making adding capabilities to the hardware slightly more difficult
without extending the API, but that downside is outweighed by
the fact that there doesn't need to be a thousand different SATA
host controller drivers. (even then, hardware manufacturers don't
always follow the standards, or have bugs in their implementations,
which the drivers must often be updated to accomodate - called Quirks in linux).

https://www.intel.com/content/www/us/en/io/serial-ata/ahci.html
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf
https://www.sdcard.org/downloads/pls/

Consider NVMe, which was developed because AHCI was too
limited when working with high-bandwidth storage devices;
it has a fairly complex multiple ring-based interface
to the hardware where the driver just adds a command
to the ring (sector address, number of sectors and a
scatter-gather list) and rings a doorbell on the hardware
controller to inform it that work is pending. The
NVMe hardware sends an interrupt at a programmable
point (e.g. at the end of a single command, or at the
end of group of commands for interrupt moderation).

https://nvmexpress.org/developers/nvme-specification/

Updating the firmware image is very complex, and the firmware
contains several security-related blobs (microcode updates,
SMM mode code, etc) that one must husband carefully.

And besides, the BIOS "int" interface is fairly useless
for modern operating systems and has been obsolete for decades.

[muta...@gmail.com]

On Sunday, July 11, 2021 at 2:07:59 AM UTC+10, Scott Lurndal wrote:

> "muta...@gmail.com" <muta...@gmail.com> writes:
> >What is the reason that drivers for various bits of
> >hardware are being put into the operating system,
> >usually only the very latest version of Windows,
> >instead of being flashed onto the firmware with
> >an API that is available (via BIOS or UEFI) to all

> Do recall that for many years, the BIOS was in
> ROM or EPROM (and later EEPROM). It's only recently
> that Flash devices have been used.
>
> In any case, why put all that cruft (do you know just
> how many Windows (and Linux, and Wind River, and QNX
> et alia) device drivers exist in the world? They
> wouldn't all fit in the firmware.

Ok, then how about the BIOS/UEFI has access to
both the hard disk (as it already does with BOOTX64.EFI)
and a reserved area of RAM (it is already responsible
for providing a memory map). It could even secure this
memory in another ring.

> And besides, the BIOS "int" interface is fairly useless
> for modern operating systems and has been obsolete for decades.

I said "or UEFI" above. It's just the principle of abstracting
the hardware.

In actual fact, can the Windows driver interface be used
as-is for the purpose I describe? However ReactOS is
doing things - move all that code into UEFI.

Thanks. Paul.

[muta...@gmail.com]

Actually, why can't the firmware have its own SD drive?
Those can be overwritten lots of times.

And why didn't they make the MBR have a signature of
66AA to indicate 16-bit mode UEFI-style, 77AA to
indicate 32-bit mode UEFI-style and 88AA to indicate
64-bit mode UEFI-style?

That way the firmware doesn't need to mandate and
have knowledge of the FAT format.

It would have been great to have 7c00 entered in PM32.

BFN. Paul.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>Actually, why can't the firmware have its own SD drive?

SPI-attached flash, or EMMC flash is much less
expensive.

>Those can be overwritten lots of times.

You seem to be the only person who believes that the
firmware needs to be overwritten "lots of times".

>
>And why didn't they make the MBR have a signature of
>66AA to indicate 16-bit mode UEFI-style, 77AA to
>indicate 32-bit mode UEFI-style and 88AA to indicate
>64-bit mode UEFI-style?

Because the MBR was obsolete the year it was developed.

As was FAT.

[Rod Pemberton]

On Fri, 9 Jul 2021 21:24:29 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> On Saturday, July 10, 2021 at 2:16:35 PM UTC+10, JJ wrote:
>
> > Moreover, BIOS/firmware EEPROM chips can only be flashed for a
> > limited number of times.
>
> Ok, in the same way that the computer reads BOOTX64.EFI,
> why can't it read a whole stack of drivers.EFI in the same
> directory?

I'm sure that it could. I have one Dell computer in the house which
loads an OS from the first partition, to provide a significant portion
of the non-OS related BIOS functionality, e.g., memory tester, device
tester, fan speed check, mouse check, keyboard check, etc.

> I was going to suggest that the firmware have its own disk
> drive

Been done. It wasn't just Dell either. HP did so too. Some of their
machines have a dedicated partition for BIOS too. Obviously, this is
the BIOS proper, it's the extra BIOS features.

I'm not sure yet what happens if you delete Dell's partition, as the
machine is still in use. However, I read online that if you delete HP's
partition, the machine is bricked. I.e., you have to recreate the
partition, and install their setup software.


--
The Chinese have such difficulty with English ... The word is not
"reunification" but "revenge".

[Rod Pemberton]

The hardware generates the interrupt. That's why interrupts exist, to
halt the software, so the hardware can be serviced by the OS software.
So, how exactly does the OS come first? ... 1) hardware interrupt 2)
software interrupt 3) OS ... Clearly, you meant something else here,
which I, nor likely anyone else here, understand. Reading about some
Windows function, which no one here is familiar with, doesn't explain
it to me either.

[Rod Pemberton]

On Sat, 10 Jul 2021 16:07:57 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

> Updating the firmware image is very complex, and the firmware
> contains several security-related blobs (microcode updates,
> SMM mode code, etc) that one must husband carefully.

It's only "complicated" if you're using the same device to update it's
own firmware. If the chip is programmed off-board, it's not difficult.

[Scott Lurndal]

Rod Pemberton <noe...@basdxcqvbe.com> writes:
>On Sat, 10 Jul 2021 16:07:57 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>> Updating the firmware image is very complex, and the firmware
>> contains several security-related blobs (microcode updates,
>> SMM mode code, etc) that one must husband carefully.
>
>It's only "complicated" if you're using the same device to update it's
>own firmware. If the chip is programmed off-board, it's not difficult.

When was the last time you created a firmware images for a mondern
processor?

I'm not talking about the process to update the firmware storage
device, I'm talking about the process to create and compile
the firmware.

We have a team of a dozen engineers working on ours.

FWIW, there are no systems anymore where the "chip" can be removed
from the mainboard to be programmed by an external PROM programmer.

[Rod Pemberton]

On Mon, 12 Jul 2021 17:09:08 GMT

sc...@slp53.sl.home (Scott Lurndal) wrote:

> Rod Pemberton <noe...@basdxcqvbe.com> writes:
> >On Sat, 10 Jul 2021 16:07:57 GMT
> >sc...@slp53.sl.home (Scott Lurndal) wrote:

> >> Updating the firmware image is very complex, and the firmware
> >> contains several security-related blobs (microcode updates,
> >> SMM mode code, etc) that one must husband carefully.
> >
> >It's only "complicated" if you're using the same device to update
> >it's own firmware. If the chip is programmed off-board, it's not
> >difficult.
>
> When was the last time you created a firmware images for a mondern
> processor?

I never did. I worked for an electronics manufacturer which did their
own embedded ROMs in house. That was some decades ago. They were
E2PROMs, and not for PCs.

> I'm not talking about the process to update the firmware storage
> device, I'm talking about the process to create and compile
> the firmware.
>
> We have a team of a dozen engineers working on ours.

Ok. (Seems like overkill for x86 BIOS, but maybe not for UEFI ...? )

> FWIW, there are no systems anymore where the "chip" can be removed
> from the mainboard to be programmed by an external PROM programmer.

Well, this x86 motherboard, circa 2009, has dual-BIOS stored in two
small 8-pin surface mount DIPs. I.e., snip them off, remove old pins,
clean up the board, replace with newly programmed chips, and solder on.
Just about anyone can do this at home with no special tools, but they
may need some experience.

As for what is required to build a new firmware image, I'm assuming
that Paul will start with some open source project like Coreboot
(formerly LinuxBIOS) with SeaBIOS. Some motherboard manufacturers " ...
offer coreboot alongside their standard BIOS ..." according to
Wikipedia, which also lists a UEFI BIOS project, TianoCore, among
others. In other words, if Paul acquires the correct hardware, the
work of programming both the hardware and non-hardware portions of the
BIOS or UEFI are done for him. So, all he needs after that is some
programmable chips a chip (re)programmer, etc. I'm sure the people who
work with these projects regularly have provided instructions on what
to do, where to buy, etc.

https://en.wikipedia.org/wiki/Coreboot
https://en.wikipedia.org/wiki/SeaBIOS

[Scott Lurndal]

Rod Pemberton <noe...@basdxcqvbe.com> writes:
>On Mon, 12 Jul 2021 17:09:08 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>> Rod Pemberton <noe...@basdxcqvbe.com> writes:
>> >On Sat, 10 Jul 2021 16:07:57 GMT
>> >sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>> >> Updating the firmware image is very complex, and the firmware
>> >> contains several security-related blobs (microcode updates,
>> >> SMM mode code, etc) that one must husband carefully.
>> >
>> >It's only "complicated" if you're using the same device to update
>> >it's own firmware. If the chip is programmed off-board, it's not
>> >difficult.
>>
>> When was the last time you created a firmware images for a mondern
>> processor?
>
>I never did. I worked for an electronics manufacturer which did their
>own embedded ROMs in house. That was some decades ago. They were
>E2PROMs, and not for PCs.
>
>> I'm not talking about the process to update the firmware storage
>> device, I'm talking about the process to create and compile
>> the firmware.
>>
>> We have a team of a dozen engineers working on ours.
>
>Ok. (Seems like overkill for x86 BIOS, but maybe not for UEFI ...? )

Ah, but the "application visible" portion of the BIOS (e.g. the
interrupts that Paul is so fond of) is a very, very small part
of the BIOS.

The vast majority of it is processor-specific code to initailize
the hardware (memory controllers, mainboard i2c components,
PCI/PCIe controllers (link training, PCI discovery), serializer/deserializers,
processor microcode loading, and a hundred other things that
most people aren't aware of.

>
>> FWIW, there are no systems anymore where the "chip" can be removed
>> from the mainboard to be programmed by an external PROM programmer.
>
>Well, this x86 motherboard, circa 2009, has dual-BIOS stored in two
>small 8-pin surface mount DIPs. I.e., snip them off, remove old pins,
>clean up the board, replace with newly programmed chips, and solder on.
>Just about anyone can do this at home with no special tools, but they
>may need some experience.

But why? Today you have SPI-based flash devices that can
be programmed dynamically, if you know how.

>As for what is required to build a new firmware image, I'm assuming
>that Paul will start with some open source project like Coreboot
>(formerly LinuxBIOS) with SeaBIOS. Some motherboard manufacturers " ...
>offer coreboot alongside their standard BIOS ..." according to
>Wikipedia, which also lists a UEFI BIOS project, TianoCore, among
>others. In other words, if Paul acquires the correct hardware, the
>work of programming both the hardware and non-hardware portions of the
>BIOS or UEFI are done for him.

Those have very limited hardware support. Very limited.

>So, all he needs after that is some
>programmable chips a chip (re)programmer, etc. I'm sure the people who
>work with these projects regularly have provided instructions on what
>to do, where to buy, etc.
>
>https://en.wikipedia.org/wiki/Coreboot
>https://en.wikipedia.org/wiki/SeaBIOS

We use tianocore as the basis for our UEFI subsystem. However, that's a
very small part of the firmware[*]. The TC UEFI code is, for the most
part, hardware independent. The hardware-dependent parts of the
firmware are the responsiblity of the builder of the hardware. And
for that you need deep specs for all the hardware, understanding of
things like serial-presence-detect memory devices, I2c/I3c voltage
and temperature sensors, mainboard PLDs, etc.

[*] Most of our customers prefer uboot over uefi, both of which are
components added to the firwmare that rely on mainboard specific
code in the firmware.

Not to mention the SMM code - a significant challenge to develop without
access to proprietary specifications from the mainboard and processor
vendors.

[muta...@gmail.com]

On Tuesday, July 13, 2021 at 11:55:44 PM UTC+10, Scott Lurndal wrote:

> >> We have a team of a dozen engineers working on ours.
> >
> >Ok. (Seems like overkill for x86 BIOS, but maybe not for UEFI ...? )

> Ah, but the "application visible" portion of the BIOS (e.g. the
> interrupts that Paul is so fond of) is a very, very small part
> of the BIOS.
>
> The vast majority of it is processor-specific code to initailize
> the hardware (memory controllers, mainboard i2c components,
> PCI/PCIe controllers (link training, PCI discovery), serializer/deserializers,
> processor microcode loading, and a hundred other things that
> most people aren't aware of.

You mentioned the BIOS above - not sure if this means
you support 16-bit INT calls - but is there any barrier to
you having a little bit of 16-bit code behind those INTs
that switches to 32-bit mode to run C code to do all
your work?

> >As for what is required to build a new firmware image, I'm assuming
> >that Paul will start with some open source project like Coreboot
> >(formerly LinuxBIOS) with SeaBIOS. Some motherboard manufacturers " ...
> >offer coreboot alongside their standard BIOS ..." according to
> >Wikipedia, which also lists a UEFI BIOS project, TianoCore, among
> >others. In other words, if Paul acquires the correct hardware, the
> >work of programming both the hardware and non-hardware portions of the
> >BIOS or UEFI are done for him.

> Those have very limited hardware support. Very limited.

I don't mind paying more for a computer, but I do need to
be able to tell someone in the Philippines - go to a computer
store and ask for a computer with xyz specs so that I will
be able to flash abc so as to support PDOS/386.

From my initial investigations, it seems that this "very
limited hardware support" actually entails "well, there's
this one thing, but it doesn't even have a case".

That's not what I'm looking for. I can put up with only
10% of computers being flashable, or maybe even only
1%. But computers that don't even have a case don't
even appear as a count.

> Not to mention the SMM code - a significant challenge to develop without
> access to proprietary specifications from the mainboard and processor
> vendors.

Everything you have said has suggested that the firmware
is off-limits.

But there is such a thing as an "option ROM". I'm not entirely
sure what that is, but do even 10% or 1% of computers allow
me to flash one of those?

As far as I can tell, a BOOTX64.EFI containing maybe
3000 lines of code, mainly 64-bit C code, but maybe
1000 lines of 16-bit assembler and C, will do what I
want, which is to restore a mini-BIOS on a UEFI-only
machine. I only need a few interrupts - 13H, 10H
and 14H.

Is there really no way, even on 1% of currently manufactured
computers, to get that 3000 lines of code off my hard disk
and into the firmware so that I don't need to have any
subdirectories at all on my FAT-16 disks? I shipped an
image a couple of days ago that only had IO.SYS, MSDOS.SYS
and COMMAND.COM. It won't run Win32 programs - you are
required to add kernel32.dll and msvcrt.dll yourself, but it
does boot and will run a.out programs with nothing further,
even though I discourage that.

I would like that disk image to work, unchanged. It doesn't
even use INT 14H.

Thanks. Paul.

[Joe Monk]

> As far as I can tell, a BOOTX64.EFI containing maybe
> 3000 lines of code, mainly 64-bit C code, but maybe
> 1000 lines of 16-bit assembler and C, will do what I
> want, which is to restore a mini-BIOS on a UEFI-only
> machine. I only need a few interrupts - 13H, 10H
> and 14H.

BIOS and UEFI are pretty much mutually exclusive. Take a read here: https://wiki.osdev.org/UEFI#UEFI_vs._legacy_BIOS

For instance, you mention INT 14h - that has been replaced in UEFI with the Serial Protocol ... an example serial protocol driver can be found here: https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/appendix_a_edk_ii_file_templates/readme.3/a36_serialioc_file

Joe

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Tuesday, July 13, 2021 at 11:55:44 PM UTC+10, Scott Lurndal wrote:
>
>> >> We have a team of a dozen engineers working on ours.
>> >
>> >Ok. (Seems like overkill for x86 BIOS, but maybe not for UEFI ...? )
>
>> Ah, but the "application visible" portion of the BIOS (e.g. the
>> interrupts that Paul is so fond of) is a very, very small part
>> of the BIOS.
>>
>> The vast majority of it is processor-specific code to initailize
>> the hardware (memory controllers, mainboard i2c components,
>> PCI/PCIe controllers (link training, PCI discovery), serializer/deserializers,
>> processor microcode loading, and a hundred other things that
>> most people aren't aware of.

>> >As for what is required to build a new firmware image, I'm assuming
>> >that Paul will start with some open source project like Coreboot
>> >(formerly LinuxBIOS) with SeaBIOS. Some motherboard manufacturers " ...
>> >offer coreboot alongside their standard BIOS ..." according to
>> >Wikipedia, which also lists a UEFI BIOS project, TianoCore, among
>> >others. In other words, if Paul acquires the correct hardware, the
>> >work of programming both the hardware and non-hardware portions of the
>> >BIOS or UEFI are done for him.
>
>> Those have very limited hardware support. Very limited.
>
>I don't mind paying more for a computer, but I do need to
>be able to tell someone in the Philippines - go to a computer
>store and ask for a computer with xyz specs so that I will
>be able to flash abc so as to support PDOS/386.
>
>From my initial investigations, it seems that this "very
>limited hardware support" actually entails "well, there's
>this one thing, but it doesn't even have a case".

You're not paying attention. I'm talking about the hardware
present on the CPU and Southbridge chips. You have to be
able to configure how the CPU routes physical addresses,
for example. The registers that control this are either
private model specific registers (e.g. TOS/TOS2) or
PCI configuration registers on one of the functions on
domain 0 bus 0 (accessed using IN/OUT to CF8/CFC).

Every processor has a difference sequence to initialize
these registers. Each processor has one or more memory
controllers that need to be programmed (also using PCI
configuration space registers on domain 0 bus 0).

Here, for example from an Intel processor:

00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
00:1c.5 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #6 (rev d5)
00:1c.6 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #7 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H87 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)

All of those devices need to be configured, and the configuration
is unique to each CPU.

You don't have the documentation required to performn the
initialization for those (it is chip specific) and it is
not likely that you'll find it in an open source firmware
offering for anything other than a couple of obsolete
processors.

Some of that is documented in the corresponding OS/BIOS
writers guide available from the manufacturer, but not
all of it. Particularly the memory controller
initialization.

>
>That's not what I'm looking for. I can put up with only
>10% of computers being flashable, or maybe even only
>1%. But computers that don't even have a case don't
>even appear as a count.
>
>> Not to mention the SMM code - a significant challenge to develop without
>> access to proprietary specifications from the mainboard and processor
>> vendors.
>
>Everything you have said has suggested that the firmware
>is off-limits.
>
>But there is such a thing as an "option ROM". I'm not entirely
>sure what that is, but do even 10% or 1% of computers allow
>me to flash one of those?

A legacy PCI device may have an option ROM on the PCI card. This
is generally copied from the PCI card to the firmware/BIOS at
power on by the firmware and slotted into the appropriate
address range (e.g. near 1MB or near 4GB). The address of the
option ROM is stored in the PCI Configuration header for the
device providing the option ROM. This was usually used to
hook the device into the BIOS INT I/O calls.

PCI Express, has deprecated option ROMs.

[muta...@gmail.com]

On Wednesday, July 14, 2021 at 10:19:46 AM UTC+10, Scott Lurndal wrote:

> >From my initial investigations, it seems that this "very
> >limited hardware support" actually entails "well, there's
> >this one thing, but it doesn't even have a case".

> You're not paying attention. I'm talking about the hardware
> present on the CPU and Southbridge chips. You have to be
> able to configure how the CPU routes physical addresses,

I think we're talking cross-purposes. I'm not questioning
any of that, and I'm not trying to replace any of that.

I just want a computer manufacturer to allow me to
flash a little bit of my own code. Doesn't have to be
every manufacturer. Just 10% of computer manufacturers
would be good enough.

This code would be executed instead of loading a
BOOTX64.EFI.

Or alternatively, download their firmware from their
website, append my little bit of code, and zap their
firmware to call my code.

BFN. Paul.

[muta...@gmail.com]

On Wednesday, July 14, 2021 at 10:10:24 AM UTC+10, Joe Monk wrote:

> > As far as I can tell, a BOOTX64.EFI containing maybe
> > 3000 lines of code, mainly 64-bit C code, but maybe
> > 1000 lines of 16-bit assembler and C, will do what I
> > want, which is to restore a mini-BIOS on a UEFI-only
> > machine. I only need a few interrupts - 13H, 10H
> > and 14H.

> BIOS and UEFI are pretty much mutually exclusive.

> For instance, you mention INT 14h - that has been replaced
> in UEFI with the Serial Protocol ... an example serial protocol
> driver can be found here

And what is preventing my BOOTX64.EFI from hooking
INT 14H (RM16), switching to long mode, and calling the
UEFI Serial Protocol?

BFN. Paul.

[Joe Monk]

> And what is preventing my BOOTX64.EFI from hooking
> INT 14H (RM16), switching to long mode, and calling the
> UEFI Serial Protocol?
>

How are you going to hook an interrupt that doesnt exist? There is no INT 14h in UEFI.

Joe

[muta...@gmail.com]

My BOOTX64.EFI will put one there.

It will point to some RM16 code which may or may not
be embedded in the BOOTX64.EFI (my choice).

BFN. Paul.

[Rod Pemberton]

On Tue, 13 Jul 2021 15:56:12 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> But there is such a thing as an "option ROM". I'm not entirely
> sure what that is, but do even 10% or 1% of computers allow
> me to flash one of those?
>

This is just an extra ROM that comes on a insert-able expansion card.

It's inserted just like any other card, e.g., video, network, mouse,
com, etc. It has a ROM with code on it, like the BIOS or Video BIOS.
Of course, the card will need the correct edge connector for your
generation of motherboard, e.g. ISA, MCA, PCI, PCI-EX, ...

For example, in the mid 1990's, there were option ROM cards which
extended or updated the BIOS, such as providing Enhanced Int 13h BIOS
ROM support or upgrade the BIOS for IDE drives. You can also get them
for remote booting via the LAN.

IIRC, the BIOS detects a AA55h signature on a 2K boundary in the
address space for ROMs (Video, BIOS, Lan, etc) and calls a function
to initialize the hardware associated with the ROM.


From an old post of mine in 2012:

RP> PS/2 technical reference defines the use of the 0xAA55 signature
RP> for expansion ROMs.


From an old post of mine in 2009:

RP> As for 0xAA55 signature on 2k boundaries required for ROM's, network
RP> devices, PnP, etc., there numerous specifications that require that:
RP>
RP> "Microsoft Extensible Firmware Initiative FAT32 File System
RP> Specification", Microsoft Corporation, V1.03, Dec. 6, 2000
RP>
RP> "BIOS Boot Specification", Compaq Comp. Co., Phoenix Technologies
RP> Ltd., Intel Corp., Jan 11, 1996 V1.01
RP>
RP> "Plug and Play BIOS Specification", Compaq Comp. Co., Phoenix
RP> Technologies Ltd., Intel Corp. May 5, 1994, V1.0A
RP>
RP> "PhoenixBIOS 4.0 Revision 6", Phoenix Technologies Ltd., June 22,
RP> 2000
RP>
RP> "Novell Boot Rom Developer's Guide for DOS Workstations", July 9,
RP> 1992, V. 1.0
RP>
RP> Some of these also make changes to Int 19h and Int 18h boot order.


This old post of mine lists all the specifications I knew of at the time
which modified and extended the BIOS, especially Int 13h, 15h, 18h,
19h, and 28-bit or 48-bit LBA etc:

https://groups.google.com/g/alt.os.development/c/DTnX-lYbTHA/m/xrcQinFLEGkJ

[Rod Pemberton]

On Tue, 13 Jul 2021 13:55:40 GMT

...

> >> FWIW, there are no systems anymore where the "chip" can be removed
> >> from the mainboard to be programmed by an external PROM programmer.
> >
> >Well, this x86 motherboard, circa 2009, has dual-BIOS stored in two
> >small 8-pin surface mount DIPs. I.e., snip them off, remove old
> >pins, clean up the board, replace with newly programmed chips, and
> >solder on. Just about anyone can do this at home with no special
> >tools, but they may need some experience.
>
> But why? Today you have SPI-based flash devices that can
> be programmed dynamically, if you know how.

The point was there is always a way.

> >As for what is required to build a new firmware image, I'm assuming
> >that Paul will start with some open source project like Coreboot
> >(formerly LinuxBIOS) with SeaBIOS. Some motherboard manufacturers "
> >... offer coreboot alongside their standard BIOS ..." according to
> >Wikipedia, which also lists a UEFI BIOS project, TianoCore, among
> >others. In other words, if Paul acquires the correct hardware, the
> >work of programming both the hardware and non-hardware portions of
> >the BIOS or UEFI are done for him.
>
> Those have very limited hardware support. Very limited.

So? Today, we have Amazon and Alibaba, where you can get just about
anything, no matter how obscure or specific or obsolete, especially
electronics. Yes? There was a point in the past where you had to
settle for what a local store carried, or what some regional
electronics supplier had in stock, or pay a fortune to a large national
supplier, but not anymore.

> >So, all he needs after that is some
> >programmable chips a chip (re)programmer, etc. I'm sure the people
> >who work with these projects regularly have provided instructions on
> >what to do, where to buy, etc.
> >
>

> We use tianocore as the basis for our UEFI subsystem. However,
> that's a very small part of the firmware[*]. The TC UEFI code is,
> for the most part, hardware independent. The hardware-dependent
> parts of the firmware are the responsiblity of the builder of the
> hardware. And for that you need deep specs for all the hardware,
> understanding of things like serial-presence-detect memory devices,
> I2c/I3c voltage and temperature sensors, mainboard PLDs, etc.
>
> [*] Most of our customers prefer uboot over uefi, both of which are
> components added to the firwmare that rely on mainboard specific
> code in the firmware.
>
> Not to mention the SMM code - a significant challenge to develop
> without access to proprietary specifications from the mainboard and
> processor vendors.

Both tianocore and that some motherboard manufacturers offer a
coreboot solution which works for their hardware was mentioned above.

[Rod Pemberton]

I wonder if anyone has done this or something similar for DOS or even
CP/M. I'm sure there are some diehards who won't give up DOS (or
CP/M) even in the face of UEFI. Maybe, they already coded a UEFI-shim
to drop out of LM and into RM, install a usable BIOS, then start up DOS
(or CP/M). Worth a search?

[muta...@gmail.com]

On Wednesday, July 14, 2021 at 1:22:04 PM UTC+10, Rod Pemberton wrote:

> I wonder if anyone has done this or something similar for DOS or even
> CP/M. I'm sure there are some diehards who won't give up DOS (or
> CP/M) even in the face of UEFI. Maybe, they already coded a UEFI-shim
> to drop out of LM and into RM, install a usable BIOS, then start up DOS
> (or CP/M). Worth a search?

I mentioned this to someone from Freedos, and they
didn't know of such a thing.

But even if it exists, it won't be public domain, so I won't
be putting it on my 100% pure public domain hard disk
image.

I will see if I can commission someone to write a public
domain version.

But even when I have that, I still want to get it off my hard
disk and into the firmware.

That option rom description in the previous message sounds
exactly what I want.

I want an option ROM to be installed on every computer
interested in running PDOS/386.

But is there an effective way to get it there without the
user needing to buy a special PCI card with a specially
programmed ROM?

When flash ram is just a flash away.

BFN. Paul.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Wednesday, July 14, 2021 at 10:19:46 AM UTC+10, Scott Lurndal wrote:
>
>> >From my initial investigations, it seems that this "very
>> >limited hardware support" actually entails "well, there's
>> >this one thing, but it doesn't even have a case".
>
>> You're not paying attention. I'm talking about the hardware
>> present on the CPU and Southbridge chips. You have to be
>> able to configure how the CPU routes physical addresses,
>
>I think we're talking cross-purposes. I'm not questioning
>any of that, and I'm not trying to replace any of that.
>
>I just want a computer manufacturer to allow me to
>flash a little bit of my own code. Doesn't have to be
>every manufacturer. Just 10% of computer manufacturers
>would be good enough.

They'll never allow you to flash your own code; that would
be a significant security shortcoming in their product
line, which would cost them far more customers than the one
customer they would gain.

[muta...@gmail.com]

On Thursday, July 15, 2021 at 12:51:19 AM UTC+10, Scott Lurndal wrote:

> >I just want a computer manufacturer to allow me to
> >flash a little bit of my own code. Doesn't have to be
> >every manufacturer. Just 10% of computer manufacturers
> >would be good enough.

> They'll never allow you to flash your own code; that would
> be a significant security shortcoming in their product
> line, which would cost them far more customers than the one
> customer they would gain.

Ok, in the same way that people post cracks for games,
is there something preventing cracks for firmware so
that we can add our own code? Or have they found a
way to stop that? And is it illegal to apply a crack to
firmware flashed on your own computer?

Thanks. Paul.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Thursday, July 15, 2021 at 12:51:19 AM UTC+10, Scott Lurndal wrote:
>
>> >I just want a computer manufacturer to allow me to
>> >flash a little bit of my own code. Doesn't have to be
>> >every manufacturer. Just 10% of computer manufacturers
>> >would be good enough.
>
>> They'll never allow you to flash your own code; that would
>> be a significant security shortcoming in their product
>> line, which would cost them far more customers than the one
>> customer they would gain.
>
>Ok, in the same way that people post cracks for games,
>is there something preventing cracks for firmware so
>that we can add our own code? Or have they found a
>way to stop that?

Yes, they've a simple solution. The firmware is
cryptographically signed. It can only be loaded if
the signature is signed by the private key associated
with the public key stored in the TPM.

[Joe Monk]

> Ok, in the same way that people post cracks for games,
> is there something preventing cracks for firmware so
> that we can add our own code? Or have they found a
> way to stop that? And is it illegal to apply a crack to
> firmware flashed on your own computer?

Firmware is signed. Posting a crack to firmware will brick the computer.

Joe

[muta...@gmail.com]

On Thursday, July 15, 2021 at 7:04:02 AM UTC+10, Scott Lurndal wrote:

> Yes, they've a simple solution. The firmware is
> cryptographically signed. It can only be loaded if
> the signature is signed by the private key associated
> with the public key stored in the TPM.

Wow. They've gone to a lot of effort to keep me away.

I wonder if they've also got some spyware in there.
How would that be done? Perhaps the bluetooth
receiver is detecting an incoming request, and if
the ID is CIA_HERE_FOR_YOU it sets up its own
connection and dumps whatever it wants from my
hard disk. They've already got FAT-32 code in there.
I'm using NTFS, but no reason why they can't add
that too.

I don't suppose the Chinese have put this firmware
anywhere near their nukes so that the Free World
can rock up with a bluetooth device and disable them all?

Ok, so if I have my own x64 computer-controlled nuclear
arsenal, and I want some non-CIA-controlled firmware,
this is my only option:

https://www.pcengines.ch/apu.htm

and I even have to supply my own case?

There's no drive from even the Chinese themselves to
have some open firmware?

Thanks. Paul.

[muta...@gmail.com]

On Thursday, July 15, 2021 at 8:35:12 AM UTC+10, muta...@gmail.com wrote:

> I wonder if they've also got some spyware in there.

Jean-marc, who used to post here and was another
PD fan pointed me to this CPU:

http://plasmacpu.no-ip.org/

as the closest he had found to PD hardware, as if
such a concept even exists.

I had other priorities at the time than to investigate
this, or why anyone would even care about the
hardware, but if I want to avoid people invalidating
my software whenever they feel like it, and not even
accepting public domain software to restore that
functionality, maybe I should be switching CPUs.

And in fact, I may as well simply switch to the S/390,
which essentially needs to run under emulation anyway.

Actually, that won't work either, because they've already
invalidated S/390 hardware too. I believe I can have a
32-bit z/Arch version of PDOS (that will still run on
real hardware) without a lot of effort, but they can
invalidate that one day too.

Someone contacted me wanting to run PDOS/3X0
or MVS/380 (can't remember) on some real mainframe
hardware that had been scrapped, but were missing
some sort of microcode that was supplied by an
OS/2-connected machine.

Is there some sort of cartel in operation here? z/Arch
is already out of patent and x64 soon will be. Is there
anyone lurking?

BFN. Paul.

[muta...@gmail.com]

I guess I could just have 2 hard disks (ie USB sticks).
One with BOOTX64.EFI on it.

And PDOS/386 should just gracefully accept being
booted from the second hard disk, which only
contains IO.SYS, MSDOS.SYS and COMMAND.COM.

I have had some really strange results from real
hardware.

If I put two PDOS USB sticks in, only the boot is
accepted. The only one's MBR can't be read, either
via CHS or LBA.

But if I put in a PDOS and some USB stick from the
wild, the wild one is read fine. The only strange thing
was that the CHS of the VBR was 0/1/1 as expected,
and is read, but is zeros. The LBA of the VBR was 31
from memory, and works, with an AA55 signature.

I think the deciding factor is more likely to be the
fact that the wild USB is only 2 GB and untouched,
while the others are bigger and have a 1 GB
image burnt. I don't want the 2 GB stick disturbed as
it is now a reference. So I've asked for more USB
sticks to be bought so that I can suss out this machine.

But it's a fantastic result so far - I have found a machine
willing to give me 2 hard disks on USB sticks.

Oh, one other thing is that 5 retries for reading a sector
is not always enough. 500 is enough, but makes the
boot process take several minutes with the unrecognized
drives.

And one other thing is that I get a return code of 1,
invalid parameter, when trying to find the hard disk
status of the USB sticks that are being presented
as hard disks. So I have to ignore that and continue
anyway.

And VHD can be burnt by Win32 Disk Imager, but I
need to select "all files" instead of the default *.img.

It's a fantastic result.

BFN. Paul.

[Joe Monk]

> Is there some sort of cartel in operation here? z/Arch
> is already out of patent

I dont know what gave you that idea, but there are new patents granted on z/arch every year.

Joe

[muta...@gmail.com]

I'm only interested in the first version of z/Arch, for the
same reason I'm only interested in the 80386, not the
80486 etc. And the next thing in the x64 range that I
am interested in is the subset of AMD's first x64 that
works on Intel's first x64.

I code to the lowest common denominator wherever
possible.

Hell, I even created the lowest common denominator
of Win32 - PDOS/386. There are only 10 or something
functions implemented, with minimal functionality
even within that. Just good enough to write a C library,
which is enough to implement a toolchain. Not an
editor though. I had to cheat (0xb8000) to get that to
work. And even the non-cheat (ANSI escape sequences,
still in proof of concept, worse than PDOS/3X0) will only
work on Win10 and above.

BFN. Paul.

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> What is the reason that drivers for various bits of
> hardware are being put into the operating system,
> usually only the very latest version of Windows,
> instead of being flashed onto the firmware with
> an API that is available (via BIOS or UEFI) to all
> operating systems?

There is simple answer: drivers are really part of operating
system. In more details: driver interface, that is way
in which drivers interact with operating system is
important part of design of operating system. DOS
took CPM design with BIOS interface. This design was
good for small machines but severly limited possible
DOS improvements.

As simple example of possible troubles look at interrupt:
driver that blocks interrupts and returns control to
operating system only when it finishded is easy to
write, but will have low performance on anything reasonably
new. And single such driver may exclude using better
drivers for other devices (because such drivers need
to react timely to interrupts). There is question of
memory needed by drivers: on classic PC high performace
floppy driver needs track buffer which must be allocated
withing single 64kB memory block (to satisfy DMA restrictions).
Allocating such block at system startup is easy. But if
machine is 32kB PC, then track buffer is likely to be
considered too much overhead.

Another trouble is USB: logically there is single bus
with several devices which need to be polled. Bus
controller performs rather complex operations affection
all devices. Drivers for devices on USB bus must
cooperate with bus control, no single device should
take exclusive control of the bus. Since there are
limited number of bus controller chips, it is natural
to put bus control in operating system and drivers
for specific devices operate via operating system
calls. But then clearly drivers are specific to
operating system...

--
Waldek Hebisch

[muta...@gmail.com]

On Friday, July 16, 2021 at 1:32:50 AM UTC+10, anti...@math.uni.wroc.pl wrote:

> muta...@gmail.com <muta...@gmail.com> wrote:
> > What is the reason that drivers for various bits of
> > hardware are being put into the operating system,
> > usually only the very latest version of Windows,
> > instead of being flashed onto the firmware with
> > an API that is available (via BIOS or UEFI) to all
> > operating systems?
>
> There is simple answer: drivers are really part of operating
> system. In more details: driver interface, that is way
> in which drivers interact with operating system is
> important part of design of operating system. DOS
> took CPM design with BIOS interface. This design was
> good for small machines but severly limited possible
> DOS improvements.

Thanks. Based on your answer, I now have the ability to
refine my question.

Whenever I pick up some C code, I throw it into a C
compiler to see what it does out-of-the box. I expect
it to be C90-compliant out-of-the-box.

If you go:

bcc32 -DGIVE_ME_POSIX *.c

and it activates a whole lot of Posix functionality that
makes the program so much better, that's fine.

But the default should be for a non-Posix system,
like MVS 3.8J.

Same applies to:

bcc32 -DGIVE_ME_WINDOWS7_AND_ABOVE *.c

So, if all attached USB sticks are presented by the BIOS
as hard drives by default when the system boots, so that
no USB driver is required, then that's what I want. Or if
not that, then give me a BIOS or UEFI call to access
the USB sticks as hard drives.

If this is going to produce performance problems, fine,
provide a non-default BIOS/UEFI call to deactivate the
firmware-control over the USB sticks and pass control
to the OS to manage the devices since the OS knows,
or thinks, or is configured, that it has the appropriate
drivers for this device already and can do a better job.

BFN. Paul.

[anti...@math.uni.wroc.pl]

There are much more "USB sticks" than hard drives (mass
storage device in USB lingo). For booting BIOS supports
keyboard and probably mouse. There is some chance that
there will be support for USB connected network interfaces.
I do not expect support for USB connected digitizing tablet,
speakers, camera or microphone. The same for serial and
parallel port or USB printers. Some USB devices make
support tricky: by default they look as drive and driver
needs to perform special sequence of commands to switch
device to proper operating mode. The idea above is that
fake drive contains Windows drivers and some "autorun"
file, when you insert device first time Windows will
run autorun file and install the driver. Once driver
is installed it will recognize device, take over it and
switch it to normal operating mode. Such device have
no chance to work without special driver, so do not
expect support in BIOS.

> If this is going to produce performance problems, fine,
> provide a non-default BIOS/UEFI call to deactivate the
> firmware-control over the USB sticks and pass control
> to the OS to manage the devices since the OS knows,
> or thinks, or is configured, that it has the appropriate
> drivers for this device already and can do a better job.

Note that BIOS traditionaly offered a boot menu and
ability to boot from various devices is important for
many users. So BIOS is likely to support typical
boot devices. But there is no reason to put support
for non-boot devices in BIOS. And there is no reason
for high-performance ones: even low performance driver
should be enough to boot operating system.

Low cost systems like Raspberry Pi have no of traditional
BIOS. There is mask ROM in CPU (GPU actually in case of
Raspberry Pi) which load next stage boot loader from SD
card. Driving SD card is easy, so small mask ROM is
enough. Rest is done via second nad higher level boot
loaders loaded from SD card (or other mass storage media).
Allwinner procesor use similar tactic, except for that
thay load rather large bootloader called U-boot. U-boot
contains drivers for rather large number of devices.
IIUC after loading operating system it is still possible
to use U-boot drivers. OTOH U-boot is largish (more than
meg in typical configuration) and in a sense more similar
to operating system than to normal bootloader. In a sense
using U-boot is similar to using Linux as a BIOS.

--
Waldek Hebisch

[muta...@gmail.com]

On Friday, July 16, 2021 at 9:58:58 AM UTC+10, anti...@math.uni.wroc.pl wrote:

> to operating system than to normal bootloader. In a sense
> using U-boot is similar to using Linux as a BIOS.

I guess this is the most practical solution.

Switch to PDOS-generic and use Linux as my BIOS.

And my INT 14H will disappear with PDOS-generic,
it will be an bios->fopen() of some non-hardcoded filename.

And the BIOS layer will use the Linux-provided TCP/IP
calls to turn that fopen() into TCP/IP calls. Or maybe
I can actually hide that in PDPCLIB for the Linux target.

I'm planning on creating a Linux distribution of my own
anyway. That looks identical to MSDOS except it is a
Wine prompt. The code is all written (by others). It just
needs to be rearranged (by someone I commission).

In the short-term I can simply run PDOS/386 under
Bochs under Linux. But in the even shorter term, I
don't particularly mind running Windows at that level.

So I'm back to abandoning PDOS/386 in favor of
PDOS-generic. Perhaps with a detour via a 512 MiB
PDOS/86.

BFN. Paul.

[Rod Pemberton]

I know you're not in the U.S., being in Australia, but I only know
about U.S. copyright laws.

In the U.S., under copyright law, you have the right to modify anything
in your possession, whether you own or paid for it or not, even if it's
copyrighted by someone else, but you only have that right exclusively
for your own PERSONAL use, meaning you can't distribute or publish or
sell the changes, patches, fixes etc (Lewis Galoob Toys v Nintendo of
America, Vault v Quaid, Narrell v Freeman). However, you also DO NOT
have the legal right to modify anything that is copyrighted under the
DMCA law, even if you possess it, own it, paid for it, etc. I.e., you
are expressly prohibited by law from doing anything to DMCA protected
material, of which most embedded code is covered nowadays. However,
binary code or object code is not protected by copyright at all in the
U.S. (Apple Computer v Franklin Computer), unless, of course, it's
been DMCA protected.

Got it? ...

So, yes, in the U.S., if the firmware is DMCA protected, then it is
"illegal to apply a crack to firmware flashed on your own computer".
Right now, owners of farm tractors have this exact issue. They can't
legally fix the tractor software since it's DMCA protected. However,
in the U.S., if your firmware isn't DMCA protected, you can do anything
to it, since the object and binary code have no legal copyright
protections. How do you tell if the code is DMCA protected? Nobody
knows until they've been sued, as it's not usually stated in a contract,
nor printed on the hardware.

Are you going to tell us about Aussie's messed up copyright laws?

[muta...@gmail.com]

On Wednesday, July 14, 2021 at 1:22:04 PM UTC+10, Rod Pemberton wrote:

> I wonder if anyone has done this or something similar for DOS or even
> CP/M. I'm sure there are some diehards who won't give up DOS (or
> CP/M) even in the face of UEFI. Maybe, they already coded a UEFI-shim
> to drop out of LM and into RM, install a usable BIOS, then start up DOS
> (or CP/M). Worth a search?

Do any computer vendors allow you to flash a floppy disk
image? If I could set the computer to boot from floppy,
that would cover almost everything I want. I just get the
above floppy to boot the first hard disk.

And if someone really wants to boot a real floppy, they will
have to do the reverse, from a real hard disk, unless a
computer vendor is willing to let you flash a hard disk
image.

Actually, since I never use floppies anyway, maybe I can
burn a floppy image to USB stick, make the boot priority
to go to floppies-on-USB, and then what I need is for my
remaining USB sticks to appear as hard disk images,
and have priority over the internal hard disk.

Note that my experimentation with USB sticks on a real
laptop is that it accepts a (I think) 4 GB USB stick, burnt
with a 1 GB hard disk image, as a boot device, but not
as an extra drive. But a 2 GB USB stick, at its natural
size, is accepted as an extra drive, but only after the
internal hard disk. That's not a big deal, and it's currently
ignored by PDOS/386 anyway, since it is NTFS and
unrecognized, but it would be nice to leave the internal
hard disk last.

I think it will take less than 3000 lines of code to
reinstate the BIOS calls I care about too.

BFN. Paul.

[muta...@gmail.com]

> On Wednesday, July 14, 2021 at 1:22:04 PM UTC+10, Rod Pemberton wrote:
> > I wonder if anyone has done this or something similar for DOS or even
> > CP/M. I'm sure there are some diehards who won't give up DOS (or
> > CP/M) even in the face of UEFI. Maybe, they already coded a UEFI-shim
> > to drop out of LM and into RM, install a usable BIOS, then start up DOS
> > (or CP/M). Worth a search?

I assume that I can have a BOOTX64.EFI and a
32-bit version sitting on the same floppy disk and
the computer will boot whichever one is correct
for the current processor?

Thanks. Paul.

[Joe Monk]

> Do any computer vendors allow you to flash a floppy disk
> image? If I could set the computer to boot from floppy,
> that would cover almost everything I want. I just get the
> above floppy to boot the first hard disk.
>
> And if someone really wants to boot a real floppy, they will
> have to do the reverse, from a real hard disk, unless a
> computer vendor is willing to let you flash a hard disk
> image.

How do you propose to boot from a floppy when that code is not present in UEFI?

Joe

[muta...@gmail.com]

Are you saying a UEFI-only computer cannot boot a
real floppy disk?

And in fact, not even read a real floppy disk drive?

Can it boot a floppy disk image burnt to USB stick
that has the required BOOTX64.EFI?

Thanks. Paul.

[Joe Monk]

> Are you saying a UEFI-only computer cannot boot a
> real floppy disk?

Most UEFI based motherboards no longer include floppy disk controllers...

>
> And in fact, not even read a real floppy disk drive?
>

If it is a USB floppy... maybe.

> Can it boot a floppy disk image burnt to USB stick
> that has the required BOOTX64.EFI?
>

If it is booting BOOTX64.EFI, something is wrong. BOOTX64.EFI is far too large for a floppy image.

Joe

[Scott Lurndal]

Or when a computer doesn't even have a floppy controller, and nobody makes
USB floppy drives anymore?

[s_dub...@yahoo.com]

On Tuesday, July 13, 2021 at 10:22:04 PM UTC-5, Rod Pemberton wrote:
> On Tue, 13 Jul 2021 19:34:25 -0700 (PDT)
> "muta...@gmail.com" <muta...@gmail.com> wrote:
>
> > On Wednesday, July 14, 2021 at 12:27:11 PM UTC+10, Joe Monk wrote:
>
> > > > And what is preventing my BOOTX64.EFI from hooking
> > > > INT 14H (RM16), switching to long mode, and calling the
> > > > UEFI Serial Protocol?
> > > >
> > > How are you going to hook an interrupt that doesnt exist? There is
> > > no INT 14h in UEFI.
> >
> > My BOOTX64.EFI will put one there.
> >
> > It will point to some RM16 code which may or may not
> > be embedded in the BOOTX64.EFI (my choice).
> >
> I wonder if anyone has done this or something similar for DOS or even
> CP/M. I'm sure there are some diehards who won't give up DOS (or
> CP/M) even in the face of UEFI. Maybe, they already coded a UEFI-shim
> to drop out of LM and into RM, install a usable BIOS, then start up DOS
> (or CP/M). Worth a search?
"

The Compatibility Support Module (CSM) is a component of the UEFI firmware that provides legacy BIOS compatibility by emulating a BIOS environment, allowing legacy operating systems and some option ROMs that do not support UEFI to still be used.
"
The CP/M-80 folks are using emulators on linux, which don't require CSM.

CP/M-86 would need it, but nobody develops for it anymore, the closest would be those working in the S-100 buss environment.

The CP/M BDOS would only support 8mb logical volumes, and 4 of those with a 32mb MBR.

Purportedly, intel is no longer supporting CSM in their bios
I have two Dell 64-bit machines, desktop & laptop, which support CSM, but they're 8-10 yrs old.

It looks like they may still (quick searches didn't yield good results):

https://www.dell.com › ... › Knowledge Base Article
Jun 3, 2021 — CSM (Compatibility Support Module) is enabled by default on the Boot screen in your BIOS. · Look for the option Launch Storage OpROM Policy ...

Steve

[Rod Pemberton]

On Sat, 17 Jul 2021 20:35:46 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> On Wednesday, July 14, 2021 at 1:22:04 PM UTC+10, Rod Pemberton wrote:

> > I wonder if anyone has done this or something similar for DOS or
> > even CP/M. I'm sure there are some diehards who won't give up DOS
> > (or CP/M) even in the face of UEFI. Maybe, they already coded a
> > UEFI-shim to drop out of LM and into RM, install a usable BIOS,
> > then start up DOS (or CP/M). Worth a search?
>
> Do any computer vendors allow you to flash a floppy disk
> image? If I could set the computer to boot from floppy,
> that would cover almost everything I want. I just get the
> above floppy to boot the first hard disk.

Well, I have a bootable compact-flash to IDE adapter which I moved part
of my DOS partition onto, which I'll likely need to replace with a
compact-flash to SATA adapter (or similar) for my next computer. When
you combine the adapter with a compact flash card, it functions like a
very small, very slow SSD. I have a larger compact-flash memory card
here which I've been meaning to, being lazy, moving the entire DOS
partition onto. But, I really don't see the point in doing this
anymore. Just get a cheap SSD. Cheapest SSD here is $22 USD for 120GB.

> Actually, since I never use floppies anyway, maybe I can
> burn a floppy image to USB stick, make the boot priority
> to go to floppies-on-USB, and then what I need is for my
> remaining USB sticks to appear as hard disk images,
> and have priority over the internal hard disk.

Yes, you should be able to do that, but I had problems with this older
machine. I tried putting floppy and hard disk images onto USB and
booting them. Look for USB-FDD, USB-HDD, and USB-ZIP booting, or my
post which comes up on Google's second page:

https://groups.google.com/g/alt.os.development/c/gtA0v5QDkyI/m/s7nN6u9MBwAJ

[muta...@gmail.com]

On Sunday, July 18, 2021 at 11:39:56 PM UTC+10, Joe Monk wrote:

> > Can it boot a floppy disk image burnt to USB stick
> > that has the required BOOTX64.EFI?
> >
> If it is booting BOOTX64.EFI, something is wrong. BOOTX64.EFI is far too large for a floppy image.

I bet a BOOTX64.EFI that suits my purposes would fit
on less than a 360k floppy.

BFN. Paul.