OSDev.org

Hi,
after the launch of QEMU, initializing the ram: I need to know the address of the 'sistema' module.
Which field of the multiboot_info structure contains this address?

I'm not quite sure about QEMU's multiboot implementation (it seems to be a bit faulty, so I recommend GRUB instead of the (albeit convenient) -kernel option), but I would have a look at the modules section of the multiboot structure.

I have to use QEMU because is a project and I can not do otherwise.

standard multiboot is described here:
http://www.gnu.org/software/grub/manual ... iboot.html

A field of the multiboot_info structure should be the address of 'sistema' (ELF format), loaded by -initrd.

XenOS wrote:I'm not quite sure about QEMU's multiboot implementation (it seems to be a bit faulty, so I recommend GRUB instead of the (albeit convenient) -kernel option)

Do you have any specific problems with it? Depending on how hard it turns out I might take a look at fixing it.

Multiboot modules generally work with it, I've often used them myself.

Kevin wrote:Do you have any specific problems with it? Depending on how hard it turns out I might take a look at fixing it.

I hadn't tried it for a while. One thing I remember is that the "upper memory" field in the multiboot info shows the total memory instead of the upper one, i.e., 1 MB too much - at least that's what I thought. But now I tried it again and just saw that it's not 1 MB more, but instead it included the memory used by ACPI in the "upper memory" value (in this case 8 kB more). Instead, GRUB only shows the size of the first free memory block. I don't know which behavior is correct, or whether both are correct. It seems that the spec is not very clear about this, it only mentions the "first memory hole". The problem I encountered with my kernel is that it assumes that the region indicated by the "upper memory" field is completely usable, and uses this a a scratch area before making use of the complete memory map - thereby trashing the ACPI tables.

Just for comparison, the output from my kernel when I boot it with GRUB (or GRUB2, "Base contiguous memory" means upper memory + 1 MB):
And QEMU's -kernel option:
The last entry in the memory map is missing here as well, compared to the one provided by GRUB (which in turn comes from the BIOS).

And what about my problem?

The point was to run a proper bootloader (GRUB) inside qemu instead of relying on a proven broken multiboot implementation. Have you tried that (and the other suggestions) yet?

My project is porting a 32-bit kernel in a 64-bit one. The 32-bit version worked and the 64-bit one too; my problem is just finding the "sistema"'s address.
The bootloader leaves in ebx register the address of multiboot_info structure, so I just to know which its field I need.

boot module
Other auxiliary files that a boot loader loads into memory along with an OS image, but does not interpret in any way other than passing their locations to the operating system when it is invoked.

Do your own homework?

costa90sm wrote:And what about my problem?

You may solve it by actually reading the multiboot spec.

dozniak wrote:

costa90sm wrote:And what about my problem?

You may solve it by actually reading the multiboot spec.

Yes, I did it, but I don't understand which field I need if "sistema" is loaded with -initrd setting

You may continue by reading QEMU manual.

It can either be a multiboot module or linux kernel-specific boot protocol.

XenOS wrote:Just for comparison, the output from my kernel when I boot it with GRUB (or GRUB2, "Base contiguous memory" means upper memory + 1 MB)

Thanks for the detailed explanation. I sent patches [1] for both problems, so hopefully qemu 1.6 will get it right.

[1] http://lists.nongnu.org/archive/html/qe ... 03997.html

Kevin wrote:Thanks for the detailed explanation. I sent patches [1] for both problems, so hopefully qemu 1.6 will get it right.

[1] http://lists.nongnu.org/archive/html/qe ... 03997.html

Great, thanks a lot!