[Unmoderated] ArticiaS: mystery finaly solved ? | ANN.lu |
Posted on 08-Jul-2004 06:47 GMT by brotheris | 140 comments View flat View list |
Here's the summary of the last posts from hot topic. It may finaly put some dots on I's. Up to now we have heared a lot of small bits from variuos parties and finaly we can put the puzzle together. Read more about it.
I'll play Amon_Re of the past:
It all started when Chris Hogdes started explaining few things (in this thread and @226 comment).
During DMA transfers, the ArticiaS does not flag accessed memory as "dirty", therefore the CPU does not automatically know, that it has to update/flush its caches
Later (@ comment 247, 248 and others) Bernie Meyer explained how such a lack of feature (or call it a bug) affects stability, performance and may cause data corruption even in AmigaOS-like enviroment while using CachePreDMA()/CachePostDMA().
And then we discover quotes from ArticiaS documentation:
"The snoop cycle is used to probe the primary and secondary cache for updated data when the PCI
accesses DRAM. This is done to maintain data coherency between the Floating Buffer, DRAM and both
caches. The Articia S performs the Snoop cycle. When there is a snoop hit on a modified cache line in
either level one or two cache, the contents are written back directly to the Floating Buffer. A PCI Bus
master can subsequently later on fetch the data directly from the Floating Buffer. The Floating Buffer is
flushed back to DRAM during a PCI write cycle. The corresponding line in level one or level two cache is
thus invalidated. Snoops are hidden, meaning the CPU can continue its current data access without
being interrupted while the Articia S simultaneously queries both caches."
You can find similar information using google cache. It seems like some people lied. Is lack of Cache Coherency a bug or a feature (it was advertised that there is Cache Coherency, so it had to work) ? We may now put this case to rest.
|
|
List of all comments to this article |
ArticiaS: mystery finaly solved ? : Comment 77 of 140 | ANN.lu |
Posted by Anonymous on 09-Jul-2004 16:30 GMT | In reply to Comment 73 (Amon_Re): >So basicly, my stance would be that i assume it's not broken, and that the reason >why linux fails is related to the peculiarities of the chip, rather then the chip >being broken.
The chip *IS* broken.
Well, I guess, most of the chipset (CPU, NorthBridge, SouthBridge ...) are more or less broken. But most of the time, I guess it's small issue that can be fixed *easily* in software.
Just have a look to the various Linux drivers, there are always some notes about broken hardware (depending of some revision) and their workaround.
But, the case of the ArticiaS is different:
- no *easy* workaround (fixing all the existing Linux driver is neither easy, nor quick).
- total silence from MAI
- bPlan *fixed* it with the April, but gave up and choose another chipset.
Note, that you can perfectly make a working OS and devices drivers without cache coherency, but then you are back in the 80s...
So I don't clame that the AOne will never work correctly on any OS. Nevertheless, the chipset *IS* broken because it doesn't support HW cache cohenrency as specified in its doc.
Also, their could other issue....
Bye |
|
List of all comments to this article (continued) |
|
- User Menu
-
- About ANN archives
- The ANN archives is powered by #AmigaZeux. It was updated daily (news last: 22-Oct-2004; comments last: 18-May-2005).
ANN.lu was created, previously owned and maintained by Christian Kemp, www.ckemp.com.
- Contribute
- Not possible at this time!
- Search ANN archives
- Advanced search
- Hosting
- ANN.lu was hosted by Dreamhost. Sign up through this link, mention "ckemp" as referrer and he will get a 10% commission on any account you purchase.
Please show your appreciation for any past, present and future work on ANN.lu by making a contribution via PayPal.
|