[unintentional edit by vid]Sorry, AGAIN i was going to click QUOTE and hit EDIT instead without noticing... grrrr, i'm going to need some moderating UNDO.

Sorry tom, i deleted text of your post, and don't gave original text to revert it

Anyway, i suggest you to use "Search for all terms" instead of "Search for any terms"...

Good ideea... I think i will write something like this for my OS dev tutorials...

But then it is so simple that it is almost required for a truth seeker on the path of OS Dev...

One must be able to collect and understand this kind of information from multiple sources for multiple assemblers out there...

There are so many options, so many paths for each assumption taken, for each instruction written...

For example you could be booted by the BIOS... or by EFI or by a 3rd party boot loader or boot manager like GRUB or XOSL or SmartBootmanager or... <you name it>

Such boot managers will try to simulate the behavior of the BIOS (to the best of it's author knowledge).

Assumption One
Let's assume that BIOS it is.

BIOS will load the first sector from the media (floppy or HDD) at address 0:7C00. It will also check that the last bytes of the sector are 0x55 0xAA

If those last two bytes are not like this then the BIOS will reject the boot sector code.

Right at the first bytes of your boot code a problem arrises: some bioses do load at 07C0:000 . This is equivalent as a physical address to 0:7C00 in real mode but the segment part is diferent. Then it is uncertain where the stack used by the BIOS is located and if it is big enough.

Most boot code starts with a JMP My_Start instruction in short form (0xEB, short offset) . This is because they assume a structure will follow right after this jump. However this structure is NOT needed unless you want your floppy to be also accessible from or as a FAT12 filesystem.

Since you say that you do not care for FAT or other proprietary file systems (neither do I other than for inter interoperability) then this structure might not be there and the JMP could be considered superfluous.

Enough for this post ....

Thank you Bogdan, excellent response, as always. Umm, no, I don't believe that I mentioned FAT, though, you have correctly read my mind!!!!

Ok, we're getting somewhere. BIOS does this, and that, and so on. Yes, but, what if one wished to BYPASS BIOS? As I understand, BIOS is 100% Real mode code.
This peculiar business with the "signature" of 0x55 0xAA is illustrative of what I am seeking to clarify. Isn't this, as I believe you have suggested, a bit of CODE, necessary for BIOS to accept the initialization as valid? But, if one wished to start afresh, start anew, start over, bypassing the BIOS, then, this bit of nonsense disappears from the initial code..... What other CODE, besides this silly 0x55 stuff, is in the startup that is perhaps irrelevant, depending upon what one seeks to develop? What are the MINIMUM essential instructions which MUST be present for the cpu to operate, and for the motherboard devices to function correctly? Obviously, one can CHANGE the CMOS program, if one wishes to do so, (and if one has an old motherboard kicking around, getting dusty, and if one has a CMOS programmer available......)

BIOS or EFI or ... is whatever code does take over processor and hardware initializations when computer/motherboard/power starts-up. In this regard each device might also have some code executed by it's micro controller at startup (usually named firmware).

Conceptually speaking it has to be some kind of code that gets control at start-up... and guess what: it is not your code unless you manufactured the device



It serves no purpose to bypass BIOS. Firsto of all by beeing motherboard or device specific the BIOS knows "exactly" what is there to be done. It serves as the very first abstraction layer. At least it starts up the computer.

I does not have to be all real mode. It just has to start in real mode because the CPU does start like this. Today BIOS does have some SMM code that is executed even when the CPU/OS is otherwise in 32bits protected mode or even in 64bits long mode. A special execution environment that you can not touch....well almost

BIOS it is a very good an intelligent idea, but it gives too much power to ordinary people and this is disliked by corporations. It is also disliked by some part of "elite" programmers.

IF BIOS would have been extended into 32bits and 64bits then OS programming and hardware programming would be much more easy for every human. You could have a decent fall back driver coming from the hardware manufacturer itself. And of course you could later on bypass this with your ultra speedy sophisticated super driver if you desire...

Nevertheless this rant's point is that you should not bypass BIOS.

Instead you should say "thank you" for setting things up for me until now, it is interesting to see what informations you have for me to inspect... I will take it from here... bye bye and see you at next re-boot

No matter what you do there will have to be some form of BIOS or at least "boot strap code" present on a piece of hardware...



This 0x55 0xAA stuff is simply a data signature tested by BIOS as a minimal safety check. Otherwise BIOS will simply try an "boot" random data.

If 55AA is in there, then BIOS will assume that you wanted this device / media to be bootable. If 55AA is not there, then BIOS will conclude that this is not a bootable device.

There is nothing more to it.



To accept it? NO., there is nothing more required, only the 55AA.

But if you are talking about beeing functional, executable and really usefully in this context is another issue.




As I have said before you can not start fresh unless you write your own BIOS and have your own hardware.

Well to be naughty you could erase your BIOS (if it is in a writeable flash) and then you are really in trouble... but "fresh"

If you need to startup the motherboard devices, test the CPU, boot an OS --> then you will need to pretty much rewrite a... kind of "BIOS".

But I do not see how you can do that without proper hardware information details about the hardware of choice....



55AA is not "code" is it a "data" signature

Many things could be "irelevant" if one seek to develop just for a specific version of BIOS or a specific hardware.

BUT If you seek to run on multiple hardware and BIOS configurations then one must take redundant actions and write some code that might be irelevant on some hardware but required on another hardware.

One such issue is the start-up location of either 0000:7C00 or 07C0:0000
On some machine you can assume one of them and then the code that deals with the other "posibilitty" can be considered as " irelevant" ... but in fact it is not...



Oh this is too much...

Basically the CPU will start at a specific location when powered up...

As I have said before it is the BIOS that gets control at that location
It is not you. BIOS will usually run a series of tests to ensure that the CPU is in a valid "workable" state.

Those tests are quite a lot. It has to test the cache, memory the stack, CPU inetrnals, FPU etc. Of course one can bypass such tests and always assume that the CPU works flawlessly

But then again this is NOT your choice...it is BIOS choice...

The the BIOS will have to initialize and startup each motherboard device and additional devices present. This depends on each chipset, each chipset version, each device present and it's versions. You end up with thousands or thens of thousands of configurations and small "code" routines and sequences for doing this. As we speak new devices emerge and new chipset versions emerge.

The BIOS manufacturers have slowly created a database of such code and deploy only needed components for a specific product that is going to be fabricated... plus or minus the possible upgrades (CPU, a few devices).

Hence BIOS is hardware release specific. On a simple hardware it could be somehow "simple" ... but there is no simple hardware sold in stores anymore




I sense a small miss interpretation of the term CMOS here.

CMOS is technically an data area that preserves it's contents during power down power up cycle... It is a CMOS chip because it has a battery back-up and CMOS devices require very little power to operate... you can store few parameters in there...

Ooops no, what I mean is that the BIOS can store a few parameters in there.

And there is also a CMOS real time chip that will continue to thick when power off (using the same battery)...

What people name as: "CMOS program" is a wrong name for the BIOS setup screens routines. This is a part of the BIOS that presents to the user a few options that can be tweaked.

The whole BIOS is either in an EEPROM memory (very old motherboards) or in a FLASH re writable memory; it might be socketed or not

This memory yes can be re-written by using a BIOS vendor specific software utility... This utility is mainly used for updating the BIOS

Yes one can abuse this utility in order to erase the BIOS completely and insert <your own startup program> in there...

But doing this is NOT advisable!!!

You will most likely damage your motherboard/devices.

The reson for this is that you do not have the information about how and what to do in order to startup the hardware devices and you can not obtain this information.

Obtaining this information for only ONE variation in ONE hardware computer/laptop is not a trivial task...that could possibly never get acomplished in a life time beacuse it is usually keept secret by the BIOS manufaturer and hardware manufactureres...

"They" do create a cartel of capitalistic "silence" players and information blockade against any individual or open source teams. And this is "normal" since they have profits and perfectly legal interests to protect.

"Normal" under human capitalistic rules of course...

Some open source BIOS projects do exist...but they are far from functional or from running on a decent heap of devices.

By the time this open source projects advance... a new series of devices will emerge. A series with even more secret and encrypted features and modes of operations unconceivable before.

...There is no tomorrow...

no problem, vid, really. Umm, as most FASM forumers know, my posts are much too verbose anyway. Moreover, Bogdan is so thorough in responding to inquiries, that a reader always has a good chance to understand the issues of concern....
In brief, I started this thread with some questions about the initial start up, and suggested that it could be useful to list, instruction by instruction, whether or not the particular instruction existed to permit the cpu, the motherboard itself, or the BIOS to function....
I concluded the initial post by suggesting that perhaps some of the current startup code reflected limitations from the 8086 era, thirty years ago, and could be omitted/changed by those seeking to develop a new operating system, functioning outside the sphere of Microsoft/Linux.....

....OK. fine. Then, another way of writing my question is this:
What is the minimum size of this "boot strap code"? Are all manufacturers of chip sets equally secretive about their requirements at the time of power initialization?

This is a question for the BIOS programmers to answer

AFAIK today BIOS flash chips have a capacity on approximative 1Megabyte
IF it is all for code then it is way bigger than Solar_OS as a whole

It has to deal with CPU and chipset initializations, PCI, PCI Express, legacy devices (keyboard, mouse, beeper, timer, CMOS), IRQ setup and Routing, power management, ACPI, emulation of some devices, booting from floppy, CD-ROM, HDD, USB stick, ZIP drive.

Then it has to handle USB Stack, Network cards, Video cards. And all of this can also have their own BIOS code insterted and executed at startup.




Intel chipsets (new ones) are somehow open. But the documentation is complicated to understand for a non technical person. However the chipset does not equal a motherboard

With NVidia you are out of luck

The way things are connected into amotherboard is only reported to the BIOS manufaturers by the motherboard manufacturers. This kind of information is not available for the public.

As a side note: to your topic, the ARM processor does not do any hardware setting up, it useally just dumps the first 4k of nand to ram and jumps to it.
Example of simplest bootloader for DexArm, but everything will need setting up, by the loader or OS, BIOS does no setting up at all.
So maybe you code get away from M$/linux, by coding for ARM, as its licensed, no one maker can control it.

It is not about the CPU here... The CPU is usually doing a very clear procedure at startup / restart. And usually we have full documentation about CPU's.

However the way electronics are layouted arround the CPU, the chipset and other devices is proprietary to the manufacturer.

You have one chance on mainstream PC's that are to be used under Windows or Linux because there is some information leaked about them and hardware manufacturers have to adhere to some sort of standards..

But on such embeded devices like the ones using an ARM CPU... you stand no chance. There is no need for a standardization. Each series of devices can have a completely diferent hardware layout. they might have some internal buss interoperability (like JTAG) but that is all. Each producer will make short series of devices that are proprietary and impossible to break or know inside.

Take for example a Nokia smart phone using ARM CPU... can you make an OS for that? what about the "other" 20 versiosn of the device? what about Somsung smartphones or Sony Ericson? ... your best cance is Java of maybe C++ or C .

And then a game gadget device using the same ARM CPU and then a CD-Burner using the same ARM CPU... The fact that it is an ARM and you know at what address it will start execution is of little use...

Without detailed hardware documentation you have no chance...

Being defeated in software areas...the protections will move into hardware areas. And there is no chance to break those hardware devices(if done properly).

For example there are devices that will self destruct only if you read the electrical signals on their busses

You should PRAY for hardware standardization in PC world because of Windows / Linux... many devices means no information.

Very interesting how these devices can recognize that, i.e. distinct it from normal work?

By the capacitance and inductance values that are locked during finnal testing pahase of the assembly ....

Even more some devices encrypt their buss communications all the time with public / private keys burned inside them

So unless you can break PGP in real time... you can not understand their buss data even if you read it

Some devices will detect your probe and will change operations slightly... so that you will be chasing the wrong data for a long time to come...

And there no noninvasive (without direct contact) method for "spying" chip activity (some kind of EEG [electroencephalogram] applied to the hardware)?

Well, what 'compiler' will you use in C to compile that for the Samsung smartphone? If it's Samsung's compiler then we can reverse engineer it

by the way I am not familiar in this area, so I probably said something stupid.