All of lore.kernel.org
 help / color / mirror / Atom feed
* Contribution: a file loading module
@ 2011-06-17 16:11 Pierre-Nicolas Clauss
  2011-06-23 15:42 ` Vladimir 'φ-coder/phcoder' Serbinenko
  0 siblings, 1 reply; 13+ messages in thread
From: Pierre-Nicolas Clauss @ 2011-06-17 16:11 UTC (permalink / raw)
  To: grub-devel

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hi folks,

I subscribed to this list in order to share with you a humble
contribution of mine to grub.

As an OS developer enthusiastic, I needed to load a file to memory at
a given specific address.
No command in grub 1.99 was fitting my needs (as my file as no
semantic known to grub: it's not a module, it's not an initrd, it's
not a multiboot kernel either), so I developed my own module.

Please find included the source code of this module. For now, I've
added a copyright notice with my name and a mention to the GPLv3, but
I'm willing to share the source under GPLv3+ and/or hand over my
copyright rights to the GNU project if needed.
Also note that I wrote this module based on what I understand from
grub after reading its source, so please forgive me if I used the
wrong method.

Cheers,

Pierre-Nicolas "pini" Clauss

[-- Attachment #2: loadfile.c --]
[-- Type: text/x-csrc, Size: 3962 bytes --]

/* loadfile.c - file loading module
 * Copyright (C) 2011  Pierre-Nicolas Clauss
 *
 * Loadfile is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 3 as
 * published by the Free Software Foundation.
 *
 * Loadfile is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with Loadfile.  If not, see <http://www.gnu.org/licenses/>.
 */

/*
 *  GRUB  --  GRand Unified Bootloader
 *  Copyright (C) 2003,2007  Free Software Foundation, Inc.
 *  Copyright (C) 2003  NIIBE Yutaka <gniibe@m17n.org>
 *
 *  GRUB is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  GRUB is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
 */

#include <grub/dl.h>
#include <grub/err.h>
#include <grub/extcmd.h>
#include <grub/file.h>
#include <grub/i18n.h>
#include <grub/misc.h>
#include <grub/relocator.h>
#include <grub/types.h>

GRUB_MOD_LICENSE("GPLv3");

static struct grub_relocator* rel;

static grub_extcmd_t cmd;

static const struct grub_arg_option options[] = {
   {"skip", 's', 0, N_("Skip offset bytes from file."), 0, ARG_TYPE_INT},
   {0, 0, 0, 0, 0, 0}
};

static grub_err_t
grub_cmd_loadfile(grub_extcmd_context_t ctxt, int argc, char** argv) {
  struct grub_arg_list* state = ctxt->state;
  grub_file_t file;
  grub_relocator_chunk_t chunk;
  char* dest;
  grub_off_t skip, size;
  grub_ssize_t done;

  if(argc != 2) {
    return grub_error(GRUB_ERR_BAD_ARGUMENT,
                      "file name and memory address required");
  }
  skip = (grub_off_t)(state[0].set ? grub_strtoull(state[0].arg, 0, 0) : 0);
  file = grub_file_open(argv[0]);
  if(!file) {
    return grub_errno;
  }
  size = grub_file_size(file);
  if(size == GRUB_FILE_SIZE_UNKNOWN) {
    return grub_error(GRUB_ERR_FILE_READ_ERROR,
                      "could not determine size of %s", argv[0]);
  }
  if(skip >= size) {
    return grub_error(GRUB_ERR_BAD_ARGUMENT,
                      "cannot skip %llu bytes, file is only %llu", skip, size);
  }
  if(grub_relocator_alloc_chunk_addr(rel, &chunk,
       (grub_phys_addr_t)grub_strtoull(argv[1], 0, 0), size)) {
    return grub_errno;
  }
  dest = get_virtual_current_address(chunk);
  if(skip > 0) {
    grub_printf("Skipping %llu bytes from %s...\n", skip, argv[0]);
    size -= skip;
    if(grub_file_seekable(file)) {
      grub_file_seek(file, skip);
    } else while(skip > 0 && (done = grub_file_read(file, dest, skip)) > 0) {
      skip -= done;
    }
  }
  grub_printf("Loading %llu bytes from %s to %p...\n", size, argv[0], dest);
  while(size > 0 && (done = grub_file_read(file, dest, size)) > 0) {
    dest += done;
    size -= done;
  }
  grub_file_close(file);
  if(size > 0) {
    return grub_error(GRUB_ERR_FILE_READ_ERROR,
                      "early stop while reading %s: %llu bytes missing",
                      argv[0], size);
  }
  return 0;
}

GRUB_MOD_INIT(loadfile) {
  rel = grub_relocator_new();
  cmd = grub_register_extcmd("loadfile", grub_cmd_loadfile, 0,
                             N_("[OPTIONS] FILE ADDR"),
                             N_("Load a file to memory."), options);
}

GRUB_MOD_FINI(loadfile) {
  grub_unregister_extcmd(cmd);
  grub_relocator_unload(rel);
}

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-17 16:11 Contribution: a file loading module Pierre-Nicolas Clauss
@ 2011-06-23 15:42 ` Vladimir 'φ-coder/phcoder' Serbinenko
  2011-06-23 19:41   ` Pierre-Nicolas Clauss
  2011-06-25  2:24   ` Graeme Russ
  0 siblings, 2 replies; 13+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2011-06-23 15:42 UTC (permalink / raw)
  To: grub-devel

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

