problems with bootloader

[RetainSoftware]

Hi All,

Maybe you guys can shed a light on this because now i'm at a complete loss. The following code runs perfectly under bochs and qemu but doesn't run on real hardware. Hope you can find it because i've tried all day without success.

to build binary (gcc)
- as -o pm2rm pm2rm.s
- objcopy -O binary pm2rm pm2rm

Rene

[Pype.Clicker]

did you checked the FAQ doesn't tell you what's wrong already ?

[Solar]

Between two beers and calling it an early night:

• [tt].code16[/tt] once at the beginning of the code is sufficient;
• mixing [tt].code16[/tt] and [tt]%edi[/tt] smells fishy;
• if I see it correctly you jump to setup_environment first thing, which calls fdc_load_floppy... without setting up %ss and %sp?
• fdc_load_floppy goes ahead and does INT 13h stuff, before you set up e.g. %es?
• only after return from fdc_load_floppy (i.e., first use of stack) does the stack get configured?

I stopped there, because it's very fishy at that point already.

[RetainSoftware]

I agree that the beginning is rather fishy but it works on all the machines i tried. Every single one runs until the 'P' is displayed meaning that protectedmode is enabled correctly. however it fails at the 'kernel' call or switching back to real mode, but i'll investigate it further.

The .code16 & .code32 are indeed redundant but are just there to let me know witch part is code16 or code32.

Rene

PS. Anyone of you have code for switching between protected and real mode.

[Solar]

I agree that the beginning is rather fishy but it works on all the machines i tried.

No it doesn't, or you wouldn't have started this thread. Emulators aren't "machines", they are merely approximations of them. (For example, Bochs initializes memory to zero, which makes uninitialized reads behave predictably. Real HW doesn't -> unpredictable behaviour.)

Making [tt]call[/tt]s before stack segment and stack pointer are set to defined values is a capital offense, in my book.

You are calling INT 13h, AX=0x02 (Read Sector(s) Into Memory). That expects ES:BX to point to the data buffer. At that point, ES has not yet been initialized. Chances are that it's zero on Bochs, and undefined on real hardware.

That Bochs and qemu are actually displaying a "P" doesn't mean your code is correct.

You're deep in "undefined" country there. As my C64 used to say, "REDO FROM START".

[RetainSoftware]

I removed the 'call kernel' statement and then it seems to work on my 3 computers. But indeeded the code is rather fishy so i indeed like the statement "REDO FROM START". So i'll rewrite it *sigh*.

Thanks for the pointers.

Rene

[Solar]

While we're talking of pointers, do visit the FAQ. There's stuff like the BabyStep tutorial that can be very helpful during the first few steps.

[RetainSoftware]

solved ;D

I've fixed the problem by rewriting the whole stuff.

The program does the following:
- Switch to 16 bit protected mode to load 2nd part of the boot loader.
- Switch to 32 bit protected mode to copy 0xC0000..0xFFFFF to 0x10000..0x4FFFF.
- Switch to realmode to store 0x10000..0x4FFFF on disk in sector 36..547.

In short this will store your BIOS on disk, though not all bioses. I 'm using this dump to test my parser which will be capable of detecting ACPI, SMBIOS, VBE3+, BIOS32, MP structures.

If you wish to help me run this floppy image on your system and send me the resulting floppy image (zipped).

[email protected]

i'll only use the image for information parsing. Not for reverse engineering and disassembling as that is in many cases prohibited (read illegal).

Greets,

Rene