English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware

 
 
Thread Tools
Old 14 July 2017, 17:10   #1
Hedeon
PPC Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 1,281
Occasional bus error during PCI transfers

Hi all,

I'm currently working on a project where a PPC CPU on the PCI bus (mediator) reads and writes to config registers of a graphics card on the same PCI bus. If I issue a lot of commands through the CPU to the config area of the graphics board the graphic cards locks and after a while a bus error pops up.

I was thinking, could there be a conflict between the PPC CPU and 68K CPU both trying to drive the PCI bus resulting in a lock up?

I know the mediator had a bus master jumper. Can this help?

The code already looks for a sign whether the gfx card is idle before issueing the next commands so it shouldn't be an overflow of commands. If I add delays between the commands issued the system becomes stable. (but slowing it down....)

Any experts who can point me in a right direction?
Hedeon is offline  
Old 14 July 2017, 23:31   #2
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 4,802
The Mediator uses its own little DMA system with the graphics card memory, so some transfers are probably cached and queued to be transferred to the Amiga side. Perhaps you're running foul of issues with that cache between the two CPUs? Just speculation though, I've never coded that sort of hardware combo...
Daedalus is offline  
Old 15 July 2017, 00:25   #3
Stedy
Registered User

Stedy's Avatar
 
Join Date: Jan 2008
Location: United Kingdom
Age: 43
Posts: 677
Hi,

What values do the Base Address Registers (BAR) of the GPU report?
The last nibble denotes if the device supports 32/64 bit, I/O or mem space and importantly cacheable support. Try an eieio command or msync(0) depending on the CPU.

What PPC chip and northbridge or is it custom chip?

The PCI arbiter should stop the PPC and 68K both driving the bus.

When the error occurs, what status is returned by the various PCI devices?

Sorry for so many questions but I don't know enough about your system to go into specifics.
Stedy is offline  
Old 15 July 2017, 05:48   #4
Hedeon
PPC Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 1,281
PPC is MPC750. Northbridge is MPC107.

When the error occurs the whole Amiga halts in such a bad way no status can be retrieved. I need to reset the machine. Even the reset takes a while to get through..

Not sure if eieio is fully supported on the MPC750, btw. I think it is treated as a nop in most cases.

For now, most of the errors are gone as, you guessed it, I made an error in setting up the memory in which the config registers of the GPU were. I set it up to be cache inhibited using a page table, which is correct. But I also set up a BAT which was Write_Through and overlapping the page table setup. And BAT is checked first before page table.

You always find that kind of stuff out moments after you post a question...

So the idle check was actually done on a value in cache.... idle check works correctly now and I have gotten rid of the delays and the test programs now seem to work. So I can now draw triangles and stuff and texture them. I actually use the Warp3D examples of Kas1e from os4coding forum, but compiled for WarpOS.

The more complex programs like gearsppc still don't work (bus error). Have to dig deeper for that, Can be an error in the driver itself also in this case.
Hedeon is offline  
Old 16 July 2017, 00:08   #5
Stedy
Registered User

Stedy's Avatar
 
Join Date: Jan 2008
Location: United Kingdom
Age: 43
Posts: 677
Hi,

@Hedeon

Had not realised you were the guy working on the Sonnet 7200 software.

Have you got the Errata document for the TSI107?

One thing that caught me out on one design, using the MPC8245 (PPC603 + TSI107 in 1 chip) , was issues with DMAs and back to back transfers. Try clearing bit 9 (Fast back to back) of the command register of the target device, in your case, the GPU.

Also try setting bit 0 of the AMBOR register at offset 0xE0, this removes an issue with speculative reads of local memory.

The MPC8245, which has identical registers to the TSI107, has an errata document freely available here:
http://www.nxp.com/docs/en/errata/MPC8245CE.pdf

Good luck.
Stedy is offline  
Old 01 July 2020, 11:47   #6
Hedeon
PPC Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 1,281
In the end I worked around it. It was bad code haha.

But over the years.....I have seen it pop-up occasionally again. Is there also such a thing as a bus time-out? I read somewhere that PCI solutions for the Amiga give a bus time-out (in the shape of a bus error) when addressing slow stuff on the bus (e.g. a ROM from let's say Voodoo or Radeon).

I think the readme of the new FireStorm firmware states something around that lines.
Hedeon is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Occasional Red Screen Kiskstart 3.1 ScottC2010 support.Hardware 7 02 June 2017 02:51
Occasional green/pink tint on A1200 pedrorq support.Hardware 5 30 May 2014 11:22
PC-Amiga-PC transfers Yesideez New to Emulation or Amiga scene 4 21 March 2007 15:15
Prometheus PCI & Voodoo 3 PCI GFX Card Slayer support.Hardware 21 05 September 2006 10:57
PC<> miggy file transfers arizz support.Hardware 3 03 April 2005 01:47

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:43.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.06957 seconds with 15 queries