OSDev.org

mariuszp wrote:According to the x86 memory map, that address should be free for use. Exactly what interrupts are you getting?

Did you enable the A20 line?

Have you checked (e.g. with the Bochs debugger) if ImageSize was loaded correctly? Do registers have the expected values just before rep movsd?

Side note: There is a simpler (and faster) way to divide by 4. Instead of:

Code: Select all

      mov           eax, dword [ImageSize]
      mov         ebx, 4
      div           ebx

You could have just written:

Code: Select all

CopyKernelImage:
    mov ecx, [ImageSize]
    shr ecx, 2                     ; divide by 2^2 (=4)
    cld
    mov esi, 0x7e00
    mov edi, 0x100000
    rep movsd

RezaNoei wrote:i'm not using of bochs

RezaNoei wrote:but i believe that the kernel has loaded correctly

RezaNoei wrote:about registers i have written some value directly to check that, and it doesn't work as explained before.

RezaNoei wrote:So, I have been decided to load the kernel at 0x100000 but CopyKernelImage Doesn't work Correctly like an infinite loop :

Code: Select all

CopyKernelImage:
  	 mov	        eax, dword [ImageSize]
  	 mov         ebx, 4
  	 div           ebx
   	 cld
   	 mov         esi, 0x7e00
   	 mov	        edi, 0x100000
   	 mov	        ecx, eax
   	 rep	 movsd   

please help me to find the problem

CopyKernelImage:
  	 mov ecx, dword [ImageSize]
   	 cld
   	 mov esi, 0x7e00
   	 mov	edi, 0x100000
   	 rep movsb

embryo2 wrote:

RezaNoei wrote:i'm not using of bochs

It's very bad practice. You aren't see what you're doing, like a blind man.

RezaNoei wrote:but i believe that the kernel has loaded correctly

Any belief is bad when you are going to program something useful. Only the facts that you can see can be your ground. Until you can't see the actual register values your belief just deceives you.

RezaNoei wrote:about registers i have written some value directly to check that, and it doesn't work as explained before.

It means you have made an error and now just can't find it. Yes, it's a normal practice, but how are you going to fight it? With your beliefs only? Most probably you'll be hunting the error(s) much longer than it takes to install Bochs and to get used to it.

neon wrote:Hello,

We are a little uncertain about the provided code given the reference to the series. The series boot loader and kernel define imageSize and kernelSize as the number of sectors rather than the number of bytes. The presented CopyKernelImage as well as what you expected appear to be inconsistent with the series. Please compare your presented code with the series stage2.asm and main.c (Specifically CopyImage and how we call pmm_initialize.)

If this is a custom boot loader, please let us know. If it is only modified, please try the original version. However we suspect it is an incorrectly modified version of the boot loader resulting in an error during loading.

neon wrote:Hello,

It appears the problem has been resolved then. I would not recommend avoiding something due to a problem that can not be resolved; it is better to overcome the problems and support it if necessitated by your system requirements. With that said however, we do typically use fat32 hard disk volumes in our system and provide support for those that want to deviate from the legacy fat12 media. We also provide copies of our boot records if needed for these file systems.

As noted above, the boot loader you presented has a number of problems that should be addressed later on, most notably that it does not support loading large files (which requires swapping between real and protected/long modes.) I encourage looking into expanding the software later on since the boot loader can easily be itself a large project. Since your boot loader appears to be somewhat based off the one in the series, it should be noted that it will be unable to load images that exceed 65k without, eventually, corruption, do to readSectors not supporting loading across segment boundaries. We can provide our updated version if requested, but you will still be limited by the real mode address space.

Finally, I highly recommend learning the Bochs debugger. It is your only means of debugging (next to displaying contents on screen, dumping data to serial port and redirecting it to file, and trial and error) until you are able to port or write a kernel symbolic debugger. Besides, you will need to be able to run and test your software in a lot of different environments; just because it runs in one emulator does not guarantee (and often it won't) work in another. The only way to catch these types of bugs is by running the software in a lot of different architecture environments; either real or emulated.

BASICFreak wrote:Well a page fault is int 0x0E and if you did not remap the PIC, a floppy INT is also int 0x0E (highly unlikely)

Other than that, what does your memset look like?
Are you sure it is a #PF?
Have you enabled paging?
Have you mapped the page? Present and writable?

If it overlaps your int handlers it shouldn't cause a #PF unless the page is marked RO. (not saying it should be allowed to overlap it...)





As suggested before learn to (fully / properly) use Bochs or maybe QEMU - it really helps in debugging.
I know Bochs allows one to transverse the TLB (I do not use QEMU so I cannot speak for it).