On Don, 2012-02-16 at 19:02 +1100, Benjamin Herrenschmidt wrote:
On Thu, 2012-02-16 at 08:50 +0100, Michel Dänzer wrote:
The second case with no firmware is a bit more surprising, looks like something bad happened on the PCI express bus or the kernel tried to access something that the card rejected (target abort or PCIe equivalent most likely), thus triggering a PLB error . That could be investigated a bit more.
AFAICT in both cases the immediate problem is the PLB error on first access to VRAM, indicating some kind of problem with ioremap_wc() or generally PCIe device memory access.
I think the problem here is more along the lines of >32-bit physical memory and ttm screwing up the physical addresses before mapping the vram object.
Tony (CC) has some patches to address that part (for use with a 476 which is cache coherent, we got evergreen working on that).
I think he hasn't yet "polished" the patches enough (ie fixed all the drivers for the change in types) but basically, quite a few places in there need to store physical addresses in resource_size_t instead of long's.
I see, thanks.
Anyway after nearly ten years, due a lack in resources, i'm sadly going to suspend the CRUX PPC project and my activism pro free software thus i'm unable to follow these debug. I'll hold on to me the only YDL Powerstation then from the next weeks i'll can only follow trying to help in debug [1] on this specific machine.
[1]http://lists.freedesktop.org/archives/dri-devel/2012-January/018575.html
For that one, I'd try adding some more debugging output to radeon_get_bios() to find out which method it ends up using to retrieve the ROM contents, and why it doesn't look like it's an ATOM BIOS.
Is it an Apple card or an x86 card ? Apple cards don't have the BIOS in the right place unfortunately.
I don't think there ever were any Mac Editions of FireGL cards, and if it wasn't an x86 card, I'd expect different error messages.