On 17.06.2011 18:11, Pierre-Nicolas Clauss wrote:
> Hi folks,
>
> I subscribed to this list in order to share with you a humble
> contribution of mine to grub.
>
> As an OS developer enthusiastic, I needed to load a file to memory at
> a given specific address.
While such a functionality would be a toy for loader developpers, it's
completely useless for the end users. If the user has to know any single
address or any single address figures in grub.cfg it's automatically a
bad design. Also while it would be possible to write a loader in scripts
using such kind of commands it's simply a wrong place for it. Loaders
have to be written in C. Also people who really need such kind of
functionality (devs) can quickly add such a kludge to the loader they
are currently developping. As for the user the syntax has to be sth like
loader_name <file> <args>
This allows for a much higher flexibility, portability and future-proof.
> No command in grub 1.99 was fitting my needs (as my file as no
> semantic known to grub: it's not a module, it's not an initrd, it's
> not a multiboot kernel either), so I developed my own module.
>
What is it then? I'm willing to consider adding new loading as long as
they are sane and make sense.
> Please find included the source code of this module. For now, I've
> added a copyright notice with my name and a mention to the GPLv3, but
> I'm willing to share the source under GPLv3+ and/or hand over my
> copyright rights to the GNU project if needed.
> Also note that I wrote this module based on what I understand from
> grub after reading its source, so please forgive me if I used the
> wrong method.
>
> Cheers,
>
> Pierre-Nicolas "pini" Clauss
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-23 15:42 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2011-06-23 19:41   ` Pierre-Nicolas Clauss
  2011-06-23 19:57     ` Vladimir 'φ-coder/phcoder' Serbinenko
  2011-06-25  2:24   ` Graeme Russ
  1 sibling, 1 reply; 13+ messages in thread
From: Pierre-Nicolas Clauss @ 2011-06-23 19:41 UTC (permalink / raw)
  To: The development of GNU GRUB

Hi,

2011/6/23 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> As an OS developer enthusiastic, I needed to load a file to memory at
>> a given specific address.
> While such a functionality would be a toy for loader developpers, it's
> completely useless for the end users. If the user has to know any single
> address or any single address figures in grub.cfg it's automatically a
> bad design. Also while it would be possible to write a loader in scripts
> using such kind of commands it's simply a wrong place for it. Loaders
> have to be written in C. Also people who really need such kind of
> functionality (devs) can quickly add such a kludge to the loader they
> are currently developping. As for the user the syntax has to be sth like
> loader_name <file> <args>
> This allows for a much higher flexibility, portability and future-proof.

Ok, I understand your point regarding end-users (which have absolutely
no need for this kind of module).

My use of it is not to write a loader in script: this module is my
loader in its own right.
For now, I'm using it to load my kernel at 1MB and use a chainloader
of mine to jump to it (and do some other things before).

But I agree it'd be better to wrap everything into a single loader command.

>> No command in grub 1.99 was fitting my needs (as my file as no
>> semantic known to grub: it's not a module, it's not an initrd, it's
>> not a multiboot kernel either), so I developed my own module.
>>
> What is it then? I'm willing to consider adding new loading as long as
> they are sane and make sense.

Basically, I wanted to have a small chainloader of mine to load my kernel.
IIRC, I cannot use both the 'kernel' and 'chainloader' commands
together, so I just skipped using a multiboot compliant kernel and
have the chainloader to jump at a given address (1MB).
This module is only intended to load the kernel at this expected
address, so I only rely on the 'chainloader' command.

But again, I'll try to make the whole thing a clean loader.
If I come up with such a loader, do you consider it could be eligible
for inclusion in grub ? Maybe maintaining the loaders for all the
kernel formats of hobbyist like me is not what you wish for...

Anyway, thanks for your lights,

-- 
pini


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-23 19:41   ` Pierre-Nicolas Clauss
@ 2011-06-23 19:57     ` Vladimir 'φ-coder/phcoder' Serbinenko
  2011-06-23 21:45       ` Pierre-Nicolas Clauss
  0 siblings, 1 reply; 13+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2011-06-23 19:57 UTC (permalink / raw)
  To: grub-devel

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

