All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Issues with Linux loading code
Date: Thu, 16 Jun 2011 19:29:18 -0400	[thread overview]
Message-ID: <4DFA91CE.4050803@gmail.com> (raw)
In-Reply-To: <20110616210404.GA26013@srcf.ucam.org>

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

On 16.06.2011 17:04, Matthew Garrett wrote:
> I'm currently handling some issues related to the kernel ending up on 
> top of used EFI regions on some machines. These seem to be exacerbated 
> by some of grub's behaviour. It seems that the kernel will always be 
> loaded at GRUB_LINUX_BZIMAGE_ADDR, which is problematic in two cases - 
> one being that the kernel can be configured with a different start 
> address, and also that the firmware may have put code there that we wish 
> to preserve.
>
> At present it doesn't seem possible to indicate to the relocator that if 
> there isn't enough space for the decompressed kernel (ie, the init_size 
> parameter from the header) at the desired address, it should put the 
> kernel somewhere else making sure to adhere to the alignment constraints 
> the kernel provides. The load address and the alignment then need to be 
> written back into the kernel header.
You would need to add a new argument dont_kill_useless_firmware,
propagate it to EFI and IEEE1275-specific functions and make relocator
ignore the runtime regions if this argument is set. Then if *_addr fails
use *_align.
> Or am I misinterpreting the behaviour of the relocation code?
>


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



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

      reply	other threads:[~2011-06-16 23:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16 21:04 Issues with Linux loading code Matthew Garrett
2011-06-16 23:29 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]

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=4DFA91CE.4050803@gmail.com \
    --to=phcoder@gmail.com \
    --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.