GRUB problem

[Jeko]

I've some problems about getting some multiboot informations from GRUB...
This is my menu.lst:

Code: Select all

timeout=5

title Jeko

root (fd0)

kernel /system/kernel.bin root=fdc0
module /system/drv/fdc.drv

I've the first 4MB identity mapped. I can read the memory:

Code: Select all

extern struct multiboot_info_t *bootinfo;

physical_memory = (bootinfo->mem_upper) * 1024;

But I can't know the cmdline:

Code: Select all

char *cmdline = (char*)(bootinfo->cmdline);

printk("Kernel cmdline: %s at 0x%x\n", cmdline, cmdline);

In fact, this code gives me:

Code: Select all

Kernel cmdline: ! at 0x2000

And this code:

Code: Select all

struct multiboot_module *mods = (struct multiboot_module*)(bootinfo->mods_addr);
printk("Mods count: %d\n", mods_count);

printk("Mods addr: 0x%x\n", mods);

printk("mods[0].string: %s at 0x%x\n", (char*)(mods[0].string), (char*)(mods[0].string));

Gives:

Code: Select all

Mods count: 1
Mods addr: 0x22F00
mods[0].string: a at 0x2019

The mods count is correct, but mods[0].string isn't.

Why these informations are incorrect?

[jal]

Why these informations are incorrect?

Assuming the other values (e.g. start address, module count) are correct, and it is just the strings that seem bad, the only thing I can think off is that your kprintf %s implementation is bugged. Try printing the string character by character, and see what that yields.


JAL

[Jeko]

Why these informations are incorrect?

Assuming the other values (e.g. start address, module count) are correct, and it is just the strings that seem bad, the only thing I can think off is that your kprintf %s implementation is bugged. Try printing the string character by character, and see what that yields.


JAL

It's incorrect also if I print character by character...

However module count, memory info, are simple variables, instead mods strings and cmdline are pointers to other memory locations, maybe there is some memory issue? But the addresses are below 4MB, and I've identity mapped the first 4MB...

[cr2]

Where did you get bootinfo from? EBX or the stack?

[Jeko]

Where did you get bootinfo from? EBX or the stack?

A third method:

Code: Select all

; // Kernel virtual start address.

#define K_VIR_START	0xC0000000


; // Kernel physical start address.

#define K_PHYS_START	0x100000
; // Address adjustement.

#define ADDRADJUST	(K_VIR_START-K_PHYS_START)

.global bootinfo

.align 4

	bootinfo: .long	0

entry:
	...
	...
	...
	; // Save multiboot structure pointer.

	movl	%ebx, (bootinfo-ADDRADJUST)

Some parts are cutted off.

In C I use the global variable bootinfo (extern struct multiboot_info_t *bootinfo)

[CodeCat]

Did you check the flags first to make sure that the command line field is actually valid?

[Jeko]

Did you check the flags first to make sure that the command line field is actually valid?

Yes:

Code: Select all

if(bootinfo->flags & 2)
        ...

[mystran]

You also haven't allocated the relevant pages to other purposes and filled 'em with other stuff before you read the command line?

[Jeko]

You also haven't allocated the relevant pages to other purposes and filled 'em with other stuff before you read the command line?

Ah, I've find! This is in my start32 routine:

Code: Select all

; // Page directory.

#define K_PDE		0x1000

; // Kernel page table #0 (4MB).

#define K_PTE		0x2000

; // First 4MB Identity-map page table.

#define I_PTE		0x3000

So, the kernel page table is on the address of the cmdline...
Now I have:

Code: Select all

; // Page directory.

#define K_PDE		0x3000

; // Kernel page table #0 (4MB).

#define K_PTE		0x4000

; // First 4MB Identity-map page table.

#define I_PTE		0x5000

But, how can I be sure of which memory locations aren't used by GRUB?

[mystran]

Why not put the page tables just as 4096 bytes aligned, 4096 bytes big objects into .bss section? At least ELF has no problems with such variables, and GRUB will happily honor your request, taking care of not overwriting your cmdline.

edit: brain bug fixed