booting from a usb device - Minix

This is a discussion on booting from a usb device - Minix ; hi the minix book doesnt talk about how booting from a usb device is done..does anyone know anything about this? i tried copying the minix usb image to my usb stick but it wouldnt work (as i expected)..i also tried ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: booting from a usb device

  1. booting from a usb device

    hi
    the minix book doesnt talk about how booting from a usb device is
    done..does anyone know anything about this?
    i tried copying the minix usb image to my usb stick but it wouldnt work
    (as i expected)..i also tried copying the data in it directly unto my
    usb stick with a hex editor but that wouldnt work either
    i think its pretty hard to follow many of the things in the book when
    you don't really know how some very basic things are done...does anyone
    know of some kind of a tutorial that teaches how to bootstrap the pc,
    switch from real mode to protected mode and then display some simple
    message..besides, what's all this fuss about real and protected mode,
    what a difference does it make from a hardware point of view?

    thanx,

    martin


  2. Re: booting from a usb device

    hi
    > the minix book doesnt talk about how booting from a usb device is
    > done..does anyone know anything about this?

    It should work if you simply raw-copy a bootable minix floppy onto your
    stick (it should show up as an USB floppy). Drawback is that afterwards the
    stick only has 1,44 Mb. You could also create an USB hard disk, but I'm not
    sure how it's done.

    The bigger problem is that after switching to protected mode, the BIOS is
    not accessible anymore. That means the emulation of a floppy or hard disk
    done by the BIOS fades away, so unless your operating system [minix] is
    ready for taking over, no access to your boot drive is possible.

    > i tried copying the minix usb image to my usb stick but it wouldnt work
    > (as i expected)..i also tried copying the data in it directly unto my
    > usb stick with a hex editor but that wouldnt work either


    I don't know precisely when Minix switches to protected mode. I believe that
    you should come up to the monitor where you can type "boot c0d0p0" or
    something similar. Don't have my laptop here, though...

    > i think its pretty hard to follow many of the things in the book when
    > you don't really know how some very basic things are done...does anyone
    > know of some kind of a tutorial that teaches how to bootstrap the pc,
    > switch from real mode to protected mode and then display some simple
    > message..


    Try a simple google search.
    I can recommend "Das PC Hardwarebuch" (The PC hardware book), but I don't
    know its name in english. The best way to learn about these basic principles
    would be to buy a hardware book where this is descripted.

    http://my.execpc.com/~geezer/os/pm.htm
    http://www.x86.org/articles/pmbasics/
    http://lowlevel.brainsware.org/index...name=tutorials (only german,
    sorry).

    I don't know anything else without searching myself.

    > besides, what's all this fuss about real and protected mode,
    > what a difference does it make from a hardware point of view?


    The real mode was the mode in which the first x86-processor ran.
    It was designed as much as possible to the architecture, which means no
    memory protection, no multitasking but segmentation (every 16th byte in
    memory can be accessed as a segment, between there an offset is used - every
    segment has a maximum of 64 Kb). This is, of course, bad for "real"
    operating systems like Minix, Linux, OS/2 or Windows NT. So the Intel
    designers did a major design change without breaking compatibility - the
    protected mode.

    Problem is, that the BIOS for compatibility reasons (i86-software) only
    operates in real mode (which DOS or CP/M uses) and after switching to
    protected mode, you have to address the hardware by yourself and directly.
    No nice BIOS functions/interrupts anymore. Only your own drivers work here.
    BUT: You are able to do multitasking, different protection mechanisms, you
    can (if you want) address the memory linear (up to 4 Gb on 386+, 16 Mb on
    i286) and anything else you want.

    That is, in very short, the problem.
    From the point of hardware, both modes are the same; the hardware may be
    accessed the same way.

    The AMD64-architecture did the same many years later and created a new mode
    the processor can be run in, the so-called Long Mode. You have to switch
    from real mode to protected mode and are later able to switch further to
    long mode. There you have the complete 64 bit anything, but for example no
    hardware tasking (which, under Protected Mode, works).

    Hope this helps at least a little.

    Regards



  3. Re: booting from a usb device


    sancho1980 wrote:

    > i tried copying the minix usb image to my usb stick but it wouldnt work
    > (as i expected)..i also tried copying the data in it directly unto my
    > usb stick with a hex editor but that wouldnt work either


    I think you need to check whether your BIOS has support for it or not
    first.

    > i think its pretty hard to follow many of the things in the book when
    > you don't really know how some very basic things are done...does anyone
    > know of some kind of a tutorial that teaches how to bootstrap the pc,
    > switch from real mode to protected mode and then display some simple
    > message..besides, what's all this fuss about real and protected mode,
    > what a difference does it make from a hardware point of view?


    see kernel/protect.c

    It is all about segmentation to protect processes from touching each
    other.

    I hope it helps


    tmK


  4. Re: booting from a usb device

    > hi
    > > the minix book doesnt talk about how booting from a usb device is
    > > done..does anyone know anything about this?

    > It should work if you simply raw-copy a bootable minix floppy onto your
    > stick (it should show up as an USB floppy). Drawback is that afterwards the
    > stick only has 1,44 Mb. You could also create an USB hard disk, but I'm not
    > sure how it's done.


    I was talking about the image for download on the minix website:

    http://www.minix3.org/download/usb_image-3.1.2a.zip

    how do i have to copy that unto my usb device?
    simply copying the file doesnt do the trick; opening the file w/ hex
    editor and pasting the content of it unto my usb device at address 0
    doesnt work either!


  5. Re: booting from a usb device

    Hello

    > > > the minix book doesnt talk about how booting from a usb device is
    > > > done..does anyone know anything about this?

    > > It should work if you simply raw-copy a bootable minix floppy onto your
    > > stick (it should show up as an USB floppy). Drawback is that afterwards

    the
    > > stick only has 1,44 Mb. You could also create an USB hard disk, but I'm

    not
    > > sure how it's done.

    >
    > I was talking about the image for download on the minix website:
    >
    > http://www.minix3.org/download/usb_image-3.1.2a.zip
    >
    > how do i have to copy that unto my usb device?
    > simply copying the file doesnt do the trick; opening the file w/ hex
    > editor and pasting the content of it unto my usb device at address 0
    > doesnt work either!


    I cannot download the file, because it is quite large and would take some
    hours to load... so I don't know what there is inside.
    After reading the web site however, I believe there is an image file inside
    which should be copied raw onto the device.

    In Linux there is a very good program "dd" which does the trick, but it is
    also available for win32:
    http://www.chrysocome.net/downloads/dd-0.3.zip

    You have to find out your usb device (something like /dev/sda for Linux or
    \\.\G: for Win32).

    This helps for win32:
    dd if=imagefile.img of=\\.\g: bs=1024 --progress

    This for linux (no progress indicator):
    dd if=imagefile.img of=/dev/sda bs=1024

    Of course, your BIOS needs support for booting from USB. Some older BIOS
    don't support this, or only via floppy-emulation or whatever. You need to
    check there. Try to switch off the computer, put the stick in, switch on the
    computer and go straight into the setup (Del, Ctrl+Alt+Esc, F10, whatever)
    and look there for boot sequence or something similar.
    If your BIOS supports a Boot Menu (mine does Netboot with F8 and Boot Menu
    via F11) you can check there if your device is listed. If it isn't, you have
    either written the image somehow wrongly onto the stick or your BIOS doesn't
    support booting via USB-HDD (which, in my belief, is the way the image
    should be booted).

    Hope this helps/works for you.

    Regards



  6. Re: booting from a usb device

    > Hope this helps/works for you.
    >
    > Regards


    Sorry, but it doesn't work :-(
    And yes my BIOS supports booting from usb


  7. Re: booting from a usb device

    > > Hope this helps/works for you.
    > >
    > > Regards

    >
    > Sorry, but it doesn't work :-(
    > And yes my BIOS supports booting from usb


    Does it also support booting from USB HDD as well as USB FDD?
    You could try another stick, sometimes it works, sometimes it doesn't. Some
    BIOS versions do not boot from some sticks, while other sticks work fine.

    I cannot help any further, sorry.

    Regards



  8. Re: booting from a usb device

    > what's all this fuss about real and protected mode,
    > what a difference does it make from a hardware point of view?


    Martin,

    I assume you have some understanding of typical microprocessor
    architectures.

    Early designs of the Intel processors (8086 and 80186) looked more like
    a microcontroller than a CPU. They had an 8bit data and address bus and
    the interrupt handling mechanism was very na´ve. There were no
    multitasking facilities and the memory could not be page'd. However
    they looked great at that time.
    You may probably be wondering why this ancient stuff is seen everywhere
    when you look through books and papers on bootstrapping or implementing
    an OS. The answer is `backward compatibility'. Modern Intel design
    (compatible) CPUs still boot up in real mode to keep the older OSes or
    softwares running and so obeys this guideline the BIOS software.
    When a PC is powered on, BIOS which is located on a ROM chip on the
    motherboard gets running, setting up some devices, setting some initial
    values for some memory locations, loading the boot sector of the boot
    device into a specific memory location (0x07C0) and jumping to it. All
    this is called Bootstrapping which is done in real mode. After the
    initial OS code has run it may change the operating mode to protected
    mode (as Linux or Windows do) or leave it be (as DOS).

    There is a great and explanatory paper about the protected mode issue:
    http://www.intel.com/design/intarch/papers/exc_ia.pdf
    Check that out. It gives you an idea of what is protected mode.

    I Hope that helped.

    Good luck,
    Bahman


  9. Re: booting from a usb device

    > There is a great and explanatory paper about the protected mode issue:
    > http://www.intel.com/design/intarch/papers/exc_ia.pdf
    > Check that out. It gives you an idea of what is protected mode.
    >
    > I Hope that helped.
    >
    > Good luck,
    > Bahman


    Thanks for the link; but I'm still not able to grasp how the system
    makes sure that segments are only accessed by processes that have the
    appropriate privilege level..
    this text in particular talks about 3 different types:

    cpl: current privilege level ist the least 2 bits of the cs register
    spl: descriptor privilege level is the 2 bit field in a descriptor
    rpl: requestor's privilege level is the least 2 bits of a selector
    value

    ...wait! whats that difference between cpl and rpl? the requestor is the
    code making the access request to the segment..so it IS the code being
    currently executed; so whats that difference?

    also, if the system checks the cs register for a sufficiently
    privileged level to access the segment, how is made sure that the user
    code not simply modify the cs register in a way that it "pretends" to
    have a higher privilege?

    thanx

    martin


  10. Re: booting from a usb device

    sancho1980 wrote:
    > hi
    > the minix book doesnt talk about how booting from a usb device is
    > done..does anyone know anything about this?
    > i tried copying the minix usb image to my usb stick but it wouldnt work
    > (as i expected)..i also tried copying the data in it directly unto my
    > usb stick with a hex editor but that wouldnt work either
    > i think its pretty hard to follow many of the things in the book when
    > you don't really know how some very basic things are done...does anyone
    > know of some kind of a tutorial that teaches how to bootstrap the pc,
    > switch from real mode to protected mode and then display some simple
    > message..besides, what's all this fuss about real and protected mode,
    > what a difference does it make from a hardware point of view?
    >
    > thanx,
    >
    > martin
    >


    Fuss about modes: Go get yourself a 386 assembly book. The differences
    between real-mode and protected mode are so different, that they change
    how the CPU itself works.

    USB key: Make sure that:
    a) You image the USB image directly to a USB key. I suggest a 512MB
    key. Don't put it as a file on the key. BIOS manufacturers read the
    devices raw, and don't have the space in the 256KB EEPROMs to include a
    mechanism to read a FAT16 volume, and to search through *every* single
    file on the volume looking for a bootable image.
    b) That the USB key is plugged in when the BIOS initializes USB.
    Otherwise it won't be detected (the BIOS, again, cannot detect the
    removal and insertion of devices, such code is not crucial for USB
    booting and only wastes space when 256KB is a hard limit)
    c) Since most BIOSes register USB devices as hard disks (in their own
    terms and categorization), you will probably need to push "ESC" to bring
    up the boot menu. USB devices will show up under hard disks, but with ID
    numbers that differentiate them from hard disks, for example, my BIOS
    boot menu looks like this:

    > Floppy disks

    0: 3.5" Floppy disk drive
    > Hard disks

    0: SEAGATE ST380012A
    1: WDC WD400EB-00CPF0
    USB-HDD0: Generic USB SD/MMC card reader
    > CD-ROM drives

    0: HL-DT-ST RW/DVD GCC-4481B
    1: HL-DT-ST GCE-8526B

    (Note that the SD card slot on my USB multi-card reader appears as a
    bootable target here)

    USB drives, although counted and treated as hard drives by the BIOS, are
    boted *after* IDE drives. It is important that you make sure that you
    use the BIOS menu, usualyl be pushing 'ESC'.

    d) Your BIOS is new enough to support booting USB. This is a no-brainer.

    Remember to copy the USB image directly to the USB key. It seems you
    were using Hex Workshop to copy it, and well, it's best to just boot
    Linux and copy it, because Linux just provides easier access to disks in
    a raw manner.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFFMraxsjeOFtd+nycRAoc5AJoCg8L0feDOwZCkG5pMVw bNbGP0KQCfax+P
    xVqb9p/M7Fr8LcD7IO/liSs=
    =3GKj
    -----END PGP SIGNATURE-----


  11. Re: booting from a usb device

    > I'm still not able to grasp how the system makes sure that segments are only accessed by
    > processes that have the appropriate privilege level..
    > this text in particular talks about 3 different types:
    >
    > cpl: current privilege level ist the least 2 bits of the cs register
    > spl: descriptor privilege level is the 2 bit field in a descriptor
    > rpl: requestor's privilege level is the least 2 bits of a selector
    > value


    You may only access a segment in an i386+ if and only if the DPL of the
    target segment is bigger than or equal to MAX{CPL, RPL}. This assures
    that no one is able to access a higher privilieged segment. Bear in
    mind that HIGHER privilege number means LESSER privilege.

    > ..wait! whats that difference between cpl and rpl? the requestor is the
    > code making the access request to the segment..so it IS the code being
    > currently executed; so whats that difference?


    CPL is stored in an internal register and it IS the privilege level of
    the currently executing code. RPL is a field that you, as the
    programmer fill it. Suppose that you are writing a system library in
    which you, as the library's core code!, have to access some parts of
    memory which programmers who use your library should not. In this case
    the simplest way is to build two different selector (actually same
    selectors with different RPLs), one for the core and one for the users.
    By selecting two different privilege levels, this is where RPL takes
    part.

    > also, if the system checks the cs register for a sufficiently
    > privileged level to access the segment, how is made sure that the user
    > code not simply modify the cs register in a way that it "pretends" to
    > have a higher privilege?


    Absolutely Impossible! If CS is changed, CPU will fetch the instruction
    at NEW_CS:IP the next time it tries to execute an instruction and
    simply it will not be yours.

    Regards,
    Bahman


  12. Re: booting from a usb device


    what's all this fuss about real and protected mode,
    > what a difference does it make from a hardware point of view?


    Ooops! I gave wrong info.

    You may want to look at boot.c , which is NOT on appendix. You may have
    to look at the source tree.


  13. Re: booting from a usb device

    what's all this fuss about real and protected mode,

    > what a difference does it make from a hardware point of view?


    Ooops! I gave wrong info.

    You may want to look at boot.c , which is NOT on appendix. You may have
    to look at the source tree. what's all this fuss about real and
    protected mode,

    > what a difference does it make from a hardware point of view?


    Ooops! I gave wrong info.

    You may want to look at boothead.s , which is NOT on appendix. You may
    have
    to look at the source tree.


+ Reply to Thread