OSDev.org

I read that old machines had a rom with a BASIC interpreter. The BIOS when it didn't found any os, called the int 18h, that jumped to this rom. Now it has been removed by computers, but there is still the interrupt. Is possible write a small os in that rom area?

It was not removed. It was replaced by a routine that says: "pleas insert boot-media and press enter to continue" or something similiar.

Hi,

Karlosoft wrote:Is possible write a small os in that rom area?

Sort of. That area isn't empty (it's not like there's a 64 KiB chunk of unused zeros in the ROM where BASIC used to be); so you'd need to replace the entire ROM. You won't be able to get source code for the computer's existing BIOS, so you'd need to write your own firmware, including the motherboard specific initialization, RAM chip setup, POST, etc and you wouldn't be able to use any BIOS functions without writing them yourself. Then you'd need a way to get your code into ROM (e.g. either a utility to write to flash memory that suits the motherboard, or perhaps something like an EPROM programmer for computers that don't use flash memory).

Note: For previous versions of my OS I did write "boot from ROM" code for Bochs. This actually isn't too hard (mostly because Bochs doesn't need much initialization/POST code). As long as your OS is designed carefully (e.g. doesn't use BIOS functions after boot), this may mean writing a special boot loader (to do chipset initialization, etc) and not much else. My own "boot from ROM" code for Bochs was intended as a proof of concept thing, that people who manufacture embedded devices could use as a reference when they want to write a boot loader (to boot my OS from ROM) for their embedded system.

Rather than starting from scratch, you might want to build it on top of coreboot. At a minimum that might save you from writing chipset specific initialization/POST code for each motherboard. However, (if nothing has changed since last time I looked into it) the coreboot project seem to assume that the OS will use a boot loader (GRUB2, FILO, etc) and won't be in the ROM itself. To get around that you'd need to write your own "payload" (basically a boot loader that will start your OS from ROM that runs after coreboot has done chipset initialization, etc), but the coreboot project refuse to write or provide any sort of specification that a payload can rely on, and you'd need to have a lot of conditional code and update your payload/boot loader every time anything in coreboot changes (which IMHO makes coreboot mostly useless for "boot the OS directly from ROM" situations, unless you want to spend most of your time updating/maintaining one boot loader for your OS rather than actually writing your OS).

An alternative would be to create a ROM on a device instead. For example, most cheap ethernet cards have an empty socket for a boot ROM, so you'd be able to put your OS on a ROM chip and plug it into the ethernet card. This would avoid the problems of using the main/BIOS ROM chip, as the existing BIOS wouldn't need to be changed, and the existing BIOS will map your ROM somewhere (e.g. in the area from 0x000C8000 to 0x000F0000), and call your ROM's initialization routine (which could insert it's own "int 0x18" interrupt handler that boots your OS when the BIOS doesn't find anything else to boot). The problem here is that most ethernet cards don't support large ROMs - for e.g. your OS might need to fit in 64 KiB of space.

Finally, (depending on your goals) probably the most practical idea would be to forget booting from ROM, and boot from an SSD drive, or use something like an "IDE to compact flash" adapter, or even just use USB flash. It's not the same, but it's very similar and means the OS doesn't need to be changed at all.


Cheers,

Brendan

Brendan wrote: An alternative would be to create a ROM on a device instead. For example, most cheap ethernet cards have an empty socket for a boot ROM, so you'd be able to put your OS on a ROM chip and plug it into the ethernet card. This would avoid the problems of using the main/BIOS ROM chip, as the existing BIOS wouldn't need to be changed, and the existing BIOS will map your ROM somewhere (e.g. in the area from 0x000C8000 to 0x000F0000), and call your ROM's initialization routine (which could insert it's own "int 0x18" interrupt handler that boots your OS when the BIOS doesn't find anything else to boot). The problem here is that most ethernet cards don't support large ROMs - for e.g. your OS might need to fit in 64 KiB of space.

That's a cool idea. To elaborate, the BIOS scans each 2 KB region from C8000 to F0000 for a valid ROM. A valid ROM begins with 0x55 0xAA followed by a byte indicating the length of the ROM image (in 512 byte increments). It must also have a checksum of zero (if all bytes in the ROM are added together, unsigned). When a valid ROM is found, it is activated via a far call to the fourth byte. So if you want to use this ROM-on-a-device method, your ROM must follow that format.

The Bochs emulator allows you to load extra ROMs, and its BIOS will look for the 0x55 AA signature and appropriate checksum. So you could test your ROM without risking a real computer.

manonthemoon wrote: That's a cool idea. To elaborate, the BIOS scans each 2 KB region from C8000 to F0000 for a valid ROM. A valid ROM begins with 0x55 0xAA followed by a byte indicating the length of the ROM image (in 512 byte increments). It must also have a checksum of zero (if all bytes in the ROM are added together, unsigned). When a valid ROM is found, it is activated via a far call to the fourth byte. So if you want to use this ROM-on-a-device method, your ROM must follow that format.
The Bochs emulator allows you to load extra ROMs, and its BIOS will look for the 0x55 AA signature and appropriate checksum. So you could test your ROM without risking a real computer.

Nice. I also think its a cool idea. I have a RTL8139 that has a DIP32 Socket, which apparently can be used with ROMs up to 128K x 8, which is great. I will try to search more info on what ICs are supported.

I want to know, is loading from a ROM like that supported by every BIOS?

Cheers,
Gzaloprgm

gzaloprgm wrote:I want to know, is loading from a ROM like that supported by every BIOS?

Most likely, it is a standardized functionality.. you'll find option ROM's on ATA/SATA controllers, VGA graphics cards, and Ethernet cards as mentioned previously (..for PXE booting, etc).

http://en.wikipedia.org/wiki/Option_ROM
http://en.wikipedia.org/wiki/BIOS#The_B ... cification
http://www.phoenix.com/NR/rdonlyres/56E ... bbs101.pdf

Have fun.

Hi Brendan,

Brendan wrote: However, (if nothing has changed since last time I looked into it) the coreboot project seem to assume that the OS will use a boot loader (GRUB2, FILO, etc) and won't be in the ROM itself.

Sorry to say, but that is wrong, and has never been the case. coreboot started out as "LinuxBIOS" and hence started Linux directly from flash, without another boot loader. However, in many cases the OS is too big for available and supported NOR flash sizes, so that is where a boot loader comes in handy and loads the OS from a secondary device. Systems usually support 512KB-2MB (4-16MBit) flash parts these days. As long as the OS you want to put in flash is smaller than that, you are perfectly fine without boot loader.

Brendan wrote: To get around that you'd need to write your own "payload" (basically a boot loader that will start your OS from ROM that runs after coreboot has done chipset initialization, etc), but the coreboot project refuse to write or provide any sort of specification that a payload can rely on, and you'd need to have a lot of conditional code and update your payload/boot loader every time anything in coreboot changes (which IMHO makes coreboot mostly useless for "boot the OS directly from ROM" situations, unless you want to spend most of your time updating/maintaining one boot loader for your OS rather than actually writing your OS).

Wrong, again, sorry. Coreboot uses two very defined interfaces between itself and its payload:

• It loads an ELF or Multiboot binary. So if your OS kernel is an ELF binary, coreboot can load it.
• It provides the coreboot table to its payloads. This table is well defined and contains all information needed by the payload to take full advantage of coreboot.

In addition to that, coreboot provides a Library to facilitate OS and payload writers, so they don't have to worry about parsing any of those tables, or re-implement commonly used functionality like libc, serial, text mode or graphical console, and even a tiny USB stack (all features can of course be disabled):
Libpayload - http://www.coreboot.org/Libpayload

Hi,

@coresystemsgmbh; you're replying to a post I made on 31 Jul 2009 (give or take minor time zone differences), and almost 8 months have passed...

Not too long before I wrote my comments I attempted to get documentation about the interface between coreboot and payloads (on their mailing list), and failed. The best they could do is "read the source code" (even though the source code was being heavily changed at the time, and there was no way they could guarantee that any payload that worked one day would still work the next day, the next month or the next year). You can probably still find my emails and their replies in Coreboot's mailing list archive.

Since then, coreboot has done a lot more work.

Also note that the "GRUB2" payload didn't exist at the time (and the "GRUB2" project still hasn't published an adequately usable multi-boot specification for "non-PC BIOS" computers - here's their draft, but at least they *do* have a specification, sort of).

coresystemsgmbh wrote:

Brendan wrote: However, (if nothing has changed since last time I looked into it) the coreboot project seem to assume that the OS will use a boot loader (GRUB2, FILO, etc) and won't be in the ROM itself.

Sorry to say, but that is wrong, and has never been the case. coreboot started out as "LinuxBIOS" and hence started Linux directly from flash, without another boot loader. However, in many cases the OS is too big for available and supported NOR flash sizes, so that is where a boot loader comes in handy and loads the OS from a secondary device. Systems usually support 512KB-2MB (4-16MBit) flash parts these days. As long as the OS you want to put in flash is smaller than that, you are perfectly fine without boot loader.

Linux is 5 MiB or more (compressed) - over twice as big as the biggest flash part today (and probably 4 times larger than the biggest flash part that was available when LinuxBIOS first started). Of course coreboot itself takes up some of this space too.

Initially they wanted to do the minor modification on Linux to make it boot from flash (and thought that Linux would configure most of the chipset, etc). Then they found out it didn't fit and there's a large amount of "configure the chipset" that Linux doesn't do. Their "minor modifications" became a complete change of plans followed by years of work.

coresystemsgmbh wrote:

Brendan wrote: To get around that you'd need to write your own "payload" (basically a boot loader that will start your OS from ROM that runs after coreboot has done chipset initialization, etc), but the coreboot project refuse to write or provide any sort of specification that a payload can rely on, and you'd need to have a lot of conditional code and update your payload/boot loader every time anything in coreboot changes (which IMHO makes coreboot mostly useless for "boot the OS directly from ROM" situations, unless you want to spend most of your time updating/maintaining one boot loader for your OS rather than actually writing your OS).

Wrong, again, sorry. Coreboot uses two very defined interfaces between itself and its payload:

• It loads an ELF or Multiboot binary. So if your OS kernel is an ELF binary, coreboot can load it.
• It provides the coreboot table to its payloads. This table is well defined and contains all information needed by the payload to take full advantage of coreboot.

If the coreboot table is well defined, where can I find the specification that "well defines" it? Is "Payload API" this wiki page what you're talking about?

At the time, I wanted a "payload specification", so that I could write a payload that complies with the specification and know that my payload will work in all (current and future) versions of coreboot that also comply with the specification. I did not want to write a payload that continually breaks because of changes to the "payload API", because this would be a nightmare for end-users (trying to figure out which version/s of coreboot are compatible with which version/s of my payload, and complaining when they get it wrong and their computer won't boot).

As far as I can tell, they have still failed to produce any such document.

They do have "Libpayload", which might work (sort of) if I used C (and not assembler) and if my end users were forced to compile my payload before installing it (which is something I've always avoided - I never assume any end-user has a compiler). Een then, it's not an adequate substitute for a specification - nothing says that coreboot can't change libpayload any time they like, and break my code so that it fails to compile when end-users attempt to install my code.

Anyway, I gave up on coreboot back then, because they were too stupid to produce a specification, and too stupid too see why a specification is needed. I'm not convinced that's changed since (but I'd be happy to be proven wrong).


Cheers,

Brendan

I didn't yet read the post, I just saw the Multiboot 2 draft link in Brendan's post. That draft is not update anymore and people have stopped working on it. There's another standard that's actively beeing worked on but I'm too lazy to search for the Bazaar repo. More info on the GRUB mailing list.

Hi,

Love4Boobies wrote:I didn't yet read the post, I just saw the Multiboot 2 draft link in Brendan's post. That draft is not update anymore and people have stopped working on it. There's another standard that's actively beeing worked on but I'm too lazy to search for the Bazaar repo. More info on the GRUB mailing list.

Hehee

Fred: "Let's build a house!"
Dave: "Ok, do you have any plans?"
Fred: "No, I just want to build a house!"
Dave: "Ok"
-several months pass-
Fred: "We're finished - it's magnificent!"
Dave: "Yes, it's a very nice statue of an elephant, but where are you going to live?"


Cheers,

Brendan