On 23.06.2011 21:41, Pierre-Nicolas Clauss wrote:
> Basically, I wanted to have a small chainloader of mine to load my kernel.
> IIRC, I cannot use both the 'kernel' and 'chainloader' commands
> together, so I just skipped using a multiboot compliant kernel and
> have the chainloader to jump at a given address (1MB).
> This module is only intended to load the kernel at this expected
> address, so I only rely on the 'chainloader' command.
>
You need to just add a small header to make this kernel
multiboot-compliant (read multiboot header and multiboot kludge)
> But again, I'll try to make the whole thing a clean loader.
> If I come up with such a loader, do you consider it could be eligible
> for inclusion in grub ? Maybe maintaining the loaders for all the
> kernel formats of hobbyist like me is not what you wish for...
Nope. We won't maintain loaders for a single system which will always
stay extremely minor (if your OS becomes major it can be reconsidered).

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-23 19:57     ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2011-06-23 21:45       ` Pierre-Nicolas Clauss
  2011-06-23 22:01         ` Vladimir 'φ-coder/phcoder' Serbinenko
  0 siblings, 1 reply; 13+ messages in thread
From: Pierre-Nicolas Clauss @ 2011-06-23 21:45 UTC (permalink / raw)
  To: The development of GNU GRUB

> You need to just add a small header to make this kernel
> multiboot-compliant (read multiboot header and multiboot kludge)

I know, but I have to give up my chainloader if I want to use a
multiboot kernel.

> Nope. We won't maintain loaders for a single system which will always
> stay extremely minor (if your OS becomes major it can be reconsidered).

That's perfectly understandable, so I'll maintain the loader on my side.

Cheers,

