OSDev.org

RBIL actually does mention that its 32 bit - right there in its name - "Phoenix BIOS v4.0 - GET MEMORY SIZE FOR >64M CONFIGURATIONS (32-bit)" It would be nice to find a more authoritative source though but expect the details to differ between systems anyways. Don't confuse E881h with E801h.

Hi,



I think you're right.

I've been researching it (or at least trying to). I found a document/presentation from Pheonix that points towards an "EISA specification" that I can't find anywhere, and can't find anything "official looking" (either online or in books I have) that describe the BIOS function at all; but circumstantial evidence points towards the function being for protected mode.



I assumed it was called "32-bit" in Ralph Brown's list simply because it uses 32-bit registers; and thought that maybe it was designed to be a little future-proof and that on systems with more than 4 GiB of RAM it'd say there's more than 0xFFFF 64 KiB blocks of extended memory (but still less than 0xFFFF blocks configured due to the "PCI hole").


Cheers,

Brendan

Why worry?
Using CPU hardware multitasking and a V86 task for handling the A20 enabling by the KBC, we can certainly terminate the task along with the lock up automatically after a set limit time from the main system task (keeping the "A20 disabled status" as a result).

After that time limit, we simply terminate the V86 task. We would do the same secondary task termination to avoid failing when using the mouse or the keyboard. If we fail all of those tasks, we can also take note of it and assume that there's something wrong with the KBC, not necessarily meaning thati it's missing.



I remember that there's a bit in one of the KBC registers that lets you reset the system. This is how everyone uses to reset the OS with software. It should be documented in the wiki.

Because either the chipset will cause a reset or lock up in hardware, or the firmware will cause problems in SMM mode; and it won't make any difference if you diddle with the IO port/s using V86 mode or not.


Cheers,

Brendan

Then, why not implement a journaled initialization layer that stores data on disk? If it locks up or resets, it will continue where it left, using also the good configuration and initialization methods proven so far.

It can state that it was reset during initialization of XYZ and that it's continuing the boot and loading process.

So unless we use something like F8, the system will continue a stable execution, without worrying of bogus resets.

Stop taking about make-believe virtualization layers and listen to the people who know what they're talking about.

If you frob hardware that doesn't exist, bad things happen. Worse things happen if you frob hardware that the chipset and a microcontroller don't agree on whether or not they exist. Let's say there's something attached to ISA port 0x60 and 0x64, but the chipset has it lazily turned "off". A byte goes out I/O port 0x60, the CPU waits on the chipset to hand it over, the chipset just ignores it and doesn't tell the CPU that it's releasing the I/O bus. System hangs. Or maybe the chipset, knowing full well that the keyboard controller is off, decides the only thing that you could possibly want if you frob the keyboard controller is to pulse the reset line. System resets.

And don't tell me this doesn't happen, because it happens, and I've seen it happen several times.

You can base the initialization tasks on testing the results. You can have an API to record what worked and what didn't.

If you store the successful configuration on disk with journaling of its own, you can suffer resets and continue advancing until you end up loading the system correctly.

If you add APIs that inform the system whether the configuration succeeded or not, and write that on disk, you can try something else if you happen to need a reboot. Now you just skip the failing option (of course you will need to mark it as the last configuration point after failure, to try something else).

_____________________________________
_____________________________________
_____________________________________
_____________________________________
I personally have always only ever needed to use the KBC for the A20. Of course, I still can't handle machines that have exclusively USB ports. I still need the PS/2 machines because they are still modern and have everything I need right now, so why not end up learning how to handle it? That's the natural sequence that absolutely everybody in the planet followed to get to the current hardware state. But once it's understood, it will be easy (and convenient) being able to have a system capable of booting in the oldest and newest machines, which will only ever reboot at most, and still continue loading, finding the right options until recording them (as a bare minimum system installation and configuration... some other reason for things like Windows to reboot so many times during install, don't you think?).



I guess that sustaining the configuration process until loading, even against bogus resets, is the minimum that a small personal OS could do to work much better instead of just hanging. Probably this is exactly what they lack.

There are extremely tiny initialization details that even I have implemented but that bigger OSes don't for whatever reason, and in which case they also just hang, but mine don't, but then my OS loads but doesn't have all of the functions of the bigger one that hanged, but at least it booted correctly.

Hi,



Because it's trivial to get A20 right (and avoid all the pitfalls) using well known (and already described) practices; without needing any over-complicated (and therefore error prone) mess to deal with problems caused by not doing A20 right.

Journaling might be a good idea later during boot (e.g. after you've got kernel, storage drivers and file systems started, which may include networking and NFS for diskless machines), when you're starting "less essential" drivers (sound, video, USB, keyboard, etc). Before you've got file systems working it's far too complicated (until/unless reliable "non-volatile main memory" becomes ubiquitous?).


Cheers,

Brendan

The intention would be to give the system all the chances to boot successfully. Always taking into account a balance of the number of layers to add to one same thing, maybe the initialization structures in RAM could have a checksum and a signature. If they are still there after a reboot, we can know where to continue. It would probably be too unreliable.

We could have those structures on disk and in RAM. I don't know what use it would have knowing that there was a hard reset (erasing RAM) or having the RAM copy of the structure destroyed, but it could tell us how the machine behaves.

Then it would be good to implement hardware multitasking for V86 mode to protect against common lockups, an abstracted enough hardware and software layer to make it standard not necessarily through emulation but through service wrapper functions with standard ordinal numbers in place of memory regions and legacy/standard I/O ports, and file system drivers, at least FAT file systems to at least read and write the root directory, and capability to load raw libraries and binaries. With that it would now be possible to do considerably more with a relatively simple system.

It's easy to implement a FAT file system in the sense that it doesn't take that many Kilobytes. It just needs to be well debugged. Once it's written, it will be of big help from now on so even if it takes months of thinking it will be worthy.

Hi,



The intention would be to increase the probability of booting successfully (which is fine/admirable); but in practice too much complexity too early has the opposite effect and reduces the probability of booting successfully.



Yes, it's easy to implement one of the world's worse file systems and completely ignore any hope of security, ignore the chance of file system corruption and other errors, etc. However this makes the huge assumption that you're able to find and access (and write to) the disk in the first place; which means there's a large number of corner cases where it's going to fail (disk errors, booting from hard disk when you're FAT partition is on USB flash and BIOS "int 0x13" doesn't give you access, GPT partitioned disk where the "protective MBR" doesn't mention the partition you want, diskless machines that boot from network, booting from CD where writes aren't possible and FAT is inappropriate, USB flash where you write on one machine then plug it into another and wonder why everything is different now, etc).

If you don't handle all the corner cases it ends up failing for all the corner cases you neglected. If you do handle all the corner cases, implementing poor quality/low performance FAT file system code becomes a speck of snow on the tip of the iceburg, and you end up needing the equivalent of a small monolithic kernel built into your boot loader (and start wondering about maybe having a journal for your journal, in an attempt to work-around and recover from "failed to read/write to the journal" problems).


Cheers,

Brendan

my motto regarding this issue. use LSD (lowest common denominator). If there is a substitute approach using simpler instruction use it.

LSD is a drug. Don't use drugs.

Hi,



Unless it's a Limited Slip Differential - they're awesome (and should be used).


Cheers,

Brendan

Don't use LSD radix sorts either!