I need to make a mini OS(boot from floppy A) that can write/read floppy B.
The environment is vmware workstation. The floppies are A.img and B.img.
In A.img, I set a MBR program and a func.bin. I need to archieve above function in func.bin. Following is a code snippet in it.
... ; set es:bx
mov ah, 0x03 ; read sectors
mov al, 0x01 ; 1 sector
mov ch, 0x00 ; cylinder
mov cl, 0x03 ; sector
mov dh, 0x00 ; head
mov dl, 0x01 ; B.img
int 0x13
Then I got the return code: ah = 0x01. It means "illegal command" but I don't know what caused it.
I tried to change mov dl, 0x01 to mov dl, 0x00(A.img) or mov dl, 0x80(hard disk), they all succeed. So I want to know how I can solve it.
update my question:
The B.img has been set to "be auto-connected when vm runs".
size of A: 31.5KB
size of B: 1.44MB
The problem has been sovled by myself.
It caused by I don't know the config of VM.
By default, only one floppy drive is enabled in the virtual machine's BIOS. If you are adding a second floppy drive to the virtual machine, click inside the virtual machine window and press F2 as the virtual machine boots to enter the BIOS setup utility. On the main screen, choose Legacy Diskette B: and use the plus (+) and minus (-) keys on the numerical keypad to select the type of floppy drive you want to use. Then press F10 to save your changes and close the BIOS setup utility.
https://www.vmware.com/support/ws5/doc/ws_disk_add_floppy.html
Related
Is it possible to make 64bit Linux loader to limit the address space of the loaded 32bit program to some upper limit?
Or to set some holes in the address space that to not be allocated by the kernel?
I mean for specific executable, not globally for all processes, neither through kernel configuration. Some code or ELF executable flags are examples of appropriate solution.
The limit should be forced for all loaded shared libraries as well.
Clarification:
The problem I want to fix is that my code uses the numbers above 0xc0000000 as a handle values and I want to clearly distinct between handle values and memory addresses, even when the memory addresses are allocated and returned by some third party library function.
As long as the address space in 64bit Linux is very close to 4G limit, there is no enough addressing space left for the handle values.
On the other hand 3GB or even less is far enough for all my needs.
OK, I found the answer of this question elsewhere.
The solution is to change the "personality" of your program to PER_LINUX32_3GB, using the Linux system call sys_personality.
But there is a problem. After switching to PER_LINUX32_3GB Linux kernel will not allocate space in the upper 1GB, but the already allocated space, for example the application stack, remains there.
The solution is to "restart" your program through sys_execve system call.
Here is the code where I packed everything in one:
proc ___SwitchLinuxTo3GB
begin
cmp esp, $c0000000
jb .finish ; the system is native 32bit
; check the current personality.
mov eax, sys_personality
mov ebx, -1
int $80
; and exit if it is what intended
test eax, ADDR_LIMIT_3GB
jnz .finish ; everything is OK.
; set the needed personality
mov eax, sys_personality
mov ebx, PER_LINUX32_3GB
int $80
; and restart the process
mov eax, [esp+4] ; argument count
mov ebx, [esp+8] ; the filename of the executable.
lea ecx, [esp+8] ; the arguments list.
lea edx, [ecx+4*eax+4] ; the environment list.
mov eax, sys_execve
int $80
; if something gone wrong, it comes here and stops!
int3
.finish:
return
endp
As a learning experience, I'm writing a boot-loader for BIOS in NASM on 16-bit real mode in my x86 emulator, Qemu.
BIOS loads your boot-sector at address 0x7C00. NASM assumes you start at 0x0, so your labels are useless unless you do something like specify the origin with [org 0x7C00] (or presumably other techniques). But, when you load the 2nd stage boot-loader, its RAM origin is different, which complicates the hell out of using labels in that newly loaded code.
What's the recommended way to deal with this? It this linker territory? Should I be using segment registers instead of org?
Thanks in advance!
p.s. Here's the code that works right now:
[bits 16]
[org 0x7c00]
LOAD_ADDR: equ 0x9000 ; This is where I'm loading the 2nd stage in RAM.
start:
mov bp, 0x8000 ; set up the stack
mov sp, bp ; relatively out of the way
call disk_load ; load the new instructions
; at 0x9000
jmp LOAD_ADDR
%include "disk_load.asm"
times 510 - ($ - $$) db 0
dw 0xaa55 ;; end of bootsector
seg_two:
;; this is ridiculous. Better way?
mov cx, LOAD_ADDR + print_j - seg_two
jmp cx
jmp $
print_j:
mov ah, 0x0E
mov al, 'k'
int 0x10
jmp $
times 2048 db 0xf
You may be making this harder than it is (not that this is trivial by any means!)
Your labels work fine and will continue to work fine. Remember that, if you look under the hood at the machine code generated, your short jumps (everything after seg_two in what you've posted) are relative jumps. This means that the assembler doesn't actually need to compute the real address, it simply needs to calculate the offset from the current opcode. However, when you load your code into RAM at 0x9000, that is an entirely different story.
Personally, when writing precisely the kind of code that you are, I would separate the code. The boot sector stops at the dw 0xaa55 and the 2nd stage gets its own file with an ORG 0x9000 at the top.
When you compile these to object code you simply need to concatenate them together. Essentially, that's what you're doing now except that you are getting the assembler to do it for you.
Hope this makes sense. :)
I am trying to build a simple x86 Linux bootloader in nasm.
The Linux bzImage is stored on disk partition sda1 starting from the first sector.
I read the real mode code from the bzImage (15 sectors) into memory starting from 0x7E00.
However when i jump into the code it just hangs, nothing happens.
I have created code for the master boot record on sda. I's probably best if i just attach
the whole thing. I would like to know why it just hangs after the far jump instruction.
[BITS 16]
%define BOOTSEG 0x7C0
%define BOOTADDR (BOOTSEG * 0x10)
%define HDRSEG (BOOTSEG + 0x20)
%define HDRADDR (HDRSEG * 0x10)
%define KERNSEG (HDRSEG + 0x20)
[ORG BOOTADDR]
entry_section:
cli
jmp start
start:
; Clear segments
xor ax, ax
mov ds, ax
mov es, ax
mov gs, ax
mov fs, ax
mov ss, ax
mov sp, BOOTADDR ; Lots of room for it to grow down from here
; Read all 15 sectors of realmode code in the kernel
mov ah, 0x42
mov si, dap
mov dl, 0x80
int 0x13
jc bad
; Test magic number of kernel header
mov eax, dword [HDRADDR + 0x202]
cmp eax, 'HdrS'
jne bad
; Test jump instruction is there
mov al, byte [KERNSEG * 16]
cmp al, 0xEB
jne bad
xor ax, ax ; Kernel entry code will set ds = ax
xor bx, bx ; Will also set ss = dx
jmp dword KERNSEG:0
; Simple function to report an error and halt
bad:
mov al, "B"
call putc
jmp halt
; Param: char in al
putc:
mov ah, 0X0E
mov bh, 0x0F
xor bl, bl
int 0x10
ret
halt:
hlt
jmp halt
; Begin data section
dap: ; Disk address packet
db 0x10 ; Size of dap in bytes
db 0 ; Unused
dw 15 ; Number of sectors to read
dw 0 ; Offset where to place data
dw HDRSEG ; Segment where to place data
dd 0x3F ; Low order of start addres in sectors
dd 0 ; High order of start address in sectors
; End data section
times 446-($-$$) db 0 ; Padding to make the MBR 512 bytes
; Hardcoded partition entries
part_boot:
dw 0x0180, 0x0001, 0xFE83, 0x3c3f, 0x003F, 0x0000, 0xF3BE, 0x000E
part_sda2:
dw 0x0000, 0x3D01, 0xFE83, 0xFFFF, 0xF3FD, 0x000E, 0x5AF0, 0x01B3
part_sda3:
dw 0xFE00, 0xFFFF, 0xFE83, 0xFFFF, 0x4EED, 0x01C2, 0xb113, 0x001D
part_sda4:
dw 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000
dw 0xAA55 ; Magic number at relative address 510
mbrend: ; Relative address 512
Assuming your code is a boot loader (and therefore is not an MBR):
Never disable IRQs unless you have to. The BIOS needs them to function correctly, and will enable them inside some BIOS functions anyway (e.g. waiting for a "sectors transferred" IRQ inside disk functions). Because your code is only loading and passing control to more real mode code (e.g. and no switch to protected mode or anything is involved) you have no reason to disable IRQs anywhere in your entire boot loader.
For real mode addressing, it's typically cleaner/easier to use 0x0000:0x7C00 rather than 0x07C0:0x0000. You seem to be attempting to mix both (e.g. set segment registers for the former but define BOOTSEG and HDRSEG for the latter).
The partition table contains "extended partitions" and not "primary partitions" and your partition table is therefore wrong (and should probably be blank/empty).
The boot loader should not assume any specific/hard-coded "starting LBA" (the "starting LBA" for the partition depends on how the end user felt like partitioning their disk when the OS is installed). You need to determine the partition's "starting LBA" from the MBR's primary partition table, which is typically done by hoping that the MBR left DS:SI pointing to your partition's partition table entry.
You should not assume that your are booting from "BIOS device 0x80". The MBR should leave DL set to the correct device number, and there should be no reason why your code shouldn't work if (e.g.) the OS is installed on the second hard drive or something else.
Your hard-coded "starting LBA to read" (in the DAP) is wrong. For historical reasons there's probably 63 sectors per track and your partition starts on the 64th sector. This means that LBA sector 0x3F is the first sector in the partition (which is your boot loader) and is not the first sector of the kernel. I'm assuming the first sector of the kernel might be LBA sector 0x40 (the second sector of the partition).
The "number of sectors" shouldn't be hard-coded either. You'd want to load the beginning of the kernel and examine it, and determine how many sectors to load where from that.
Typically 512 bytes (actually more like 446 bytes) is far too little for a decent boot loader. The first 512 bytes of a boot loader should load the rest of the boot loader (with every spare byte left over used to improve error handling - e.g. puts("Read error while trying to load boot loader") rather than just putc('B')). Everything else (loading the pieces of the kernel, setting up a video mode, setting correct values in the "real mode kernel header" fields, etc) should be in the additional sectors and not be in the first sector.
Note that the way the computer boots has been carefully designed such that any MBR can chainload any OS on any partition of any disk; and the MBR may be part of something larger (e.g. a boot manager) that allows multiple OSs to be installed (e.g. where the user can use a pretty menu or something to choose which partition the MBR's code should chain-load). This design allows the user to replace the MBR (or boot manager) with anything else at any time without effecting any installed OS (or causing all of their installed OSs to need fixing). For a simple example, a user should be able to have 12 different partitions that all contain your boot loader and a separate/independent version of Linux, and then install any boot manager (e.g. GRUB, Plop, GAG, MasterBooter, etc) that they want at any time.
For why your code hangs, it's not very important given that all of the code needs to be rewritten anyway . If you're curious, I'd strongly recommend running it inside an emulator with a debugger (e.g. Bochs) so that you can examine exactly what has happened (e.g. dump memory at 0x00007E00 to see what it contains, single-step the JMP to see what is being executed, etc).
Comment does not match code!
xor bx, bx ; Will also set ss = dx
I seriously doubt if that is your problem...
Disclaimer: I have not done this! I'm "chicken" and have always done my bootin' from floppy.
What I "expect" to see in an MBR is for it to move itself out of the way, and then load the first sector on the active partition to 7C00h again, and then jump there. This "real bootloader" loads the rest. I'm not familiar with the layout of a bzImage - maybe it'll work loaded at 7E00h...
I think I'm in over my head. I'll get me coat...
I have grub v1.98 installed and after disassembling the MBR I find the following code snippet that I don't understand:
xor ax,ax
mov [si+0x4],ax
inc ax
mov [si-0x1],al
mov [si+0x2],ax
mov word [si],0x10
mov ebx,[0x7c5c]
mov [si+0x8],ebx
mov ebx,[0x7c60]
mov [si+0xc],ebx
mov word [si+0x6],0x7000
mov ah,0x42
int 0x13
It seems this piece of code tries to set up disk address of stage 1.5 code, then load and run it. However, how could I figure out which physical block it tries to read? What's more, what is the destination of the stage 1.5 code? 0x7000?
I refer to MBR for Windows 7, where subsequent boot up code is loaded 0x7c00. Given MBR is first loaded at address 0x7c00, it contains a piece of code copying MBR from 0x7c00 to 0x0600 and then branch to 0x0600 in case the original code corrupted. Will loading stage 1.5 code to address 0x7000 conflict the original code? What's more, I also find:
jmp short 0x65
nop
sar byte [si+0x7c00],1
mov es,ax
mov ds,ax
mov si,0x7c00
mov di,0x600
mov cx,0x200
cld
rep movsb
push ax
push word 0x61c
retf
at the beginning of the MBR. It seems the code tries to do the same thing as in MBR of windows 7 to copy the original MBR from 0x7c00 to 0x0600, except for the first jmp instruction. Will these codes in fact executed? If yes, when will control jumps here.(I believe the answer is YES, but am confused by the leading jmp).
GRUB 1.98 is GRUB version 2. In version 2, there is no stage 1.5 anymore.
The stage 1.5 had a fixed place between MBR and first partition. It was (most often) unused space on the hard drive. GPT partitioning and other (unusual) layouts do not provide this space.
In GRUB v2 stage 1 loads core.img, which can be stored at any LBA48 location, typically between MBR and first partition, but it can also be stored within a partition. In the non-EFI case of GPT, a custom partition should be created for it. The location is hardwired into stage 1.
See also: http://www.gnu.org/software/grub/manual/grub.html#Images
Is it possible to shut down or kill the power (is there a difference?) to a computer from nasm. I know you can use this to reboot:
mov al, 0xFE
out 0x64, al
Is there an equivalent for shutting down?
I am making my own 16 bit OS.
The code you have is not guaranteed to work. It relies on two facts:
the OS maps the physical IO memory into the process memory space.
the machine has BIOS.
Neither of the two might be true.
The only reliable way to reboot or shutdown the machine programatically is to call the corresponding OS API.
An alternative to calling the OS API (which you need, since you are writing the OS :-)) is using ACPI. Not all machines support ACPI an of these that do, there's at four different ACPI revisions.
http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface?wasRedirected=true
http://www.acpi.info
mov ax, 0x1000
mov ax, ss
mov sp, 0xf000
mov ax, 0x5307
mov bx, 0x0001
mov cx, 0x0003
int 0x15
you can try this code:-
shutdown_sucess:
mov ax, 5301h ; Connect to the APM
xor bx, bx
int 15h
je near continue_connection ; Pass if connected
cmp ah, 2
je near continue_connection ; Pass if already connected
ret ; Bail if fail
continue_connection:
mov ax, 530Eh ; Check APM Version
xor bx, bx
mov cx, 0102h ; v1.2 Required
int 15h
ret