-- 
pini


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-23 21:45       ` Pierre-Nicolas Clauss
@ 2011-06-23 22:01         ` Vladimir 'φ-coder/phcoder' Serbinenko
  2011-06-24  9:33           ` Pierre-Nicolas Clauss
  0 siblings, 1 reply; 13+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2011-06-23 22:01 UTC (permalink / raw)
  To: grub-devel

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

On 23.06.2011 23:45, Pierre-Nicolas Clauss wrote:
>> You need to just add a small header to make this kernel
>> multiboot-compliant (read multiboot header and multiboot kludge)
> I know, but I have to give up my chainloader if I want to use a
> multiboot kernel.
Why? Multiboot specification specifically allows the files to be
multi-standard (an example is netbsd). You can add the header anywhere
in the first 8K and this shouldn't affect your own protocol.
>> Nope. We won't maintain loaders for a single system which will always
>> stay extremely minor (if your OS becomes major it can be reconsidered).
> That's perfectly understandable, so I'll maintain the loader on my side.
>
> Cheers,
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-23 22:01         ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2011-06-24  9:33           ` Pierre-Nicolas Clauss
  2011-06-24 10:36             ` Vladimir 'φ-coder/phcoder' Serbinenko
  2011-06-24 11:31             ` Brendan Trotter
  0 siblings, 2 replies; 13+ messages in thread
From: Pierre-Nicolas Clauss @ 2011-06-24  9:33 UTC (permalink / raw)
  To: The development of GNU GRUB

2011/6/24 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> On 23.06.2011 23:45, Pierre-Nicolas Clauss wrote:
>>> You need to just add a small header to make this kernel
>>> multiboot-compliant (read multiboot header and multiboot kludge)
>> I know, but I have to give up my chainloader if I want to use a
>> multiboot kernel.
> Why? Multiboot specification specifically allows the files to be
> multi-standard (an example is netbsd). You can add the header anywhere
> in the first 8K and this shouldn't affect your own protocol.

Are you saying that :

kernel /my_multiboot_kernel
chainloader /my_chainloader
boot

will load the kernel as per the multiboot header and then call the chainloader ?
does grub guarantee that the kernel will be kept in memory ?

Regards,

