grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ppc patch] grub-mkimage


From: Marco Gerards
Subject: Re: [ppc patch] grub-mkimage
Date: Fri, 03 Dec 2004 12:50:47 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Hollis Blanchard <address@hidden> writes:

> I'm going to be on vacation next week, so I wanted to get this out so
> others could continue progress on PPC module loading... this is not
> ready for inclusion, but it is functional. Comments are welcome.

Nice!  Enjoy your vacation.

> Use the -n/--note switch to add the CHRP NOTE segment on CHRP platforms
> (e.g. briQ and Pegasos). NEVER use this switch on Power Macintosh. I
> guess that should be documented better in the help text, but anyways...

Oh, weird.  For me grubof worked on the PegasosII without doing this.

> 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'm firmly convinced that grub_load_modules(), currently in kern/main.c,
> will need to be changed to a more generic interface. For example, each
> arch could provide its own grub_module_start() and grub_module_end()
> functions. It is no longer a valid assumption that the modules begin
> immediately after grub_end_addr in memory. But for now I will leave that
> to someone (Marco?) doing the real module loading; grub-mkimage just
> needs to get it into memory (which I've verified it does).

Right, I agree.

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...

For some reason my REL24 code does not work, when it does I will send
in a patch.  But there are 3 options we should consider:

- Making sure REL24 should not be used.  This can be done using the
  -mlongcall option.  Still, after using this the module will not work
  when it uses libraries, this is a gcc bug that has been fixed last
  week.  The library that we use is libgcc.  If we choose for
  eliminating all calls to libgcc and if we use -mlongcall the
  relocator will work.  The disadvantage of this solution is that the
  modules will get a bit bigger.

- It is possible to fix the relocator just to use PPC_REL24, but in
  that case the module should be loaded near grubof.

- What linux uses is jumping to some code near the module and that
  code does a long jump into grubof.  This is the hardest solution and
  I don't yet have enough knowledge to do this.

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.  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. ;)

Thanks,
Marco






reply via email to

[Prev in Thread] Current Thread [Next in Thread]