All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Cc: Jan Nieuwenhuizen <janneke-list@xs4all.nl>
Subject: Re: Testing on PowerMac G4
Date: Fri, 4 Jan 2008 13:32:24 +0100	[thread overview]
Message-ID: <20080104123224.GA6657@thorin> (raw)
In-Reply-To: <20080103112301.a1rs2lyk0oc8wsws@webmail.spamcop.net>

On Thu, Jan 03, 2008 at 11:23:01AM -0500, Pavel Roskin wrote:
> >Why?  Does the firmware impose this restriction, or is it GRUB itself that
> >gets confused?
> 
> I wish I knew it.  0x7000 is not OK, 0x8000 is OK.  Less granularity  
> makes no sense since the value is aligned at the 0x1000 boundary.

AFAICT, it can only happen in three ways:

  1- The firmware doesn't like GRUB image, and aborts with bogus errors before
  transferring control to GRUB.  You can easily tell this appart by checking
  for early "Welcome to GRUB" message.

  2- The change in layout makes GRUB issue different parameters in its claim
  requests, which the firmware doesn't like.  I'd verify that the change you
  added by setting up this 0x8000 gap propagates as a change in the parameters
  passed to claim requests (grub_ieee1275_claim() invokation), and if this is
  so, try to determine what is it in the claim request that it doesn't like
  (we already work this out mostly by heuristics e.g. see my commit in
  2007-10-07).

  3- Some twisted mind in Apple decided to add a tilt flag that is activated
  under some circumstances and makes claim requests fail afterwards, thereby
  confusing free software developers.  I hope this is not the case :-)

> >Can we make this work per inclusion rather than exclusion?  The names
> >of needed segments are well-known, right?
> 
> Segments don't have names AFAIK.  Sections have names.

Ah, right.  Sorry, I get easily confused about ELF stuff.

> >It might be simpler than this.  If you check what is the code flow between
> >those two:
> >
> >disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
> >kern/disk.c:299: Opening `ide1/disk' failed.
> >
> >that'll give more details.
> 
> There is a possibility that grub_errno remains set to some error.

Well, that's easy to tell appart with some printfs.

One thing that makes me suspicious is the ":0" bit.  We already found two
brands of firmware that have their own way of understanding what :0 means.
Maybe this is the same as GRUB_IEEE1275_FLAG_NO_PARTITION_0 ?

Btw, one thing I find very disturbing about GRUB_IEEE1275_FLAG_NO_PARTITION_0,
is that its description in ieee1275.h says this is an Apple bug, but the code
that is supposed to initialise this flag is only targetted at SmartFirmware.

Now THAT is suspicious :-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)



  reply	other threads:[~2008-01-04 12:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-31  8:12 Testing on PowerMac G4 Pavel Roskin
2007-12-31  8:45 ` Jan Nieuwenhuizen
2007-12-31 22:37   ` Pavel Roskin
2007-12-31 23:34     ` Robert Millan
2008-01-02  6:46       ` Pavel Roskin
2008-01-02 10:32         ` Robert Millan
2008-01-03  8:09           ` Pavel Roskin
2008-01-03 12:11             ` Robert Millan
2008-01-03 15:28               ` Pavel Roskin
2008-01-03 15:57                 ` Robert Millan
2008-01-03 16:23                   ` Pavel Roskin
2008-01-04 12:32                     ` Robert Millan [this message]
2008-01-04 12:54                       ` Robert Millan
2008-01-04 18:26                       ` Pavel Roskin
2008-01-04 20:37                         ` Robert Millan
2008-01-05  1:45                           ` Yoshinori K. Okuji
2008-01-05 11:43                             ` Robert Millan
2008-01-05  2:10                           ` Pavel Roskin
2008-01-05 11:45                             ` Robert Millan
2008-01-05  1:27                 ` Yoshinori K. Okuji
2008-01-05  2:02                   ` Pavel Roskin
2008-01-05 10:31                     ` Yoshinori K. Okuji
2008-01-05 11:46                   ` Robert Millan
2007-12-31 14:04 ` Robert Millan
2007-12-31 22:58   ` Pavel Roskin

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=20080104123224.GA6657@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    --cc=janneke-list@xs4all.nl \
    /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.