-- 
pini


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-24  9:33           ` Pierre-Nicolas Clauss
@ 2011-06-24 10:36             ` Vladimir 'φ-coder/phcoder' Serbinenko
  2011-06-24 11:31             ` Brendan Trotter
  1 sibling, 0 replies; 13+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2011-06-24 10:36 UTC (permalink / raw)
  To: grub-devel

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On 24.06.2011 11:33, Pierre-Nicolas Clauss wrote:
> 2011/6/24 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> On 23.06.2011 23:45, Pierre-Nicolas Clauss wrote:
>>>> You need to just add a small header to make this kernel
>>>> multiboot-compliant (read multiboot header and multiboot kludge)
>>> I know, but I have to give up my chainloader if I want to use a
>>> multiboot kernel.
>> Why? Multiboot specification specifically allows the files to be
>> multi-standard (an example is netbsd). You can add the header anywhere
>> in the first 8K and this shouldn't affect your own protocol.
> Are you saying that :
>
> kernel /my_multiboot_kernel
> chainloader /my_chainloader
> boot
>
> will load the kernel as per the multiboot header and then call the chainloader ?
> does grub guarantee that the kernel will be kept in memory ?
>
No, I'm saying that multiboot and another protocol are not mutually
exclusive. (and grub2 has no "kernel" command)
> Regards,
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-24  9:33           ` Pierre-Nicolas Clauss
  2011-06-24 10:36             ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2011-06-24 11:31             ` Brendan Trotter
  1 sibling, 0 replies; 13+ messages in thread
From: Brendan Trotter @ 2011-06-24 11:31 UTC (permalink / raw)
  To: The development of GNU GRUB

Hi,

Note: I am me. I speak on behalf of myself only, and don't represent
the views of the GRUB team in any way.

On Fri, Jun 24, 2011 at 7:03 PM, Pierre-Nicolas Clauss
<pini@tuxfamily.org> wrote:
> Are you saying that :
>
> kernel /my_multiboot_kernel
> chainloader /my_chainloader
> boot
>
> will load the kernel as per the multiboot header and then call the chainloader ?
> does grub guarantee that the kernel will be kept in memory ?

The terminology GRUB uses is very misleading. What they call "kernel"
really means "the module that the boot loader should pass control to",
and it does not need to be a kernel as such. The "kernel" may just be
a layer that sets things up for the real kernel, where the real kernel
is loaded by GRUB as a module (or possibly not loaded by GRUB at all).

For example, if your chainloader is happy to relocate itself and then
copy the real kernel to 0x00100000, then you might do:

kernel /boot/my_chainloader
module /boot/my_kernel
boot

Otherwise, if you want to keep your chainloader "as is" for other
reasons, then you might want an extra layer ("thunk code") to set
things up in the state your chainloader expects (e.g. relocate things,
potentially switch CPU modes, etc):

kernel /boot/my_thunk_code
module /boot/my_chainloader
module /boot/my_kernel
boot

In GRUB, "chainloading" is chainloading in the old MBR partition way -
e.g. loading a 512-byte boot sector from the start of a partition and
passing control to it (in real mode). GRUB can't pass control to a
512-byte boot sector while also passing control to "the module that
the boot loader should pass control to" (what GRUB incorrectly calls
"kernel") - it simply doesn't make sense.

If your chainloader actually is an old MBR partition style
chainloader, then you're not really using GRUB at all (you're using
the de facto boot method that's been standard for about 30 years,
which GRUB and just about every other boot manager for "80x86 PC BIOS"
happens to support).If your chainloader isn't an old MBR partition
style chainloader, then you should call it something different to
avoid confusion (maybe "<your OS name> stage 1".or something).



Cheers,

Brendan


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-23 15:42 ` Vladimir 'φ-coder/phcoder' Serbinenko
  2011-06-23 19:41   ` Pierre-Nicolas Clauss
@ 2011-06-25  2:24   ` Graeme Russ
  2011-06-25  3:23     ` Vladimir 'φ-coder/phcoder' Serbinenko
  1 sibling, 1 reply; 13+ messages in thread
From: Graeme Russ @ 2011-06-25  2:24 UTC (permalink / raw)
  To: The development of GNU GRUB
  Cc: Vladimir 'φ-coder/phcoder' Serbinenko,
	Pierre-Nicolas Clauss

On 24/06/11 01:42, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 17.06.2011 18:11, Pierre-Nicolas Clauss wrote:
>> Hi folks,
>>
>> I subscribed to this list in order to share with you a humble
>> contribution of mine to grub.
>>
>> As an OS developer enthusiastic, I needed to load a file to memory at
>> a given specific address.

I also have such a requirement - I am developing U-Boot for x86 systems and
I have real trouble getting documentation for the SDRAM initialisation
code. I figured I could leave that to BIOS for the time being and use GRUB
to load my U-Boot image into memory. This way, I do not have to flash the
BIOS chip until very late in the development cycle.

> While such a functionality would be a toy for loader developpers, it's
> completely useless for the end users. If the user has to know any single
> address or any single address figures in grub.cfg it's automatically a
> bad design. Also while it would be possible to write a loader in scripts
> using such kind of commands it's simply a wrong place for it. Loaders
> have to be written in C. Also people who really need such kind of
> functionality (devs) can quickly add such a kludge to the loader they
> are currently developping. As for the user the syntax has to be sth like
> loader_name <file> <args>

Well, I now have GRUB2 installed on a USB pen drive and have it run
memtestx86+. So from here I would like it to be a simple matter of copying
the U-Boot binary onto the USB pen drive and adding an entry in the
grub.cfg file - But I need the 'raw image loader' module to do this

> This allows for a much higher flexibility, portability and future-proof.
>> No command in grub 1.99 was fitting my needs (as my file as no
>> semantic known to grub: it's not a module, it's not an initrd, it's
>> not a multiboot kernel either), so I developed my own module.
>>
> What is it then? I'm willing to consider adding new loading as long as
> they are sane and make sense.

I think a command like:

exec_file file load_address [execute_address]

would fit my needs perfectly. The U-Boot images are raw (not ELF) with a
32-bit entry point at the first byte of the file but this may change (I may
put the version string at the start of the file) so the optional
execute_address could come in handy.

Regards,

Graeme


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-25  2:24   ` Graeme Russ
@ 2011-06-25  3:23     ` Vladimir 'φ-coder/phcoder' Serbinenko
  2011-06-25  3:35       ` Graeme Russ
  0 siblings, 1 reply; 13+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2011-06-25  3:23 UTC (permalink / raw)
  To: Graeme Russ; +Cc: The development of GNU GRUB, Pierre-Nicolas Clauss

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

