OSDev.org

Hi,

rdos wrote:

Brendan wrote:I've done it with Bochs (e.g. where the normal "BIOS-bochs-latest" ROM image is replaced by my ROM image that contains my OS).

It was actually relatively easy; partly because for Bochs you don't need to initialise some things that you normally would (e.g. memory controller - unlike real hardware the RAM just works at power on),

Doing this in Bochs is not a realistic scenario since you don't need to initialize the chipset in Bochs.

Wow, I would never have guessed...

rdos wrote:Part of initializing the chipset is initializing the PS/2 controller, as most chipsets have registers related to that. Chipset initialization on modern machines is very complex, and chipset manuals are 1000s of pages if they are available at all. This was more interesting on 386 and 486 processors / chipsets. I don't think I'd do this on latter systems.

Obviously you'd choose hardware where it's easy to get the chipset's datasheet (and for Intel's chipsets, it's usually easy to get the datasheet/s). For configuring the chipset you can split things into 3 groups - stuff that has sane power-on defaults that you don't need to care about, stuff that the OS can do (MTRRs, PIC/IO APIC, all PCI, etc), and stuff that the firmware/loader would have to take care of.

For the PS/2 controller itself (assuming you don't care about getting PS/2 devices working), there's only really the reset line (which must have a sane power-on default state to avoid "infinitely rebooting") and A20 (which must have a sane power-on default state to allow the CPU to execute the firmware's code). I can't see why the firmware/loader would need to touch it at all.

rdos wrote:Another issue would be how to keep the system alive if you download something that malfunctions. At the very minimum, you would need some spare flash chips, a tool to remove the flash, and a programmer to even consider this. Although it might be interesting to see if the computer sellers technical support can solve such an issue.

Yes - this is the main reason I haven't attempted to install my OS in a real computer's ROM. I have looked into it though (the easiest way would be something like this device).

The other reason is that I don't really care about booting my OS from ROM myself; and only care about making sure other people can boot my OS from ROM. The idea of the "Bochs ROM" was to provide an example (and framework, and documentation) that other people (e.g. someone planning to manufacture thousands of embedded devices) could use as a starting point.

rdos wrote:

Brendan wrote:Also note that it was extremely fast. Normally Bochs BIOS takes half a second initialising irrelevant/unnecessary stuff and then my code takes another half a second or so to load data from disk. Getting rid of the BIOS and the disk IO means the OS booted in 1 second instead of 3 seconds.

I think it would be possible to boot real machines in sub-seconds by replacing BIOS, but it seems like a lot of work.

If you're making thousands of devices it'd make sense (e.g. smartphone, tablet, GPS, smartTV, etc); especially if the hardware is custom designed for the device. If you're only making a small number of devices it probably wouldn't make sense.


Cheers,

Brendan

Brendan wrote: Obviously you'd choose hardware where it's easy to get the chipset's datasheet (and for Intel's chipsets, it's usually easy to get the datasheet/s). For configuring the chipset you can split things into 3 groups - stuff that has sane power-on defaults that you don't need to care about, stuff that the OS can do (MTRRs, PIC/IO APIC, all PCI, etc), and stuff that the firmware/loader would have to take care of.

I wouldn't do it that way. As I see it, there is no reason why the OS would mess with MTRRs or PCI configuration. That's the job of the BIOS/firmware, mainly because the BIOS knows best how to configure those. Also, there is no reason why the OS would reinitialize for instance PCI when the BIOS already did this from the optimal point of view of the actual hardware setup.

Brendan wrote: For the PS/2 controller itself (assuming you don't care about getting PS/2 devices working), there's only really the reset line (which must have a sane power-on default state to avoid "infinitely rebooting") and A20 (which must have a sane power-on default state to allow the CPU to execute the firmware's code). I can't see why the firmware/loader would need to touch it at all.

The thing is, the PS/2 controller doesn't need to be touched at all unless it needs to be enabled in the chipset.

But you forget the major problem with replacing BIOS: ACPI. In the case of ACPI, I would save several 100kbs of unnecessary code in the OS by not having ACPI support. It would also save the work of fixing AML code for PCI-IRQs. I think I'd provide the data needed by the OS (mainly number of cores and PCI IRQs) in another way, and add a new OS driver instead of ACPI.

Brendan wrote: Yes - this is the main reason I haven't attempted to install my OS in a real computer's ROM. I have looked into it though (the easiest way would be something like this device).

Interesting

Brendan wrote: If you're making thousands of devices it'd make sense (e.g. smartphone, tablet, GPS, smartTV, etc); especially if the hardware is custom designed for the device. If you're only making a small number of devices it probably wouldn't make sense.

I could see it as interesting for our terminal as well, and it has a relatively old CPU (AMD Geode), and probably relatively simple chipsets, and we don't use ACPI with it. Today it takes a long time to boot, and booting it in 1 second, and with no option to replace the OS, that would both be nice and potentially an security advantage.

Rdos, how do you identify the type of mouse that is connected to the PS/2 port.

rdos wrote:I wouldn't do it that way. As I see it, there is no reason why the OS would mess with MTRRs or PCI configuration. That's the job of the BIOS/firmware, mainly because the BIOS knows best how to configure those.

You just missed a 90% speed improvement by design for a lack of write-combining and AGP support.

Combuster wrote:...lack of write-combining...

Write combining can be enabled via PAT

Hi,

rdos wrote:

Brendan wrote:Obviously you'd choose hardware where it's easy to get the chipset's datasheet (and for Intel's chipsets, it's usually easy to get the datasheet/s). For configuring the chipset you can split things into 3 groups - stuff that has sane power-on defaults that you don't need to care about, stuff that the OS can do (MTRRs, PIC/IO APIC, all PCI, etc), and stuff that the firmware/loader would have to take care of.

I wouldn't do it that way. As I see it, there is no reason why the OS would mess with MTRRs or PCI configuration. That's the job of the BIOS/firmware, mainly because the BIOS knows best how to configure those. Also, there is no reason why the OS would reinitialize for instance PCI when the BIOS already did this from the optimal point of view of the actual hardware setup.

Nothing guarantees that the BIOS/firmware found the optimum configuration for MTRRs or PCI; and nothing really guarantees that the BIOS/firmware isn't a buggy mess (e.g. "tested on Windows only").

Beyond that, if you start looking at things like hot-plug RAM and hot-plug PCI you end up needing something code to adjust MTRRs and/or PCI while the OS is running. In this case you can do the minimum necessary to adjust to the changes (and end up with less than optimal configuration after the changes) or find the optimum configuration for MTRRs and PCI again (which may be completely different).

rdos wrote:But you forget the major problem with replacing BIOS: ACPI. In the case of ACPI, I would save several 100kbs of unnecessary code in the OS by not having ACPI support. It would also save the work of fixing AML code for PCI-IRQs. I think I'd provide the data needed by the OS (mainly number of cores and PCI IRQs) in another way, and add a new OS driver instead of ACPI.

I've always planned to have "motherboard drivers" instead of using ACPI (although it should still be possible to have a generic motherboard driver that uses ACPI internally). The first step towards writing "boot from ROM" firmware would be to write the motherboard driver and make sure it works.

rdos wrote:

Brendan wrote:If you're making thousands of devices it'd make sense (e.g. smartphone, tablet, GPS, smartTV, etc); especially if the hardware is custom designed for the device. If you're only making a small number of devices it probably wouldn't make sense.

I could see it as interesting for our terminal as well, and it has a relatively old CPU (AMD Geode), and probably relatively simple chipsets, and we don't use ACPI with it. Today it takes a long time to boot, and booting it in 1 second, and with no option to replace the OS, that would both be nice and potentially an security advantage.

The other thing I didn't mention is that writing your own "boot from ROM" code can mean writing SMM code. Normally the firmware's SMM does things like power management until the OS takes over (e.g. starts using ACPI).


Finally, in case anyone isn't aware of it, I should probably mention the coreboot project. One of the goals of coreboot is to replace proprietary firmware with open source firmware. Currently they have code for over 230 motherboards and all of that code is GPL. Anyone that wants to do "boot from ROM" can either build on top of coreboot's code (e.g. your OS as a coreboot payload), or "cut & paste" from coreboot's code to create your own loader (as long as your own loader is GPL), or use coreboot's code as a reference (without using any of coreboot's code, and possibly without making your code GPL).


Cheers,

Brendan

Owen wrote:

Combuster wrote:...lack of write-combining...

Write combining can be enabled via PAT

Exactly. MTRRs doesn't add anything that cannot be done with PAT.

Brendan wrote: Nothing guarantees that the BIOS/firmware found the optimum configuration for MTRRs or PCI; and nothing really guarantees that the BIOS/firmware isn't a buggy mess (e.g. "tested on Windows only").

Agreed, but I use the simplest approach until it is proved inadequate. The simplest approach is to leave MTRRs and PCI to BIOS. If I'd change this it would be part of a project to eliminate BIOS, and then this code could be feed-back into the OS if needed.

Brendan wrote: Beyond that, if you start looking at things like hot-plug RAM and hot-plug PCI you end up needing something code to adjust MTRRs and/or PCI while the OS is running. In this case you can do the minimum necessary to adjust to the changes (and end up with less than optimal configuration after the changes) or find the optimum configuration for MTRRs and PCI again (which may be completely different).

Frankly, I cannot see the point of hot-plug RAM or hot-plug PCI. None of my current targets have such functions. But then I might change my mind if I need any of these in the future. For now, I take the lazy approach and ignore it.

Brendan wrote: I've always planned to have "motherboard drivers" instead of using ACPI (although it should still be possible to have a generic motherboard driver that uses ACPI internally). The first step towards writing "boot from ROM" firmware would be to write the motherboard driver and make sure it works.

Kind of my thought too. I suppose there would be a need to create some generic APIs for processor and motherboard, and then supported processors and chipsets will get their own implementation module. That would move much of the chipset initialization to the OS. What would remain in the firmware would be basic processor initialization and memory configuration only. That gets rid of much of the need for ACPI.

The motherboard driver probably should be kind of "object oriented", in that the generic chipset driver sets up default conditions, and then a more specific motherboard driver tweaks settings for a particular mother-board. Ideally, this should be possible to do in multiple steps.

Brendan wrote: The other thing I didn't mention is that writing your own "boot from ROM" code can mean writing SMM code. Normally the firmware's SMM does things like power management until the OS takes over (e.g. starts using ACPI).

I'd rather avoid SMM as much as possible, as it creates non-determinable execution times. Removing SMM would make it feasible to add hard realtime.

Hi,

rdos wrote:

Owen wrote:

Combuster wrote:...lack of write-combining...

Write combining can be enabled via PAT

Exactly. MTRRs doesn't add anything that cannot be done with PAT.

For older CPUs (Pentium, Pentium Pro, Pentium II) there is no PAT and you have to use MTRRs.

For newer CPUs that do have PAT, it can only be used to strengthen the MTRR types. For example, if the MTRR says "uncachable" then you can't set the PAT to "write-back" and expected it to make any difference at all.

Finally, if PAT exists and is used to strengthen the MTRR's type; then it's normally less efficient anyway because the CPU still has to do all the cache coherency stuff. For example, if the MTRR says "write-back" and the PAT says "uncachable" then the CPU can't know that the same page isn't "write-back" somewhere else (in the same CPU's virtual address space or on a different CPU) and therefore can't skip things like telling other CPUs to evict/write the cache line or checking it's own cache before modifying data.

As far as I know; making something "write-combining" when the MTRRs say "uncached" may be the only case where PAT (if supported) is as good as MTRR.


Cheers,

Brendan

Hi,

rdos wrote:I'd rather avoid SMM as much as possible, as it creates non-determinable execution times. Removing SMM would make it feasible to add hard realtime.

Getting rid of ACPI, and getting rid of any legacy device emulation (PS/2 emulation, HPET emulating PIT, etc) would only solve part of the problem. The other part is power management (e.g. control of fans, etc in the time between power-on and the OS starting appropriate drivers) which is likely to require SMM, but that would solve itself after the OS takes control of power management from the firmware. Depending on motherboard; that can still leave a few minor issues (e.g. like "RAM scrubbing" for ECC in some systems) that can't really be avoided.

Of course I wouldn't necessarily be happy with completely avoiding SMM anyway - a powerful feature like that begs to be taken advantage of in some way (e.g. maybe some sort of SMM based watchdog to store diagnostic info and reboot the OS if things go wrong).


Cheers,

Brendan