Exact startup sequence and difference between jumpboot.s andmasterboot.s - Minix

This is a discussion on Exact startup sequence and difference between jumpboot.s andmasterboot.s - Minix ; Hello, What is the difference between the files masterboot.s, jumpboot.s, doshead.s, boothead.s, bootblock.s? I understood when the computer first starts up, it checks address 0x7C00 of a diskette or the active partition on the hard disk. So bootblock.s gets executed ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Exact startup sequence and difference between jumpboot.s andmasterboot.s

  1. Exact startup sequence and difference between jumpboot.s andmasterboot.s

    Hello,

    What is the difference between the files masterboot.s, jumpboot.s,
    doshead.s, boothead.s, bootblock.s?
    I understood when the computer first starts up, it checks address
    0x7C00 of a diskette or the active partition on the hard disk. So
    bootblock.s gets executed at this time. The order of disks can be
    checked and set in the BIOS of the computer.
    What are the other files in the boot directory for? For example,
    jumpboot.s? If bootblock.s gets executed, why bother with other files
    like jumpboot.s? And what's the difference between doshead.s and
    boothead.s? One seems to run under MS-DOS, but i don't understand
    this, isn't MINIX supposed to be an operating system by itself, not
    run under any other OS?

    I understood boot.c is the boot manager, the program that gets
    executed before even the operating system itself is started. But what
    is installboot for? It changes an address reference in a file, but
    what for? In what file?

    Can anybody explain me the difference between the files and tell me
    the exact startup sequence, which code file runs when? I'm a little
    confused right now. Thanks very much.

    Steven

  2. Re: Exact startup sequence and difference between jumpboot.s and masterboot.s

    StevenR escreveu:

    > What is the difference between the files masterboot.s, jumpboot.s,
    > doshead.s, boothead.s, bootblock.s?
    > I understood when the computer first starts up, it checks address
    > 0x7C00 of a diskette or the active partition on the hard disk.


    No. As far as the BIOS is concerned, it goes through the bootable
    candidates (physical devices only) and for each of them:
    - Enterely loads sector 0 to 0x7C00;
    - Checks if last two bytes of read sector are 0x55
    and 0xAA (in this order):
    - If not, skips to next candidate;
    - If yes, jumps to start of read sector.

    El Torito CD-ROM booting differs completely from this process.

    > So bootblock.s gets executed at this time.


    I don't think so.
    Or better: if booting from an hard disk, BIOS loads and executes
    masterboot.s, which chainloads the boot partition (i.e. determines the
    active partition and mimics the aforemention 0x7C00 boot protocol, but this
    time pretending the partition was a physical disk). This gets bootblock.s
    loaded into 0x7C00 and executed from there.
    Then, bootblock.s reads the more complex boot loader (which I believe is
    the "boot monitor") by loading it's sectors from some hardcoded sector
    numbers.

    The boot monitor then does the rest.

    > What are the other files in the boot directory for? For example,
    > jumpboot.s?


    Don't know. Have to check.
    These kind of source files are usually a bit hard to read, and requires
    having an RBIL (Ralph Brown's Interrupt List) window somewhere nearby.
    Aditionally, they are generally of little importance the the rest of the
    system as the environment in which they run is mostly temporary and is
    rapidly replaced by the kernel's more complex environment.

    > If bootblock.s gets executed, why bother with other files
    > like jumpboot.s?


    Like I mentioned, some devices don't follow this old BIOS boot protocol.
    It's possible that some of the files are used to support recent media like
    CD-ROMs and so.
    Furthermore, if you want to load the boot monitor from the Minix FS, you
    need a boot code (the one which lays in the active partition) that is able
    to read MFS. If you want to load the boot monitor from a FAT filesystem,
    you need a boot code that is able to read from FAT, and so on.

    > And what's the difference between doshead.s and
    > boothead.s? One seems to run under MS-DOS, but i don't understand
    > this, isn't MINIX supposed to be an operating system by itself, not
    > run under any other OS?


    Operating systems that *load from* DOS don't generally *run under* DOS. I
    mean, being loaded from DOS doesn't imply using DOS system calls during
    normal operation. As I wrote before:
    > Aditionally, they are generally of little importance the the
    > rest of the system as the environment in which they run is
    > mostly temporary and is rapidly replaced by the kernel's more
    > complex environment.

    Minix running under DOS is a nonevent [1]. What really happens is that the
    monitor is aware that it must take care to not damage the memory areas that
    are being used by DOS and the kernel someshat can be made aware of this
    too. And if fact I think the monitor can return to DOS. I've not
    investigated far enough, though.
    However, the kernel won't use the DOS environment while running. It's only
    able to put the system back in a state for the monitor to take control,
    which in turn is able to put the system back in a state from which it's
    possible to return to the DOS kernel.

    And nothing prevents you from running an operating system under another
    operating system. This won't be however an OS in the "classical" sense,
    though, because it won't be managing the hardware resouces, but rather the
    resources exposed by the system (which are un turn unlikely to need even
    more "management"). For example, I've read that Unununium[2] is able to run
    from inside Linux.

    > I understood boot.c is the boot manager,


    Is it? I didn't know.
    Is I have said, I've not investigated the low level aspects of Minix
    booting. My own experience tells me that studying that is the first step to
    get bored with any OS. :-)
    I find the boot monitor an interesting idea, and I think I'll implement
    something alike in an OS I'm working on.

    > the program that gets
    > executed before even the operating system itself is started. But what
    > is installboot for? It changes an address reference in a file, but
    > what for? In what file?


    My understanding is that one of the tasks that installboot accomplishes is
    installing bootblock.s in the specified MFS partition and then patch the
    24-bit addresses to point the the disk sectors where the boot monitor lays.

    > Can anybody explain me the difference between the files and tell me
    > the exact startup sequence, which code file runs when? I'm a little
    > confused right now. Thanks very much.


    The exact startup sequence is most likely dependant from the device you are
    booting from.
    However, the common point is that the boot monitor eventually gets executed
    from some compile-time known memory address. Then it boots the kernel and
    loads the startup apps alongside.



    [1] From:http://preview.tinyurl.com/5lp6c9 :
    1. MINIX UNDER DOS
    Installation of MINIX to run under DOS is a nonevent. Chances
    are, you are reading this manual page from an already running
    MINIX system, but if not then the setup goes like this(...)
    [2] http://unununium.org/ - It's dead by now.

    --
    João Jerónimo

    "Computer are composed of software, hardware, and other stuff terminated
    in "ware", like firmware, tupperware, (...)" - by JJ.

  3. Re: Exact startup sequence and difference between jumpboot.s and masterboot.s

    En news:g8ua21$6pt$1@aioe.org, João Jerónimo va escriure:
    > StevenR escreveu:
    >
    >> What is the difference between the files masterboot.s, jumpboot.s,
    >> doshead.s, boothead.s, bootblock.s?


    I guess you are interested in the function of the various binary files
    instead (i.e. masterboot, not masterboot.s)

    masterboot: intended to go in sector 0 of a hard drive, will act as the
    standard IBM code; embeeds a partition table at the end of the sector, in
    bytes 446-509
    jumpboot: same destination and format, but does not pay attention to the
    active partition flag, instead goes to the parameterized one (can be
    overriden if Alt is pressed)

    Both can be installed (and one usually is) in the first sector of a Minix
    (type=0x81) partition too, to provide the sub-partitionning scheme; this
    also have been done on floppies, to provide sub-partionning there too
    (mostly to avoid "wasting" a whole valuable 1.4M floppy just for the small
    250 KB ramdisk used on 8088-PCs). Other than that use, they are not specific
    to Minix in any way; and reversedly you can use any program with similar
    capabilities to {,dual-,multi-}boot Minix.


    bootblock: stored in the first sector of a Minix filesystem, load at
    1000:0000 the /boot program whose sectors addresses are stored within the
    sector (i.e. does not search the filesystem)

    boothead: starts (i.e., similar to crtso) the boot program, and provides the
    low-level support (i.e., similar to klib386); started from the bootblock
    "primary bootstrap" above
    doshead: starts and provides the low-level support for the boot program, but
    work from Microsoft's MS-DOS instead

    Both are intended to be linked with the boot.c program


    And finally there is/was
    bootblok (without c to stick with 8 letters): was prepended to the Minix
    "image" (the kernel with the drivers, mm and fs servers, and the init
    program); embeeded a few key parameters (sizes) at bytes 504-509; started
    Minix when used as first sector of a floppy (with the image stored in the
    following sectors, i.e. there were no filesystem on those "boot" floppies);
    this is the original way Minix 1.x was bootstrapped


    >> I understood when the computer first starts up, it checks address
    >> 0x7C00 of a diskette or the active partition on the hard disk.

    >
    > No. As far as the BIOS is concerned, it goes through the bootable
    > candidates (physical devices only) and for each of them:
    > - Enterely loads sector 0 to 0x7C00;
    > - Checks if last two bytes of read sector are 0x55
    > and 0xAA (in this order):


    Real clone BIOS does not do that for floppies; this is not an escape to
    avoid putting them there, since some more recent breed of the booting tools
    (for example, VMWare or earlier versions of Grub) insist for these bytes to
    be present, even when loaded from a device numbered below 0x80 (a "floppy"
    by the definitions of IPL services)

    > - If not, skips to next candidate;


    Really, invokes INT18 which by default do that

    > - If yes, jumps to start of read sector.


    Normally at address 0000:7C00 (although 07C0:0000 was also seen years ago)


    > El Torito CD-ROM booting differs completely from this process.


    There are two cases here.
    One is El Torito in emulation mode: it just loads the image in memory, and
    handles it as a ram drive, i.e. boots like a floppy (or a harddrive, but
    BIOS are often buggy here) except that the sectors comes from the ram image

    The other is the no-emulation mode, and it is not really different from the
    above: it is loaded (usually at 0000:7C00) by the BIOS with the count of
    2048-byte sectors specified (so it is bigger than the above case, which
    allows it to avoid the primary+secondary mechanism which otherwise plags the
    process), then control is transferred to the loaded code, like above


    Quite different are the BEV devices, like the bootable network cards: they
    bypass the IPL process described above, and for example download the /boot
    program from some other computer using TFTP, then they branch to it; they
    can also do something ceompletely different, like running DonkeyKong
    (actually the first intended use of this mechanism.)


    >> If bootblock.s gets executed, why bother with other files
    >> like jumpboot.s?


    On one side, with the partitionning scheme of the IBM PC, while on a floppy
    you can start with bootblock.s, on a hard disk you need either masterboot or
    jumpboot or equivalent to actually load the first sector (bootblock) of the
    active partition.

    boothead/doshead on the other side are not small bootstraps, they are much
    bigger and carry the needed baggage to provide boot with all the necessary
    low-level stuff, including starting the C code (something usually done by
    the code in crtso.s)


    > Furthermore, if you want to load the boot monitor from the Minix FS,
    > you need a boot code (the one which lays in the active partition)
    > that is able to read MFS.


    That code is burried inside boot.c

    > If you want to load the boot monitor from a FAT filesystem, you need
    > a boot code that is able to read from FAT, and so on.


    Here boot.com relies directly on DOS to provide the service (and doshead.s
    provide the assembler interface between the C code and the interrupt-based
    MS-DOS API using INT 21)


    > Minix running under DOS is a nonevent [1]. What really happens is
    > that the monitor is aware that it must take care to not damage the
    > memory areas that are being used by DOS


    Yes

    > and the kernel someshat can be made aware of this too.


    This is very limited: kernel (and then MM) is passed by the boot monitor a
    memory map showing the available memory; under dosboot.com this memory map
    does not show the DOS allocated area as free, that's all.

    > And if fact I think the monitor can return to DOS.


    Yes it can.

    > However, the kernel won't use the DOS environment while running.


    It sort-of can, using the dosfile device.


    > And nothing prevents you from running an operating system under
    > another operating system.


    Well, usually you cannot, and DOS is really a special case here.
    "Normal" operating systems (on 286+) insist to have all control to all
    aspects of the hardware, and it includes being the king of the hill, and the
    only one able to run at CPL0, for instance. Of course, this precludes any
    other OS to do so, unless there is some special agreement (like
    virtualization or hypervisor, or user-mode OS like coLinux).


    >> I understood boot.c is the boot manager,


    It is named the boot monitor; but you are right it is very much like Sun's
    monitor (to which it is modelled), "loader", NtLdr, Grub, or the very recent
    BootMgr, as its main purpose is to load and boot some OS (which would be
    SunOS, FreeBSD, WinNT, Linux or a MultiBoot-compatible kernel, or Vista
    respectively), and also provides some intereaction with the environement,
    some editing capabilities, and the possiblity to "chain-load" a wholly
    different operating system.


    > I find the boot monitor an interesting idea, and I think I'll
    > implement something alike in an OS I'm working on.


    Since that have been done a number of times already, you probably can reuse
    any of the standing proposals as booting support, and concentrate yourself
    on the main task of the OS. In fact the very prupose of the Grub project was
    (initially) to provide this service, a standard framework for starting the
    OS!


    >> But what is installboot for?


    RTFM. But basically, installboot has five options and consequently five main
    uses:
    - create a Minix image (-image/-i option, inherited from the earlier "build"
    tool it replaced and really few relationship with all the stuff we are
    talking about);
    - extract the components from a Minix image (-extract/-x);
    - writes bootblock on some device and patches it with the adresses for /boot
    (-device/-d);
    - writes a MBR code (-master/-m), with options to deal with jumpboot extra
    features;
    - creates a bootable Minix floppy (-boot/-b);


    Antoine


+ Reply to Thread