On 25.06.2011 04:24, Graeme Russ wrote:
> would fit my needs perfectly. The U-Boot images are raw (not ELF) with a
> 32-bit entry point at the first byte of the file but this may change (I may
> put the version string at the start of the file) so the optional
> execute_address could come in handy.
This is perfectly accomodated by multiboot specification. Just add a
small structure somewhere in the first 8K of the file and your image is
multiboot-compliant.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-25  3:23     ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2011-06-25  3:35       ` Graeme Russ
  2011-06-25  3:54         ` Vladimir 'φ-coder/phcoder' Serbinenko
  0 siblings, 1 reply; 13+ messages in thread
From: Graeme Russ @ 2011-06-25  3:35 UTC (permalink / raw)
  To: Vladimir 'φ-coder/phcoder' Serbinenko
  Cc: The development of GNU GRUB, Pierre-Nicolas Clauss

Hi Vladimir,

On 25/06/11 13:23, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> This is perfectly accomodated by multiboot specification. Just add a
> small structure somewhere in the first 8K of the file and your image is
> multiboot-compliant.

Thanks for the advice, but I have a few questions (please excuse any that
appear really 'newby')

 - What GRUB command(s) would I use to load & run the image
 - How do I specify where in memory the file is loaded?
 - Is there a 'quick and dirty' document on how to create a multiboot
   header which GRUB can load?

Regards,

Graeme


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Contribution: a file loading module
  2011-06-25  3:35       ` Graeme Russ
@ 2011-06-25  3:54         ` Vladimir 'φ-coder/phcoder' Serbinenko
  0 siblings, 0 replies; 13+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2011-06-25  3:54 UTC (permalink / raw)
  To: Graeme Russ; +Cc: The development of GNU GRUB, Pierre-Nicolas Clauss

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

On 25.06.2011 05:35, Graeme Russ wrote:
> Hi Vladimir,
>
> On 25/06/11 13:23, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> This is perfectly accomodated by multiboot specification. Just add a
>> small structure somewhere in the first 8K of the file and your image is
>> multiboot-compliant.
> Thanks for the advice, but I have a few questions (please excuse any that
> appear really 'newby')
>
>  - What GRUB command(s) would I use to load & run the image
multiboot+boot
>  - How do I specify where in memory the file is loaded?
It's part of this structure.
>  - Is there a 'quick and dirty' document on how to create a multiboot
>    header which GRUB can load?
>
http://bzr.savannah.gnu.org/lh/grub/trunk/multiboot/annotate/head:/doc/multiboot.texi

"Multiboot header must be contained completely within the first 8192
bytes of the OS image, and must be longword (32-bit) aligned."
In short your header should be (little-endian uint32_t):

/* magic */ 0x1BADB002,

/* flags */ 0x00010000,

/* checksum */ 0xe4514ffe,

header_offset+load_addr,
load_addr,
0,
0,
entry_addr


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2011-06-25  3:54 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-17 16:11 Contribution: a file loading module Pierre-Nicolas Clauss
2011-06-23 15:42 ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-06-23 19:41   ` Pierre-Nicolas Clauss
2011-06-23 19:57     ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-06-23 21:45       ` Pierre-Nicolas Clauss
2011-06-23 22:01         ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-06-24  9:33           ` Pierre-Nicolas Clauss
2011-06-24 10:36             ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-06-24 11:31             ` Brendan Trotter
2011-06-25  2:24   ` Graeme Russ
2011-06-25  3:23     ` Vladimir 'φ-coder/phcoder' Serbinenko
2011-06-25  3:35       ` Graeme Russ
2011-06-25  3:54         ` Vladimir 'φ-coder/phcoder' Serbinenko

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.