From: Goswin von Brederlow <goswin-v-b@web.de>
To: "Vladimir 'Ï-coder/phcoder' Serbinenko" <phcoder@gmail.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>,
Goswin von Brederlow <goswin-v-b@web.de>
Subject: Re: Would a cleanup+extending of docs/multiboot.h be acceptable?
Date: Thu, 07 Apr 2011 19:32:07 +0200 [thread overview]
Message-ID: <87y63motm0.fsf@frosties.localnet> (raw)
In-Reply-To: <4D9DD0CD.5040904@gmail.com> (Vladimir Serbinenko's message of "Thu, 07 Apr 2011 16:57:17 +0200")
"Vladimir 'Ï-coder/phcoder' Serbinenko" <phcoder@gmail.com> writes:
> On 07.04.2011 16:50, Goswin von Brederlow wrote:
>> "Vladimir 'Ãâ -coder/phcoder' Serbinenko" <phcoder@gmail.com> writes:
>>
>>> On 07.04.2011 14:09, Goswin von Brederlow wrote:
>>>> Hi,
>>>>
>>>> I've been working on a 32bit->64bit trampoline based on the example
>>>> kernel that just switches to 64bit mode and executes a real kernel
>>>> passed as module. As real kernel I want to use grubs example kernel as
>>>> well to just verify the multiboot infos passed through the trampoline
>>>> are intact.
>>> Please don't use outdated code as base. Now we work on multiboot2 and
>> I've seen multiboot2 mentioned but I can't find specs for it. What I
>> did find are the "Multiboot Specification version 0.6.96" [1]
>>
>> So where is this multiboot2?
>>
> Latest multiboot1 (cleanups) is at
> http://bzr.savannah.gnu.org/r/grub/trunk/multiboot/
Ok, this is much cleaner than what is in the grub source in Debian already.
Remaining issues:
1) hardcoded bit numbers:
/* Check if the bit BIT in FLAGS is set. */
#define CHECK_FLAG(flags,bit) ((flags) & (1 << (bit)))
...
/* Are mem_* valid? */
if (CHECK_FLAG (mbi->flags, 0))
The multiboot.h does not define the bit numbers, only masks for each
bit. Maybe this could be changed to
In multiboot.h add:
#define MULTIBOOT_INFO_MEMORY_BIT 0
In kernel.c:
/* Check if the bit BIT in FLAGS is set. */
#define CHECK_FLAG(flags,bit) ((flags) & (1 << (MULTIBOOT_INFO_##bit##_BIT)))
...
/* Are mem_* valid? */
if (CHECK_FLAG (mbi->flags, MEMORY))
2) Wrong types
void cmain (unsigned long magic, unsigned long addr);
static void itoa (char *buf, int base, int d);
should be:
void cmain (multiboot_uint32_t magic, multiboot_uint32_t addr);
static void itoa (char *buf, char base, int d);
All occurances of '(unsigned)' should be '(multiboot_uint32_t)'.
3) Could we use 64bit types?
It might be nice to teach printf about '%llx' (or '%q' for quad word)
and add a 64bit itoa. And maybe add a '%p' which would be 64bit in
64bit code and 32bit in 32bit code while '%x' is allways 32bit.
> Multiboot2 is at http://bzr.savannah.gnu.org/r/grub/branches/multiboot2/
I see that you have added 32bit MIPS support. No 64bit x86_64 support
though. So my trampoline + 64bit kernel stuff would still be interesting
to people.
The bigger problem though is the thing doesn't build or work:
1) ./autogen.sh
doc/Makefile.am:2: compiling `kernel.c' with per-target flags requires `AM_PROG_CC_C_O' in `configure.ac'
2) wrong source file
Making all in doc
make[2]: Entering directory `/home/mrvn/t/t/multiboot2/doc'
make[2]: *** No rule to make target `boot_mips.o', needed by `kernel'. Stop.
There is only the boot.S, which is for x86. Fixing that:
3) -m32 missing
gcc -DHAVE_CONFIG_H -I. -I.. -DHAVE_CONFIG_H -I. -I.. -nostdlib -g -O2 -MT boot.o -MD -MP -MF .deps/boot.Tpo -c -o boot.o boot.S
boot.S: Assembler messages:
boot.S:97: Error: invalid instruction suffix for `push'
boot.S:101: Error: invalid instruction suffix for `push'
boot.S:103: Error: invalid instruction suffix for `push'
boot.S:109: Error: invalid instruction suffix for `push'
make[2]: *** [boot.o] Error 1
Note that the CFLAGS aren't used for the assembler file at all.
exporting CC="gcc -m32" to work around this.
4) typos in boot.S
--- doc/boot.S.orig 2011-04-07 18:58:41.000000000 +0200
+++ doc/boot.S 2011-04-07 18:58:59.000000000 +0200
@@ -50,11 +50,11 @@
/* magic */
.long MULTIBOOT2_HEADER_MAGIC
/* ISA: i386 */
- .long GRUB_MULTIBOOT_ARCHITECTURE_I386
+ .long MULTIBOOT_ARCHITECTURE_I386
/* Header length. */
.long multiboot_header_end - multiboot_header
/* checksum */
- .long -(MULTIBOOT2_HEADER_MAGIC + GRUB_MULTIBOOT_ARCHITECTURE_I386 + (multiboot_header_end - multiboot_header))
+ .long -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT_ARCHITECTURE_I386 + (multiboot_header_end - multiboot_header))
#ifndef __ELF__
address_tag_start:
.short MULTIBOOT_HEADER_TAG_ADDRESS
Ok, after all this I get:
% make
gcc -m32 -DHAVE_CONFIG_H -I. -I.. -DHAVE_CONFIG_H -I. -I.. -nostdlib -g -O2 -MT boot.o -MD -MP -MF .deps/boot.Tpo -c -o boot.o boot.S
gcc -m32 -DHAVE_CONFIG_H -I. -I.. -fno-builtin -nostdinc -O -g -Wall -imacros ../config.h -nostdlib -g -O2 -MT kernel-kernel.o -MD -MP -MF .deps/kernel-kernel.Tpo -c -o kernel-kernel.o `test -f 'kernel.c' || echo './'`kernel.c
gcc -m32 -fno-builtin -nostdinc -O -g -Wall -imacros ../config.h -nostdlib -g -O2 -nostdlib -Wl,-N -Wl,-Ttext -Wl,80100000 -Wl,--build-id=none -o kernel boot.o kernel-kernel.o
% file doc/kernel
doc/kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
% kvm -m 64 -kernel doc/kernel
doesn't output anything, doesn't clear the screen.
And here I'm stuck. Everything looks alright.
I thought maybe the extra "-O2" screws something up. So I tried
doc% gcc -m32 -DHAVE_CONFIG_H -I. -I.. -DHAVE_CONFIG_H -I. -I.. -nostdlib -g -O -MT boot.o -MD -MP -MF .deps/boot.Tpo -c -o boot.o boot.S
doc% gcc -m32 -DHAVE_CONFIG_H -I. -I.. -fno-builtin -nostdinc -O -g -Wall -imacros ../config.h -nostdlib -g -O -MT kernel-kernel.o -MD -MP -MF .deps/kernel-kernel.Tpo -c -o kernel-kernel.o `test -f 'kernel.c' || echo './'`kernel.c
doc% gcc -m32 -fno-builtin -nostdinc -O -g -Wall -imacros ../config.h -nostdlib -g -O -nostdlib -Wl,-N -Wl,-Ttext -Wl,80100000 -Wl,--build-id=none -o kernel boot.o kernel-kernel.o
doc% kvm -m 64 -kernel kernel
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support
Failed to allocate memory: Cannot allocate memory
zsh: abort kvm -m 64 -kernel kernel
It tries to allocate -0xE000 byte of memory, which is a few trillion
gazillion byte.
Trying the commands the old multiboot (from your first url) used to
build:
doc% gcc -DHAVE_CONFIG_H -I. -I.. -m32 -nostdlib -fno-builtin -nostdinc -O -g -Wall -imacros ../config.h -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT kernel-boot.o -MD -MP -MF .deps/kernel-boot.Tpo -c -o kernel-boot.o `test -f 'boot.S' || echo './'`boot.S
doc% gcc -DHAVE_CONFIG_H -I. -I.. -m32 -nostdlib -fno-builtin -nostdinc -O -g -Wall -imacros ../config.h -g -O2 -MT kernel-kernel.o -MD -MP -MF .deps/kernel-kernel.Tpo -c -o kernel-kernel.o `test -f 'kernel.c' || echo './'`kernel.c
doc% gcc -g -O2 -m32 -nostdlib -Wl,-N -Wl,-Ttext -Wl,100000 -Wl,--build-id=none -o kernel kernel-boot.o kernel-kernel.o
doc% kvm -m 64 -kernel kernel
doesn't output anything, doesn't clear the screen.
Any idea what is going wrong?
MfG
Goswin
next prev parent reply other threads:[~2011-04-07 17:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-07 12:09 Would a cleanup+extending of docs/multiboot.h be acceptable? Goswin von Brederlow
2011-04-07 12:56 ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-04-07 14:50 ` Goswin von Brederlow
2011-04-07 14:57 ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-04-07 17:32 ` Goswin von Brederlow [this message]
2011-04-07 17:50 ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-04-08 14:43 ` Goswin von Brederlow
2011-04-08 14:53 ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-04-08 17:18 ` Goswin von Brederlow
2011-04-18 19:49 ` Goswin von Brederlow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y63motm0.fsf@frosties.localnet \
--to=goswin-v-b@web.de \
--cc=grub-devel@gnu.org \
--cc=phcoder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.