[Top][All Lists]

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

Re: Testing on PowerMac G4

From: Robert Millan
Subject: Re: Testing on PowerMac G4
Date: Fri, 4 Jan 2008 13:32:24 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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

  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 via email to

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