All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Access to PCI Expansion ROMs on PPC
Date: Mon, 26 Nov 2007 07:20:00 +1100	[thread overview]
Message-ID: <1196022000.7195.70.camel@pasglop> (raw)
In-Reply-To: <9e4733910711250530r454c01ecoe8867a7f492b8704@mail.gmail.com>


On Sun, 2007-11-25 at 08:30 -0500, Jon Smirl wrote:
> 
> > The two cards with x86 firmware return 0xFF for those two readb()
> > instructions, while the X1900 with OF returns 0x00 for the readb().
> >
> > Could one of the more knowledgeable folk for PPC intricacies suggest
> why
> > those readb calls are returning the wrong data?
> 
> I don't know PPC at this low of level but it may be a problem with non
> word-aligned access to memory. I thought readb() was supposed to work
> on all archs and alignment issues are handled inside readb(). Also,
> the readw() may have an endian bug.

Ugh ? Read be reads -bytes- ! Can you tell me how the hell can a byte
access be non-aligned ?


> BenH, has source code for an x86 emulator that will run on PPC. That
> will let you run the ROMs. The original plan was for the kernel to
> generate a uevent that would have triggered the x86 emulator to run.
> 
> Progress along that path was blocked by the X developers. The X server
> contains code for enabling the PCI ROM and reading it from user space.
> I wanted to move this code out of X and into the kernel.
> 
> Because the path was blocked things like the PCI ROM API were never
> throughly tested. It works most of the time but the occasional problem
> is still turning up. Once we identify the PPC problem we can fix it in
> the kernel.

Nobody blocked anything, you are free to develop an emulator triggered
by a uevent, nobody prevented you from doing so.

Now, regarding that user problem, this it totally unrelated as it's a
"mac" card.

It's possible that it's one of these radeons that disable ROM access via
a register in which case a quirk is needed to re-enable it.

Ben.

  parent reply	other threads:[~2007-11-25 20:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-25  1:57 Access to PCI Expansion ROMs on PPC Robin H. Johnson
2007-11-25  2:13 ` Jon Smirl
2007-11-25 11:15   ` Robin H. Johnson
2007-11-25 11:49     ` Robin H. Johnson
2007-11-25 13:30       ` Jon Smirl
2007-11-25 19:41         ` Robin H. Johnson
2007-11-26  8:59           ` Robin H. Johnson
2007-11-26  9:20             ` Michel Dänzer
2007-11-26 10:24               ` Robin H. Johnson
2007-11-26 16:33                 ` Jon Smirl
2007-11-26 17:35                   ` Robin H. Johnson
2007-11-25 20:20         ` Benjamin Herrenschmidt [this message]
2007-11-25 20:51           ` Jon Smirl
2007-11-25 20:54             ` Benjamin Herrenschmidt
2007-11-25 21:24           ` Jon Smirl
2007-11-25 21:34             ` Benjamin Herrenschmidt
2007-11-25  9:42 ` Andreas Schwab
2007-11-25  9:58   ` Robin H. Johnson

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=1196022000.7195.70.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=jonsmirl@gmail.com \
    --cc=linuxppc-dev@ozlabs.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.