All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Gerards <metgerards@student.han.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [ppc patch] grub-mkimage
Date: Fri, 03 Dec 2004 16:10:45 +0000	[thread overview]
Message-ID: <871xe7l5ve.fsf@marco.marco-g.com> (raw)
In-Reply-To: <95B8E280-453E-11D9-A999-000A95A0560C@penguinppc.org> (Hollis Blanchard's message of "Fri, 3 Dec 2004 09:18:28 -0600")

Hollis Blanchard <hollis@penguinppc.org> writes:

>>> It may be possible to place module variables into their own section
>>> containing nothing else, yet still in a LOAD segment.  Then
>>> grub-mkimage
>>> could parse the *section* table (right now it only does segments) and
>>> overwrite the contents of this section to inform the runtime of the
>>> module location. I'm not convinced it's worth the effort.
>>
>> Whatever is the most flexible seems the best to me...
>
> I was aiming for simplicity really... What's the simplest possible way
> we can inform grubof of the location of its modules? :)

The solution with the other LOAD segment sounded the cleanest to me.
The one that assumed it would follow immediately after the rest of GRUB
sounded a bit hard to me.  I mean, can you really rely on such
assumptions?

>> AS Hollis said, I'm working on the relocator for PPC at the moment.
>> It is quite easy, but PPC_REL24 is a bit more complex.  It is used for
>> relative jumps.  That means the module should be loaded close to
>> grubof, which IMHO really sucks...
>
> 24-bit offsets give you a 16 MiB range, is that really a problem?

The modules are loaded into the free memory of grubof.  And grubof is
loaded to where it is linked, IIRC.  So I think that would cause
problems. :)

>> I am now trying to get option 2 to work first (by using black magic to
>> get everything loaded at the right address ;)) and when module loading
>> works for me I will try to make 3 work.
>
> I agree this makes sense. I'm not sure that option 3 will end up being
> necessary, but option 2 is obviously needed.

Right, and it is finished now.  I am quite sure it is required, but we
can test it.

>> Does someone else think I
>> try to do something else, or can someone help a bit somehow?  As you
>> might have noticed I really suck at this stuff and doing it just
>> because no one else does. ;)
>
> I've never seen relocation code before, but if it's still not working
> when I get back I'd be happy to take a look...

Cool.

Thanks,
Marco




  reply	other threads:[~2004-12-03 16:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-03  5:36 [ppc patch] grub-mkimage Hollis Blanchard
2004-12-03 12:50 ` Marco Gerards
2004-12-03 13:49   ` Johan Rydberg
2004-12-03 14:14     ` Marco Gerards
2004-12-03 15:13       ` Johan Rydberg
2004-12-03 15:20         ` Marco Gerards
2004-12-03 16:04           ` Johan Rydberg
2004-12-03 16:13             ` Marco Gerards
2004-12-03 15:18   ` Hollis Blanchard
2004-12-03 16:10     ` Marco Gerards [this message]
2004-12-03 16:45       ` Hollis Blanchard
2004-12-03 16:58         ` Marco Gerards
2004-12-03 17:12       ` Yoshinori K. Okuji
2004-12-03 17:18 ` Yoshinori K. Okuji
2005-01-01 22:42 ` [ppc patch] grub-mkimage and module loading Hollis Blanchard
2005-01-02 13:47   ` Marco Gerards

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=871xe7l5ve.fsf@marco.marco-g.com \
    --to=metgerards@student.han.nl \
    --cc=grub-devel@gnu.org \
    /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.